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

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

Re: [TLS] Comments on EndOfEarlyData

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 termi

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

Eric Rescorla wrote: > draft-ietf-tls-ecdhe-psk-aead-04: Discuss > > -- > DISCUSS: > -- > > The following text appears to have been added in -04 > >A server

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

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

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

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 >

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 understandin

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

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

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

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

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

On Mon, May 22, 2017 at 08:19:46PM -0400, Dave Garrett wrote: > On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote: > > So if putting the consensus to ban MD5/SHA-1 in its *proper context* > > is consistent with the WG consensus, let's do that. > > Yes, please. +1 > On Monday, May 22, 201

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

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

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

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

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

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

> 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

Re: [TLS] Comments on EndOfEarlyData

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 h

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

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

Re: [TLS] Comments on EndOfEarlyData

On 05/23/2017 01:36 PM, David Benjamin wrote: > On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk > wrote: > > > 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

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://www.ietf.org/mailman/l

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

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

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

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

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

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

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

Adam Roach wrote: > draft-ietf-tls-ecdhe-psk-aead-04: No Objection > > -- > COMMENT: > -- > > I agree with EKR's discuss -- specifying semantics for these cipher

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

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 aroun

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

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

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

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 conne

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

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

Re: [TLS] Comments on EndOfEarlyData

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

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

On Tue, May 23, 2017 at 9:34 PM, Martin Rex wrote: > Eric Rescorla wrote: > > draft-ietf-tls-ecdhe-psk-aead-04: Discuss > > > > -- > > DISCUSS: > > -- > > > > Th

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

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

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

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

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

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

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

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.

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

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 t

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

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

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

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 th

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

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 fo

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

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

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

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/

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

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 l

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

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 contrad

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

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 suit