[TLS] oob-pubkey and cached-info

[Paul Wouters <[e-mail]>]

On Thu, 17 Nov 2011, =JeffH wrote:

> Subject: [TLS] raw unofficial minutes: TLS WG:   IETF-82 Taipei

Thanks Jeff!

> --------------------------------------------------
> Hannes T. :  tls out-of-band public key validation
> --------------------------------------------------
> 
> draft-wouters-tls-oob-pubkey-01
> 
> Tero and Hannes are on the author team now since ietf-81 quebec
> 
> "RawPublicKey" -- new cert type in client_hello
> 
> leverages the TLS Cert types registry that RFC 6091 defined
> 
> convey pub key in subjectPublicKeyInfo structure from X.509 cert structures (see also rfc5280)
> 
> don't need to define new ciphersuites -- but need to use approp ciphersuite with type of pubkey that's being exchanged
> 
> dan harkins (dh): why not just send the raw pub key rather than sending a hash of it?
> 
> tero: send hash to keep bytes on wire smaller
> 
> js: it might  be an idea to ressurect the ? work -- that might address the hash thing

That was refering to: http://tools.ietf.org/html/draft-ietf-tls-cached-info

    A new extension type (cached_information(TBD)) is defined and used in
    both the client hello and server hello messages. The extension type
    is specified as follows.

       enum {
            cached_information(TBD), (65535)
       } ExtensionType;


    The extension_data field of this extension, when included in the
    client hello, SHALL contain CachedInformation according to the
    following structure:

       enum {
            certificate_chain(1), trusted_cas(2), (255)
       } CachedInformationType;

Note that the cached-info draft has text that it can only use the
hashes computed from previous TLS sessions, and does currently not allow
calculatng the cached information based on information from other sources,
such as DANE/DNSSEC. I think there might be an interest on these small
devices to also avoid sending this information unhashed on their first
connection. Perhaps the cached-info draft could allow that? (apologies if
I missed previous discussion on this topic)

Note also that if within DANE a sha256 hash is used, it might be more
convenient for the client to use the same hashing algorithm here to
allow for easier strncmp(). However, that does reduce the strength of
the public key to the strength of the hashing algorithm, since in that
case, no full copy of the public key is going over the wire either in DANE
or TLS.

Paul