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

[Eric Rescorla <[e-mail]>]

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk <[e-mail]> wrote:

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

That's just incompetent writing by me, I guess.

For 2, I meant "If there is an application profile allowing 0-RTT, but it
doesn't say you don't
need mitigations, then you MUST..."


-Ekr


>
>
>
> 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]> wrote:
>
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <[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
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>