[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[D. J. Bernstein]

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 inappropriate" to discuss "market
opportunities for specific companies". What's the IETF process for
addressing violations of RFC 9680?

As part of messages to tls@ietf.org advocating IETF action, a Cisco
employee claimed market opportunities for Cisco: "There are people whose
cryptographic expertise I cannot doubt who say that pure ML-KEM is the
right trade-off for them, and more importantly for my employer, that’s
what they're willing to buy." The message was from a Cisco address and
also went out of its way to specifically name Cisco in the text.

I find it perfectly clear how antitrust litigation can address this. I
don't find it clear that there are effective IETF procedures to address
this. I sent email requesting IETF LLC attention to this Cisco incident;
the response didn't acknowledge the incident and didn't suggest specific
followup procedures beyond this vague "appropriate IETF process" note.
Hence my question above.

> If your concern is that the IETF processes contain an overlooked
> antitrust risk

That's certainly an issue too. One of my messages quoted, e.g.,


https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)

asking whether there are "objective criteria for selecting the
technology to be included in the standard". My message continued by
asking where IETF's objective criteria are for deciding what to select,
and where the documentation is that demonstrates systematic enforcement
of those criteria.

RFC 9680 quotes BCP 9 text claiming that BCP 9 is designed to "provide a
fair, open, and objective basis for developing, evaluating, and adopting
Internet Standards". However, BCP 9 later contradicts this: first it
waters the claim down to just "reasonably" objective, and then it admits
that "there is no algorithmic guarantee". Furthermore, anyone trying to
find a statement of criteria in BCP 9 finds

* broad non-objective criteria (e.g., "considered to be useful"),
* no explanation of how different criteria are weighted, and
* open-ended flexibility for the decision-makers (e.g., "IESG may").

The specific situation at hand illustrates the problem. How does anyone
figure out whether Cisco's claim of market opportunities is relevant to
the BCP 9 criteria? This isn't an isolated incident---we've seen such
claims being raised again and again as arguments to override BCP 188
concerns, other security concerns, and other technical concerns.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Santosh Chokhani]

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 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-hybrids so "we'll end up 
> standardizing both". If the claim is true (I'm skeptical about the 
> non-hybrid part) and IETF acts on it (which is what I'm objecting to), 
> then how exactly does a hybrid end up as "the interoperable choice"?

same way that when DOD CAC was using DSA, long after no commercial CA was using 
DSA, the public Internet servers that would accept those CAC's were perfectly 
happy using RSA server keys so that regular browsers were able to connect to 
them, even without use of a CAC

If no browser will implement pure ML-KEM (and it very much looks so), then they 
will have to provide support for secp256r1MLKEM768 group to allow connections 
from regular browsers: hybrids will be the interoperable choice
--
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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Disallowing reuse of ephemeral keys

[Richard Barnes]

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 afterward that could compromise the
session.  Allowing key reuse (even tacitly) allows one side to silently
violate that invariant.  I'm not worried about backward compat, since (a)
it's wire compatible, and (b) any change here will be a separate RFC, so
people who care about validating can ask specifically "do you comply with
RFC "?

1 would be the next most plausible fallback, on the general principle that
IETF specifications define externally visible behavior, and this is not.

We should not do 2 because as Filippo says, there's no technical reason for
it.



On Thu, Dec 12, 2024 at 12:54 PM Filippo Valsorda 
wrote:

> 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.
>
> 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, and the hypothetical performance gain of reuse is
> marginal. The spec should defend against that and point implementations
> towards the safer course of action.
>
> As always, there is no protocol police, so implementations that want to
> risk shooting their foot off will be able to do so, but they will be
> off-spec, which is a useful signal.
> ___
> 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: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

[Christian Huitema]

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 by a peer? -- Christian Huitema On Dec 12, 2024, at 10:11 AM, Andrei Popov  wrote:







+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  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 list to forbid reuse for ML-KEM/hybrid key exchange.  There are several possible options here:

 



Keep things as they are (ie. say nothing, as was done in previous TLS versions, to forbid the reuse of ephemeral keys) - this is the default action if there is no consensus




Disallow reuse for specific ciphersuites.  It doesn’t appear that there is any real difference in this matter between MLKEM/hybrids and ECDH here except that there are many more ECDH implementations
 (some of which may reuse a keyshare)




Update 8446 to disallow reuse of ephemeral keyshares in general.  This could be done by revising RFC 8446bis or with a separate document that updates RFC 8446/bis

 

We would like to know if there are folks who think the reuse of keyshares is important for HTTP or non-HTTP use cases.







Thanks,







Joe, Deirdre and Sean





 




___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: Disallowing reuse of ephemeral keys

[Filippo Valsorda]

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.

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, and the hypothetical performance gain of reuse is marginal. The 
spec should defend against that and point implementations towards the safer 
course of action.

As always, there is no protocol police, so implementations that want to risk 
shooting their foot off will be able to do so, but they will be off-spec, which 
is a useful signal.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Sophie Schmieg]

