Subject: Re: [TLS] Revised TLS Charter

From: Brian Smith <[email-masked]>
Date: Mon, 23 May 2011 15:46:16 -0700 (PDT)

Eric Rescorla wrote:
> Can you advise on which drafts you have in mind?

1. draft-pettersen-tls-ext-multiple-ocsp

2. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 (NPN)

3. An extension to move the client certificate message to be between its ChangeCipherSuite and Finished messages (next to the NPN message), to protect it. Hopefully we can resurrect one of the previous drafts that proposed to do this.

4. An explicit one-roundtrip False-Start(-like) full handshake. (Needs a new I-D.)

We are planning to implement all of these extensions in Firefox. I believe that there are other major implementers that are planning to implement at least the first three.

We may also implement the current TLS False Start mechanism, but I think it would be better to have an opt-in one-round-trip handshake mechanism. Such a mechanism would probably involve the client optimistically putting a ClientKeyExchange (probably formatted like a ServerKeyExchange) message in a ClientHello extension, so that the server can send its ChangeCipherSuite and Finished messages immediately after its ServerHelloDone message.

Cheers,
Brian

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 24 May 2011 08:49:58 +0200

> We may also implement the current TLS False Start mechanism, but I think it would be better to have an opt-in one-round-trip handshake mechanism. Such a mechanism would probably involve the client…

Kerberos PKINIT does something similar to that. I found few attacks on
that approach when using smart-cards:
http://old.nabble.com/-Ietf-krb-wg--PKINIT-with-smart-cards-td31578223.html

Being conservative in design (as TLS does) pays off.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 May 2011 19:54:20 +0200 (MEST)

Brian Smith wrote:
> 
> 3. An extension to move the client certificate message to be between
> its ChangeCipherSuite and Finished messages (next to the NPN message),
> to protect it. Hopefully we can resurrect one of the previous drafts
> that proposed to do this.

What about the CertificateVerify handshake message?  In the original
TLS handshake, the handshake message hash that goes into CertificateVerify
covers the client's Certificate (handshake message), and I think that
is an important property.

Looking at the existing TLS handshake:
http://tools.ietf.org/html/rfc5246#page-36

I thought about just exhanging the Certificate and ClientKeyExchange
handshake messages, to be able to compute the MasterSecret
before composing the client's Certificate handshake message.
Being able to compute the master secret is a prerequisite
to being able to protect (at least part of the contents of)
the client's Certificate handshake message.

However, moving the handshake past ChangeCipherSpec as you
suggest, would have the advantage that protection of
(at least part of the contents of handshake messages)
would continue to use only the existing record layer logic.

> 4. An explicit one-roundtrip False-Start(-like) full handshake.

Personally, I see a need for something in the opposite direction.

While Browser vendors seem not have an issue with doing
reconnect fallbacks with feature-reduced ClientHellos after
handshake failures and caching such meta-information on
a per-destination basis, I'm much more worried about the
server and the programmatic client situations, where failed
handshakes, feature-reduced reconnect fallbacks and having
to cache meta-information on a per-destination basis are
no-goes.

I'm much more interested in a reliable negotiation, and I would
NOT mind an extra round-trip (crypto-free restart of ClientHello),
because >95% of the connects are going to be TLS session resumes
anyway, so that an additional round-trip on initial handshakes
really does not matter, and is significantly less of a problem
than failed full handshakes, because the latter have a huge
impact on the application callers, whereas an additional
round-trip to obtain a sensible negotiation would be
completely transparent/invisible for the application caller.

With the migration from 1024-bit RSA to 2048-bit RSA server
certificates I'm noticing a signficant performance impact
on RSA private key operations.  The public key operation
is fairly cheap due to the convenient use of e.g. Fermat-4 (0x10001)
for the public modulus,  But for private key operations
I am noticing a 8x performance impact,
from 3-5ms for 1024 bit to 25-40ms for 2048 bit.

-Martin