rfc: verify-ssh

[Nikos Mavrogiannopoulos]

On Wed, Feb 1, 2012 at 1:32 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> Hi Nikos--
> On 01/31/2012 06:37 PM, Nikos Mavrogiannopoulos wrote:
>> This wasn't the intent, but being able to support pinning (which looks
>> like a similar idea) would be nice.
> yes, indeed.  perhaps verify-ssh.c is a misleading title for this
> approach?  What you're enabling here isn't specifically for ssh.  it can
> be used to implement a TOFU (trust on first use) scheme, an out-of-band
> key distribution scheme, etc.

Yes. I couldn't figure out a better name though. Is TOFU used as term?

>> Storing hashes though, I don't think
>> it is a good idea. Why would one trust a hash and not the actual public
>> key? If he trusts the hash he could use it to verify the public key and
>> then store it. The issue with hashes is that they might break (e.g. if
>> collisions are found) and replacing stored hashes is a mess, thus I'd
>> try to avoid them (are they really required for pinning?).
> the idea behind identifying keys by their digest instead of the public
> key material is that you can pin your site to two keys (one active, one
> that you keep as an offline backup).  If your hardware dies and you lose
> access to your active key (or if you worry the old key may have been
> compromised), you can re-deploy with your backup immediately, without
> waiting for the pin to expire.
> until we all move to ECDSA keys, shipping two full 2048-bit RSA public
> keys in the header was probably considered a bit too much;  hence using
> the digest.
> So, in particular, storing a digest would be useful for a pinning
> implementation; it would enable the use of verify_stored_pubkey(),
> though obviously find_stored_pubkey wouldn't be possible.

Ok then it might make sense to support storing hashes. It might be on
a different file though to keep things simple.

>> If an application wants to store keys that are specific for that one it
>> could specify an application string. The service I use it currently to
>> specify the port number of the service connecting to.
>
> ah, i got it: "application" is the tool using gnutls, while "service" is
> the network service it is connecting to.
> in Monkeysphere, we haven't bothered with the "application" distinction
> (on the basis that different applications that have entirely distinct
> requirements will want to use an entirely separate key databse from each
> other, while most services offered by a host will just use the common
> system database), and our equivalent of your "service"  is called
> "context", which is more flexibly-defined (and human-visible) than just
> the port number (e.g. "https" or "ssh" or "e-mail").  This allows the
> keyfinding operation to work for more than just network service keys; it
> could work for signed or encrypted e-mail messages, IM conversations,
> etc as well.
> What do you think the tradeoffs are between these approaches?

Do you mean something like passing the output of getservbyport()? (or
services(5) entries).
That is a good idea.

>> I was thinking about it, but it seems it is very simple to implement an
>> alternative approach with a different backend. Thus I am not really sure
>> if a generic approach would be better, or it would provide a complex
>> interface that would be hard to use.
> I like the general outline of the interface you've defined; my main
> concern is the backend storage.  why do you think that a more efficient
> backend-storage mechanism would require a different interface?

No, actually this is not what I thought. It thought you were suggesting to
have an extensible interface for developers to plug their back-end. An efficient
backend such as a database engine would involve an extra library dependency,
which I'd like to avoid, and the text-based approach has the advantage of
being easy to edit without the need of a tool.

Maybe having a hybrid solution of having a default (linearly searched) file,
and allowing for an alternative back-end be a more generic solution. Or do
you have something else/better in mind?

regards,
Nikos