Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Martin Thomson]

Hi Daniel,

This removes the offending text.

This is incorrect:

> Clients MUST NOT offer one of these cipher suites with a (D)TLS version that 
> differs from TLS 1.2.

It should be possible to offer these when attempting to negotiate TLS
1.3.  The server simply cannot negotiate these cipher suites if it
chooses to use 1.3.  I'd remove that sentence (and the one following
it, since it's redundant with the first sentence of the paragraph).

As others have noted, the paragraph about TLS 1.3 isn't helpful and
should be removed.

This:

> In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2 [RFC4346] 
> split the pre-master into two  parts.  The PRF results from mixing the two 
> pseudorandom streams with distinct hash functions (MD5 and SHA-1) by 
> exclusive-ORing them together.

You mean TLS 1.1 rather than 1.2.  But as with the former paragraph,
talking about the limitations of TLS versions that you explicitly
don't support isn't useful.  Remove this paragraph also.

Nits:
s/pre-master(| secret)/premaster secret/g

You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
means to use AEAD_AES_128_GCM (and the same for the other
ciphersuites).  I mention this because the order in which the AEAD
algorithms are mentioned is different to the order of the ciphersuites
in the list.



On 24 May 2017 at 12:37, Daniel Migault  wrote:
> re-sending with the version 05 but removing the diff to be under the 100 KB
> limit.
> Yours,
> Daniel
>
> On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
>  wrote:
>>
>> Hi Eric,
>>
>> Thank you for the feed backs. The version 05 contains all text changes you
>> agreed. In addition, the text explaining dictionary/brute force has been
>> removed and replace by a reference to 4279. The recommendation regarding to
>> all PSK ciphers has been limited to the one of the document.  Please see
>> inline for more details.
>>
>> For some reasons I am not able to validate the submission of version 05. I
>> have attached the diff with version 04 as well as the locally generated
>> version 05.
>>
>> Yours,
>> Daniel
>>
>> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
>>>  wrote:

 Hi Eric,

 Thank you for your reviews. Please see my responses inline. If you agree
 with the text I will update the draft.

 Yours,
 Daniel

 On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> DISCUSS:
> --
>
> The following text appears to have been added in -04
>
>A server receiving a ClientHello and a client_version indicating
>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>this document in ClientHello.cipher_suites can safely assume that
> the
>client supports TLS 1.2 and is willing to use it.  The server MUST
>NOT negotiate these cipher suites with TLS protocol versions earlier
>than TLS 1.2.  Not requiring clients to indicate their support for
>TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>improves the interoperability in the installed base and use of TLS
>1.2 AEAD cipher suites without upsetting the installed base of
>version-intolerant TLS servers, results in more TLS handshakes
>succeeding and obviates fallback mechanisms.
>
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.
>
> This is a very material technical change. I don't consider it wise,
> but in any case it would absolutely need WG consensus, which I
> don't believe that it has given the recent introduction.


 I agree that the text is a technical change, and that it may not be
 appropriated to do so now. The reason I included it was that it was conform
 to the previous text, but I agree that implicit assumption of version 1.2
 may need some 

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Adam Roach]

On 5/23/17 9:33 PM, Daniel Migault wrote:
The current version does not consider that proposing the cipher suites 
of the document implicitly assumes the client supports TLS1.2.


