D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated
> the Dual EC points randomly and that Dual EC is secure.
Do you have a link to the video? Such a comment is surprising as it is a very
bad PR strategy. “No comment” is a far better strategy.
John Mattsson writes:
> We would not be prepared for PQC if it was not for the NSA.
Um, what?
The PQCrypto conferences started in 2006. The PQCRYPTO grant application
was filed in 2014---that's the project that produced the specifications
and software for Classic McEliece, Dilithium, FrodoKEM, Ky
des state-of-the-art security.
From: Blumenthal, Uri - 0553 - MITLL
Date: Sunday, 15 December 2024 at 05:44
To: John Mattsson , tls@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA
On Sat, 14 Dec 2024 at 12:00, Viktor Dukhovni wrote:
>
> On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:
>
> > You continue to violate list policy with unprofessional commentary on other
> > participants' motivations and repeatedly raising points that are out of
> > scope. Please
D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated
> the Dual EC points randomly and that Dual EC is secure.
Do you have a link to the video? Such a comment is surprising as it is a very
bad PR strategy. “No comment” is a far better strategy.
T
I would also be against a temporarily ban at this point, but hopefully the
warning will help reduce unprofessional commentary and personal attacks in the
future. Commentaries on other participants' motivations should not be forbidden
in general, and I don't think they are according to any IETF p
D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated
> the Dual EC points randomly and that Dual EC is secure.
Do you have a link to the video? Such a comment is surprising as it is a very
bad PR strategy. “No comment” is a far better strategy. The
On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:
> You continue to violate list policy with unprofessional commentary on other
> participants' motivations and repeatedly raising points that are out of
> scope. Please stop this behavior. This is the last warning before we will
> ta
Hi Dan,
You continue to violate list policy with unprofessional commentary on other
participants' motivations and repeatedly raising points that are out of
scope. Please stop this behavior. This is the last warning before we will
take action and temporarily ban you from the list; see BCP 94 [0].
Adding antitrust-pol...@ietf.org; but I'm replying to a tls@ietf.org
message, and the antitrust issues here are clearly relevant to an
ongoing TLS discussion, so I'm also keeping tls@ietf.org.
Rob Sayre writes:
> I think you can find Brad Biddle saying "the process is fine" about all of
> these le
Deirdre Connolly writes:
> I wrote it because I wanted to use it. Enough.
Don't proposals to IETF always claim that there will be users? This is
content-free, and not a valid argument for IETF endorsement.
Back in March, the first message announcing the draft similarly didn't
give a technological
> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of
this spec.
No. I proposed this document because I want to be able to negotiate PQ-only
key establishment without hybrid. It got codepoints and now is getting more
support, which is nice. I wrote it because I wanted to use it.
> > > Security is not easy to evaluate. Asking random users to make
> > > security decisions is a recipe for disaster. Blaming users for the
> > > resulting failures simply perpetuates the problem.
> And you would have a point if this was a decision between a known broken
> scheme and a known to be
On Fri, Dec 13, 2024 at 11:29 AM Sophie Schmieg wrote:
> Answers inline. I will only bother to answer questions others might have
> as well, and ignore the rather laughable legal speculation.
>
I don't agree with Daniel, but let's not say words like "laughable". It's
just an insult.
I think you
Answers inline. I will only bother to answer questions others might have as
well, and ignore the rather laughable legal speculation.
> "I do not see a security concern with having the option for RC4 in TLS.
> TLS has ways of negotiating algorithms. If one side believes RC4 to be
> insufficiently
Sophie Schmieg writes:
> I do not see a security concern with having the option for pure ML-KEM in
> TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
> be insufficiently secure, they can negotiate 0x11EC (which equally should
> be adopted).
"I do not see a security conce
Hi Daniel
> On 13 Dec 2024, at 13:49, D. J. Bernstein wrote:
>
> Jay Daley writes:
>> I took your note to me as invoking the escalation path that RFC 9680
>> provides information on and consulted with counsel and the response
>> is, as previously conveyed, that your concern should be addressed
>
Sean Turner writes:
> Scott is not an author of this draft
The draft author claimed at the outset that hybrids were currently a
"big 'maybe' at best" under "FIPS / CNSA 2.0 compliance guidelines" and
would be prohibited by 2033. Scott's message was simply explicit about
the money flow ("more impor
Jay Daley writes:
> I took your note to me as invoking the escalation path that RFC 9680
> provides information on and consulted with counsel and the response
> is, as previously conveyed, that your concern should be addressed
> through the standards process.
Thanks for your message. I have three
+1 for adoption
Dan.
On 12/12/24 2:06 PM, Filippo Valsorda wrote:
2024-12-07 18:36 GMT+01:00 Watson Ladd :
Having MLKEM without a hybrid as an option in TLS when the
interoperable choice is a hybrid is not going to exclude people.
Furthermore we didn't hybridize x25519 and RSA. It's cle
+1 for adoption, and not commenting on the silliness of the counterargument
brought up here, because it is silly.
I do not see a security concern with having the option for pure ML-KEM in
TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
be insufficiently secure, they can
2024-12-07 03:19 GMT+01:00 D. J. Bernstein :
> 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 t
Hi Daniel,
Joe and I have reviewed the thread and believe that while Scott’s email is in a
grey area with respect to Section 6.1 of RFC 9680 (an informational RFC that
provides “Antitrust Guidelines for IETF Participants”), we do not believe that
email should impact this draft being discussed o
2024-12-07 18:36 GMT+01:00 Watson Ladd :
> Having MLKEM without a hybrid as an option in TLS when the interoperable
> choice is a hybrid is not going to exclude people.
>
> Furthermore we didn't hybridize x25519 and RSA. It's clear some people
> believe ML-KEM is secure enough for their uses.
A
> On 13 Dec 2024, at 09:43, Jay Daley wrote:
>
> Hi Daniel
>
>> On 13 Dec 2024, at 06:28, D. J. Bernstein wrote:
>>
>> RFC 9680 coauthor writes:
>>> 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
>>> app
Hi Daniel
> On 13 Dec 2024, at 06:28, D. J. Bernstein wrote:
>
> RFC 9680 coauthor writes:
>> 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 p
RFC 9680 coauthor writes:
> 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.
RFC 9680 says that it's "generally inapp
FWIW and probably not relevant, DoD CAC has never used DSA.
FORTEZZA used DSA.
-Original Message-
From: Alicja Kario [mailto:hka...@redhat.com]
Sent: Monday, December 9, 2024 2:23 PM
To: D. J. Bernstein
Cc: tls@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
On
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 t
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 h
Pursuant to this thread, preliminary support for MLKEM768-only has been
merged into rustls (I contributed):
https://github.com/rustls/rustls/pull/2259
On Thu, Dec 5, 2024 at 4:10 PM Scott Fluhrer (sfluhrer) wrote:
> How do we proceed with this draft?
>
>
>
> This draft is quite boring (which is
On Saturday, 7 December 2024 23:32:03 CET, D. J. Bernstein wrote:
Watson Ladd writes:
Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid
Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hy
+1 for adoption
While I'm stronly against wide deployment of pure ML-KEM at this moment in
time, I'm very much in favour of adoption of this document, having
stable definitions for such codepoints, even if they will get doployed only
in closed networks is still useful.
On Thursday, 5 December 20
Watson Ladd writes:
> Having MLKEM without a hybrid as an option in TLS when the interoperable
> choice is a hybrid
Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hybrids so "we'll end up
standardizing both". If the claim is true (
P256+MLKEM and
P384+MLKEM.
Cheers,
Andrei
From: John Mattsson
Sent: Friday, December 6, 2024 11:17 PM
To: Andrey Jivsov ; TLS@ietf.org
Subject: [EXTERNAL] [TLS] Re: draft-connolly-tls-mlkem-key-agreement
For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and
make that the
Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid is not going to exclude people.
Furthermore we didn't hybridize x25519 and RSA. It's clear some people
believe ML-KEM is secure enough for their uses.
There also is no protocol police: code points for this
Salz, Rich writes:
> The IETF has lawyers who are familiar with how the IETF works, and
> that legal counsel finds our processes acceptable level of risk.
RFC 9680 was issued in October 2024 and says that it's "intended to
educate IETF participants about how to reduce antitrust risks in
connection
The IETF has long accepted that saying "we have customers who want this" as a
metric into its decisions. If Foo.Com says they have customers for RFC X, then
the IETF community believes it is more likely that Foo.Com will implement RFC
X. Market acceptance is important to what the IETF considers
21:45
To: TLS@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I second D.J. Bernstein's concerns, but my other issue with giving options like
this is that they will creep up into MTI sets or default sets, with higher
priority than hybrids.
I find it less ideal that the doc
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 for
> Which one? Yours or Panos et al? :)
I don’t care – we just need something reasonable, and those both qualify…
From: Salz, Rich
Sent: Friday, December 6, 2024 5:58 PM
To: Scott Fluhrer (sfluhrer) ; Andrey Jivsov
; TLS@ietf.org
Subject: Re: [TLS] Re: draft-connolly-tls-mlkem-key-agreem
ople implementing it instead of hybrid, well, the working group
> can help to prevent that by moving ahead with the hybrid draft (hint, hint).
>
>
>
> *From:* Andrey Jivsov
> *Sent:* Friday, December 6, 2024 3:44 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] Re: draft-connolly
Jivsov
Sent: Friday, December 6, 2024 3:44 PM
To: TLS@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I second D.J. Bernstein's concerns, but my other issue with giving options like
this is that they will creep up into MTI sets or default sets, with higher
priority
I second D.J. Bernstein's concerns, but my other issue with giving options
like this is that they will creep up into MTI sets or default sets, with
higher priority than hybrids.
I find it less ideal that the document on pure ML-KEM (or signature) and
hybrids are disassociated, causing the progress
Scott Fluhrer (sfluhrer) writes:
> 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?
See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur se
+1
From: Russ Housley
Date: Thursday, 5 December 2024 at 22:20
To: Scott Fluhrer (sfluhrer)
Cc: IETF TLS
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I hope so. Can we start an adoption call?
Russ
On Dec 5, 2024, at 4:08 PM, Scott Fluhrer (sfluhrer)
wrote:
How do we proceed
I hope so. Can we start an adoption call?
Russ
> On Dec 5, 2024, at 4:08 PM, Scott Fluhrer (sfluhrer)
> wrote:
>
> How do we proceed with this draft?
>
> This draft is quite boring (which is good from a cryptographical
> perspective); it just says ‘take ML-KEM and insert it as a key agreem
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of any
kind can be done. Where do IANA preallocations start bumping up against "well
we're doing something completely different anyway"?
Your co-c
On Fri, Nov 1, 2024 at 2:02 PM Alicja Kario wrote:
> On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
> >> Tangentially, this is registering a `NamedGroup` /
> >> `SupportedGroup`, but of course it's not a group, it's a KEM
> >> scheme over which no Diffie-Hellman of any kind can b
On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
Tangentially, this is registering a `NamedGroup` /
`SupportedGroup`, but of course it's not a group, it's a KEM
scheme over which no Diffie-Hellman of any kind can be done.
Where do IANA preallocations start bumping up against "wel
> The FFDH range isn't treated special because of naming but because of
some mistakes that RFC 7919 made where the implementation actually needs to
categorize codepoints.
Gotcha, cheers.
I'm definitely not advocating another name change, it's not worth it
On Fri, Nov 1, 2024, 1:03 PM David Benja
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
of any kind can be done. Where do IANA preallocations start bumping up
against "well we're doing something completely different anyway"?
The decidin
If there's a choice to be made I favor the 512 513 514 choices
On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly
wrote:
> Ah, oops!
>
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
> of any kind
Ah, oops!
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of
any kind can be done. Where do IANA preallocations start bumping up against
"well we're doing something completely different anyway"?
O
I made a mistake and you're right " 261, 262, and 263 are assigne to the
MLKEM512, MLKEM768, and MLKEM1024" wrong.
We'll notify IANA to pick 512 513 514 or 4584 4585 4586. Or something.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email
55 matches
Mail list logo
