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

[Eric Rescorla <[e-mail]>]

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:
> > >> [HRR state]
> > >
> > > That enlarges the state that needs to be kept. If one keeps extensions,
> > > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114
> > > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes.
> >
> > Cookies are as yet undefined, but I would imagine that these would be
> > just the same size as the pre-shared-key identity for all the same
> > reasons.
>
> Well, this is about the size one needs for the required state.
>
> > > And not many hash implementations support dumping and reloading state.
> >
> > What would you prefer?  We could specify some very strict rules about
> > what changes a client can make to their ClientHello so that the server
> > can simply store things that might change (like the early_data
> > extension, which will disappear on the second attempt, and whether a
> > key share was needed, and so forth).
>
> That ~40 bytes (IIRC, it was actually 37) was done by exploiting every-
> thing I could out of the rules in WIP #344 and relied on EDI being
> preserved.
>
> 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.



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


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

-Ekr




> > Note that this means that clients will have to deal with having to
> > change protocols when 0-RTT data is rejected.  But I don't see any
> > other way to do this.
>
> Well, the applications obviously have to be able to deal with the
> protocol possibly changing.
>



>
> > This also assumes that TLS session resumption is not carrying over
> > application state in addition to TLS state.  I believe that is
> > reasonable, though it's worth stating.
>
> Well, any state they can't recover.
>
>
> -Ilari
>