Really? Can you clarify the meaning of the following passage? Because I 
can't read it in any way other than to contradict your assertion above:



   A server receiving a ClientHello and a client_version indicating
   (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
   this document in ClientHello.cipher_suites can safely assume that the
   client supports TLS 1.2 and is willing to use it.



/a

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

Re: [TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi,
Thanks for your review. I believe version 05 address Eric comments..
Yours,
Daniel

On Tue, May 23, 2017 at 6:12 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> COMMENT:
> --
>
> I support Ekr's DISCUSS position.
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

re-sending with the version 05 but removing the diff to be under the 100 KB
limit.
Yours,
Daniel

On Tue, May 23, 2017 at 9:28 PM, Daniel Migault  wrote:

> Hi Eric,
>
> Thank you for the feed backs. The version 05 contains all text changes you
> agreed. In addition, the text explaining dictionary/brute force has been
> removed and replace by a reference to 4279. The recommendation regarding to
> all PSK ciphers has been limited to the one of the document.  Please see
> inline for more details.
>
> For some reasons I am not able to validate the submission of version 05. I
> have attached the diff with version 04 as well as the locally generated
> version 05.
>
> Yours,
> Daniel
>
> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <
>> daniel.miga...@ericsson.com> wrote:
>>
>>> Hi Eric,
>>>
>>> Thank you for your reviews. Please see my responses inline. If you agree
>>> with the text I will update the draft.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>>>
 Eric Rescorla has entered the following ballot position for
 draft-ietf-tls-ecdhe-psk-aead-04: Discuss

 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)


 Please refer to https://www.ietf.org/iesg/stat
 ement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.


 The document, along with other ballot positions, can be found here:
 https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



 --
 DISCUSS:
 --

 The following text appears to have been added in -04

A server receiving a ClientHello and a client_version indicating
(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
this document in ClientHello.cipher_suites can safely assume that
 the
client supports TLS 1.2 and is willing to use it.  The server MUST
NOT negotiate these cipher suites with TLS protocol versions earlier
than TLS 1.2.  Not requiring clients to indicate their support for
TLS 1.2 cipher suites exclusively through ClientHello.client_hello
improves the interoperability in the installed base and use of TLS
1.2 AEAD cipher suites without upsetting the installed base of
version-intolerant TLS servers, results in more TLS handshakes
succeeding and obviates fallback mechanisms.

 This is a major technical change from -03, which, AFAIK, prohibited
 the server from negotiating these algorithms with TLS 1.1 and below
 and maintained the usual TLS version 1.2 negotiation rules.

 This is a very material technical change. I don't consider it wise,
 but in any case it would absolutely need WG consensus, which I
 don't believe that it has given the recent introduction.

>>>
>>> I agree that the text is a technical change, and that it may not be
>>> appropriated to do so now. The reason I included it was that it was conform
>>> to the previous text, but I agree that implicit assumption of version 1.2
>>> may need some additional discussion especially regarding RFC5246 Appendix
>>> E. Unless you prefer further discussion I assume the text below address
>>> your concern.
>>>
>>> The cipher suites defined in this document MUST NOT be negotiated for
>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
>>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
>>> Servers MUST NOT select one of these cipher suites with a TLS version that
>>> differs from TLS 1.2. A client MUST treat the selection of these cipher
>>> suites in combination with a version of TLS as an error and generate a
>>> fatal 'illegal_parameter' TLS alert. 
>>>
>>
>> Yes, this seems fine
>>
>>
>> The discussion of dictionary attacks here seems inferior to that
 in 4279. In particular, you only need to actively attack one
 connection to capture the data you need for a brute force attack
 despite the text there referring to trying "different keys".
 Please correct that.

 I believe the text below address your concern:
>>>
>>> OLD:
>>> Use of Pre-Shared Keys of limited entropy may allow an active
>>> attacker attempts to connect to the server and try different keys.
>>> For example, limited entropy may be provided by using a short PSK in
>>> which
>>> case an attacker may perform a brute-force attack. Another example
>>> includes the use of a PSK  chosen by a human which thus may be exposed to
>>> dictionary attacks.
>>>
>>> NEW:
>>> Pre-Shared Keys security relies on 

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi Martin,

The current version does not consider that proposing the cipher suites of
the document implicitly assumes the client supports TLS1.2. However, if
people think there is an advantage of adding this I am fine this being
discussed and  added in the next versions.

Yours,
Daniel

On Tue, May 23, 2017 at 7:10 PM, Martin Thomson 
wrote:

> On 24 May 2017 at 08:04, Daniel Migault 
> wrote:
> > So I have propose a fall back to the latest version. However, if we agree
> > this is a better approach, I am fine adding it to the document.
>
>
> Not sure what you mean by this.  If you mean removing the offending
> paragraph, that seems best.
>
> It's OK for these suites to be 1.2 only.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Martin Thomson]

On 24 May 2017 at 08:04, Daniel Migault  wrote:
> So I have propose a fall back to the latest version. However, if we agree
> this is a better approach, I am fine adding it to the document.


Not sure what you mean by this.  If you mean removing the offending
paragraph, that seems best.

It's OK for these suites to be 1.2 only.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/20/2017 04:33 AM, Ilari Liusvaara wrote:
>
> I meant what prevents the (say 10 second) windows from stacking up into
> (say 20 second windows) if 0-RTT is used on multiple hops (client-
> middlebox and middlebox-server)?
>
> One can not assume that the client has knowledge of any middlebox on
> the path (e.g. CDNs in HTTP are in general invisible to the client).
>

I think the attacker has to delay sending the client's 0-RTT to the
middlebox for the 10-second window if it wants to get the 20-second
delay overall (assuming the middlebox does at-most-once properly), at
which point the client would have a sense that something fishy might be
going on.  Though, that still doesn't give the client a hard bound on
the delay, I suppose.

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

[TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



--
COMMENT:
--

I support Ekr's DISCUSS position.


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

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Thank you for the clarifying text. I have added it on my local copy.
Yours,
Daniel

On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk  wrote:

> Sorry for the slow reply.
>
> On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> > Thank you,
> >
> > Your comments have all been addressed. I have one remaining
> clarification.
> > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and
> not
> > only for the cipher suites of the draft. In your opinion do we clarify
> > this, and should we use something else than SHOULD NOT ?
>
> It's somewhat awkward, as what we really want to do is Update RFC
> 5489 to add this prohibition there.  But, that's more process to
> jump through and this document is already at a late stage, so I do
> not actually propose doing that.  I would be okay saying
>
>   As such, all ECDHE_PSK ciphers, including those defined outside
>   this document, SHOULD NOT be negotiated in TLS versions prior to
>   1.2.
>
> to match up with the MUST NOT text we have for these new ciphers.
> (Taking into account Martin's text that the prohibition is on
> negotiating them, but offering them in a ClientHello that also
> offers the old version is okay.)
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi,

So I have propose a fall back to the latest version. However, if we agree
this is a better approach, I am fine adding it to the document.

Yours,
Daniel

On Tue, May 23, 2017 at 3:34 PM, Martin Rex  wrote:

> Adam Roach wrote:
> > draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> >
> > --
> > COMMENT:
> > --
> >
> > I agree with EKR's discuss -- specifying semantics for these ciphersuites
> > with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
> > which servers are encouraged to infer 1.2 support even in the absence of
> > explicit indication) is a bit baffling.
>
> It encourages (but does not require) servers to infer 1.2 support
> from _very_explicit_ information: the offering of TLSv1.2-only TLS
> ciphersuites is the very same TLS ClientHello handshake message.
>
> We know since rfc5746 that the most reliable scheme to indicate support
> for certain TLS protocol features is a cipher suite value.  It is far
> from rocket science to infer support for 1.2 from 1.2-only cipher
> suite codepoints in ClientHello.cipher_suites.
>
>
>
> I just realized that I suggested removal of a description of client
> behaviour that can, and should remain in the document (I'm sorry):
>
> A client MUST treat the selection of these cipher
>   suites in combination with a version of TLS that does not support
>   AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
>   'illegal_parameter' TLS alert.
>
>
> -Martin
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

Hi Eric,

Thank you for your reviews. Please see my responses inline. If you agree
with the text I will update the draft.

Yours,
Daniel

On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> DISCUSS:
> --
>
> The following text appears to have been added in -04
>
>A server receiving a ClientHello and a client_version indicating
>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>this document in ClientHello.cipher_suites can safely assume that
> the
>client supports TLS 1.2 and is willing to use it.  The server MUST
>NOT negotiate these cipher suites with TLS protocol versions earlier
>than TLS 1.2.  Not requiring clients to indicate their support for
>TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>improves the interoperability in the installed base and use of TLS
>1.2 AEAD cipher suites without upsetting the installed base of
>version-intolerant TLS servers, results in more TLS handshakes
>succeeding and obviates fallback mechanisms.
>
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.
>
> This is a very material technical change. I don't consider it wise,
> but in any case it would absolutely need WG consensus, which I
> don't believe that it has given the recent introduction.
>

I agree that the text is a technical change, and that it may not be
appropriated to do so now. The reason I included it was that it was conform
to the previous text, but I agree that implicit assumption of version 1.2
may need some additional discussion especially regarding RFC5246 Appendix
E. Unless you prefer further discussion I assume the text below address
your concern.

The cipher suites defined in this document MUST NOT be negotiated for
any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
these cipher suites with a (D)TLS version that differs from TLS 1.2.
Servers MUST NOT select one of these cipher suites with a TLS version that
differs from TLS 1.2. A client MUST treat the selection of these cipher
suites in combination with a version of TLS as an error and generate a
fatal 'illegal_parameter' TLS alert. 

>
> The discussion of dictionary attacks here seems inferior to that
> in 4279. In particular, you only need to actively attack one
> connection to capture the data you need for a brute force attack
> despite the text there referring to trying "different keys".
> Please correct that.
>
> I believe the text below address your concern:

OLD:
Use of Pre-Shared Keys of limited entropy may allow an active
attacker attempts to connect to the server and try different keys.
For example, limited entropy may be provided by using a short PSK in which
case an attacker may perform a brute-force attack. Another example
includes the use of a PSK  chosen by a human which thus may be exposed to
dictionary attacks.

NEW:
Pre-Shared Keys security relies on its associated entropy, and it is
RECOMMENDED to follow  to ensure the PSK has enough
entropy. Possible reasons for low entropy includes PSK chosen by humans or
PSK of small length as well as using random generators with limited
entropy. 

PSK of limited entropy may allow an attacker to test different PSK
values against a valid output such as master secret or any output derived
from it. In this document, the master secret is generated using the PSK as
well as the ECDHE shared secret. The use of ECDHE limits the possibilities
of passive eavesdropping attackers, as the ECDHE shared secret is not
expected to be derived from the observed ECDH parameters. As a result,
passive eavesdropping is unlikely to happen, and the collection of all
necessary material relies on an active attack.
An active attacker may collect the necessary material by setting a TLS
session as a client with the legitimate server. One PSK is tested for each
session, and a match occurs when key exchange succeeds. On the other hand,
an active attacker may also consider gathering the necessary information
for offline computation. One way consists in getting a legitimate client to
establish a connection with the attacker. It is also assumed 

Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

[Nick Sullivan]

Ben,

Thanks for pointing that out, you are right. A client is jointly
authoritative if there was in-handshake client auth followed by a
post-handshake client auth. Subsequent client authentications can be
computed in any order and are disambiguated by the context id.

Nick

On Tue, May 23, 2017 at 1:12 PM Benjamin Kaduk  wrote:

> On 05/23/2017 03:07 PM, Nick Sullivan wrote:
>
> 3) In TLS 1.3 post-handshake authentication, each successive certificate
> added to the connection is incorporated into the handshake state. The last
> certificate in a sequence of authentications would result in a connection
> in which the party could say they were jointly authoritative a over
> multiple identities. In exported authenticators, the only state that is
> signed comes from the original handshake, so there's no way to order them.
> Each exported authenticator is tied to the connection, but not tied
> directly to another authenticator, and therefore there is no proof that the
> party is "jointly authoritative". I welcome text changes to make this more
> clear.
>
>
> I thought at least for "normal" post-handshake auth, the handshake hash
> used was always just the initial handshake, and did not include
> intermediate certificates that had been transmitted.
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, May 23, 2017 at 9:34 PM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > draft-ietf-tls-ecdhe-psk-aead-04: Discuss
> >
> > --
> > DISCUSS:
> > --
> >
> > The following text appears to have been added in -04
> >
> >A server receiving a ClientHello and a client_version indicating
> >(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
> >this document in ClientHello.cipher_suites can safely assume that
> > the
> >client supports TLS 1.2 and is willing to use it.  The server MUST
> >NOT negotiate these cipher suites with TLS protocol versions earlier
> >than TLS 1.2.  Not requiring clients to indicate their support for
> >TLS 1.2 cipher suites exclusively through ClientHello.client_hello
> >improves the interoperability in the installed base and use of TLS
> >1.2 AEAD cipher suites without upsetting the installed base of
> >version-intolerant TLS servers, results in more TLS handshakes
> >succeeding and obviates fallback mechanisms.
> >
> > This is a major technical change from -03, which, AFAIK, prohibited
> > the server from negotiating these algorithms with TLS 1.1 and below
> > and maintained the usual TLS version 1.2 negotiation rules.
>
> This change _still_ prohibits the server from negotiating these algorithms
> with TLSv1.1 and below.



> Could you elaborate a little on where and why you see a problem with this?
>

For starters, TLS 1.3 has already designed a completely independent
mechanism for doing version negotiation outside of ClientHello.version,
so doing another seems pretty odd. In any case, it's not something you
do between IETF-LC and IESG approval.


As this changes tries to explain, had such a text been used for all
> TLSv1.2 AEAD cipher suite code points, then browsers would have never
> needed any "downgrade dance" fallbacks, POODLE would have never
> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
> would not been needed, either.
>

I'm not sure this is true, because there were also servers which did
not understand extensions.

-Ekr


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

Re: [TLS] Comments on EndOfEarlyData

[Andrei Popov]

Yes, it is my plan to make 0-RTT data opt-in only in the Windows TLS stack, 
with a clear distinction in the API.
It is possible, however, that certain middleware components above the TLS stack 
might choose to blur this distinction (which would be bad design, in my 
opinion).

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Tuesday, May 23, 2017 11:48 AM
To: Markulf Kohlweiss ; Kaduk, Ben ; 
tls@ietf.org
Cc: Antoine Delignat-Lavaud ; Samin Ishtiaq 
; Britta Hale 
Subject: Re: [TLS] Comments on EndOfEarlyData

> Given that 0-RTT and 1-RTT guarantees are very different, it seem important 
> to distinguish the two streams and model them separately.

Cool; is SChannel going to do that?

OpenSSL does.
___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7Cdd3c1a8132a34d29c46908d4a20c5706%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636311621300870812=MXINz0jr8SWWW9GWOt3Ayrojidu3RdiK%2FkBffEZZ0Eo%3D=0

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

Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

[Benjamin Kaduk]

On 05/23/2017 03:07 PM, Nick Sullivan wrote:
> 3) In TLS 1.3 post-handshake authentication, each successive
> certificate added to the connection is incorporated into the handshake
> state. The last certificate in a sequence of authentications would
> result in a connection in which the party could say they were jointly
> authoritative a over multiple identities. In exported authenticators,
> the only state that is signed comes from the original handshake, so
> there's no way to order them. Each exported authenticator is tied to
> the connection, but not tied directly to another authenticator, and
> therefore there is no proof that the party is "jointly authoritative".
> I welcome text changes to make this more clear.

I thought at least for "normal" post-handshake auth, the handshake hash
used was always just the initial handshake, and did not include
intermediate certificates that had been transmitted.

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

Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

[Nick Sullivan]

Hi Watson,

Some points that should help clarify your questions:
1) The certificate used in the construction is no the plain certificate
chain, it's the TLS 1.3 certificate message which could contain extensions.
2) The finished message is used to bind the certificate+certificateverify
to the connection state. It mirrors TLS 1.3 post-handshake authentication.
3) In TLS 1.3 post-handshake authentication, each successive certificate
added to the connection is incorporated into the handshake state. The last
certificate in a sequence of authentications would result in a connection
in which the party could say they were jointly authoritative a over
multiple identities. In exported authenticators, the only state that is
signed comes from the original handshake, so there's no way to order them.
Each exported authenticator is tied to the connection, but not tied
directly to another authenticator, and therefore there is no proof that the
party is "jointly authoritative". I welcome text changes to make this more
clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017 at 12:40 PM Watson Ladd  wrote:

