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

From: =JeffH <[email-masked]>
Date: Thu, 17 Nov 2011 03:31:12 -0800

These could undoubtedly use some cleanup wrt things I missed and/or got wrong 
wrt what folks said. please consider them to be preliminary and unofficial.

HTH,

=JeffH
------

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2011 11:37:41 -0500 (EST)

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

---

From: Badra <[email-masked]>
Date: Fri, 18 Nov 2011 13:17:40 +0100

Thanks Jeff,

> wtc: badra also proposes state machine change as well as the ciphersuite
stuff

If you mean draft-hajjeh-tls-identity-protection-09, the chage are minor
with comparison to draft-agl-tls-encryptedclientcerts-00.
ciphersuite is more suitable than extensions, especially for SSLv3 and
TLS1.0/TLS1.1 implementations.

If you mean draft-badra-tls-identity-protection-01, you are right.

> sean (st): badra has IPR in his draft too -- need to consider that

I am not a lawyer, but I think that draft-agl-tls-encryptedclientcerts-00
and any other document - that proposes encrypting the client's certificate
during the initial TLS handshake- are equally relevant to the same IPR.

Best regards
Badra

On Thu, Nov 17, 2011 at 12:31 PM, =JeffH <[email-masked]>
wrote:
These could undoubtedly use some cleanup wrt things I missed and/or got
wrong wrt what folks said. please consider them to be preliminary and
unofficial.

HTH,

=JeffH
------

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 18 Nov 2011 14:33:22 +0100

> during the initial TLS handshake- are equally relevant to the same IPR.

I would be very surprised on something like that because client and
server certificate encryption was first(*) used in IKEv2 (RFC4306)
which predates the disclosed patents.

(*) to my knowledge. Protocols using this technique before that, might exist.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 08:36:19 +0200

> (*) to my knowledge. Protocols using this technique before that, might exist.

IKEv1 also encrypts the certificates in messages #5 and #6 of Main Mode, so that takes us to 1998 for publication, and probably several years earlier for drafts.

Yoav