+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 negotiate 0x11EC (which equally should
be adopted).

On Thu, Dec 12, 2024 at 2:11 PM Filippo Valsorda 
wrote:

> 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 to antitrust litigation.
>
>
> hahahahahahahahahahahaha
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Jay Daley]

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 process
>> for addressing that.
> 
> RFC 9680 says that it's "generally inappropriate" to discuss "market
> opportunities for specific companies". What's the IETF process for
> addressing violations of RFC 9680?

RFC 9680 is not a policy but an informational document, including information 
on an escalation path for antitrust concerns, and so there is no concept of 
“violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
for the topics to avoid because there is a vast grey area here.  The decision 
on whether or not any specific action is inappropriate rests with the IETF 
community through its structure and processes.  

The role of IETF Counsel is to provide advice to IETF leadership to support 
their formal decision making role as set out in these processes, but neither 
they nor I have any powers beyond that.  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.

I believe you will be getting an email in due course from the WG chairs that 
explains that further and addresses the rest of your points.

Jay

-- 
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

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Dan Harkins]

  +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 clear some 
people believe ML-KEM is secure enough for their uses.


Agreed on both counts, +1 to adoption.

___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Disallowing reuse of ephemeral keys

[Eric Rescorla]

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 for now [0] to avoid breakage and
then later we can allow it. If there are no such implementations, then I
think we can allow and/or encourage validation.

-Ekr


[0] This might be a reason to distinguish between existing and new cipher
suites.

On Thu, Dec 12, 2024 at 10:01 AM Richard Barnes  wrote:

> 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 afterward that could compromise the
> session.  Allowing key reuse (even tacitly) allows one side to silently
> violate that invariant.  I'm not worried about backward compat, since (a)
> it's wire compatible, and (b) any change here will be a separate RFC, so
> people who care about validating can ask specifically "do you comply with
> RFC "?
>
> 1 would be the next most plausible fallback, on the general principle that
> IETF specifications define externally visible behavior, and this is not.
>
> We should not do 2 because as Filippo says, there's no technical reason
> for it.
>
>
>
> On Thu, Dec 12, 2024 at 12:54 PM Filippo Valsorda 
> wrote:
>
>> 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.
>>
>> 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, and the hypothetical performance gain of reuse is
>> marginal. The spec should defend against that and point implementations
>> towards the safer course of action.
>>
>> As always, there is no protocol police, so implementations that want to
>> risk shooting their foot off will be able to do so, but they will be
>> off-spec, which is a useful signal.
>> ___
>> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Disallowing reuse of ephemeral keys

[Richard Barnes]

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 Eric Rescorla  wrote:

> 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 for now [0] to avoid breakage and
> then later we can allow it. If there are no such implementations, then I
> think we can allow and/or encourage validation.
>
> -Ekr
>
>
> [0] This might be a reason to distinguish between existing and new cipher
> suites.
>
> On Thu, Dec 12, 2024 at 10:01 AM Richard Barnes  wrote:
>
>> 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 afterward that could compromise the
>> session.  Allowing key reuse (even tacitly) allows one side to silently
>> violate that invariant.  I'm not worried about backward compat, since (a)
>> it's wire compatible, and (b) any change here will be a separate RFC, so
>> people who care about validating can ask specifically "do you comply with
>> RFC "?
>>
>> 1 would be the next most plausible fallback, on the general principle
>> that IETF specifications define externally visible behavior, and this is
>> not.
>>
>> We should not do 2 because as Filippo says, there's no technical reason
>> for it.
>>
>>
>>
>> On Thu, Dec 12, 2024 at 12:54 PM Filippo Valsorda 
>> wrote:
>>
>>> 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.
>>>
>>> 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, and the hypothetical performance gain of reuse is
>>> marginal. The spec should defend against that and point implementations
>>> towards the safer course of action.
>>>
>>> As always, there is no protocol police, so implementations that want to
>>> risk shooting their foot off will be able to do so, but they will be
>>> off-spec, which is a useful signal.
>>> ___
>>> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

[Andrei Popov]

  *   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,

Andrei

