On 9 November 2016 at 05:59, Brian Smith wrote:
> This isn't a pervasively shared goal, though. It's good to let the browsers
> police things if they want, but I think a lot of implementations would
> prefer to avoid doing work that isn't necessary for interop or security.
If you permit someone t
On 8 November 2016 at 21:08, Daniel Migault wrote:
> 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 the lower limits as a connection error
> of type insufficie
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
matters, but I'll get workin
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:
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 s
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 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
Best regards,
Roel Peeters and Jens Hermans
PS: we are also wondering whether or not th
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 transport up to 2 bytes of information hop-to-hop if the
> 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 interest
Yoav Nir wrote:
>
>> On 3 Nov 2016, at 20:20, Martin Rex wrote:
>>
>>> With visible content type, you can tell these two flows apart.
>>
>> (a) so what? for those interested, one can tell such flows appart
>> pretty reliably by traffic analysis. So there is exactly ZERO
>> protection
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 the
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 at
Hi Martin, Niko,
Thanks for the comment. Regarding Martin comment, I agree the text should
not comment the SHAX as these are defined by the cipher suites. What is not
clear to me is how the reference to DH should be handled. I also did not
feel that the provided text provides different recommendat
On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> Hi,
>
> Please find the text I propose. Let me know if you have any comment
> regarding the proposed text. Unless I receive comment on it, the text
> will be publish as soon as draft submission is possible.
>
> Yours,
> Daniel
>
> T
14 matches
Mail list logo
