Re: [TLS] Next Protocol Negotiation 03

[George Kadianakis <[e-mail]>]

Adam Langley wrote:

> On Thu, Apr 26, 2012 at 1:21 PM, Martin Rex <mrex at sap.com> wrote:
> > Maybe we should define something similar for the encrypted part of
> > the handshake, so that we don't have to add new handshake messages
> > for every new feature?
> 
> Indeed, folks seem to be leaning towards wanting more generic support
> for extensions under encryption. Having a "client offers, server
> selects" extension exchange after the ChangeCipherSpecs is perfectly
> possible, although at the cost of precluding False Starting a full
> handshake. False Start isn't a real TLS feature of course, but we're
> currently pondering how much we want to be able to support it, and how
> much we want NPN under encryption.
> 
> Also, if there's a generic "secure" extension exchange after the CCS,
> it has the same concerns as False Start. i.e. an attacker can perform
> a downgrade attack on it. For False Start we say that if the
> ciphersuite isn't strong enough, we simply won't do it. But having a
> TLS feature switch on and off like that seems untenable.
> 
> So, in short, "still thinking".
> 
> 
> Cheers
> 
> AGL

Minimizing the unnecessary unencrypted information in TLS seems like a
wise idea, and post-CCS TLS extensions is a good first step in that
direction.

Defining the use cases and the threat model of post-CCS extensions is
probably a useful thing to do at this point.

For example, thinking about use cases, there are TLS extensions that
can't be placed post-CCS, like the ECC extensions or SessionTicket,
since they concern the SSL key exchange. At the same time, TLS
extensions like server_name, RI or NPN make sense post-CCS.

With regards to the threat model, post-CCS extensions should probably
share the exact same threat model as pre-CCS extensions, since they
both happen before the Finished record (for example, putting
application data on them is not a good idea).

Talking about threat models, the "client offers, server selects" model
might be susceptible to brute-force extension enumeration attacks, and
if 'secret TLS extensions' are considered useful, the protocol should
be designed appropriately.

Getting a bit funkier (since the state machine is a-changing these
days) maybe it makes sense to add a post-auth post-Finished phase to
TLS, so that "supplemental data" can be exchanged without the fear of
an MITM.

PS: Sorry for screwing up the threading; I am not subscribed to the
list and the ML web archive does not expose Message-IDs.