From: Richard Barnes 
Sent: Thursday, December 12, 2024 4:23 PM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys

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 Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
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 for now [0] to avoid breakage and then later we 
can allow it. If there are no such implementations, then I think we can allow 
and/or encourage validation.

-Ekr


[0] This might be a reason to distinguish between existing and new cipher 
suites.

On Thu, Dec 12, 2024 at 10:01 AM Richard Barnes 
mailto:r...@ipv.sx>> wrote:
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 afterward that could compromise the session.  Allowing 
key reuse (even tacitly) allows one side to silently violate that invariant.  
I'm not worried about backward compat, since (a) it's wire compatible, and (b) 
any change here will be a separate RFC, so people who care about validating can 
ask specifically "do you comply with RFC "?

1 would be the next most plausible fallback, on the general principle that IETF 
specifications define externally visible behavior, and this is not.

We should not do 2 because as Filippo says, there's no technical reason for it.



On Thu, Dec 12, 2024 at 12:54 PM Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:
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.

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, and the hypothetical performance gain of reuse is marginal. The 
spec should defend against that and point implementations towards the safer 
course of action.

As always, there is no protocol police, so implementations that want to risk 
shooting their foot off will be able to do so, but they will be off-spec, which 
is a useful signal.
___
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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Disallowing reuse of ephemeral keys

[Joseph Salowey]

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:


   1.

   Keep things as they are (ie. say nothing, as was done in previous TLS
   versions, to forbid the reuse of ephemeral keys) - this is the default
   action if there is no consensus
   2.

   Disallow reuse for specific ciphersuites.  It doesn’t appear that there
   is any real difference in this matter between MLKEM/hybrids and ECDH here
   except that there are many more ECDH implementations (some of which may
   reuse a keyshare)
   3.

   Update 8446 to disallow reuse of ephemeral keyshares in general.  This
   could be done by revising RFC 8446bis or with a separate document that
   updates RFC 8446/bis


We would like to know if there are folks who think the reuse of keyshares
is important for HTTP or non-HTTP use cases.


Thanks,


Joe, Deirdre and Sean
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Disallowing reuse of ephemeral keys

[Russ Housley]

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 list to forbid reuse 
> for ML-KEM/hybrid key exchange.  There are several possible options here:
> 
> Keep things as they are (ie. say nothing, as was done in previous TLS 
> versions, to forbid the reuse of ephemeral keys) - this is the default action 
> if there is no consensus
> Disallow reuse for specific ciphersuites.  It doesn’t appear that there is 
> any real difference in this matter between MLKEM/hybrids and ECDH here except 
> that there are many more ECDH implementations (some of which may reuse a 
> keyshare)
> Update 8446 to disallow reuse of ephemeral keyshares in general.  This could 
> be done by revising RFC 8446bis or with a separate document that updates RFC 
> 8446/bis
> 
> We would like to know if there are folks who think the reuse of keyshares is 
> important for HTTP or non-HTTP use cases.
> 
> Thanks,
> 
> Joe, Deirdre and Sean



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[D. J. Bernstein]

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 clarification questions, on-list
for transparency.

First, am I correctly understanding that IETF LLC is refusing to take
corrective action regarding the Cisco incident that I pointed out?

Second, is IETF LLC going to provide transparency regarding its
rationale for this? The comments I've seen from IETF LLC aren't saying
anything explicitly about the incident.

Third, is there a mechanism to appeal this decision to IETF LLC? A
generic reference to "the standards process" doesn't distinguish actions
by IETF LLC from actions by other parties; the reason I sent email to
you in the first place was to request IETF LLC action.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

[Andrei Popov]

+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>> 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 list to forbid reuse for 
ML-KEM/hybrid key exchange.  There are several possible options here:


  1.  Keep things as they are (ie. say nothing, as was done in previous TLS 
versions, to forbid the reuse of ephemeral keys) - this is the default action 
if there is no consensus

  1.  Disallow reuse for specific ciphersuites.  It doesn’t appear that there 
is any real difference in this matter between MLKEM/hybrids and ECDH here 
except that there are many more ECDH implementations (some of which may reuse a 
keyshare)

  1.  Update 8446 to disallow reuse of ephemeral keyshares in general.  This 
could be done by revising RFC 8446bis or with a separate document that updates 
RFC 8446/bis

We would like to know if there are folks who think the reuse of keyshares is 
important for HTTP or non-HTTP use cases.


Thanks,


Joe, Deirdre and Sean

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Jay Daley]

