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

On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla wrote: > > > As promised: > > https://github.com/tlswg/tls13-spec/pull/1005 > > > > Note: I may have to do a little post-landing cleanup, but I wanted to get > > people's

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

> On May 19, 2017, at 9:43 PM, Dave Garrett wrote: > >> I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, >> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 >> or even MD5. > > They're not listed as possible field values

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

On Friday, May 19, 2017 04:18:03 pm Daniel Migault wrote: > 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

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

On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote: > On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, > > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 > > or even MD5. >

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

> On May 20, 2017, at 1:41 AM, Nico Williams wrote: > > "When using TLS to authenticate the server, certificate signature > algorithms weaker than > MUST NOT be used." Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX) to authenticate... (the

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

On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already addressed

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

Thanks for the feed backs. I have found two occurrences of perfect forward secrecy which have been changed to forward secrecy. Yours, Daniel On Thu, May 18, 2017 at 5:51 PM, Viktor Dukhovni wrote: > > > On May 18, 2017, at 5:30 PM, Eric Rescorla wrote: >

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

Benjamin Kaduk wrote: > > Some other editorial nits follow. > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. This reminds me of the specification goofs

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

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

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

Hi Benjamin, Thank you for the review. Please find my comments inline and let me know if you agree with the proposed text. I believe the only point not addressed concerns the addition of CCM-256 which has been remove after discussion during the WGLC. Thanks you for the review, Yours, Daniel On

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

Hi Martin, Thank you for the proposed text. It was very clear and I took it entirely, just changing s/TLSv1/TLS 1/. Yours, Daniel The current text is as follows: The cipher suites defined in this document MUST NOT be negotiated for any version of (D)TLS other than TLS 1.2. TLS version

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

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara wrote: > > To me, that reads as gross understatement about the dangers involved in > 0-RTT: > > - The side channel attacks with millions or billions of replays are hard > to protect against. This is if the side channels

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

Hi Benjamin and Dave, Thanks for the clarification. Considering also Roman' s and Ben' s comments the section is built as follow. 1) Limit cipher suites to TLS1.2, 2) explain how TLS1.3 and higher version negotiate them 3) bring all explanation foe the previous versions. Yours, Daniel The text

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

On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote: > Hi Benjamin, > > Thank you for the review. Please find my comments inline and let me know if > you agree with the proposed text. I believe the only point not addressed > concerns the addition of CCM-256 which has been remove after

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

On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara wrote: > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > > - Even if once-per-server or

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

On 05/19/2017 02:16 AM, Dave Garrett wrote: > On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: >> In section 4, "these cipher suites MUST NOT be negotiated in TLS >> versions prior to 1.2" should probably clarify that "these" cipher >> suites are the new ones specified by this document. >

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

Seeing as this utterly ridiculous ticket_age_add thing is partially my fault, I suppose I should respond: On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh wrote: > > And then separate to all of the above, and lower priority: >> > >> > * There's a contradiction between the

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

> On May 19, 2017, at 5:34 AM, Sankalp Bagaria wrote: > > I would like to mention that TLS can be used with non-X.509 certificates also. > In particular, it can be used with ITS ETSI and IEEE certificates. >

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

> On May 19, 2017, at 4:49 PM, David Benjamin wrote: > > Could you expand on your cryptanalysis? I don't believe this is actually > leaked. It's addition mod 2^32, not XOR, which means you effectively > randomize the parent starting time. (It was initially XOR, and then

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

On Fri, May 19, 2017 at 04:51:21PM -0400, Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already

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

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla wrote: > Yup. There are no known reasons that prevent at-most-once 0-RTT delivery, > >> even with distributed servers for the origin. >> > > I don't disagree with that necessarily, but if the client responds by > retransmitting > in

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

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

[TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-04.txt

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 : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Authors : John

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

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara wrote: > > * In order to fully reason about when that message may later get > received, > > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by > all > > potential middle-boxes in the pipe that may be

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

On Fri, May 19, 2017 at 1:58 PM, Viktor Dukhovni wrote: > > +1. The additive obfuscation leaks nothing that is not already leaked > just by sending the tickets. > You're both right, that does work out. I was thinking my balanced equations stupidly and solving for x while

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

On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. Probably should be: "the cipher suites defined in

[TLS] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04

Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new

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

On Fri, May 19, 2017 at 4:49 PM, David Benjamin wrote: > Seeing as this utterly ridiculous ticket_age_add thing is partially my > fault, I suppose I should respond: > > On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh > wrote: > >> > And then separate