Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk <[e-mail]>]

Trying to consolidate various things into a single mail...

On 05/04/2017 04:37 PM, Eric Rescorla wrote:
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the
> mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps
> we say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do
> one of these mitigations?
>
>

That seems like an inconsistent position to take (don't do this, but if
you ignore me, do this in this fashion).  Advising application profiles
to consider one of those things might be better.



On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on
> separate connections) using the same PSK (for forward secrecy reasons)
>
>  
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior
> to receiving a NST (if they are out of cached PSKs). I’d expect the
> need for these retries to be larger with 0-RTT data, particularly when
> 0-RTT data is sent without even a transport roundtrip (in the case of
> TFO or QUIC). Servers are definitely not required to accept multiple
> 0-RTT connections using the same PSK, but I don’t think clients should
> be banned from attempting.
>

Obligatory note that if clients are forbidden from reusing a single PSK
for multiple 0-RTT, they can still use it for 1-RTT.



On 05/04/2017 03:24 PM, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>         1. A SHOULD-level requirement for server-side 0-RTT defense,
>         explaining
>         both session-cache and strike register styles and the merits
>         of each.
>
>
>     I don't believe this is technically viable for the large-scale
>     server operators most interested in 0-RTT.
>
>
> I think it is (and work at one of the biggest) ... but if even it
> weren't, that would just imply that we can't have 0-RTT at all, not
> that it's ok to ship an insecure version.

I would be okay with that being the case ... but I don't think that's
actually the case.  Some people are going to do 0-RTT in one form or
another, whether or not we specify it here.  I'd rather have something
well-specified that can be used correctly in some cases and is
unfortunately used in more cases than that, then a
less-well-documented-and-analyzed thing used in those same questionable
cases.


On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> P.S. Care to name (another :) one security-related protocol that
> doesn't provide replay protection?

Some of the earlier uses of Kerberos are subject to replay (hence
kerberos implementations can end up providing replay caches to try and
help, which are not perfect and slow to boot).  More modern exchanges
that use GSS acceptor subkeys are not subject to replay, though.


On 05/03/2017 09:31 PM, Martin Thomson wrote:
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.

You can still be in trouble if you used the early exporter, e.g., for
token binding.  We had some discussions in the tokbind session in
Chicago that clarified that handshake completion does not retroactively
bless the properties you want from 0-RTT token binding.


-Ben