Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla <[e-mail]>]

On Thu, Sep 1, 2016 at 8:46 AM, David Benjamin <[e-mail]>
wrote:

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

ALPN is also in EE. My general principle was that only things that were
required
to decrypt the handshake messages should be in SH. Arguably, btw, this means
that Server.signature_algorithms should be in EE, but I chickened out.

-Ekr




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