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

[Tom Ritter <[e-mail]>]

On 19 February 2014 15:40, 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

Thanks Eric!

> 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

I agree with this.

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

But not so much with this.  TLS has suffered from the multitude of
options and the complexity choosing them provides. If at all possible,
I lean away from accommodating more modes in favor of fewer much more
secure, but perhaps slightly more complicated modes.

> Thanks and comments welcome

Random:

---------------------------------------------
On replays

"   o Once the client and server have communicated once, they can
      establish an anti-replay token which can be used by the client to
      do a 0-RTT handshake with the server in future.  This is shown in
      Figure 5."

This confused me, because from this paragraph alone, it seemed like
the server was providing the client with a nonce, storing it, and when
the client used it again, the server forgot it and thus invalidated
it.  This does prevent replay - but it's not what the draft actually
describes.  I would try and rephrase this.

"Generally all of them require the server to give
   the client some identifier which is later replayed to the server to
   help it recover state and detect replays."

I don't think this is accurate wording either.  It implies a session
resumption. I would describe all of them as "the client remembers the
server's preferred parameters (ciphersuites, groups, orbit), and may
include something unique the server is expected to remember and use to
reject replays".

Two techniques I'm aware of for rejecting replays are relatively simple.
The first is the same as snap start, I'll mention that it's used by
mixmaster. The server stores identifiers, and discards any message
that has the same identifier or a timestamp older than X hours;
discarding state older than X hours as well.
The other is used by mixminion, and does not require roughly
synchronized clocks. The server stores the packet identifiers, and
rotates its keys every X hours, discarding the state and the keys upon
rotate. The server can detect replayed packets using it's state up
until discard and after discard, cannot decrypt any replayed packets
at all.  This also removes the need for an orbit.

On the topic of 0-RT and PFS. It adds complexity, but I can envision
an inline key exchange happening alongside the first few application
data packets.  I think this is what you mention on line 458, but I'm
not sure I understand why you say it's too expensive on a regular
basis? The client is doing two DH operations, the server similarly
does two. Normal PFS handshakes today require a RSA decryption and a
DH.  A resumption is much cheaper, yes.  Is this what you meant or did
I miss it?

---------------------------------------------

RE: No SNI and the issue on line 657 - I suspect, but testing would
need to be done, that nearly all major sites and most in general will
serve a valid default certificate if SNI is omitted.  I suspect this
would not be a difficult test for someone with a SSL scanning setup to
run.

-tom