> Dear all,
>
> I don't think this design needs to be as complex as it is. Why isn't
> signing a party-dependent (server or client) exporter with the key of the
> certificate, and then appending the certificate chain, enough? I am fairly
> certain this gets the properties we need.  Further, the language around
> jointly authoritative remains very opaque to me.
>
> My other (much more minor) comment is that exporters labels should start
> with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
> it.
>
> Sincerely,
> Watson Ladd
> ___
> 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

Re: [TLS] Security review of TLS1.3 0-RTT

[Salz, Rich]

> Well it's a little more subtle then that; folks seem to acknowledge the 
> attacks
> but feel that their use-cases won't be affected.  I'm looking at you, Chrome,
> boring, Firefox :)

I've heard from two people that the "looking at you" phrase was not 
well-received.  I apologize to the list, and those whose feelings I hurt.  I 
look forward to seeing more detailed responses to Colm's posts soon. 

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Martin Rex]

Adam Roach wrote:
> draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> 
> --
> COMMENT:
> --
> 
> I agree with EKR's discuss -- specifying semantics for these ciphersuites
> with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
> which servers are encouraged to infer 1.2 support even in the absence of
> explicit indication) is a bit baffling.

It encourages (but does not require) servers to infer 1.2 support
from _very_explicit_ information: the offering of TLSv1.2-only TLS
ciphersuites is the very same TLS ClientHello handshake message.

