Re: [TLS] #445: Enhanced New Session Ticket

[Ilari Liusvaara <[e-mail]>]

On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote:
> On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote:
> > > On 29 April 2016 at 15:58, Ilari Liusvaara <[e-mail]>
> > 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