Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01

[Watson Ladd <[e-mail]>]

On Sun, Feb 23, 2014 at 1:26 PM, Eric Rescorla <[e-mail]> wrote:
> Watson,
>
> Thanks for your comments.
>
> On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd <[e-mail]> wrote:
>> It seems to me the basic idea is to have the client encrypt its
>> handshake after learning the server ECDH key, under the idea that this
>> protects the client handshake. But this is wrong: the server's key
>> isn't authenticated, so the handshake isn't actually being protected.
>
> It's being protected from passive attack.

At a cost that would suffice to protect it from active attack, namely
a DH computation on each side after looking up one end in the DNS.

>
> In general, because the server has multiple certificates and uses
> SNI to select between them, we can't really authenticate the DH
> exchange until the client has supplied the SNI to indicate which
> certificate is to be used to authenticate the exchange.
> The idea here is to do an initial unauthenticated DH exchange
> to protect the SNI from passive attackers. Obviously this isn't
> perfect, but it's an improvement over the current state.
>
> Note that once the client and the server have spoken once and the
> client has a valid server key (via ServerParameters or the like), the
> client can use that key to form a secure connection and therefore
> protect the SNI from an active adversary (in theory).  However (and
> this is a big however) if you won't fall back to the non-optimistic
> case, you have a permanent commitment for the server to use those
> parameters, and if it forgets those for some reason (or you have
> multiple servers without totally shared state), then you would have no
> way to recover, so it's a tradeoff. [There are similar tradeoffs with
> cert pinning.]
>
> See Section 8.1:
> http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-8.1
>
>
>> This is why we need to know the server ECDH key for the 1RTT
>> transaction.
>>
>> 90% of what people use TLS for can be handled by the following flow:
>> C->S: g^x
>> S->C: g^y, Sign(g^y, g^x), certificates
>> C->S:everything encrypted with g^(xy).
>
> This is effectively what's in Appendix C:
>
> http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C
>
> I agree it's basically what you want if you don't care about protecting SNI.
> As I said in my note, I am assuming we want to try to protect SNI from
> passive attackers.

True, but my point was more that anything more than 128 bytes and
certificates is cruft. Some of that is unavoidable given backwards
necessity Some of that (SNI, ALPN) is of dubious necessity. But if we
want to make a real improvement in security, we need to massively
simplify the protocol and the code required to implement it.
>
> BTW, I note that this still is counting on some degree of
> pre-knowledge, namely, of what groups are acceptable to the server, so
> there's still a possibility you will end up having to do a second
> round trip.

Easy solution: limit the options so that there is one acceptable
choice, with a means to negotiate a future one when that one
acceptable choice falls. There is no reason to have a smorgasbord of
possibilities here.
>
>
>> In particular for SNI we could get some additional information from
>> DNS like "hi, I'm hosted with alice.com and bob.com, so if you see
>> other certificates, close the connection." I don't see a way to do
>> that with the current round trip proposals.
>
> I'm not sure quite what you're proposing here, but there's been a
> bunch of work on using DNS and DNSSEC to indicate information
> about the server's certificates. See, for instance:

I'm proposing that we secure the key we are sending SNI data to with
some certificate, so that a future extension can impose restrictions
on who gets to see that data. With your proposal of security only
against passive attackers, this requires the server to keep the ECDH
key it uses in memory and say something like "expect this ECDH key",
which is much more restrictive operationally.

>
> http://tools.ietf.org/html/rfc6698
> http://tools.ietf.org/html/draft-ietf-dane-srv-05
>
> However, this work is mostly agnostic to the details of the handshake
> flow, so I'm not sure how it interacts with the question of the internals
> of TLS.