We know since rfc5746 that the most reliable scheme to indicate support
for certain TLS protocol features is a cipher suite value.  It is far
from rocket science to infer support for 1.2 from 1.2-only cipher
suite codepoints in ClientHello.cipher_suites.



I just realized that I suggested removal of a description of client
behaviour that can, and should remain in the document (I'm sorry):

A client MUST treat the selection of these cipher
  suites in combination with a version of TLS that does not support
  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
  'illegal_parameter' TLS alert.


-Martin

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Salz, Rich]

>I've seen a number of arguments here that essentially boil down to "We'd like 
>to keep it anyway, because it is so operationally convenient". Is that really 
>how this process works? Don't demonstrable real-world attacks deserve 
>deference?

Well it's a little more subtle then that; folks seem to acknowledge the attacks 
but feel that their use-cases won't be affected.  I'm looking at you, Chrome, 
boring, Firefox :)

Don't get discouraged. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote:
>
> I've seen a number of arguments here that essentially boil down to
> "We'd like to keep it anyway, because it is so operationally
> convenient". Is that really how this process works? Don't demonstrable
> real-world attacks deserve deference?

The process is more like "once the participants have gotten used to an
idea, it takes some time to digest countervailing reasoning when
potentially subtle issues are involved".  Without yet taking a position
myself, it seems like at least some folks are coming around to see your
position, and the dialogue should continue.

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

[TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



--
COMMENT:
--

I agree with EKR's discuss -- specifying semantics for these ciphersuites
with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
which servers are encouraged to infer 1.2 support even in the absence of
explicit indication) is a bit baffling.

Given the scope this document covers, I recommend adding "1.2" to the
title of the document. (e.g.: "ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security Version 1.2 (TLS 1.2)")


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

Re: [TLS] Comments on EndOfEarlyData

[Salz, Rich]

> Given that 0-RTT and 1-RTT guarantees are very different, it seem important 
> to distinguish the two streams and model them separately.

Cool; is SChannel going to do that?

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni 
wrote:

> Actually, nonces in DNScurve protect clients from replayed server
> responses (clients
> are stateful).  I see no explicit guidance to detect or refuse replays of
> client
> queries in DNScurve.  While servers could keep a nonce cache, in practice
> there
> are multiple servers and they don't share state (no "strike registers").
>

My apologies, you're right! I'll make sure to tease djb now. That's still
an insecure design (or at least a privacy defeating design) for the same
reasons as earlier. Though tinydns doesn't do RRL or Cyclic answers, so in
that coupled implementation it may be ok.

At one time we didn't think the kinds of side-channels present in TLS were
a big deal; the "it is not believed to be large enough to be exploitable" note
in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating history.

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

Re: [TLS] Comments on EndOfEarlyData

[David Benjamin]

On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk  wrote:

> My initial thoughts...
>
>
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
>
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
>
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
>
> Said otherwise, we want servers to be able to respond with application
> data based on application data from the client and know that that
> that data was not truncated.
>
>
> Thanks, the keyword of "truncated" caused me to understand the intended
> point.
>
> I think this question ends up tying into the more philosophical one of
> whether early data and 1-rtt data are considered "separate streams" or not
> -- if they are separate streams with distinct end/start, then of course one
> wants to detect possible truncation as it happens.  But, if they are
> conceptually the same stream and the boundary between them is "just" a
> bookkeeping operation of key change, then there is no need to be concerned
> about detecting truncation; the application just continues reading in data
> and replying when complete application protocol requests are received.
>

Truncation detection is meaningful in both cases. We rely on KeyUpdate
being protected and tied to the immediately preceding record (by way of
sequence number). Otherwise an attacker could toss out chunks in the middle
of the stream immediately before a KeyUpdate.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 23, 2017, at 2:07 PM, Colm MacCárthaigh  wrote:
> 
> That's not good for users, and seems like another very strong reason to make 
> it clear in the TLS draft that that it is not secure. FWIW; DNSCurve includes 
> nonces to avoid attacks like this: https://dnscurve.org/replays.html (which 
> means keeping state).

Actually, nonces in DNScurve protect clients from replayed server responses 
(clients
are stateful).  I see no explicit guidance to detect or refuse replays of client
queries in DNScurve.  While servers could keep a nonce cache, in practice there
are multiple servers and they don't share state (no "strike registers").

The replays discussed in the URL you provide are replays of stale, but still
within signature validity DNSSEC server responses.  Not replays of requests.

-- 
Viktor.

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

Re: [TLS] Comments on EndOfEarlyData

[Markulf Kohlweiss]

Given that 0-RTT and 1-RTT guarantees are very different, it seem important to 
distinguish the two streams and model them separately.

Of course that does not prevent applications that want to treat them as a 
single stream, but it is harder to understand the security one gets from such a 
mixed channel, e.g. some requests may have strong replay protection, others 
won’t.

--markulf

From: Benjamin Kaduk [mailto:bka...@akamai.com]
Sent: 23 May 2017 18:35
To: Markulf Kohlweiss ; tls@ietf.org
Cc: Samin Ishtiaq ; Antoine Delignat-Lavaud 
; Britta Hale 
Subject: Re: [TLS] Comments on EndOfEarlyData

My initial thoughts...

On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:


I am paraphrasing a long thread on the issue that we had within

the miTLS development team, and I am primarily commenting on the

analysis aspects. I also hope that it will clarify any remaining

problems of understanding that I have on the issue.



If we see EOED as a stream termination signal, then there seems

to be a difference in performance for conservative servers that

want to wait until receiving all 0RTT data before responding to

the client's request in 0.5RTT communication.



Said otherwise, we want servers to be able to respond with application

data based on application data from the client and know that that

that data was not truncated.

Thanks, the keyword of "truncated" caused me to understand the intended point.

I think this question ends up tying into the more philosophical one of whether 
early data and 1-rtt data are considered "separate streams" or not -- if they 
are separate streams with distinct end/start, then of course one wants to 
detect possible truncation as it happens.  But, if they are conceptually the 
same stream and the boundary between them is "just" a bookkeeping operation of 
key change, then there is no need to be concerned about detecting truncation; 
the application just continues reading in data and replying when complete 
application protocol requests are received.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni 
wrote:

