2021-08-27 05:08 GMT+02:00 Joseph Salowey <j...@salowey.net>: > Thanks for all the discussion on this topic. There are several modes that > TLS 1.2 can operate with respect to DH. Below is a proposal on cases to > merge some of the cases covered by this draft into the obsolete keyex draft. > I'd like to see if there is some consensus to make this change before we > adopt it into the working group. > > 1. static-static where both client and server have DH certificates with long > term keys. I think we have general consensus that this mode should be a must > not. To deprecate this mode I think we need to state that clients MUST NOT > use certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT > request them. Would the working group support merging this guidance into the > obsolete keyex draft? > > 2. ephemeral-static where the client uses an ephemeral key and the server > uses a long term key. This mode does not provide forward secrecy. I'm not > sure we have reached consensus on how far to deprecate this option. Would > the working group support MUST NOT use these ciphersuites unless forward > secrecy does not matter for your use case and any implementation guidance > provided to avoid weaknesses is followed?
The implementation guidance to avoid weaknesses in any ephemeral-static exchange is "don't get anything wrong, anything at all, all the way down to your field arithmetic libraries". I don't think that's a workable recommendation, and I believe we should deprecate modes that are so unsafe to implement. > 3. ephemeral-ephemeral - I think these are already covered in the obsolete > keyex draft. > > Thanks, > > Joe > > On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle <cbartle...@icloud.com> wrote: >>> > which is a main reason cited for deprecating RSA in >>> > draft-aviram-tls-deprecate-obsolete-kex.____ >>> >>> Have the authors look at Post-Quantum KEMs? >> >> I'm not sure why PQ KEMs are relevant here. >> >> >>> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL >>> <u...@ll.mit.edu> wrote: >>> >>> > Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do >>> > not provide____ >>> > forward secrecy,____ >>> __ __ >>> Unless you use semi-static exchange, which in many cases makes sense.____ >>> __ __ >>> > which is a main reason cited for deprecating RSA in >>> > draft-aviram-tls-deprecate-obsolete-kex.____ >>> __ __ >>> Have the authors look at Post-Quantum KEMs?____ >>> __ __ >>> > 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?____ >>> __ __ >>> I think these suites should stay around. ____ >>> __ __ >>> While static-static indeed do not provide forward secrecy (and many of us – >>> though not everybody! – carry for that), static-ephemeral DH and ECDH are >>> perfectly fine from that point of view.____ >>> __ __ >>> __ __ >>> __ __ >>> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
