On Fri, Dec 30, 2016 at 9:21 AM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
> On Fri, Dec 30, 2016 at 08:14:57AM -0800, Eric Rescorla wrote:
> > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> > >
> > > What I'm wondering is if we're maybe missing a server-side check
> > > on that, with the possible attempted attack of a 0rtt replay in
> > > mind. E.g. a MUST check for the server that SNI is the same as for
> > > initial h/s before processing early data, (as is done for ALPN now)
> > > and/or some guidance about what might not be an obvious relationship
> > > between any 0rtt replay detection mechanisms and session ticket
> > > equivalents
> >
> >
> > I believe that the text I quote below already requires that check. The
> > reason
> > it's there and not in the 0-RTT text is that it is a requirement on
> > resumption
> > which itself is a requirement for 0-RTT. The ALPN check is an explicit
> 0-RTT
> > requirement but not a resumption requirement.
> >
> > I.e.,
> > Can resume only if SNI is equal
> > Can accept 0-RTT only if (resumed && ALPN is equal)
>
> Actually, AFAICT all types of PSKs can be used for 0-RTT if all the
> needed data is provisioned. But AFAICT only dynamically provisioned
> PSKs have SNI requirements.
>
> So statically provisioned ("external") PSKs AFAICT can do 0-RTT across
> SNI values.
>
Yes, I think that would be permitted by this text, though that's just a
result of bad writing,
which would be resolved by saying that you must only accept a PSK (rather
than
resume) if the SNIs are equal.
-Ekr
>
>
>
> -Ilari
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