> The fix is to amend DNSpriv to require stateless (random rather
> than say round-robit) RRset rotation.  With random rotation, the
> next RRset order is independent of previous queries.
>

That's a good fix for that specific local problem. But next, consider a
different one; what if a DNS provider has q-tuple rate-limiting for DOS
attacks? That's not an unusual measure for large providers - even bind9 has
support for it. Well with stateless 0RTT I can replay the clients query
over and over until the rate-limiting trips; now I have a DOS attack *and*
a privacy-defeating attack; because the rate limit exposes what the query
was for.


> Secondly, even with the 0-RTT leak, while privacy against an active
> attacker might not be assured for all users, there is fact privacy
> for most users, especially against a purely passive adversary.
>

My reference here isn't really meant as a criticism of DNSPriv - we should
make DNS private and secure, that's awesome, and it's a small attack in the
overall context of DNS. It's meant like Christian said; it is really really
hard to make an application protocol idempotent and side-effect free and
very smart people are often wrong about assuming that they are. I see
at-most-once 0-RTT mitigation as essential to avoiding a lot of real world
security issues here, because of that difficulty.


> To the extent that DNSpriv over TLS happens at all, 0-RTT
> will be used for DNS, and will be used statelessly (allowing
> replays).


That's not good for users, and seems like another very strong reason to
make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve
includes nonces to avoid attacks like this:
https://dnscurve.org/replays.html (which means keeping state).

Stateless mechanisms simply aren't secure. We wish they were; because it is
so attractive operationally - just as it would be nice if my MD5
accelerators were still useful. But they don't hold up. We've even seen
this before with DTLS; where replay tolerance opened up the window to
several cryptographic attacks. It's an all-round bad idea.

I've seen a number of arguments here that essentially boil down to "We'd
like to keep it anyway, because it is so operationally convenient". Is that
really how this process works? Don't demonstrable real-world attacks
deserve deference?

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

[TLS] Standard security levels (was Re: Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13))

[Nico Williams]

On Mon, May 22, 2017 at 08:57:30PM -0400, Dave Garrett wrote:
> On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote:
> > Setting a collision-resistance floor rather than naming some list
> > of algorithms makes more sense to me, but if the WG really feels
> > that naming some "verbotten" algorithms is better, so be it.
> 
> My preference would be to do both. Call out the ones we have
> codepoints for by name (MD5/SHA1/SHA224), then have a general
> collision-resistance floor value for everything else.

Sure.

In general I prefer setting floors, as Viktor says.  That's because
listing all forbidden algorithms is easy to flub up, and because it's
much easier from an API point of view to specify security levels than to
go listing things that are allowed/forbidden.

I think we should have standard algorithm security profile names that
can be used in multiple protocols.  E.g.,

 - weak (obsolete weak algorithms allowed)
 - interim  (certain obsolete weak algorithms allowed during migrations)
 - default  (default security floors, no obsolete weak algorithms allowed)
 - stronger (like standard but with higher security floors)

 -    (local/custom security level, perhaps specified
 additively from standard security levels)

The meaning of each of these would be updated over time by updating the
RFCs for the relevant protocols.  Thus configurations would not have to
change.

Specifying such a security level to TLS would have it apply that level
to its ciphersuite, PRF, key agreement, PSK, and signature algorithms,
and pass it to PKIX when using PKIX.

Specifying such a security level to PKIX would have it apply that level
to certificate public key and certificate signature algorithms, as well
as to path construction and validation.

Specifying such a security level to Kerberos, SSHv2, ... would ...
And so on.

This would make security level configuration much easier in the common
case.  And would avoid periodically having to update configurations to
adjust for recent cryptanalysis advances: just update the meanings of
these standard security levels and update software.

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 23, 2017, at 12:52 PM, Christian Huitema  wrote:
> 
> Colm's point is that for many DNS servers, queries are not truly stateless. 
> The answer to a query for  records for example.net might vary over time, 
> or even query to query, for example to manage load balancing. Adversaries can 
> predict these variations. They can observe the state of the server before and 
> after replaying 0-RTT data. If they observed that the 0-RTT data caused the 
> answer to change, they can confirm that the 0-RTT data contained a request to 
> that server.

The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation.  With random rotation, the
next RRset order is independent of previous queries.

Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.

DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs.  Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains.  Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.

Cryptography and 0-RTT are far from the weakest link in the
chain here.  DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.

To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays).  If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.

-- 
Viktor.

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

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Martin Rex]

It seems I had a typo in the new text.

Martin Rex wrote:
> Eric Rescorla wrote:
>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>> 
>> --
>> DISCUSS:
>> --
>> 
>> The following text appears to have been added in -04
>> 
>>A server receiving a ClientHello and a client_version indicating
>>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>this document in ClientHello.cipher_suites can safely assume that
>> the
>>client supports TLS 1.2 and is willing to use it.  The server MUST
>>NOT negotiate these cipher suites with TLS protocol versions earlier
>>than TLS 1.2.  Not requiring clients to indicate their support for
>>TLS 1.2 cipher suites exclusively through ClientHello.client_hello

That line should say
 through ClientHello.client_version