> 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
>>> appropriate course of action is to follow the appropriate IETF process
>>> for addressing that.
>> 
>> RFC 9680 says that it's "generally inappropriate" to discuss "market
>> opportunities for specific companies". What's the IETF process for
>> addressing violations of RFC 9680?
> 
> RFC 9680 is not a policy but an informational document, including information 
> on an escalation path for antitrust concerns, and so there is no concept of 
> “violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
> for the topics to avoid because there is a vast grey area here.  The decision 
> on whether or not any specific action is inappropriate rests with the IETF 
> community through its structure and processes.  
> 
> The role of IETF Counsel is to provide advice to IETF leadership to support 
> their formal decision making role as set out in these processes, but neither 
> they nor I have any powers beyond that.  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.

For the avoidance of doubt - by "note to me" I meant copying me in and 
specifically addressing me in your message to the WG list, not something 
offlist.

Jay


-- 
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

[TLS] Re: Disallowing reuse of ephemeral keys

[D. J. Bernstein]

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 examples of implementation-attack demos
that reuse keys---e.g., https://kyberslash.cr.yp.to recovering Kyber
keys from timings of the Kyber reference software with some compilers.
But it's an error to leap from ~"this demo reuses keys" to ~"avoiding
key reuse will make the Kyber reference software hard to exploit". I'm
not aware of any papers studying the latter claim.

I'm not saying that it's clear that switching keys doesn't help security
overall. I'm saying we shouldn't overstate the evidence that it helps.

Meanwhile the normal ways to set up TLS servers are reusing identity
keys for _at least_ months. If key reuse is a security problem, should
we be recommending faster rotation of identity keys? Or is signature
software being claimed to be somehow immune to implementation attacks?

As a side note, one of the attractions of replacing signatures with KEMs
for identity keys is removing the signing software as an attack target
(even if verification software is still used for signatures from CAs).
But this needs the KEM software to be safe for keys used many times.

> the hypothetical performance gain of reuse is marginal

This is not hypothetical. For example, kyber768 is reported in

https://bench.cr.yp.to/results-kem/amd64-alder2,1f626960,560.html

to take slightly over 3 cycles for key generation on Golden Cove
(Intel Alder Lake performance cores). Sure, there's also a cost to
retrieving an existing key from cache, but the measurements in

https://chipsandcheese.com/p/alder-lakes-caching-and-power-efficiency

show 4 P-cores on a Core i9-12900K together sustaining 800GB/second from
L2 cache, so (given that the CPU runs between 3.2GHz and 5.2GHz) reading
a few KB on one core is on the scale of 100 cycles, never mind the time
saved for cache misses for usually skipping the key-generation code.

People who use, e.g., ntruhrss701 to stay away from Kyber's patent
issues are incurring nearly 20 cycles for key generation on the same
cores, although https://cr.yp.to/papers.html#opensslntru explains how to
reduce this cost. For X25519, https://lib25519.cr.yp.to/speed.html shows
24000 cycles for key generation on Golden Cove.

As for "marginal": On an absolute scale? By comparison to something
else? Looking at the big picture of costs is good, but this "marginal"
claim is ambiguous, missing quantification, and missing justification.

In ongoing discussions over on CFRG, some of us have proposed requiring
extra hashing in hybrids, but there has been an objection claiming that
"saving a single hash in TLS saves compute time worth millions of
dollars/CO2 emissions/energy" (at Internet scale or at Google scale;
hasn't been clarified). Key reuse in the cryptosystems under discussion
saves more computation than that. It's inconsistent for IETF/IRTF to
have a larger cost dismissed as "marginal" while a smaller cost is
treated as a decision-making factor. (And, yes, this is _exactly_ the
sort of thing that exposes IETF to antitrust liability.)

I should emphasize that using cost arguments to hold back security
mechanisms is very often a mistake, and I wouldn't be surprised if
further consideration ends up settling on thread option 2 or 3. But cost
arguments in any direction should be clear, quantified, and justified.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Jay Daley]

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
>> through the standards process.
> 
> Thanks for your message. I have three clarification questions, on-list
> for transparency.
> 
> First, am I correctly understanding that IETF LLC is refusing to take
> corrective action regarding the Cisco incident that I pointed out?

As set out in BCP 101 (RFC 8711) the IETF LLC has "no authority over the 
standards development activities of the IETF" and explicitly has no role in the 
part of the standards process around conflict resolution "no changes are made 
to the appeals chain".  As this is clearly an issue of the IETF standards 
process, there is no concept of IETF LLC "corrective action".

> Second, is IETF LLC going to provide transparency regarding its
> rationale for this? 

