Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
There is general consensus to adopt this draft as a working group item. There is an open issue as to what content from the FFDH draft to merge into this one. While that does not prevent us from bringing the draft into the working group we will give some time to see if we can come to consensus on the content to be merged in on the other thread. Cheers, The TLS Chairs On Thu, Jul 29, 2021 at 2:50 PM Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). > There was support for adopting this draft at the IETF 111 meeting. 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
I support adoption. David On Mon, Aug 9, 2021 at 11:24 AM Loganaden Velvindron wrote: > I also support adoption. > > On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle > wrote: > > > > I support adoption. > > > > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00). > There was support for adopting this draft at the IETF 111 meeting. 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 > > > > > > ___ > > 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
I also support adoption. On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle wrote: > > I support adoption. > > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00). There > was support for adopting this draft at the IETF 111 meeting. 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 > > > ___ > 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
I support adoption. > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). > There was support for adopting this draft at the IETF 111 meeting. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Thu, Jul 29, 2021 at 02:50:20PM -0700, Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). > There was support for adopting this draft at the IETF 111 meeting. Please > review the draft and post your comments to the list by Friday, August 13, > 2021. Adopt. And then fold the material from deprecate-ffdhe in. Then I think nobody cares about KRB5 key exchange: - There are no AES ciphers for it. - It does not work with TLS 1.3 at all, and there are no plans to make it work. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one? Either way, I would support deprecating FFDHE completely. > On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni wrote: > > On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote: > >>> Was it wrong to generate server-side DH parameters? >> >> The problem is that it is hard for the client to distinguish between a >> well designed server vs a server that isn't as well written, and >> selects the DH group in a naïve way. > > I am well aware that verifying the safety of the server's choice is > computationally taxing. > >> Now, as I mentioned in the WG meeting, it would be possible to detect >> if the server proposes a safe prime (it's not especially cheap, being >> several times as expensive as the rest of the DH operations, but it's >> possible), and that would prevent most of the problems that can happen > > I don't think it is realistic for the client to go to that much trouble. > The server's choice of parameters is signed by the server's public key. > What is the threat model here? Is the client trying to avoid servers > that shoot themselves in the foot by verifiably choosing bad parameters? > > The server could also have a strong DH group, but a terrible RNG with a > well known RSA private key: > >http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html > > If the server is not one of these or similar, and attests to its choice > of DH parameters, and they happen to be less than ideal, so be it. > Server operators should be encouraged to choose strong parameters, but I > see little reason for clients to second-guess that choice. > > If the DH parameter size is below a reasonable threshold (Logjam), a > client might balk, but otherwise I am not sure what practical problem > we're actually solving. > >> Of course, this works only if the legacy servers you are talking about >> actually do use safe primes... > > All the ones I know of use "openssl dhparam", which defaults to Sophie > Germain strong primes with generator 2. > > I strongly doubt there's a non-negligible server population with weak > locally generated groups. The only likely source of weak groups is > servers that used one the older now deemed weak groups published in > deprecated RFCs. > > So it might suffice to refuse specific known weak "standard" groups, > which would have a much lower impact than requiring particular standard > groups with no mechanism to negotiate these. > > -- >Viktor. > > ___ > 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >with confirmation from Peter Gutmann below that any custom groups we're >likely to encounter are almost certainly safe Well, I haven't examined every crypto library on the planet, it's not to say there isn't something somewhere that implements its keygen as: for i = 0 to 256 dhprime[ i ] = rand(); but of the ones I'm aware of, when you ask for DLP parameters you get something appropriate like Sophie Germain primes or FIPS 186 or equivalent, e.g. Lim-Lee parameter generation. >I don't see a realistic scenario in which sufficiently large ad-hoc server DH >parameters are a problem. +1. Also if mentioning specific published values it'd be good to go with 3526 rather than 7919 due to the non-use of 7919 in implementations (unless there are implementations using the 7919 primes while not implementing 7919 itself). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote: > Looks like we have consensus for the following: IIRC we're not looking for consensus on the substance of the draft at this point, this just a WG adoption call. So the issues below do not need to be resolved at this time... We just happen to be taking the opportunity to discuss them... > - Clients may choose to not support FFDHE, a la Chrome. I don't see > consensus for full deprecation of FFDHE, please correct me if I'm wrong. > - Clients must not connect when the server uses a group of less than 2048 > bits. > - Clients may connect when the server uses a well-known, safe prime group > of at least 2048 bits (well-known might mean "from RFC 7919 plus the > built-in Postfix group", or other reasonable definitions). > - Clients may connect when the server uses a custom safe prime group of at > least 2048 bits, if the client verifies that the prime is safe. > > The only point where we don't have consensus seems to be: > - For clients who choose to support FFDHE, when the server uses a custom > group of at least 2048 bits, and the client isn't willing to check > safe-primality, what should the client do? And so, with confirmation from Peter Gutmann below that any custom groups we're likely to encounter are almost certainly safe (given a sufficiently large prime), I see no need to do anything beyond: - Client should set a floor on the FFDHE group size that is appropriate for its application ecosystem. Typically 2048, in ecosystems where smaller groups are sufficiently rare to non-existent. - A few specific, previously recommended, "standard" groups might now be explicitly refused. - Given that neither of the above can be negotiated in TLS 1.2, some clients and servers might choose to drop support for FFDHE either in TLS 1.2 or across the board. I don't see a realistic scenario in which sufficiently large ad-hoc server DH parameters are a problem. Only some specific "standard" groups (from outdated informational RFCs, ...) of suspect provenance might reasonably be blacklisted. On Sun, Aug 01, 2021 at 11:42:22AM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >OK, who goes around bothering to actually generate custom DH parameters, and > >with what tools, but then does not use a "strong" (Sophie Germain) prime? > > That's better :-). That was my thought too, every DH/DLP keygen I've seen > generates either Sophie Germain or FIPS 186 primes/parameters, so on the off > chance that your server feels like generating custom primes you'd need to go > out of your way to generate unsuitable ones, i.e. you'd probably need to write > custom code specifically for bad prime generation, and if you're going to do > that then all bets are off anyway. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >OK, who goes around bothering to actually generate custom DH parameters, and >with what tools, but then does not use a "strong" (Sophie Germain) prime? That's better :-). That was my thought too, every DH/DLP keygen I've seen generates either Sophie Germain or FIPS 186 primes/parameters, so on the off chance that your server feels like generating custom primes you'd need to go out of your way to generate unsuitable ones, i.e. you'd probably need to write custom code specifically for bad prime generation, and if you're going to do that then all bets are off anyway. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Looks like we have consensus for the following: - Clients may choose to not support FFDHE, a la Chrome. I don't see consensus for full deprecation of FFDHE, please correct me if I'm wrong. - Clients must not connect when the server uses a group of less than 2048 bits. - Clients may connect when the server uses a well-known, safe prime group of at least 2048 bits (well-known might mean "from RFC 7919 plus the built-in Postfix group", or other reasonable definitions). - Clients may connect when the server uses a custom safe prime group of at least 2048 bits, if the client verifies that the prime is safe. The only point where we don't have consensus seems to be: - For clients who choose to support FFDHE, when the server uses a custom group of at least 2048 bits, and the client isn't willing to check safe-primality, what should the client do? (This only applies when FFDHE is chosen in practice, rather than ECDHE.) My personal opinion is that both options - either allowing or forbidding the client to connect - would be reasonable here. Perhaps it'd be best to leave this specific point to the next WG meeting? We can still make progress on the document in the meanwhile. I'll also ask around if we can get some metrics, in general and specifically pertaining to that last point. thanks again everyone, Nimrod -- Forwarded message - From: Viktor Dukhovni Date: Sat, 31 Jul 2021 at 19:12 Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS To: On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >I strongly doubt there's a non-negligible server population with weak locally > >generated groups. > > Would you care to rephrase that so we can make sure you're saying what we > think you're saying in order to disagree with it? OK, who goes around bothering to actually generate custom DH parameters, and with what tools, but then does not use a "strong" (Sophie Germain) prime? The only weakness I expect to encounter is a deprecated size of e.g. 512, 768 or 1024 bits. Clients can easily detect that and enforce a floor, but of course still don't get to negotiate a minimum. Clients also don't get to negotiate the size of the server's RSA public key, or as you mentioned various other ways for the server to not screw up. -- Viktor. ___ 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >I strongly doubt there's a non-negligible server population with weak locally > >generated groups. > > Would you care to rephrase that so we can make sure you're saying what we > think you're saying in order to disagree with it? OK, who goes around bothering to actually generate custom DH parameters, and with what tools, but then does not use a "strong" (Sophie Germain) prime? The only weakness I expect to encounter is a deprecated size of e.g. 512, 768 or 1024 bits. Clients can easily detect that and enforce a floor, but of course still don't get to negotiate a minimum. Clients also don't get to negotiate the size of the server's RSA public key, or as you mentioned various other ways for the server to not screw up. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >I strongly doubt there's a non-negligible server population with weak locally >generated groups. Would you care to rephrase that so we can make sure you're saying what we think you're saying in order to disagree with it? Peter :-). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Scott Fluhrer (sfluhrer) writes:
>The problem is that it is hard for the client to distinguish between a well
>designed server vs a server that isn't as well written, and selects the DH
>group in a naïve way.
What should the client do if it could detect this? And how would it
distinguish between a server that selects bad DH parameters, a server that
uses time() to seed its RNG for prime generation, a server that has a buffer
overflow allowing RCE, and a server whose ACLs allow read/write access to any
file on the filesystem including its private key(s)?
>Now, as I mentioned in the WG meeting, it would be possible to detect if the
>server proposes a safe prime (it's not especially cheap, being several times
>as expensive as the rest of the DH operations, but it's possible),
Or you could use TLS-LTS, which sends { p, q, g } allowing the client to
verify certain properties about the primes being used at next to no cost.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >Can you explain what you mean by "don't do things that you should never have >been doing in the first place"? Just what the draft says, don't use static-ephemeral DH, don't reuse DHE secrets, etc. It seems a bit like publishing an RFC telling people not to stick forks in light sockets, but I guess enough people must have been sticking forks in light sockets to make it necessary. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote: > > Was it wrong to generate server-side DH parameters? > > The problem is that it is hard for the client to distinguish between a > well designed server vs a server that isn't as well written, and > selects the DH group in a naïve way. I am well aware that verifying the safety of the server's choice is computationally taxing. > Now, as I mentioned in the WG meeting, it would be possible to detect > if the server proposes a safe prime (it's not especially cheap, being > several times as expensive as the rest of the DH operations, but it's > possible), and that would prevent most of the problems that can happen I don't think it is realistic for the client to go to that much trouble. The server's choice of parameters is signed by the server's public key. What is the threat model here? Is the client trying to avoid servers that shoot themselves in the foot by verifiably choosing bad parameters? The server could also have a strong DH group, but a terrible RNG with a well known RSA private key: http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html If the server is not one of these or similar, and attests to its choice of DH parameters, and they happen to be less than ideal, so be it. Server operators should be encouraged to choose strong parameters, but I see little reason for clients to second-guess that choice. If the DH parameter size is below a reasonable threshold (Logjam), a client might balk, but otherwise I am not sure what practical problem we're actually solving. > Of course, this works only if the legacy servers you are talking about > actually do use safe primes... All the ones I know of use "openssl dhparam", which defaults to Sophie Germain strong primes with generator 2. I strongly doubt there's a non-negligible server population with weak locally generated groups. The only likely source of weak groups is servers that used one the older now deemed weak groups published in deprecated RFCs. So it might suffice to refuse specific known weak "standard" groups, which would have a much lower impact than requiring particular standard groups with no mechanism to negotiate these. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
> Was it wrong to generate server-side DH parameters? The problem is that it is hard for the client to distinguish between a well designed server vs a server that isn't as well written, and selects the DH group in a naïve way. For example, if the server just selects a random prime and a random generator value, well, that has a good probability of leaking quite a bit of information about the private exponents; leak enough, and the shared secret may be recoverable. This is not obvious to someone new to the field; it is also very hard to detect by the client. Now, as I mentioned in the WG meeting, it would be possible to detect if the server proposes a safe prime (it's not especially cheap, being several times as expensive as the rest of the DH operations, but it's possible), and that would prevent most of the problems that can happen (exception: if the server proposes an SNFS-friendly modulus, say, one with a very simple binary representation - that would reduce the security noticeably). Of course, this works only if the legacy servers you are talking about actually do use safe primes... -Original Message- From: TLS On Behalf Of Viktor Dukhovni Sent: Friday, July 30, 2021 2:57 PM To: tls@ietf.org Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE > >cipher code points that use negotiated groups from the group list. > >But it is far from clear that this is worth doing given that we now have > >ECDHE, X25519 and X448. > > There's still an awful lot of SCADA gear that does FFDHE, and that's > never going to change from that. The current draft as it stands is > fine, in fact it seems kinda redundant since all it's saying is "don't > do things that you should never have been doing in the first place", > but I assume someone needs to explicitly say that. No need to go beyond that. Can you explain what you mean by "don't do things that you should never have been doing in the first place"? There are quite a few deployments that generate local strong (Sophie Germain prime) DH parameters. These would break if the draft sails through as-is, and there's no mechanism for the client to inform the legacy server that its would be choice of DH parameters is not acceptable. Was it wrong to generate server-side DH parameters? -- Viktor. ___ 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
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code > >points that use negotiated groups from the group list. But it is far from > >clear that this is worth doing given that we now have ECDHE, X25519 and X448. > > There's still an awful lot of SCADA gear that does FFDHE, and that's never > going to change from that. The current draft as it stands is fine, in fact it > seems kinda redundant since all it's saying is "don't do things that you > should never have been doing in the first place", but I assume someone needs > to explicitly say that. No need to go beyond that. Can you explain what you mean by "don't do things that you should never have been doing in the first place"? There are quite a few deployments that generate local strong (Sophie Germain prime) DH parameters. These would break if the draft sails through as-is, and there's no mechanism for the client to inform the legacy server that its would be choice of DH parameters is not acceptable. Was it wrong to generate server-side DH parameters? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code >points that use negotiated groups from the group list. But it is far from >clear that this is worth doing given that we now have ECDHE, X25519 and X448. There's still an awful lot of SCADA gear that does FFDHE, and that's never going to change from that. The current draft as it stands is fine, in fact it seems kinda redundant since all it's saying is "don't do things that you should never have been doing in the first place", but I assume someone needs to explicitly say that. No need to go beyond that. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote: > On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). > > There was support for adopting this draft at the IETF 111 meeting. > > Please review the draft and post your comments to the list by Friday, > > August 13, 2021. > > Yep, let's do it. There were comments suggesting that this wasn't > going to work for some deployments yet. That's OK, that's how this > works: we decide to deprecate, discuss and publish a document, then > people get to work out how they change their deployments. If we don't > take that first step, then in many ways things don't get better. > Adopting this is that first step and a good idea. I support adoption of the draft and deprecation of RSA key exchange. For FFDHE, I'd much rather see outright deprecation a la Chrome, than a silent restriction by client (with no mechanism to negotiate otherwise0 to parameters that the server may not be prepared to support. The only other alternative is to define brand new TLS 1.2 FFDHE cipher code points that use negotiated groups from the group list. But it is far from clear that this is worth doing given that we now have ECDHE, X25519 and X448. There is far less risk of interoperability failure if the client or drops support for FFDHE, rather than silently chooses to reject previously working parameters. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). > There was support for adopting this draft at the IETF 111 meeting. Please > review the draft and post your comments to the list by Friday, August 13, > 2021. Yep, let's do it. There were comments suggesting that this wasn't going to work for some deployments yet. That's OK, that's how this works: we decide to deprecate, discuss and publish a document, then people get to work out how they change their deployments. If we don't take that first step, then in many ways things don't get better. Adopting this is that first step and a good idea. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
>This is a working group call for adoption of Deprecating Obsolete Key Exchange >Methods in TLS >(draft-aviram-tls-deprecate-obsolete-kex-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/__;!!GjvTz_vk!CUaGTbvSYQ3DqDrOKc8u-gxiKl8fNJqub7cH02BMcUQ1RgVfZ05cd5LLqbQG$>). > There was support for adopting this draft at the IETF 111 meeting. I support adoption and will work to help make it better. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
This is a working group call for adoption of Deprecating Obsolete Key Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>). There was support for adopting this draft at the IETF 111 meeting. 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