>>improves the interoperability in the installed base and use of TLS
>>1.2 AEAD cipher suites without upsetting the installed base of
>>version-intolerant TLS servers, results in more TLS handshakes
>>succeeding and obviates fallback mechanisms.
>> 
>> This is a major technical change from -03, which, AFAIK, prohibited
>> the server from negotiating these algorithms with TLS 1.1 and below
>> and maintained the usual TLS version 1.2 negotiation rules.
> 
> This change _still_ prohibits the server from negotiating these algorithms
> with TLSv1.1 and below.
> 
> Could you elaborate a little on where and why you see a problem with this?
> 
> As this change tries to explain, had such a text been used for all
> TLSv1.2 AEAD cipher suite code points, then browsers would have never
> needed any "downgrade dance" fallbacks, POODLE would have never
> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
> would not have been needed, either.

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

Re: [TLS] Comments on EndOfEarlyData

[Benjamin Kaduk]

My initial thoughts...

On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
>
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
>
> Said otherwise, we want servers to be able to respond with application 
> data based on application data from the client and know that that 
> that data was not truncated.

Thanks, the keyword of "truncated" caused me to understand the intended
point.

I think this question ends up tying into the more philosophical one of
whether early data and 1-rtt data are considered "separate streams" or
not -- if they are separate streams with distinct end/start, then of
course one wants to detect possible truncation as it happens.  But, if
they are conceptually the same stream and the boundary between them is
"just" a bookkeeping operation of key change, then there is no need to
be concerned about detecting truncation; the application just continues
reading in data and replying when complete application protocol requests
are received.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Christian Huitema]

On 5/22/2017 7:53 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk  > wrote:
>
>
> Sorry for being daft, but a direct link to this additional
> side-channel would be helpful.
>
>
> I should have done it the first time.  Here it
> is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html
>

Colm's point is that for many DNS servers, queries are not truly
stateless. The answer to a query for  records for example.net might
vary over time, or even query to query, for example to manage load
balancing. Adversaries can predict these variations. They can observe
the state of the server before and after replaying 0-RTT data. If they
observed that the 0-RTT data caused the answer to change, they can
confirm that the 0-RTT data contained a request to that server.

I take that as an example of the more generic statement, that it is
really difficult to guarantee that transactions are really stateless.
Some transactions are apparently stateless, because the operation in
theory only reads data from the server. But even these transactions can
change the state of the server in subtle ways, such as servers managing
load balancing. Another example would be web servers rotating
advertisements on the page, which also can be observed. If I get Colm's
point correctly, he asserts that this is a fairly general pattern, and
that only fools can assume that a given transaction is "stateless".

I take that as a strong argument for requiring "at most once"
functionality for 0-RTT data.

-- Christian Huitema

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

Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

[Daniel Migault]

Thanks I will add these by the end of the day.
Yours,
Daniel

On Mon, May 22, 2017 at 1:56 PM, Benjamin Kaduk  wrote:

> Thanks for the updates; the new revision addresses my concerns raised in
> the secdir review.
>
> However,
>
> % In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
> % [RFC4346] splits the pre-master in two parts.
>
> s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master secret
> into two parts".
>
> % the PSK and pre-master are treated by
> % distinct hash function with distinct properties.
>
> s/pre-master/ECDHE shared secret/?
>
> -Ben
>
>
> On 05/19/2017 03:18 PM, Daniel Migault wrote:
>
> Hi,
>
> Thank you to all reviewers for their feed backs. Please find the latest 
> version, which as far as I know includes all comments. Comments were not 
> controversial. In order to raise next reviews I am raising aspects that might 
> need a bit more attention.
>
> 1)  The current document mentions I-D.ietf-tls-rfc4492bis and 
> I-D.ietf-tls-tls13 as normative. We can wait for these documents to become 
> RFCs, but we can also dowref them to informational reference if we want to 
> move that document forward. I will leave the AD to decide, and changes if 
> needed can be done by the RFC -editor
>
> 2)  Section 4 has the following text:
>
> """In the case of ECDHE_PSK authentication, the PSK and pre-master are 
> treated by distinct hash function with distinct properties.  This may 
> introduce vulnerabilities over the expected security provided by the 
> constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be  used with 
> ECDHE_PSK. """
>
> With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suites 
> defined in the document.  I just want to make sure we are ok with the last 
> sentence.
>
> Yours,
> Daniel
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org 
> ]
> Sent: Friday, May 19, 2017 4:03 PM
> To: John Mattsson  ; 
> Daniel Migault  ; 
> tls-cha...@ietf.org
> Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
>
>
> A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
>
> Name: draft-ietf-tls-ecdhe-psk-aead
> Revision: 04
> Title:ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for 
> Transport Layer Security (TLS)
> Document date:2017-05-18
> Group:tls
> Pages:8
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04
>
> Abstract:
>This document defines several new cipher suites for the Transport
>Layer Security (TLS) protocol.  The cipher suites are all based on
>the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>(ECDHE_PSK) key exchange together with the Authenticated Encryption
>with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>provides light and efficient authentication, ECDHE provides forward
>secrecy, and AES-GCM and AES-CCM provides encryption and integrity
>protection.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> 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

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Martin Rex]

Eric Rescorla wrote:
> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
> 
> --
> DISCUSS:
> --
> 
> The following text appears to have been added in -04
> 
>A server receiving a ClientHello and a client_version indicating
>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>this document in ClientHello.cipher_suites can safely assume that
> the
>client supports TLS 1.2 and is willing to use it.  The server MUST
>NOT negotiate these cipher suites with TLS protocol versions earlier
>than TLS 1.2.  Not requiring clients to indicate their support for
>TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>improves the interoperability in the installed base and use of TLS
>1.2 AEAD cipher suites without upsetting the installed base of
>version-intolerant TLS servers, results in more TLS handshakes
>succeeding and obviates fallback mechanisms.
> 
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.