This question appears to be based on the misconception that the IETF LLC could 
take "corrective action" and if it chooses not to then it should explain why 
not.  As explained above, we can’t do something we can’t do.

> The comments I've seen from IETF LLC aren't saying
> anything explicitly about the incident.

It would be inappropriate for the IETF LLC to make an explicit statement about 
the comment made to this list that you are concerned about,  as that would 
violate the limitations above regarding the role of the IETF LLC.

> Third, is there a mechanism to appeal this decision to IETF LLC?

Yes, you can appeal any action I take (including this non-action ) to the IETF 
LLC Board.  I suggest sending any appeal to llc-bo...@ietf.org which reaches 
the LLC Board only (I am not a board member).  For full disclosure, please note 
that one of the chairs of this WG is an IETF LLC board member 
(https://www.ietf.org/administration/llc-board/ for further details).

> A
> generic reference to "the standards process" doesn't distinguish actions
> by IETF LLC from actions by other parties; the reason I sent email to
> you in the first place was to request IETF LLC action.

I understand why you may have thought that the IETF LLC could be asked to 
intervene as many other SDOs operate under a different model where the legal 
entity has that level of authority.  The IETF however is quite different as the 
authority over the standards process is delegated by the IETF community to the 
IESG and the IETF LLC sits outside of that. That is why the standards process 
appeal chain (as pointed to by the WG chairs in their recent message) is to the 
IESG and not the IETF LLC.

Jay

-- 
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

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Filippo Valsorda]

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.

Agreed on both counts, +1 to adoption.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Filippo Valsorda]

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 to antitrust litigation.

hahahahahahahahahahahaha
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Sean Turner]

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 on the TLS list. This draft has 
been around for about nine months and the idea of doing “pure” PQ cipher suites 
for ML-KEM and ML-DSA has been around for at least a year longer than this 
thread. As Scott is not an author of this draft, we do think it is not helpful 
to the rest of the community who do want these cipher suites specified to 
stifle discussions.

We should note that draft-connolly-tls-mlkem-key-agreement is not a WG draft at 
this point, so if you would like to appeal the decision to allow discussions 
about draft-connolly-tls-mlkem-key-agreement on the TLS list you can do so via 
the process outlined in s6.5 of RFC 2026.

If you have thoughts about how RFC 9680 might be improved or IETF processes 
improved to address antitrust risks please send those comments to 
antitrust-pol...@ietf.org. Discussions about the contents of RFC 9860 are not 
relevant to this mailing list and are considered off-topic; see our monthly 
reminder email [1].

Joe & Sean

[1] https://mailarchive.ietf.org/arch/msg/tls/9W7sx80XWO_RjAVBIFuaAUyAvns/

> On Dec 12, 2024, at 15: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
>>> appropriate course of action is to follow the appropriate IETF process
>>> for addressing that.
>> 
>> RFC 9680 says that it's "generally inappropriate" to discuss "market
>> opportunities for specific companies". What's the IETF process for
>> addressing violations of RFC 9680?
> 
> RFC 9680 is not a policy but an informational document, including information 
> on an escalation path for antitrust concerns, and so there is no concept of 
> “violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
> for the topics to avoid because there is a vast grey area here.  The decision 
> on whether or not any specific action is inappropriate rests with the IETF 
> community through its structure and processes.  
> 
> The role of IETF Counsel is to provide advice to IETF leadership to support 
> their formal decision making role as set out in these processes, but neither 
> they nor I have any powers beyond that.  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.
> 
> I believe you will be getting an email in due course from the WG chairs that 
> explains that further and addresses the rest of your points.
> 
> Jay
> 
> -- 
> 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

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[D. J. Bernstein]

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 importantly for my employer, that's what they're
willing to buy. Hence, Cisco will implement it").

There have been many similar claims about what NSA supposedly requires.
I think the overall discussion can reasonably be summarized as follows:

* Pro-hybrid: Non-hybrid PQ is frivolously incurring security risks.
* Anti-hybrid: NSA is throwing a lot of money at non-hybrid PQ.

Should we be letting NSA buy IETF endorsement of specs that violate
normal common-sense security practices? This sounds crazy to me: it's
contrary to BCP 188, and contrary to any notion that IETF is making
decisions based on objective technology evaluation. But it seems that
the WG chairs are allowing the do-what-NSA-wants position.

What I find really amazing here is that we don't have evidence showing
that NSA is in fact insisting on non-hybrids. It seems that _rumors_ of
money are good enough to drive IETF action.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org