[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
I honestly think it is not, given the context – not until you read the IANA section. I would suggest: no changes (including any extensions). On 10/12/2024, 17:18, "Salz, Rich" wrote:English is hard. :). I think "no new features" is clear, given the context of the words around it. I could change it to "no changes" without changing the intended meaning if people prefer that. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
Does this diff address your concern? What about the title? As I recall, the
draft originally said “TLS 1.2 is frozen” but there were some who wanted it
changed.
--- a/draft-ietf-tls-tls12-frozen.md
+++ b/draft-ietf-tls-tls12-frozen.md
@@ -70,7 +70,7 @@ Use of TLS 1.3 is growing and fixes some known deficiencies
in TLS 1.2.
This document specifies that outside of
urgent security fixes, new TLS Exporter Labels, or new
Application-Layer Protocol Negotiation (ALPN) Protocol IDs,
-no new features will be approved for TLS 1.2.
+no changes will be approved for TLS 1.2.
This prescription does not pertain to DTLS (in any DTLS version); it pertains
to
TLS only.
@@ -88,7 +88,7 @@ Both versions have several extension points, so items like
new cryptographic
algorithms, new supported groups (formerly "named curves"), etc., can be
added without defining a new protocol. This document specifies that outside of
urgent security fixes, and the exceptions listed in {{iana}},
-no new features will be approved for TLS 1.2.
+no changes will be approved for TLS 1.2.
This prescription does not pertain to DTLS (in any DTLS version); it pertains
to
TLS only.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
The point of this draft was to go on the record (“it’s an RFC it must be true”) and say explicitly what the IETF will NOT be doing, and enforcing that by directing IANA (and the experts). Will this stop someone from re-using codepoints and backporting to their TLS 1.2 stack? Nope. It even work since TLS 1.3 handshake looks like TLS 1.2 :) We can’t prevent people from coloring outside the lines, but we can make it clear where the lines are. And I don’t see how we can do anything else, since the WG clearly has near-zero interest in saying “use this for TLS 1.2” I believe that not all the reasons for that are strictly technical, but I don’t care. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
Hello, 1. **Alignment of NamedGroup X25519MLKEM768** with the order of shared secrets, as per Section 3.2 of draft-ietf-tls-hybrid-design. - I suggest updating the name to mlkem768_x25519, while keeping the codepoint unchanged (if that is acceptable). If this change is made, I also recommend changing the name of Secp256r1MLKEM768 to align with x25519. Following the feedback from the last TLS meeting at IETF@121, I have opened this PR to change the name from X25519MLKEM768 to MLKEM768X25519. This change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2). https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26 2. **Changing the order of shares in Secp256r1MLKEM768**. - The current order is based on requirements from SP800-56C-r2, and it was chosen to facilitate the migration of the TLSv1.3 handshake in a flow requiring FIPS certification. Although the switched order of shares aligns with FIPS, it necessitates the re-certification of the cryptographic module. The current order supports modules that are already deployed in the field. My (slight) personal preference would be to proceed with adoption but switch the order only if NIST relaxes the requirement regarding the order of shares in SP800-56C-r2, which we know is under discussion. Otherwise, I believe the current choice better supports migration to non-hybrid MLKEM, but I would appreciate feedback on this decision (ideally from others who have a requirement for FIPS). According to the message from https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0, NIST plans to permit the ordering of shares in either direction. This approach addresses the previously mentioned issue, so no further changes are needed in this regard. I believe it is now appropriate to register an additional code point for Secp384r1MLKEM1024, as currently outlined in the draft. 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**. I think this can only be done once draft if adopted. Hence, no change here (for now). > On 11/11/2024 23:14, Andrei Popov wrote: > I support adoption. The question of explicitly prohibiting key share reuse is orthogonal; this can be done in a separate document. I agree that the PR was submitted to change the text in the draft, but I think it would be better to include this text in draft-ietf-tls-hybrid-design. I have opened this PR https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/39. With that I hope the draft is ready for adoption. Any feedback is more then welcome. Kind regards, Kris ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
On Tue, Dec 10, 2024 at 4:28 PM Kris Kwiatkowski wrote: > Following the feedback from the last TLS meeting at IETF@121, I have > opened this PR to change the name from X25519MLKEM768 to MLKEM768X25519. > This change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2). > Well, maybe the Spanish phrase "¿Por Qué No Los Dos?” (why not both?) is appropriate here. It seems like there's no way that either will collide with something else. thanks, Rob ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Adoption call for RFC 9147bis
This document has consensus to adopt, please post a 00 draft named draft-ietf-tls-rfc9147bis to be included as a working group document. On Mon, Dec 2, 2024 at 9:38 AM Joseph Salowey wrote: > This is a call for adoption of draft-rescorla-tls-rfc9147bis-00[1] as the > basis for an RFC9147 bis document. This document is seeded with the > content of RFC 9147. If you object to the adoption of this document please > respond to this thread by December, 9 2024. > > Cheers, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-rfc9147bis-00 > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] The TLS WG has placed draft-rescorla-tls-rfc9147bis in state "Adopted by a WG"
The TLS WG has placed draft-rescorla-tls-rfc9147bis in state Adopted by a WG (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-rfc9147bis/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
Hi all, I think this document is ready for publication. Cheers, Thom Wiggers Op ma 9 dec 2024 om 17:53 schreef Sean Turner : > Just a reminder that this WG last call is still ongoing. > > spt > > > On Dec 3, 2024, at 16:26, Sean Turner wrote: > > > > This is the working group last call for TLS 1.2 is in Feature Freeze. > Please review draft-ietf-tls-tls12-frozen [1] and reply to this thread > indicating if you think it is ready for publication or not. If you do not > think it is ready please indicate why. This call will end on December 17, > 2024. > > > > Cheers, > > spt > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-connolly-tls-mlkem-key-agreement
As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen (barring Q-day happening and the current hybrid key exchanges no longer making sense). Since the draft has “N” for the recommended column, I’m also pretty sanguine about it. As for people implementing it instead of hybrid, well, the working group can help to prevent that by moving ahead with the hybrid draft (hint, hint). Which one? Yours or Panos et al? :) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
jQcmQRYFpfptBannerEnd
For the second paragraph, I would prefer “no changes and no new extension
values”. I don’t have a better idea for the title, so even if I think it’s not
100% precise, I’m good with keeping it.
How about this?
This document specifies that outside of
urgent security fixes, and the exceptions listed in {{iana}},
no changes *or new registry entries* will be approved for TLS 1.2
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
Looks good. Thanks! From: Salz, Rich Date: Tuesday, 10 December 2024 at 18:41To: Yaron Sheffer , Alicja Kario Cc: TLS List Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature FreezejQcmQRYFpfptBannerEndFor the second paragraph, I would prefer “no changes and no new extension values”. I don’t have a better idea for the title, so even if I think it’s not 100% precise, I’m good with keeping it.How about this? This document specifies that outside ofurgent security fixes, and the exceptions listed in {{iana}},no changes *or new registry entries* will be approved for TLS 1.2 ___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
I would suggest "For TLS, it is important to note that PQC efforts are
exclusively for TLS 1.3 or later."
To me, the draft (even v3) is not clear on this point. At some point in future,
PQ will become an urgent security issue, and the wording "outside of urgent
security fixes" in the draft seems to imply that then we will start working on
PQC for TLS 1.2. I suggest being explicit on this point.
How about this:
For TLS it is important to note that the focus of these efforts is exclusively
TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT
be supported (see {{iana}}) at any time and anyone wishing to deploy
post-quantum cryptography should expect to be using TLS 1.3.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-tls12-frozen-03.txt
Thanks for the update. Just a quick reminder that my questions at the bottom of email [1] remain unaddressed. Usama [1] https://mailarchive.ietf.org/arch/msg/tls/6QoaLDE3_2UQTcawV2QQznQ5Pbs/ Aha, I missed that, sorry. I will reply on-thread now. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
Considering the following two statements in I-D, I have two questions: > For TLS it is important to note that the focus of these efforts is > TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2 > WILL NOT be supported. To me the two sentences are contradicting. Which one of the following is intended? The second sentence is intended to be a clarification and emphasis of the first. I’m not aware of any TLS WG efforts to define PQC and register them for TLS 1.2 and I believe the WG assumption – perhaps unstated? – is that these things require and assume TLS 1.3. It’s not just crypto suites, but also things like David Benjamin’s proposed keyshare draft, and other stuff. If you have a wording suggestion, I’d love to hear it. 1. (My understanding from 2nd sentence) We will exclusively work on PQC for TLS 1.3 or later. What does the capitalization of WILL NOT mean? I did not find any such capitalization in RFC 2119 and RFC 8174. Please add the relevant RFC in section 2 or define it. 2119/8174 doesn’t limit all other uses of uppercase letters :). It’s just for emphasis. > This > document specifies that outside of urgent security fixes, no new > features will be approved for TLS 1.2. If the intention of draft was #2 above, cross-reading with this sentence, are we implying that PQC is not an urgent security issue? Given our finite resources, regardless of the urgency of the issue, the IETF TLS WG is not spending effort to “fix” TLS 1.2 And this document is intended to inform the community of that. So if you want to be PQ, step is one make sure you are using TLS 1.3 ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
One of the things we need to be honest with ourselves about is that telling
people not to do it won’t prevent them from doing it.
So this decision is saying that WHEN people decide do PQC with TLS 1.2, they
will be doing so without IETF guidance about how to do it. If this is the path
we choose, we need to be ok with that.
I’m somewhat ok with that, but it does concern me and cause me to wonder if
there’s something better we can do.
-Tim
From: Salz, Rich
Sent: Tuesday, December 10, 2024 11:48 AM
To: Muhammad Usama Sardar ; Valery Smyslov
; 'Sean Turner' ; 'TLS List'
Subject: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
I would suggest "For TLS, it is important to note that PQC efforts are
exclusively for TLS 1.3 or later."
To me, the draft (even v3) is not clear on this point. At some point in future,
PQ will become an urgent security issue, and the wording "outside of urgent
security fixes" in the draft seems to imply that then we will start working on
PQC for TLS 1.2. I suggest being explicit on this point.
How about this:
For TLS it is important to note that the focus of these efforts is exclusively
TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT
be supported (see {{iana}}) at any time and anyone wishing to deploy
post-quantum cryptography should expect to be using TLS 1.3.
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
On 10.12.24 16:02, Salz, Rich wrote: The second sentence is intended to be a clarification and emphasis of the first. I’m not aware of any TLS WG efforts to define PQC and register them for TLS 1.2 and I believe the WG assumption – perhaps unstated? – is that these things require and assume TLS 1.3. It’s not just crypto suites, but also things like David Benjamin’s proposed keyshare draft, and other stuff. If you have a wording suggestion, I’d love to hear it. I would suggest "For TLS, it is important to note that PQC efforts are exclusively for TLS 1.3 or later." > This > document specifies that outside of urgent security fixes, no new > features will be approved for TLS 1.2. If the intention of draft was #2 above, cross-reading with this sentence, are we implying that PQC is not an urgent security issue? Given our finite resources, regardless of the urgency of the issue, the IETF TLS WG is not spending effort to “fix” TLS 1.2 And this document is intended to inform the community of that. So if you want to be PQ, step is one make sure you are using TLS 1.3 To me, the draft (even v3) is not clear on this point. At some point in future, PQ will become an urgent security issue, and the wording "outside of urgent security fixes" in the draft seems to imply that then we will start working on PQC for TLS 1.2. I suggest being explicit on this point. Usama smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
For the second paragraph, I would prefer “no changes and no new extension values”. I don’t have a better idea for the title, so even if I think it’s not 100% precise, I’m good with keeping it. From: Salz, Rich Date: Tuesday, 10 December 2024 at 17:45To: Yaron Sheffer , Alicja Kario Cc: TLS List Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature FreezeDoes this diff address your concern? What about the title? As I recall, the draft originally said “TLS 1.2 is frozen” but there were some who wanted it changed. --- a/draft-ietf-tls-tls12-frozen.md+++ b/draft-ietf-tls-tls12-frozen.md@@ -70,7 +70,7 @@ Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs,-no new features will be approved for TLS 1.2.+no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. @@ -88,7 +88,7 @@ Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, and the exceptions listed in {{iana}},-no new features will be approved for TLS 1.2.+no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. ___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
On 10.12.24 17:47, Salz, Rich wrote:
How about this:
For TLS it is important to note that the focus of these efforts is
exclusively TLS 1.3 or later. Put bluntly, post-quantum cryptography
for TLS 1.2 WILL NOT be supported (see {{iana}}) at any time and
anyone wishing to deploy post-quantum cryptography should expect to be
using TLS 1.3.
This is fine, thanks.
smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
English is hard. :). I think "no new features" is clear, given the context of the words around it. I could change it to "no changes" without changing the intended meaning if people prefer that. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-tls12-frozen-03.txt
Thanks for the update. Just a quick reminder that my questions at the bottom of email [1] remain unaddressed. Usama [1] https://mailarchive.ietf.org/arch/msg/tls/6QoaLDE3_2UQTcawV2QQznQ5Pbs/ smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
I think the draft is confusing to the point of almost being misleading, in particular with its use of the word “feature”. Based on the words “feature freeze” people on this list have interpreted it as merely “the TLS WG will no longer work on TLS 1.2”. But by blocking IANA registrations, this has much broader implications on real-world use of TLS 1.2. This confusion is true for the document’s title, as well as the introduction, quoting: Both [TLS] versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, and the exceptions listed in Section 4, no new features will be approved for TLS 1.2. Most people would read it to mean that no new *features* (e.g. new TLS messages) will be added, but that the “extension points” (e.g. new ciphersuites) continue to be available. Thanks, Yaron On 09/12/2024, 21:01, "Alicja Kario" wrote:I think it's ready for publication. On Tuesday, 3 December 2024 22:26:30 CET, Sean Turner wrote:> This is the working group last call for TLS 1.2 is in Feature > Freeze. Please review draft-ietf-tls-tls12-frozen [1] and reply > to this thread indicating if you think it is ready for > publication or not. If you do not think it is ready please > indicate why. This call will end on December 17, 2024.> > Cheers,> spt> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ -- Regards,Alicja (nee Hubert) KarioPrincipal Quality Engineer, RHEL Crypto teamWeb: www.cz.redhat.comRed Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
No, support for a new ciphersuite, especially one that uses new primitives, is a _new feature._ At least, that's how we operate, and I am not aware of any discussions about that being confusing to customers... So I'm pretty sure that "Most people" is not correct. On Tuesday, 10 December 2024 12:44:44 CET, Yaron Sheffer wrote: I think the draft is confusing to the point of almost being misleading, in particular with its use of the word “feature”. Based on the words “feature freeze” people on this list have interpreted it as merely “the TLS WG will no longer work on TLS 1.2”. But by blocking IANA registrations, this has much broader implications on real-world use of TLS 1.2. This confusion is true for the document’s title, as well as the introduction, quoting: Both [TLS] versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, and the exceptions listed in Section 4, no new features will be approved for TLS 1.2. Most people would read it to mean that no new *features* (e.g. new TLS messages) will be added, but that the “extension points” (e.g. new ciphersuites) continue to be available. Thanks, Yaron On 09/12/2024, 21:01, "Alicja Kario" wrote: I think it's ready for publication. On Tuesday, 3 December 2024 22:26:30 CET, Sean Turner wrote: This is the working group last call for TLS 1.2 is in Feature Freeze. Please review draft-ietf-tls-tls12-frozen [1] and reply to this thread indicating if you think it is ready for publication or not. If you do not think it is ready please indicate why. This call will end on December 17, 2024. Cheers, spt [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-connolly-tls-mlkem-key-agreement
Daniel
I’m writing in response to your request below. I am told that your email
server may require me to agree to terms before delivery, which I will not be
doing, so it may be that this response is not delivered directly.
While I am an author of RFC 9680 it is an IETF consensus document and therefore
represents the view of IETF community as a whole.
If your concern is that the IETF processes contain an overlooked antitrust
risk, then please note that it is the view of the IETF, as stated in RFC 9680,
that "the IETF structure and processes are designed to mitigate antitrust
risks" and that "compliance with BCPs and other relevant policies … facilitates
compliance with antitrust law". This is a view that has been thoroughly
checked with multiple sets of counsel [1]. If you want to see a change to the
IETF processes to address a perceived antitrust risk then you should follow the
IETF process for making that happen.
If, on the other hand, your concern is that there has been a failure of IETF
processes that has created an antitrust risk, then the appropriate course of
action is to follow the appropriate IETF process for addressing that.
Given my role is only to support the IETF standards process, any more detailed
explanation of any of that process, is best left to others.
[1]
https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/
Jay
> On 7 Dec 2024, at 15:19, D. J. Bernstein wrote:
>
> I'm adding an RFC 9680 coauthor to the To line to request IETF LLC
> attention to the antitrust issues here.
>
> Scott Fluhrer (sfluhrer) writes:
>> There are people whose cryptographic expertise I cannot doubt who say
>> that pure ML-KEM is the right trade-off for them
>
> Please note that antitrust law forces standardization organizations to
> follow procedures that prevent anti-competitive activities. Here's an
> introduction to the topic from the American Bar Association:
>
>
> https://www.google.com/books/edition/Handbook_on_Antitrust_Aspects_of_Standar/zin5tgAACAAJ
>
> Having a company influencing IETF decisions by making claims about what
> customers are demanding---with no explanation of _why_ those demands are
> being made, and no opportunity for IETF review of the merits of those
> rationales---is exposing IETF to antitrust litigation. Even if the
> specific incident at hand isn't meant to suppress competition, it shows
> that IETF doesn't have the requisite procedural protections in place, so
> it provides evidence helpful for _anyone_ who decides to sue IETF about
> _any_ standardization topic.
>
> As a side note, the "could still be construed as representing their
> employer" part of RFC 9680 is certainly triggered by a message that's
> adding weight to its argument by explicitly invoking the company's name
> (in this case: "Cisco will implement it").
>
>> I am essentially just asking for code points.
>
> Hmmm. If the only request were for allocation from an open namespace
> (which apparently has been done already), then why make claims about the
> supposed desirability of omitting normal hybrid defenses? I also don't
> see how the collective-action text ("I understand that people want to
> discuss the hybrid KEM draft more (because there are more options there)
> - can we at least get the less controversial part done?") can be
> interpreted as merely an administrative allocation request. One followup
> said "Can we start an adoption call?" and another said "+1".
>
> Furthermore, email dated 24 Oct 2024 03:15:38 +, in the analogous
> context of ML-DSA, said that "Cisco" has "some customers who want ML-DSA
> only", and concluded that "we'll end up standardizing" that.
>
> The ML-DSA discussion sounded like some people think that NSA refuses to
> authorize U.S. government purchasing of hybrids (outside some special
> circumstances). I asked whether that's true---whether NSA has in fact
> banned hybrids. I quoted an official NSA statement saying "hybrid
> solutions may be allowed or required due to protocol standards, product
> availability, or interoperability requirements"; I said this "will be
> triggered if, e.g., the TLS WG issues an RFC requiring all PQ in TLS to
> be hybrid"; I haven't seen a counterargument.
>
> Now the WG is again being told, again without a rationale, that some
> unspecified cryptographic experts with money are demanding non-hybrids.
> Even if it's true that NSA is banning hybrids (is it?), I'm opposed to
> non-hybrids on security grounds and on BCP 188 grounds. But the more
> basic point is that IETF's decisions on the topic have to comply with
> IETF's procedural obligations under antitrust law.
>
> ---D. J. Bernstein
--
Jay Daley
IETF Executive Director
exec-direc...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