This change _still_ prohibits the server from negotiating these algorithms
with TLSv1.1 and below.

Could you elaborate a little on where and why you see a problem with this?

As this changes tries to explain, had such a text been used for all
TLSv1.2 AEAD cipher suite code points, then browsers would have never
needed any "downgrade dance" fallbacks, POODLE would have never
existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
would not been needed, either.

-Martin

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

Re: [TLS] Comments on EndOfEarlyData

[Markulf Kohlweiss]

Dear Eric, Britta,

I am paraphrasing a long thread on the issue that we had within
the miTLS development team, and I am primarily commenting on the
analysis aspects. I also hope that it will clarify any remaining
problems of understanding that I have on the issue.

If we see EOED as a stream termination signal, then there seems
to be a difference in performance for conservative servers that
want to wait until receiving all 0RTT data before responding to
the client's request in 0.5RTT communication.

Said otherwise, we want servers to be able to respond with application 
data based on application data from the client and know that that 
that data was not truncated.

==Scenario with EOED as Handshake message==

After the Client sends 0RTT data the Server gets 

CH, APP_C1, APP_C2

and typically responds with 

SH, ... SFIN, APP_S1

But wait, the server doesn't actually know that early data is
terminated. A conservative server would instead send only

SH,... SFIN and wait of EOED

The Client receives SH,... SFIN

Only now the Client knows that the server accepts 0RTT and he can
send and hash the EOED into the transcript hash.

The server receives EOED, CFIN

Only now such a conservative Server can send APP_S1. 

This results in an additional round trip for conservative
servers, and thus discourages the use of EOED as a stream
termination signal.  ---


==Scenario with EOED as Alert==

With an Alert based design for EOED we can instead have the
following flow, where the client immediately sends the EOED after
his request without waiting for the SFIN. Here the client makes the 
conscious choice not to send any additional early data.

The server gets 

CH, APP_C1, APP_C2, 
respond with SH,...SFIN

The server continues reading EOED and is notified about termination 
of 0RTT traffic .

The server can now immediately sends  APP_S1, 

It is important that the server would send SH regardless of
receiving EOED to avoid deadlock due to clients that wait until
receiving SFIN before sending EOED.  ---


Maybe the implicit assumption is that applications, e.g., HTTP/2
have to do their own termination of requests, and that EED serves
a different purpose? What would be the justification for
providing such a mechanism for 1RTT traffic but not for 0RTT
traffic. And why not enable different usage profiles?

Overall, I find the design based on Alert messages cleaner and
more consistent. From colleagues I heard folklore that it would
also ease verification and reduce the implementation complexity
for modular implementations that want to separate Record Layer
and Handshake Layer concerns.

This is related to verifying the handshake without relying on 
encryption at all but I will let them comment on this if they deem 
it necessary.

--markulf


> On 16. mai 2017 23:28, Eric Rescorla wrote:
>
>> On Tue, May 16, 2017 at 2:41 PM, Britta Hale  wrote:
>>
>> EOED signals the end of data encrypted with early traffic keys, yes, 
>> and the next message is the Finished message encrypted with the 
>> handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic 
>> key is signaled by the Finished message, not EOED. The Finished 
>> message, like a KeyUpdate message, are handshake messages, and both 
>> signal the start of a new key use for application data.
>>
>> In comparison, EOED signals the end of key use for application data - which
>> correlates
>> to alert behavior.
>
> This seems like a point where reasonable people can differ, especially as 
> ultimately the motivation for this change 
> was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some 
> analytic difficulty, or do you just find it > > unaesthetic?
>
> -Ekr

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

[Ilari Liusvaara]

On Mon, May 22, 2017 at 04:00:20PM -0500, Nico Williams wrote:
> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
> > wrote:
> > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
> > > > wrote:
> > > > > > In any case, I think there are two issues:
> > > > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > > > > 2. Require a specific failure if the peer presents such a
> > > certificate.
> > > > > >
> > > > > > There was pretty strong consensus to do #1 and I don't support
> > > removing
> > > > > > it. That seems like a pretty modest layering violation. If people
> > > think
> > > > > that
> > > > > > the mandate for this specific alert is too onerous, I could live 
> > > > > > with
> > > > > > removing
> > > > > > that.
> > > > >
> > > > > I don't understand how you can have (1) and not (2).
> > > >
> > > > As Ilari suggests, you could just treat the algorithms as unknown.
> > >
> > > How does that square with (1)?
> > >
> > 
> > I don't understand the question. If you treat them as unknown then
> > either your path construction code will route around them or once you
> > try to verify, it will fail.
> 
> That *really* seems like a layer violation!

The code I have tries to route around (with equivalent to exhaustive
search of all paths).

And altough the code I have has the TLS and certificate code more
tightly bound togethe than most libraries, the certificate validation
algorithm handling is wholly inside the certificate handling part.

The algorithm handling being inside certificate code is even true for
SHA-1 signatures, which have nontrivial validity rules (only allowed
for dedicated OCSP responders).

The certificate code does not concern itself about TLS version it
is running on. The exchange signature (which has differences between
TLS versions) is direct signature validation and does not involve
certificate code.


BTW:

Section 4.4.3. seemingly allows use of unadvertised exchange signature
schemes if advertised one can't be used. This should be fixed: There
is no way that can actually work (even pinning the server's key doesn't
make that work, unlike say EE certificate being signed with something
unknown).




-Ilari

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