I support adoption, and will second everything Filippo says. Deprecation is about the working group issuing updated guidance. Existing ecosystems may apply new guidance at different rates. That's up to TLS implementations and deployments to work through. Some ecosystems may remove things at long time scales. Some ecosystems may have particularly unusual setups such that they almost never want to remove anything. That's fine, but it cannot discount the other ecosystems which *do *incur security risk from having weak ciphers enabled, or the new TLS uses with no legacy. The working group needs to maintain up-to-date guidance here, and this is how we do that.
On arbitrary FFDH groups, I think pre-TLS-1.3 FFDH, even ephemeral, is unsalvageable [again, as up-to-date guidance, see above]. We don't have a way to tell the server to only consider DHE ciphers if it would have used a group the client supports. RFC7919 tried to solve the problem but, by reusing the old cipher suites, it fails to solve the problem. Triggering an external client retry instead has interesting downgrade consequences due to ServerKeyExchange signatures not covering the ClientHello. (In fact, I suspect RFC7919 has made the downgrade risks worse...) On Tue, Aug 17, 2021 at 9:29 AM Filippo Valsorda <fili...@ml.filippo.io> wrote: > (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 <(647)%20867-5658> | US: +1 (415) 287-3867 > <(415)%20287-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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
