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

[Tom Ritter <[e-mail]>]

On 17 March 2014 07:41, Michael StJohns <[e-mail]> wrote:
> On 3/16/2014 9:43 PM, Tom Ritter wrote:
>> 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.


That's fair, thanks.


>> 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?

Nope, I'm saying if I'm waving a fairy wand and randomly
rearchitecting protocols in the past, TLS _might_ have had the DHE
negotiation occur inside a channel protected by the non-PFS RSA key.
In my alternate world, we're able to upgrade the RSA key (1024, 2048,
4096) but due to annoying client restrictions, not the 1024 DH. And in
the alternate world, the 1024 DH handshake is protected by the 2048
RSA - you can't attack the 1024 without breaking the 2048.  (Like you
can now.)

It's just an example where data that was sent in the clear, instead of
in a secure channel, enabled attacks in an unexpected way a decade or
more later.


>> 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).

That's fair.  I imagine not everyone agrees with me when I see the
problem as "The client communicates version information, options, and
preferences outside a channel protected against a passive adversary.
The client is unable to communicate information it deems very
sensitive in a channel protected against an active adversary*."

* I suppose the caveat there would be "in a way performant enough for
anyone to use it" ;)

The arguements I really disagree with are the ones of the form:
 - There's no reason to try and hide the options one supports, because
the User-Agent will be sent at an earlier or later time in plaintext.
 - DNS lookups mean the data is exposed anyway, so who cares about it.

These arguements assume a specific operating environment and model.
While it's true it's common today, there is no guarentee that it will
be true tomorrow, or that someone won't try and tackle those problems
elsewhere.  It's also violating the principal of layering - I
shouldn't care what's happening at a different layer, I should make my
thing independent and secure.

I'm wondering if there is an approach here to hide the SNI against a
passive adversary, but not an active adversary - with the ability to
'bolt-on' strong authentication of 'ephemeral' keys if the stronger
protection is needed...

-tom