On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote:
> On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara <ilariliusva...@welho.com>
> wrote:
>
> > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote:
> > > On 29 April 2016 at 15:58, Ilari Liusvaara <ilariliusva...@welho.com>
> > wrote:
> >
> > EDI looks like rather sizable structure currently (even after compressing
> > the configuration_id by obvious means).
> >
>
> Are you looking at a different document than I am: EDI currently is:
>
> struct {
> select (Role) {
> case client:
> opaque context<0..255>;
>
> case server:
> struct {};
> }
> } EarlyDataIndication;
>
> And the context is basically a placeholder.
Ah, I didn't see a PR about it and then looked at Editor's Copy.
Clearly a different document.
> > >> [extension checking on resumption]
> > > >
> > > > So the 'etc' stands for "whatever will be defined by future
> > extensions"?
> > > > One might want to make that clearer.
> > > >
> > > > Also, things get screwy with SNI, and I think it is better not to try
> > to
> > > > use SNI with PSK.
> > >
> > > The primary function of SNI is routing. Remove it and stuff breaks.
> > > Thus, I would say include it, but make sure it doesn't result in a
> > > change in configuration. The simplest thing to do is reject PSK if
> > > the old SNI != the new SNI.
> >
> > That kind of non-obvious stuff really needs to be included.
> >
> > They way it is right now written, I think very few TLS stacks are going
> > to get it right.
> >
>
> Proposed text would be welcome here.
Well, the more I think about this, the messier things about interaction
between SNI, "static" PSKs and "dynamic" PSKs seem to be...
And unlike ALPN, where problems only appear in context of 0-RTT, now you
also get the issues without 0-RTT:
> > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection
> > > > ALPN needs to match, either:
> > > >
> > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN.
> > > > 2) Signal the same ALPN again, and have that client MUST check it
> > matches
> > > > and abort otherwise.
> > >
> > > I believe that we have to do the latter. Since we can't be sure that
> > > the server knows the ALPN from before if it has to reject 0-RTT. My
> > > plan for this is:
> > >
> > > 1. store ALPN in the ticket/session
> > > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal
> > > ALPN negotiation
> > > 3. check the negotiated ALPN with the stored value, and if they don't
> > > match reject the 0-RTT data
> >
> > 4. If 0-RTT is accepted, client checks the ALPN server sent and
> > compares it with value it impiled. If those don't match, the client
> > MUST abort.
> >
> >
> > 1) would be:
> >
> > 1. store ALPN in the ticket/session
> > 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT
> > ALPN is acceptable. If it isn't, reject 0-RTT.
> > 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted
> > Extensions.
> >
> > That would make ALPN and EDI mutually exclusive in EncryptedExtensions.
> >
>
> This doesn't seem awesome from the client's perspective. I'm trying to make
> the ordinary PSK-resumption design less of a special case.
Well, the client needs to keep track of the ALP anyway. If for nothing
else, to check that the server isn't trying to do anything crazy.
I think it is easier for the client just to imply the ALP in presence of
accepted 0-RTT.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
