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

[Eric Rescorla <[e-mail]>]

One more point that someone made to me offline.

The flows in this document make multiple use of the same DH/ECDH
share (i.e., pairing the client's ECDH share with two separate server
shares.) This is in some respects like static DH and so we should
provide appropriate security guidance. There's already some such
guidance in RFC 5246 Section F.1.1.3:

http://tools.ietf.org/html/rfc5246#appendix-F.1.1.3


We might also consider whether it makes sense to specify a fixed
set of DH parameters (a la IKE and in the spirit of the specified
curves in RFC 4492), thus avoiding any need for people to
validate. That seems like something that might be valuable for
all versions of TLS.

Do we need anything else?

-Ekr








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