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

[Eric Rescorla <[e-mail]>]

On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara <[e-mail]>
wrote:

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

Yes, 445 builds on 444.


>
> > 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 don't see why that's true in the absence of 0-RTt. There's no reason why
the
server shouldn't be able to select any ALPN offers the client provides
regardless
of the original offer..

-Ekr



>
> I think it is easier for the client just to imply the ALP in presence of
> accepted 0-RTT.
>
>
> -Ilari
>