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

[Eric Rescorla <[e-mail]>]

Tom,

Thanks for your comments.


On Sat, Feb 22, 2014 at 8:38 AM, Tom Ritter <[e-mail]> wrote:

> On 19 February 2014 15:40, Eric Rescorla <[e-mail]> wrote:
>  > 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.
>

Can you unpack this a little for me? Are you saying we should always
protect SNI or something else?



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

Yeah, this section is badly written. I was trying to characterize all the
possible options with a single description and ended up characterizing
them all in a confusing way. Once we select a design, we can just
remove all the generic text and in the meantime I will try to clean this
up.



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

This is old text. When I wrote it it seemed to me that two DHs was a big
deal, but I'm less sure now. Still, it's a nonzero cost and the WG should
probably discuss it before we just decide to impose the cost.

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


Agreed. I'll see if I can get someone to do that...

Thanks,
-Ekr