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 Satur
My preference order would be 3 > 1 >> 2.
3 seems like it encodes the expectation of most people for what the
protocol means. If you're using a cipher suite labeled something like
"ECDHE", it's reasonable to expect that it's actually ephemeral, i.e., that
there's not key material hanging around af
I like keeping as they are. Disallowing only makes sense if that prohibition can be enforced, and one of the peer refuses the connection if it detects key reuse. Would we want to do that? And, even if we wanted to accept the cost of refusing connections, could individual nodes actually detect reuse
I support some variation of 2 or 3, depending on what encounters the most
resistance. I agree there is no technical reason to disallow it for e.g.
X25519MLKEM768 and not X25519, but in practice it might be easier to set a new
rule for something that's still being rolled out and still a draft.
B
+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
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
+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
I agree with Richard about the ordering.
I think validation presents a distinct question: I don't think we should
require validation, as it is extra work for the peer and may not be
practical. If there are significant implementations which do reuse, then we
should discourage or forbid validation f
I concur with EKR re: validation. There's plenty of precedent in IETF
specs for requirements that cannot be validated by the remote party,
especially when it comes to maintaining security properties. See, e.g.,
the ticket deletion requirements in RFC 8446.
--RLB
On Thu, Dec 12, 2024 at 7:18 PM
* If there are significant implementations which do reuse…
By default, servers using Windows TLS stack reuse ECDHE keys for up to 30 sec.
Reuse time can be configured or altogether disabled by the system admin.
Disabling comes at a significant performance cost (for a busy TLS server).
Cheers
Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
keys. This was the consensus of the working group during the development
of TLS 1.3. There has been more recent discussion on the list to forbid
reuse for ML-KEM/hybrid key exchange. There are several possible options
here:
I prefer option 1.
Russ
> On Dec 12, 2024, at 12:35 PM, Joseph Salowey wrote:
>
> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys. This was the consensus of the working group during the development of
> TLS 1.3. There has been more recent discussion on the li
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 in favor of option1.
Cheers,
Andrei
From: Russ Housley
Sent: Thursday, December 12, 2024 9:43 AM
To: Joe Salowey
Cc: IETF TLS
Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys
I prefer option 1.
Russ
On Dec 12, 2024, at 12:35 PM, Joseph Salowey
mailto:j...@salowey.net>
> 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
Filippo Valsorda writes:
> Both ECDH and KEMs support key share (or public key) reuse *in theory*
> but in practice it makes implementation issues much more likely to be
> practically exploitable
Is there quantification and justification for the "much" claim?
Perhaps the allusion here is to examp
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
>
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
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
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
22 matches
Mail list logo
