Re: [TLS] Closing on 0-RTT

[Benjamin Kaduk]

On 06/29/2017 03:53 PM, Eric Rescorla wrote:
> I have updated the PR to match people's comments. I would like to
> merge this soon, so please get any final comments in.

I made a couple comments on the PR that are more appropriate for the
list, so I'll repeat them here and hopefully get replies from the
broader audience.


First off, I think we should MUST-level require servers to implement a
hard limit on the number of replays accepted.  However, it doesn't quite
seem realistic to require "MUST use either [single-use tickets] or
[ClientHello recording]".  My preference would be "MUST use either
[single-use tickets], [ClientHello recording], or equivalently strong
protection", but I don't know what level of support we have for such a
strong requirement.  As an alternative, I will also put out "MUST limit
replays to at most the number of endpoints capable of accepting
connections for a given identity, and SHOULD provide even stronger
replay protections, such as [single-use tickets] or [ClientHello
recording]."  I think we have general agreement that strong anti-replay
as described in the document is feasible for a single-server deployment,
and this last formulation is achievable in multi-server environments by
just giving each server its own local per-server protection.  (My main
reason for wanting a MUST-level hard cap is that I worry that
millions/billions of replays will have really nasty consequences in
terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple
forums/email subjects, so I've also probably forgotten some of the
arguments presented against having MUST-level strong anti-replay
requirements; I'd greatly appreciate if someone could repeat them here
for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" alert
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for
+as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and
accepting the PSK but rejecting 0-RTT (if a matching ClientHello is
found), especially not without giving guidance as to why they might
choose one or the other.  My natural inclination would be to have the
expected behavior be to abort and only fall back to the other behavior
if using a scheme with false positives, but Ekr thinks Erik Nygren was
in support of just continuing on with 1-RTT.  It looks like this was
https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
where I ... took the opposite position from what I just said my "natural
inclination" was, amusingly enough.  But still, why does this need to be
a choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it
would be reasonable in all the cases mentioned so far.

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

Re: [TLS] Closing on 0-RTT

[Eric Rescorla]

On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk  wrote:

> On 06/29/2017 03:53 PM, Eric Rescorla wrote:
>
> I have updated the PR to match people's comments. I would like to merge
> this soon, so please get any final comments in.
>
>
> I made a couple comments on the PR that are more appropriate for the list,
> so I'll repeat them here and hopefully get replies from the broader
> audience.
>
>
> First off, I think we should MUST-level require servers to implement a
> hard limit on the number of replays accepted.  However, it doesn't quite
> seem realistic to require "MUST use either [single-use tickets] or
> [ClientHello recording]".  My preference would be "MUST use either
> [single-use tickets], [ClientHello recording], or equivalently strong
> protection", but I don't know what level of support we have for such a
> strong requirement.  As an alternative, I will also put out "MUST limit
> replays to at most the number of endpoints capable of accepting connections
> for a given identity, and SHOULD provide even stronger replay protections,
> such as [single-use tickets] or [ClientHello recording]."  I think we have
> general agreement that strong anti-replay as described in the document is
> feasible for a single-server deployment, and this last formulation is
> achievable in multi-server environments by just giving each server its own
> local per-server protection.  (My main reason for wanting a MUST-level hard
> cap is that I worry that millions/billions of replays will have really
> nasty consequences in terms of DoS and side channel issues.)
>
> But, this has been quite a long thread spread out over multiple
> forums/email subjects, so I've also probably forgotten some of the
> arguments presented against having MUST-level strong anti-replay
> requirements; I'd greatly appreciate if someone could repeat them here for
> everyone's consideration.
>
>
> The pull request also has some text:
>
> +If the expected arrival time is in the window, then the server
> +checks to see if it has recorded a matching ClientHello. It
> +either aborts the handshake with an "illegal_parameter" alert
> +or accepts the PSK but reject 0-RTT. If no matching ClientHello
> +is found, then it accepts 0-RTT and then stores the ClientHello for
> +as long as the expected_arrival_time is inside the window.
> +Servers MAY also implement data stores with false positives, such as
> +Bloom filters, in which case they MUST respond to apparent replay by
> +rejecting 0-RTT but MUST NOT abort the handshake.
>
> I am not sure why we are giving servers a choice between aborting and
> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
> especially not without giving guidance as to why they might choose one or
> the other.  My natural inclination would be to have the expected behavior
> be to abort and only fall back to the other behavior if using a scheme with
> false positives, but Ekr thinks Erik Nygren was in support of just
> continuing on with 1-RTT.  It looks like this was
> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
> where I ... took the opposite position from what I just said my "natural
> inclination" was, amusingly enough.  But still, why does this need to be a
> choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be
> reasonable in all the cases mentioned so far.
>

Well, my reason for not wanting to do that is that it's a clear replay and
so should
be a hard failure. So, I'd be happy to mandate abort the handshake, but if
we can't
agree on that, I'd rather have a choice.

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

Re: [TLS] Closing on 0-RTT

[Benjamin Kaduk]

On 06/30/2017 11:53 AM, Eric Rescorla wrote:
>
> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk  > wrote:
>
>
>
> The pull request also has some text:
>
> +If the expected arrival time is in the window, then the server
> +checks to see if it has recorded a matching ClientHello. It
> +either aborts the handshake with an "illegal_parameter" alert
> +or accepts the PSK but reject 0-RTT. If no matching ClientHello
> +is found, then it accepts 0-RTT and then stores the ClientHello for
> +as long as the expected_arrival_time is inside the window.
> +Servers MAY also implement data stores with false positives, such as
> +Bloom filters, in which case they MUST respond to apparent replay by
> +rejecting 0-RTT but MUST NOT abort the handshake.
>
> I am not sure why we are giving servers a choice between aborting
> and accepting the PSK but rejecting 0-RTT (if a matching
> ClientHello is found), especially not without giving guidance as
> to why they might choose one or the other.  My natural inclination
> would be to have the expected behavior be to abort and only fall
> back to the other behavior if using a scheme with false positives,
> but Ekr thinks Erik Nygren was in support of just continuing on
> with 1-RTT.  It looks like this was
> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733
> 
> 
> , where I ... took the opposite position from what I just said my
> "natural inclination" was, amusingly enough.  But still, why does
> this need to be a choice?  Rejecting 0-RTT and continuing on to
> 1-RTT seems like it would be reasonable in all the cases mentioned
> so far.
>
>
> Well, my reason for not wanting to do that is that it's a clear replay
> and so should
> be a hard failure. So, I'd be happy to mandate abort the handshake,
> but if we can't
> agree on that, I'd rather have a choice.
>

Would you be willing to add some discussion about how aborting might
give an information channel to an attacker maliciously replaying packets
even though it is clearly an error that should be rejected (eventually)?

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

Re: [TLS] Closing on 0-RTT

[Erik Nygren]

On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla  wrote:

>
> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk  wrote:
>
>> On 06/29/2017 03:53 PM, Eric Rescorla wrote:
>>
>> I have updated the PR to match people's comments. I would like to merge
>> this soon, so please get any final comments in.
>>
>>
>> I made a couple comments on the PR that are more appropriate for the
>> list, so I'll repeat them here and hopefully get replies from the broader
>> audience.
>>
>>
>> First off, I think we should MUST-level require servers to implement a
>> hard limit on the number of replays accepted.  However, it doesn't quite
>> seem realistic to require "MUST use either [single-use tickets] or
>> [ClientHello recording]".  My preference would be "MUST use either
>> [single-use tickets], [ClientHello recording], or equivalently strong
>> protection", but I don't know what level of support we have for such a
>> strong requirement.  As an alternative, I will also put out "MUST limit
>> replays to at most the number of endpoints capable of accepting connections
>> for a given identity, and SHOULD provide even stronger replay protections,
>> such as [single-use tickets] or [ClientHello recording]."  I think we have
>> general agreement that strong anti-replay as described in the document is
>> feasible for a single-server deployment, and this last formulation is
>> achievable in multi-server environments by just giving each server its own
>> local per-server protection.  (My main reason for wanting a MUST-level hard
>> cap is that I worry that millions/billions of replays will have really
>> nasty consequences in terms of DoS and side channel issues.)
>>
>> But, this has been quite a long thread spread out over multiple
>> forums/email subjects, so I've also probably forgotten some of the
>> arguments presented against having MUST-level strong anti-replay
>> requirements; I'd greatly appreciate if someone could repeat them here for
>> everyone's consideration.
>>
>>
>> The pull request also has some text:
>>
>> +If the expected arrival time is in the window, then the server
>> +checks to see if it has recorded a matching ClientHello. It
>> +either aborts the handshake with an "illegal_parameter" alert
>> +or accepts the PSK but reject 0-RTT. If no matching ClientHello
>> +is found, then it accepts 0-RTT and then stores the ClientHello for
>> +as long as the expected_arrival_time is inside the window.
>> +Servers MAY also implement data stores with false positives, such as
>> +Bloom filters, in which case they MUST respond to apparent replay by
>> +rejecting 0-RTT but MUST NOT abort the handshake.
>>
>> I am not sure why we are giving servers a choice between aborting and
>> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
>> especially not without giving guidance as to why they might choose one or
>> the other.  My natural inclination would be to have the expected behavior
>> be to abort and only fall back to the other behavior if using a scheme with
>> false positives, but Ekr thinks Erik Nygren was in support of just
>> continuing on with 1-RTT.  It looks like this was
>> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
>> where I ... took the opposite position from what I just said my "natural
>> inclination" was, amusingly enough.  But still, why does this need to be a
>> choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be
>> reasonable in all the cases mentioned so far.
>>
>
> Well, my reason for not wanting to do that is that it's a clear replay and
> so should
> be a hard failure. So, I'd be happy to mandate abort the handshake, but if
> we can't
> agree on that, I'd rather have a choice.
>

Are there scenarios where the duplication might be accidental rather than a
malicious attack?
For example, one might see cases where combining 0RTT with TFO and network
packet
duplication could result in two initial 0RTT flights.  One could also see
"TCP accelerator"
middleboxes doing similar things where the first flight gets replayed.

In both of these cases, only one will actually successfully establish a TLS
connection
and move forwards, but if the successful one is the one that is aborted
then
the connection will fail.  If 0RTT is rejected and both are allowed to
proceed,
then the bogus accidental replay will be dropped and the legit connection
will succeed.

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

Re: [TLS] Closing on 0-RTT

[Eric Rescorla]

On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren  wrote:

> On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla  wrote:
>
>>
>> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk 
>> wrote:
>>
>>> On 06/29/2017 03:53 PM, Eric Rescorla wrote:
>>>
>>> I have updated the PR to match people's comments. I would like to merge
>>> this soon, so please get any final comments in.
>>>
>>>
>>> I made a couple comments on the PR that are more appropriate for the
>>> list, so I'll repeat them here and hopefully get replies from the broader
>>> audience.
>>>
>>>
>>> First off, I think we should MUST-level require servers to implement a
>>> hard limit on the number of replays accepted.  However, it doesn't quite
>>> seem realistic to require "MUST use either [single-use tickets] or
>>> [ClientHello recording]".  My preference would be "MUST use either
>>> [single-use tickets], [ClientHello recording], or equivalently strong
>>> protection", but I don't know what level of support we have for such a
>>> strong requirement.  As an alternative, I will also put out "MUST limit
>>> replays to at most the number of endpoints capable of accepting connections
>>> for a given identity, and SHOULD provide even stronger replay protections,
>>> such as [single-use tickets] or [ClientHello recording]."  I think we have
>>> general agreement that strong anti-replay as described in the document is
>>> feasible for a single-server deployment, and this last formulation is
>>> achievable in multi-server environments by just giving each server its own
>>> local per-server protection.  (My main reason for wanting a MUST-level hard
>>> cap is that I worry that millions/billions of replays will have really
>>> nasty consequences in terms of DoS and side channel issues.)
>>>
>>> But, this has been quite a long thread spread out over multiple
>>> forums/email subjects, so I've also probably forgotten some of the
>>> arguments presented against having MUST-level strong anti-replay
>>> requirements; I'd greatly appreciate if someone could repeat them here for
>>> everyone's consideration.
>>>
>>>
>>> The pull request also has some text:
>>>
>>> +If the expected arrival time is in the window, then the server
>>> +checks to see if it has recorded a matching ClientHello. It
>>> +either aborts the handshake with an "illegal_parameter" alert
>>> +or accepts the PSK but reject 0-RTT. If no matching ClientHello
>>> +is found, then it accepts 0-RTT and then stores the ClientHello for
>>> +as long as the expected_arrival_time is inside the window.
>>> +Servers MAY also implement data stores with false positives, such as
>>> +Bloom filters, in which case they MUST respond to apparent replay by
>>> +rejecting 0-RTT but MUST NOT abort the handshake.
>>>
>>> I am not sure why we are giving servers a choice between aborting and
>>> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
>>> especially not without giving guidance as to why they might choose one or
>>> the other.  My natural inclination would be to have the expected behavior
>>> be to abort and only fall back to the other behavior if using a scheme with
>>> false positives, but Ekr thinks Erik Nygren was in support of just
>>> continuing on with 1-RTT.  It looks like this was
>>> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
>>> where I ... took the opposite position from what I just said my "natural
>>> inclination" was, amusingly enough.  But still, why does this need to be a
>>> choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be
>>> reasonable in all the cases mentioned so far.
>>>
>>
>> Well, my reason for not wanting to do that is that it's a clear replay
>> and so should
>> be a hard failure. So, I'd be happy to mandate abort the handshake, but
>> if we can't
>> agree on that, I'd rather have a choice.
>>
>
> Are there scenarios where the duplication might be accidental rather than
> a malicious attack?
>
For example, one might see cases where combining 0RTT with TFO and network
> packet
> duplication could result in two initial 0RTT flights.  One could also see
> "TCP accelerator"
> middleboxes doing similar things where the first flight gets replayed.
>

Sure, and this is a good reason to hard fail because it helps us find stuff
like that.


In both of these cases, only one will actually successfully establish a TLS
> connection
> and move forwards, but if the successful one is the one that is aborted
> then
> the connection will fail.
>

Sure, though of course clients can also retry.

-Ekr




>   If 0RTT is rejected and both are allowed to proceed,
> then the bogus accidental replay will be dropped and the legit connection
> will succeed.
>
> Erik
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-tls13-vectors-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

Title   : Example Handshake Traces for TLS 1.3
Author  : Martin Thomson
Filename: draft-ietf-tls-tls13-vectors-01.txt
Pages   : 36
Date: 2017-06-30

Abstract:
   Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
   are provided so that these handshakes might be reproduced.
   Intermediate values, including secrets, traffic keys and ivs are
   shown so that implementations might be checked incrementally against
   these values.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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