On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk <bka...@akamai.com> 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 <erik+i...@nygren.org> wrote: > >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <e...@rtfm.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
