Re: [TLS] 0-RTT encrypted data limits

[Martin Thomson]

On 1 September 2016 at 23:45, Eric Rescorla  wrote:
>> 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.

Note that this is something you might want to do with
HelloRetryRequest as well (my drafty implementation in NSS cuts off
0-RTT at that point as well).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

On Thu, Sep 1, 2016 at 8:46 AM, David Benjamin 
wrote:

> On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla  wrote:
>
>> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara > > wrote:
>>
>>> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
>>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla  wrote:
>>> >
>>> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
>>> ilariliusva...@welho.com>
>>> > >>
>>> > >> 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
>>>
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[David Benjamin]

On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla  wrote:

> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara 
> wrote:
>
>> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla  wrote:
>> >
>> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
>> ilariliusva...@welho.com>
>> > >>
>> > >> 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
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara 
wrote:

> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla  wrote:
> >
> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > >>
> > >> 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.


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

-Ekr


>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Ilari Liusvaara]

On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
> On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla  wrote:
> 
> > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara 
> >>
> >> 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)...
 
> 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?


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[David Benjamin]

On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla  wrote:

> On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara 
> wrote:
>
>> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
>> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario  wrote:
>> > >
>> > > I'm afraid that requiring the server to keep the connection open for
>> > > essentially arbitrary amount of time while it consumes garbage data
>> is not
>> > > unlike the Apache slowloris attack.
>> >
>> > It's not required to. It can close the connection at any time.
>>
>> 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.)

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.

In the general case, you may even need to bounce to a new connection.
Consider if our session was established with h2, we try to 0-RTT-resume it,
send 20 replayable HTTP requests across it... and only then to hear from
server, "Nope, no 0-RTT for you, try again. Oh, by the way, we're talking
http/1.1 now." At least 19 of those 20 requests must get fresh connections
anyway.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara 
wrote:

> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario  wrote:
> > >
> > > I'm afraid that requiring the server to keep the connection open for
> > > essentially arbitrary amount of time while it consumes garbage data is
> not
> > > unlike the Apache slowloris attack.
> >
> > It's not required to. It can close the connection at any time.
>
> 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.

-Ekr


>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Hubert Kario]

On Thursday, 1 September 2016 05:48:02 CEST Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario  wrote:
> > On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> > > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario 
> > 
> > wrote:
> > > > Current draft has the following text in it:
> > > > If any of these checks fail, the server MUST NOT respond
> > > > with the extension and must discard all the remaining first
> > > > flight data (thus falling back to 1-RTT). If the client attempts
> > > > a 0-RTT handshake but the server rejects it, it will generally
> > > > not have the 0-RTT record protection keys and must instead
> > > > trial decrypt each record with the 1-RTT handshake keys
> > > > until it finds one that decrypts properly, and then pick up
> > > > the handshake from that point.
> > > > 
> > > > My understanding of that, in case client does 0-RTT but server rejects
> > 
> > it
> > 
> > > > (because the PSK is too old or its time is different enough) is that
> > 
> > the
> > 
> > > > server needs to keep on reading arbitrarily large amounts of data it
> > 
> > has
> > 
> > > > no
> > > > idea what to do with
> > > > 
> > > > Why is there no limit on the amount of data that can be encrypted
> > > > using
> > > > PSK keys (0-RTT)?
> > > 
> > > I don't think this would usefully improve things.
> > 
> > there's also second angle:
> > 
> > I'm afraid that requiring the server to keep the connection open for
> > essentially arbitrary amount of time while it consumes garbage data is not
> > unlike the Apache slowloris attack.
> 
> It's not required to. It can close the connection at any time.

Then how about making it explicit by including following paragraph:

To protect against denial of service attacks, servers MAY close the 
connection at any point when processing records with
trial decryption, but SHOULD process at least four records before doing 
so. This is so that server can find the second Finished message in case 
client sent just one record of Application Data.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario  wrote:

