(I am listed as author to one of the drafts, but haven't contributed significantly since suggesting the deprecation on the list, so I am going to renounce authorship and express my support for the adoption instead.)
As a TLS implementer, I don't want the specs to tell me what is *technically possible to implement correctly*. I want the specs to recommend the safer, most straightforward options for general purpose use. *DH reuse is less safe than ephemeral shares.* I don't think we need to debate this fact. There is a mile-high pile of CVEs that include the words "if DH shares are reused". I personally turned a 2^-32 chance of a carry bug into a full key recovery against ES-DH <https://www.youtube.com/watch?v=zPj5tTFDql0>, others have pulled off more and cooler attacks. None of these fun, job-security-providing stunts work with ephemeral shares, so it's with a heavy heart that I say we should absolutely deprecate all DH share reuses. (This includes all static kex, and an explicit MUST NOT for reuse in ephemeral kex.) *Checking the safety of an arbitrary FFDH group is relatively hard, and slow.* Implementers tend to skip hard, slow operations with no visible outcome. Besides, it's also a compatibility risk, because the only recourse on a failed check is to terminate the connection, which again encourages implementers to skip or relax the check. The most straightforward path to retaining FFDH in TLS 1.2 I see is requiring the use of a few, well known groups, that can be checked by memcmp. Still, I would rather support deprecating pre-TLS 1.3 FFDH entirely. It's not like things in the wild suddenly stop working when the IETF deprecates a cipher suite (that's my job!), it just tells bystanders "this is not the best way to do things" and in the case of DH reuse "you'll be much safer if you generate fresh shares" and in the case of FFDH "if you want to do FFDH it will be safer and more reliable to use TLS 1.3". I support adoption, and recommend merging all these deprecations into a single draft, which would be easier to refer to and communicate as an implementer. 2021-08-17 03:45 GMT+02:00 Joseph Salowey <j...@salowey.net>: > Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not > provide forward secrecy, which is a main reason cited for deprecating RSA in > draft-aviram-tls-deprecate-obsolete-kex. Do you object to just the citation > of the Raccoon attack or do you also feel that we should keep these > ciphersuites that do not provide forward secrecy around? > > Cheers, > > Joe > > On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL > <u...@ll.mit.edu> wrote: >> I agree with Rene’s points.____ >> __ __ >> -- ____ >> Regards,____ >> Uri____ >> __ __ >> __ __ >> *From: *TLS <tls-boun...@ietf.org> on behalf of Rene Struik >> <rstruik....@gmail.com> >> *Date: *Friday, August 13, 2021 at 09:58 >> ____ >> Dear colleagues:____ >> __ __ >> I think this document should absolutely *not* be adopted, without providing >> far more technical justification. The quoted Raccoon attack is an easy to >> mitigate attack (which has nothing to do with finite field groups, just with >> poor design choices of postprocessing, where one uses variable-size integer >> representations for a key). There are also good reasons to have key >> exchanges where one of the parties has a static key, whether ecc-based or >> ff-based (e.g., sni, opaque), for which secure implementations are known. No >> detail is provided and that alone should be sufficient reason to not >> adopt.____ >> __ __ >> Rene____ >> __ __ >> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:____ >>> This is a working group call for adoption for Deprecating FFDH(E) >>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 >>> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). We >>> had a presentation for this draft at the IETF 110 meeting and since it is a >>> similar topic to the key exchange deprecation draft the chairs want to get >>> a sense if the working group wants to adopt this draft (perhaps the drafts >>> could be merged if both move forward). Please review the draft and post >>> your comments to the list by Friday, August 13, 2021. ____ >>> __ __ >>> Thanks,____ >>> __ __ >>> The TLS chairs____ >>> >>> ____ >>> >>> ___________________________________________________ >>> TLS mailing list____ >>> TLS@ietf.org____ >>> https://www.ietf.org/mailman/listinfo/tls____ >> __ __ >> >> -- ____ >> email: rstruik....@gmail.com | Skype: rstruik____ >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867____ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
