Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting

[Michael StJohns <[e-mail]>]

On 3/16/2014 9:43 PM, Tom Ritter wrote:
> On 16 March 2014 10:21, Michael StJohns <[e-mail]> wrote:
>> During the TLS meeting EKR talked about encrypting most of the protocol
>> negotiation, and noted that the primary use case for that was the SNI.
> What about protecting the certificate sent by the server?
> What about protecting supported ciphersuites and extensions listed -
> taking steps towards protecting what user agent is being used?
> What about client certificates - protecting identity of the client?
> What about extensions? SRP Data, Client/Server Auth data, Padding?
Sorry - I should have put it like this (which AFAIK reflects the F2F 
discussion):

SNI is the only one of these that needs to be sent upfront - the rest 
can be done (albeit expensively) at later stages of the negotiation.

> If we had this before, the DHE exchange would be protected and we
> wouldn't be exposing 1024 DH all over the place.

I don't actually understand this point.  You're saying because the DH 
negotiation is encrypted under a key negotiated by a previous DH 
negotiation, then 1024 bit DH would be safe?

>
> If we spend all our time focusing on trying to protect individual
> components, we'll find arguments against any of them.  I'd much rather
> start from the perspective of protecting everything and address
> problems on an individual basis.  When building a cryptographic
> protocol you don't choose the smallest security margin you can think
> of for the application.

All of this is motherhood I agree with except with "protecting 
everything" because TANSTAAFL - there ain't no such thing as a free 
lunch - everything costs and sometimes provides little benefit.  But 1) 
what problem is this trying to solve?  2) How much cost is involved - on 
the client side and on the server side?  3) How much does this increase 
the attackers work factor?   These are all question I look at before 
deciding to move forward with a solution.

I'm unclear that we've agreed on the problem we're trying to solve (or 
problems), (And encrypt everything is not the problem, its the tool).

Mike

>
> -tom