> On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario 
> wrote:
> > > Current draft has the following text in it:
> > > If any of these checks fail, the server MUST NOT respond
> > > with the extension and must discard all the remaining first
> > > flight data (thus falling back to 1-RTT). If the client attempts
> > > a 0-RTT handshake but the server rejects it, it will generally
> > > not have the 0-RTT record protection keys and must instead
> > > trial decrypt each record with the 1-RTT handshake keys
> > > until it finds one that decrypts properly, and then pick up
> > > the handshake from that point.
> > >
> > > My understanding of that, in case client does 0-RTT but server rejects
> it
> > > (because the PSK is too old or its time is different enough) is that
> the
> > > server needs to keep on reading arbitrarily large amounts of data it
> has
> > > no
> > > idea what to do with
> > >
> > > Why is there no limit on the amount of data that can be encrypted using
> > > PSK keys (0-RTT)?
> >
> > I don't think this would usefully improve things.
>
> there's also second angle:
>
> I'm afraid that requiring the server to keep the connection open for
> essentially arbitrary amount of time while it consumes garbage data is not
> unlike the Apache slowloris attack.
>

It's not required to. It can close the connection at any time.

-Ekr

--
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Hubert Kario]

On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario  wrote:
> > Current draft has the following text in it:
> > If any of these checks fail, the server MUST NOT respond
> > with the extension and must discard all the remaining first
> > flight data (thus falling back to 1-RTT). If the client attempts
> > a 0-RTT handshake but the server rejects it, it will generally
> > not have the 0-RTT record protection keys and must instead
> > trial decrypt each record with the 1-RTT handshake keys
> > until it finds one that decrypts properly, and then pick up
> > the handshake from that point.
> > 
> > My understanding of that, in case client does 0-RTT but server rejects it
> > (because the PSK is too old or its time is different enough) is that the
> > server needs to keep on reading arbitrarily large amounts of data it has
> > no
> > idea what to do with
> > 
> > Why is there no limit on the amount of data that can be encrypted using
> > PSK keys (0-RTT)?
> 
> I don't think this would usefully improve things.

there's also second angle:

I'm afraid that requiring the server to keep the connection open for 
essentially arbitrary amount of time while it consumes garbage data is not 
unlike the Apache slowloris attack.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Ilari Liusvaara]

On Wed, Aug 31, 2016 at 08:14:33PM +0200, Hubert Kario wrote:
> Current draft has the following text in it:
> 
> If any of these checks fail, the server MUST NOT respond
> with the extension and must discard all the remaining first
> flight data (thus falling back to 1-RTT). If the client attempts
> a 0-RTT handshake but the server rejects it, it will generally
> not have the 0-RTT record protection keys and must instead
> trial decrypt each record with the 1-RTT handshake keys
> until it finds one that decrypts properly, and then pick up
> the handshake from that point.
> 
> My understanding of that, in case client does 0-RTT but server rejects it 
> (because the PSK is too old or its time is different enough) is that the 
> server needs to keep on reading arbitrarily large amounts of data it has no 
> idea what to do with. All using slow path (thinking exception handling in 
> particular).

Yes, read the data and attempt to decrypt it with handshake keys (with
GCM and POLY1305, failed decryptions are faster than successful ones,
of course there is exception overhead if those are used).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario  wrote:

> Current draft has the following text in it:
>
> If any of these checks fail, the server MUST NOT respond
> with the extension and must discard all the remaining first
> flight data (thus falling back to 1-RTT). If the client attempts
> a 0-RTT handshake but the server rejects it, it will generally
> not have the 0-RTT record protection keys and must instead
> trial decrypt each record with the 1-RTT handshake keys
> until it finds one that decrypts properly, and then pick up
> the handshake from that point.
>
> My understanding of that, in case client does 0-RTT but server rejects it
> (because the PSK is too old or its time is different enough) is that the
> server needs to keep on reading arbitrarily large amounts of data it has no
> idea what to do with. All using slow path (thinking exception handling in
> particular).
>
> Is my understanding correct?
>

It's not clear to me that it's particularly slow. You get a MAC failure and
rejecting
the packet is slightly faster than processing it.


Why is there no limit on the amount of data that can be encrypted using PSK
> keys (0-RTT)?
>

I don't think this would usefully improve things.

-Ekr

--
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls