Re: [TLS] COSIC's look on TLS 1.3

On Tue, Nov 8, 2016 at 2:33 PM, Ilari Liusvaara wrote: > - Yeah, there have been complaints about lack of state diagram, stating > that the present ladder diagram is not sufficient. > Yeah, I'm taking this point to heart. I've been a bit swamped with implementation

Re: [TLS] COSIC's look on TLS 1.3

On Tue, Nov 08, 2016 at 03:55:36PM +0100, Roel Peeters wrote: > Dear all, > > just to let you know that we have written a blog post on the current TLS > 1.3 draft, with our remarks that might be of use in your upcoming meeting. > > https://securewww.esat.kuleuven.be/cosic/?p=6624 Some comments:

Re: [TLS] COSIC's look on TLS 1.3

On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote: > we are also wondering whether or not the Hello Retry Request will be > included or omitted in the standard. Leaving it out will make TLS 1.3 > vulnerable again to downgrade attacks ... Why are you wondering about this? HRR is in the

Re: [TLS] COSIC's look on TLS 1.3

I let this message through the moderator queue despite the link to the blog; next time please send your comments directly to the list. Note that I wouldn’t necessarily expect anybody to pick up your points for you; PRs are welcome though. spt > On Nov 08, 2016, at 20:25, Roel Peeters

[TLS] COSIC's look on TLS 1.3

Dear all, just to let you know that we have written a blog post on the current TLS 1.3 draft, with our remarks that might be of use in your upcoming meeting. https://securewww.esat.kuleuven.be/cosic/?p=6624 Best regards, Roel Peeters and Jens Hermans PS: we are also wondering whether or not

Re: [TLS] (strict) decoding of legacy_record_version?

Martin Thomson wrote: > On 8 November 2016 at 14:01, Brian Smith wrote: > > Since this field isn't included in the additional_data of the AEAD in TLS > > 1.3 any more, it isn't authenticated. That means an active MitM can use > this > > to

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> the PDUs are still pretty much predictable > heuristically (by their ordering), even when they're padded. ... > So besides being completely pointless, can you describe any realistic problem > that is worth breaking middleware at the endpoints so badly? I found the language difference

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

If I understand correctly, you recommend something that is of the flavor in the security recommendation section: TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than

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

On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > Regarding Niko, my understanding is that the WG preferred not to have > the definition of profiles in this document. I am not sure you wanted > the text to be removed as MUST NOT was to normative or if you would > like no recommendation