It's not agnostic. The kind of key I get from DNS can dramatically
change what sorts of protocols are possible, and hence how the
handshake works. Get an ECDH key and we can do some sort of MQV
variant (AKE or SIGMA is probably the right thing here). Get out the
SHA256 fingerprint of an RSA key and there is nothing you can do: the
other side has to go first to tell you what the key is.
>
>
>
>> As a sidenote: kick DH. ECDH has the DH speed record, and isn't going
>> to give it up anytime soon. The IPR issues are long gone for something
>> invented in 1985.
>
> This seems like an orthogonal issue, so I suggest we discuss it separately.
>
> -Ekr

Sincerely,
Watson Ladd
>
>
>> On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla <[e-mail]> wrote:
>> > Folks,
>> >
>> > I have prepared a new version of the TLS 1.3 flows document which
>> > should appear in the repository shortly and in the meantime can be
>> > found at:
>> >
>> >
>> > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt
>> >
>> > This version fleshes out a "recommended" set of flows:
>> >
>> > - 2-RTT where the client has no knowledge of the
>> >   server's capabilities.
>> >
>> > - 1-RTT where the client knows the server's semi-permanent
>> >   DHE/ECDHE key pair.
>> >
>> > - 0-RTT where the client and the server have shared anti-replay
>> >   state.
>> >
>> > There are still a number of open issues, but this should be clear
>> > enough to see the direction I am trying to go. These flows are
>> > structured so that the 1-RTT case is the base case with the 2-RTT and
>> > 0-RTT versions being variants of the basic 1-RTT handshake. All
>> > variants encrypt the client extensions that are not required
>> > to define the cryptographic processing (e.g., SNI is encrypted
>> > but curve negotiation is not).
>> >
>> > I think the high order bit here is whether we want to have
>> > encrypted SNI, because that dictates the position of the DHE
>> > exchanges with respect to the server's messages.
>> >
>> > There are three options here:
>> >
>> > - Never
>> > - Sometimes
>> > - Always
>> >
>> > The flows in this draft take the position of "Always" which is
>> > simple. "Never" is actually simpler. "Sometimes" is the most
>> > complicated.  There are two cases where we could shave off latency if
>> > we were willing to disclose the SNI to passive attackers (and in cases
>> > where the client and server have never talked before.) My sense of
>> > recent discussion is that people feel it's important to have modes
>> > that protect SNI even if those are not the only modes. However, that
>> > means that if we want to have non-SNI protecting modes, they are
>> > additional complexity. Please let me know if I have misread the WG
>> > here.
>> >
>> >
>> > Here are some other things to keep in mind as you read the document.
>> >
>> > - Per my sense of the list, I have totally removed static RSA.  If
>> > people strongly object to that, please speak up and let me know.
>> >
>> > - There has been no real security analysis of this material other than
>> > at the hand-wavy level. We clearly need that, but the first thing we
>> > need is to be clear on whether this is approximately the right set of
>> > points in the complexity/performance/privacy tradeoff space and then
>> > make sure that the security properties are correct. So, if you see
>> > something that looks wrong or even grievously wrong, don't panic (but
>> > do point it out).
>> >
>> >
>> > - There is no currently defined support for any kind of resumption.
>> > We need to decide if resumption is still an important feature in light
>> > of the trend towards more PFS and faster processors.  I'm particularly
>> > looking for input from the IoT/DICE guys here.
>> >
>> > - We will probably need to work out some of the details for DTLS, but
>> > I wanted to get TLS nailed down first.
>> >
>> > - We also need to do some work on the symmetric crypto, e.g., to make
>> > encrypt-then-MAC the default, perhaps to deprecate some ciphers,
>> > compression, etc. I haven't forgotten that, but I want to deal with
>> > the handshakes first.
>> >
>> > - As before, this incorporates ideas from a lot of different people
>> > (and many times the same idea from different people). If you think
>> > you should acknowledged in the text and/or acknowledgements
>> > differently, please let me know.
>> >
>> > Thanks and comments welcome
>> > -Ekr
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>>
>>
>> --
>> "Those who would give up Essential Liberty to purchase a little
>> Temporary Safety deserve neither  Liberty nor Safety."
>> -- Benjamin Franklin
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin