Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Sorry, I'm not sure what you mean? > On Aug 28, 2021, at 6:20 PM, Rob Sayre wrote: > > On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle > wrote: > All the ciphersuites mentioned in the draft under discussion are already > listed as not recommended because they

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle wrote: > All the ciphersuites mentioned in the draft under discussion are already > listed as not recommended because they don't offer forward secrecy. > Excellent. How much WG time should we waste on so-called "embedded" use cases? thanks, Rob

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

In the revision of this draft (https://tools.ietf.org/pdf/draft-bartle-tls-deprecate-ffdh-00.pdf), which was unfortunately not the revision sent out on this call for adoption, we cite invalid curve attacks as a reason to advise against ECDH:

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

All the ciphersuites mentioned in the draft under discussion are already listed as not recommended because they don't offer forward secrecy. > On Aug 27, 2021, at 11:01 AM, Rob Sayre wrote: > > On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda > wrote: > > If a

[TLS] tls-flags: abort on malformed extension

Hi. To address Michael StJohns comment from 19-July, I submitted PR #12: https://github.com/tlswg/tls-flags/pull/12 What is says is that any implementation receiving a malformed tls_flags extensions should abort the handshake. The text provides a

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Hi Rene, We are agreed on the strategy for mitigating Raccoon. We seem to disagree on how easy it is to implement in constant time. I'd like to understand your position better: Are you OK with implementers reusing secret DH values without the above mitigation? If not, it sounds like you suggest