Re: [TLS] 0-RTT encrypted data limits

[David Benjamin <[e-mail]>]

On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla <[e-mail]> wrote:

> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara <[e-mail]>
> wrote:
>
>> On Thu, Sep 01, 2016 at 02:29:00PM +0000, David Benjamin wrote:
>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla <[e-mail]> wrote:
>> >
>> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
>> [e-mail]>
>> > >>
>> > >> Should there be recommendation for clients to cut transfer and send
>> > >> Finished if the client receives EncryptedExtensions without
>> > >> early_data extension?
>> > >>
>> > >
>> > > I thought that was implicit, but i'd take a PR that did that.
>> > >
>> >
>> > (s/EncryptedExtensions/ServerHello/, but whatever.)
>>
>> According to the table it is EncryptedExtensions (but there have been
>> errors in it before)...
>>
>
> It goes in EE, because it should be encrypted.
>

Hrm. Most of the text currently says ServerHello, except for the table
which says EncryptedExtensions.

ServerHello:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2.6
https://tlswg.github.io/tls13-spec/#rfc.section.2.3

EncryptedExtensions:
https://tlswg.github.io/tls13-spec/#rfc.section.10

I'm a little wary of putting something that tells you the handshake "shape"
in EncryptedExtensions. Accepting early_data comes with a host of
constraints  the client must enforce like ALPN not being allowed to change,
etc. But I think all the current constraints are with EncryptedExtensions,
so maybe it's fine?

(The failure mode for getting this wrong is a risk of serious
implementation complexity and bugs, similar to why client
EncryptedExtensions was a problem. E.g. if ALPN were in SH but early_data
in EE , there would be a window of time where we have a new ALPN but aren't
sure if it's a 0-RTT reject or fatal error. It makes things a mess.)


> > At this point the client must do much more than cut transfer anyway. It
>> > probably should be phrased as starting over and retrying or so.
>> Everything
>> > sent has been rejected and all you thought you knew about the connection
>> > may have changed, like ALPN. At sufficiently high layers, you should
>> > probably just pretend you got a fresh connection and are repeating the
>> > request (or whatever) from scratch.
>>
>> So server is supposed to continue on 0-RTT fail, but not client?
>
>
> There are plenty of scenarios where the client can continue. For instance,
> if the server has forgotten the ticket but is otherwise unchanged.
>

Right, I mean it's a logical starting over. I imagine most cases one can
keep affinity with the old transport socket just fine, but data does likely
need to be reset. (Although in some cases you can't.)

David


> -Ekr
>
>
>>
>> -Ilari
>>
>
>