rfc: verify-ssh

[Nikos Mavrogiannopoulos]

On 01/31/2012 04:24 PM, Daniel Kahn Gillmor wrote:

> On 01/28/2012 08:09 AM, Nikos Mavrogiannopoulos wrote:
>> Hello,
>>  I've added two new functions gnutls_verify_stored_pubkey() and
>> gnutls_store_pubkey() [0], that allow for an SSH-style authentication.
>> That is they allow to trust public keys from certificates associated
>> with a hostname and a service, based on whether they have been seen before.
>> This by itself is not really much, but using it in a hybrid model where
>> certificates are verified using the trusted certificate list _and_ the
>> known public keys, it would increase security overall, as a compromise
>> of a CA would not be enough to perform man-in-the-middle.

Hello Daniel!

> sounds like this is potentially a good toolkit for implementing public
> key pinning, which is currently being discussed on websec:
>  https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

> Is this the intent?  If so, should we consider including expiration
> dates in the format in question, or having a way to store a digest in

> place of the raw pubkey, if we haven't seen the pubkey itself yet?


This wasn't the intent, but being able to support pinning (which looks
like a similar idea) would be nice. 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?).

What I am skeptical of pinning is that it allows the server to modify
the expiration of the pinning at will.

> Can you explain the difference between the intended use of "application"
> and "service" parameters in gnutls_store_pubkey, find_stored_pubkey, and
> gnutls_verify_stored_pubkey ?


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.

> The linear file storage mechanism probably won't scale well for
> implementations that deal with many many such keys over time (e.g. a web
> browser).  Any thoughts about how to offer such a mechanism in a way
> that scales better?


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.

regards,
Nikos