Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Martin Thomson]

Reasonable statement.  It's a variation on what we already have, but the focus 
on forward secrecy is worth a small paragraph:

How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files

On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote:
> I have a suggestion which keeps things technical but hopefully 
> addresses Stephen's concern:
>
> In Security Considerations: 
>
> "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 
> 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it 
> records the used session key and so invalidates many of the security 
> claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred 
> data does not benefit from the security protections offered by RFC 8446 
> and systems using SSLKEYLOGFILE cannot be considered compliant with RFC 
> 8446 or offering similar security to the protocol outlined in that 
> draft." 
>
> I don't think the wording there is quite right, but I do think the 
> Security Considerations should clearly call out the impact on forward 
> secrecy and RFC 8446 in general and so dissuade use. 
>
> Best,
> Dennis
>
> On 12/03/2024 23:07, Eric Rescorla wrote:
>> 
>> 
>> On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell  
>> wrote:
>>> 
>>> I'll argue just a little more then shut up...
>>> 
>>> On 12/03/2024 22:55, Martin Thomson wrote:
>>> > 
>>> >> Sorry also for a late suggestion, but how'd we feel about adding 
>>> >> some text like this to 1.1?
>>> >> 
>>> >> "An implementation, esp. a server, emitting a log file such as this
>>> >> in a production environment where the TLS clients are unaware that
>>> >> logging is happening, could fall afoul of regulatory requirements
>>> >> to protect client data using state-of-the-art mechanisms."
>>> 
>>> > I agree with Ekr.  That risk is not appreciably changed by the
>>> > existence of a definition for a file format.
>>> I totally do consider our documenting this format increases
>>> the risk that production systems have such logging enabled,
>>> despite our saying "MUST NOT." So if there's a way to further
>>> disincentivise doing that, by even obliquely referring to
>>> potential negative consequences of doing so, then I'd be for
>>> doing that. 
>> 
>> Aside from this particular case, I don't think technical specifications
>> should "obliquely" refer to things. Technical specifications should be
>> clear.
>> 
>> -Ekr
>> 
>>> Hence my suggestion.
>>> 
>>> S.
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Thu, Mar 14, 2024 at 5:53 AM Deirdre Connolly 
wrote:

> I would argue adding `ML-KEM` as a standalone NamedGroup is not more
> complex than adding ECDH groups, the hybrid part is the already complex
> part. To minimize complexity even more, one can 'just' do the X-Wing style
> of having a hybrid NamedGroup that doesn't know anything about the other
> available component NamedGroups, ie, no shared ephemeral ECDH or KEM
> keypairs: less complex, a little more compute.
>

I don't quite understand what complexity you are concerned with here in
terms of reuse.

As I understand it, S 3.2 of draft-hybrid permits the reuse of key shares
for a given group across hybrids, but does not require it. This means that:

1. You're free to generate your keys independently without reusing them.
2. Your behavior is the same even if the other side chooses to reuse keys.

The point being that implementations which want to save some compute can
absorb some complexity, but nobody is forced to. Am I misunderstanding?

-Ekr

I want there to be an option to negotiate ML-KEM alone, and turn off / not
> compile in the hybrid NamedGroups if I want to in my TLS 1.3 stack, and I
> think there will be a non-trivial user base for such an option very soon.
>
>
>
>
> On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> On 14/03/2024 01:41, Deirdre Connolly wrote:
>>
>> Oh and one more consideration: hybrid brings complexity, and presenting
>> the pure-PQ solutions and their strictly lesser complexity (at the tradeoff
>> of maybe taking more risk against newer schemes no matter how good we feel
>> about their fundamental cryptographic foundations) is worthwhile in my
>> opinion.
>>
>> On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly <
>> durumcrustu...@gmail.com> wrote:
>>
>>> [...] Shaking out all the negotiation decisions is desirable as well as
>>> 'drawing the rest of the owl' for the pure PQ option implied in the
>>> negotiation (are we going to copy the same ~1000 bytes for the PQ and
>>> hybrid name groups, when sharing an ephemeral KEM keypair?).
>>>
>> This is an argument that supporting PQ-only and PQ-hybrid simultaneously
>> will be more complex than just PQ-hybrids and require further changes at
>> the TLS layer.
>>
>> Given we've already paid the (minimal) complexity cost of hybrids and
>> switching to PQ-only seems strictly less secure, I'm really struggling to
>> see the motivation at this point in time. Once we're in a position to
>> remove the classical key exchanges from TLS entirely because we know
>> they're ineffective, switching to PQ-only might then have more benefit
>> since we could retire a lot of old code.
>>
>>
>>> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS,
>>> but a note that a non-trivial segment of users of standard TLS that have
>>> been traditionally compliant will not be in a few years, and they will come
>>> knocking anyway. This is trying to skate where the puck is going.
>>>
>>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>>> agreement in the next ~6-9 years is a strong vote of confidence in any
>>> protocol doing this at all, so, TLS wouldn't be out on a limb to support
>>> this, basically.
>>>
>>> I don't have a strong opinion on whether this should be Recommended = Y.
>>>
>>> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>>>


 On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie >>> 40uwe.nsa@dmarc.ietf.org> wrote:

> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few comments. First, though, I want to say thank you for
> writing this draft. I'll echo some of what has already been voiced on this
> thread and say that, while some plan to use composite key establishment, 
> it
> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
> another option. Other WGs (lamps and ipsecme) have already begun to 
> specify
> the use of standalone FIPS 203, 204, and 205 in various protocols. With
> respect to this draft, there is certainly interest from National Security
> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions 
> for
> security).
>

 I wanted to address this CNSA 2.0 point, as I've now seen it brought up
 a couple of times.

 The IETF, together with the IRTF, needs to make an independent
 judgement on whether using PQ-only algorithms is advisable, and if we do
 not think so, then we should not standardize them, regardless of what CNSA
 2.0 requires. The supported groups registry policies are designed
 explicitly to allow people to register non Standards Track algorithms, so

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Good points. I've included these notes in the GitHub tracking issue, and
will leave the document as-is for now.

On Thu, Mar 14, 2024, 3:41 PM Sophie Schmieg  wrote:

> There was a push to change the parsing logic for ML-KEM public keys to
> never fail, by silently reducing, without changing the hash of the public
> key. I am not sure if NIST ended up adopting that change for their final
> standard (I hope they did, I think it's the best way to handle this
> problem), which would mean that any appropriately sized binary string is a
> valid ML-KEM public key. For ciphertexts, this property is already the
> case, due to the compression that is applied in ML-KEM. If NIST
> incorporated this change, there would be no way for the ML-KEM based key
> agreement to fail explicitly, any failure would result in an implicit
> rejection.
> In the end, this seems to be the same as with elliptic curves as is as
> well, point-not-on-curve checks can result in an explicit rejection of a
> keyshare (for the curves where it can occur), and manipulation of the
> keyshare (by an attacker or some accidental bit flip that somehow was not
> caught) would result in an implicit rejection here as well, with server and
> client computing a different shared secret. The only new possible error
> path I see is due to random decryption failure of a KEM, but given the
> cryptographically low chance, I'm not certain if this failure needs special
> handling in any case, and shouldn't be treated the same as a corrupted key
> share. After all, they are so unlikely that "cosmic rays flipped all the
> right bits for QUIC error correction to not notice" is far more likely to
> result in a decryption error, so treating it the same as a decryption
> failure due to a corrupted ciphertext seems fine to me.
>
> On Thu, Mar 14, 2024 at 11:43 AM David A. Cooper  40nist@dmarc.ietf.org> wrote:
>
>> I do not believe that "decode_error" would be the correct alert. As the
>> text currently says:
>>
>> *Failures* Some post-quantum key exchange algorithms, including ML-KEM,
>> have non-zero probability of failure, meaning two honest parties may derive
>> different shared secrets. This would cause a handshake failure. ML-KEM has
>> a cryptographically small failure rate; implementers should be aware of the
>> potential of handshake failure. Clients can retry if a failure is
>> encountered.
>>
>> At least in the case of ML-KEM, decapsulation failures are implicit. As
>> noted in the text above, the parties would derive different shared secrets
>> (but they wouldn't know it). So, the client would not know that
>> decapsulation failed, it would just be unable to decrypt the encrypted
>> extensions, certificate, etc. The client would have no way of knowing
>> whether this happened because of an ML-KEM decapsulation failure (extremely
>> unlikely) or because some data was changed in transit (much more likely).
>>
>> Given how small the ML-KEM decapsulation failure rate is (2^-139 or
>> less), I wouldn't be surprised if random bit flips in transit that aren't
>> caught by a CRC or other check are more likely than ML-KEM decapsulation
>> failures. Since the two are indistinguishable to the client, the client
>> would have to handle them in the same way. So, I would suggest either
>> omitting this paragraph or just note that a decapsulation failure would be
>> indistinguishable from a scenario in which some data was changed in
>> transit, and so would be handled in the same way.
>>
>> On 3/13/24 7:08 PM, Deirdre Connolly wrote:
>>
>> 4. In the Discussion section (on github), does the portion on failures
>>> need to contain more information about how a failure should be handled in
>>> TLS? Should a decrypt_error alert be sent?
>>
>>
>> Oh very good point, DH doesn't usually fail like this; either because of
>> fundamental (incredibly unlikely) decapsulation failure rates, or just a
>> bug, this is good to handle, and we should probably update -hybrid-design
>> to match. I've tracked this in this GitHub issue
>> 
>> for now. For my own sake, here's the `decode_error` defintion from RFC
>> 8446:
>>
>> decode_error:  A message could not be decoded because some field was
>>
>>   out of the specified range or the length of the message was
>>
>>   incorrect.  This alert is used for errors where the message does
>>
>>   not conform to the formal protocol syntax.  This alert should
>>
>>   never be observed in communication between proper implementations,
>>
>>   except when messages were corrupted in the network.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> sschm...@google.com
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Whoops, I copy-pasted the wrong section, this is the definition for
'decrypt_error':

> decrypt_error:  A handshake (not record layer) cryptographic

operation failed, including being unable to correctly verify a
signature or validate a Finished message or a PSK binder.



On Wed, Mar 13, 2024, 10:08 PM Deirdre Connolly 
wrote:

> Thank you very much for the notes!
>
> A few specific comments:
>
>
>
>> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
>> would suggest that the second sentence ("Having a fully post-quantum...")
>> is not needed, i.e. that there need not be a justification for why it is
>> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
>> appropriate to contextualize the specification of ML-KEM w.r.t the advent
>> of a CRQC, though I also don't think that is necessary. As an example, we
>> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>
>
> Noted, tweaked on github slightly.
>
>
>
>> 2. Section 3 (Construction on github) currently reads, "We align with
>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>> this specification (for the use of a standalone algorithm) off of RFC 8446
>> instead of the draft spec for a hybrid solution. I understand wanting to
>> align the approach with the approach taken for the hybrid solution, but I
>> don't think that fact needs to be explicitly documented in this draft. When
>> this draft is standardized, I think it's important that it is able to be
>> read, understood, and implemented without needing to refer to the hybrid
>> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
>> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
>> sent in the supported_groups extension."
>
>
> Good point, tweaked 
>
> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
>> phrase "groups" to refer to key exchange algorithms -- for example, the
>> supported_groups extension -- since all key exchange algorithms in TLS 1.3
>> are Diffie-Hellman-based.  As a result, some parts of this document will
>> refer to data structures or messages with the term "group" in them despite
>> using a key exchange algorithm that is not Diffie-Hellman-based nor a
>> group."
>> This seems okay, but on the IANA registry for TLS Supported Groups, it
>> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
>> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
>> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
>> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
>> to accommodate QR KEMs.
>
>
> This is a good point: -hybrid-design allocates 0x6399 and 0x639A for the
> two hybrid `NamedGroup`s so far. I don't have a strong opinion here, I
> basically followed -hybrid-design's lead and picked 0x0768 and 0x1024 for
> ML-KEM-768 and ML-KEM-1024.
>
>
>
>> 4. In the Discussion section (on github), does the portion on failures
>> need to contain more information about how a failure should be handled in
>> TLS? Should a decrypt_error alert be sent?
>
>
> Oh very good point, DH doesn't usually fail like this; either because of
> fundamental (incredibly unlikely) decapsulation failure rates, or just a
> bug, this is good to handle, and we should probably update -hybrid-design
> to match. I've tracked this in this GitHub issue
> 
> for now. For my own sake, here's the `decode_error` defintion from RFC
> 8446:
>
> decode_error:  A message could not be decoded because some field was
>
>   out of the specified range or the length of the message was
>
>   incorrect.  This alert is used for errors where the message does
>
>   not conform to the formal protocol syntax.  This alert should
>
>   never be observed in communication between proper implementations,
>
>   except when messages were corrupted in the network.
>
>
>
> 5. In Section 4 (or Security Considerations on github), this may be a
>> silly question, but is the definition of "commits" well-understood (in the
>> first sentence on datatracker; in the first sentence of Binding properties
>> on github)? It is not used in RFC 8446 so it might be worth explaining the
>> meaning or using different phrasing in this sentence.
>
>
> Noted
> ;
>  I
> will either define in-line or consistently use 'bind' in the X-BIND-P-Q
> sense (RFC 8446 uses 'bind' with the same colloquial sense but does not
> appear to define it).
>
> On Wed, Mar 13, 2024 at 5:36 PM Rebecca Guthrie 
> wrote:
>
>> Greetings Deirdre and TLS,
>>
>>
>>
>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>> 

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Sophie Schmieg]

There was a push to change the parsing logic for ML-KEM public keys to
never fail, by silently reducing, without changing the hash of the public
key. I am not sure if NIST ended up adopting that change for their final
standard (I hope they did, I think it's the best way to handle this
problem), which would mean that any appropriately sized binary string is a
valid ML-KEM public key. For ciphertexts, this property is already the
case, due to the compression that is applied in ML-KEM. If NIST
incorporated this change, there would be no way for the ML-KEM based key
agreement to fail explicitly, any failure would result in an implicit
rejection.
In the end, this seems to be the same as with elliptic curves as is as
well, point-not-on-curve checks can result in an explicit rejection of a
keyshare (for the curves where it can occur), and manipulation of the
keyshare (by an attacker or some accidental bit flip that somehow was not
caught) would result in an implicit rejection here as well, with server and
client computing a different shared secret. The only new possible error
path I see is due to random decryption failure of a KEM, but given the
cryptographically low chance, I'm not certain if this failure needs special
handling in any case, and shouldn't be treated the same as a corrupted key
share. After all, they are so unlikely that "cosmic rays flipped all the
right bits for QUIC error correction to not notice" is far more likely to
result in a decryption error, so treating it the same as a decryption
failure due to a corrupted ciphertext seems fine to me.

On Thu, Mar 14, 2024 at 11:43 AM David A. Cooper  wrote:

> I do not believe that "decode_error" would be the correct alert. As the
> text currently says:
>
> *Failures* Some post-quantum key exchange algorithms, including ML-KEM,
> have non-zero probability of failure, meaning two honest parties may derive
> different shared secrets. This would cause a handshake failure. ML-KEM has
> a cryptographically small failure rate; implementers should be aware of the
> potential of handshake failure. Clients can retry if a failure is
> encountered.
>
> At least in the case of ML-KEM, decapsulation failures are implicit. As
> noted in the text above, the parties would derive different shared secrets
> (but they wouldn't know it). So, the client would not know that
> decapsulation failed, it would just be unable to decrypt the encrypted
> extensions, certificate, etc. The client would have no way of knowing
> whether this happened because of an ML-KEM decapsulation failure (extremely
> unlikely) or because some data was changed in transit (much more likely).
>
> Given how small the ML-KEM decapsulation failure rate is (2^-139 or less),
> I wouldn't be surprised if random bit flips in transit that aren't caught
> by a CRC or other check are more likely than ML-KEM decapsulation failures.
> Since the two are indistinguishable to the client, the client would have to
> handle them in the same way. So, I would suggest either omitting this
> paragraph or just note that a decapsulation failure would be
> indistinguishable from a scenario in which some data was changed in
> transit, and so would be handled in the same way.
>
> On 3/13/24 7:08 PM, Deirdre Connolly wrote:
>
> 4. In the Discussion section (on github), does the portion on failures
>> need to contain more information about how a failure should be handled in
>> TLS? Should a decrypt_error alert be sent?
>
>
> Oh very good point, DH doesn't usually fail like this; either because of
> fundamental (incredibly unlikely) decapsulation failure rates, or just a
> bug, this is good to handle, and we should probably update -hybrid-design
> to match. I've tracked this in this GitHub issue
> 
> for now. For my own sake, here's the `decode_error` defintion from RFC
> 8446:
>
> decode_error:  A message could not be decoded because some field was
>
>   out of the specified range or the length of the message was
>
>   incorrect.  This alert is used for errors where the message does
>
>   not conform to the formal protocol syntax.  This alert should
>
>   never be observed in communication between proper implementations,
>
>   except when messages were corrupted in the network.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[David A. Cooper]

I do not believe that "decode_error" would be the correct alert. As the 
text currently says:


   *Failures* Some post-quantum key exchange algorithms, including
   ML-KEM, have non-zero probability of failure, meaning two honest
   parties may derive different shared secrets. This would cause a
   handshake failure. ML-KEM has a cryptographically small failure
   rate; implementers should be aware of the potential of handshake
   failure. Clients can retry if a failure is encountered.

At least in the case of ML-KEM, decapsulation failures are implicit. As 
noted in the text above, the parties would derive different shared 
secrets (but they wouldn't know it). So, the client would not know that 
decapsulation failed, it would just be unable to decrypt the encrypted 
extensions, certificate, etc. The client would have no way of knowing 
whether this happened because of an ML-KEM decapsulation failure 
(extremely unlikely) or because some data was changed in transit (much 
more likely).


Given how small the ML-KEM decapsulation failure rate is (2^-139 or 
less), I wouldn't be surprised if random bit flips in transit that 
aren't caught by a CRC or other check are more likely than ML-KEM 
decapsulation failures. Since the two are indistinguishable to the 
client, the client would have to handle them in the same way. So, I 
would suggest either omitting this paragraph or just note that a 
decapsulation failure would be indistinguishable from a scenario in 
which some data was changed in transit, and so would be handled in the 
same way.


On 3/13/24 7:08 PM, Deirdre Connolly wrote:


4. In the Discussion section (on github), does the portion on
failures need to contain more information about how a failure
should be handled in TLS? Should a decrypt_error alert be sent?


Oh very good point, DH doesn't usually fail like this; either because 
of fundamental (incredibly unlikely) decapsulation failure rates, or 
just a bug, this is good to handle, and we should probably update 
-hybrid-design to match. I've tracked this in this GitHub issue 
 
for now. For my own sake, here's the `decode_error` defintion from RFC 
8446:


decode_error:  A message could not be decoded because some field was

      out of the specified range or the length of the message was

      incorrect. This alert is used for errors where the message does

      not conform to the formal protocol syntax.  This alert should

      never be observed in communication between proper
implementations,

      except when messages were corrupted in the network.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena  wrote:

>
> On 3/14/24 00:45, Eric Rescorla wrote:
> > There are two questions here:
> >
> > 1. What the specification says
> > 2. What implementations choose to do within the envelope of that
> > specification.
> >
> > The specification needs to prescribe a set of behaviors that promote
> > interoperability, which means that whatever it tells the client to do
> > must be compatible with what it tells servers to do. Presently, the
> > specification tells clients to put whatever is in
> > ECHConfig.public_name in ClientHelloOuter.sni (S 6.1) and tells the
> > server that it may check and reject it otherwise (S 7.1).
>
> So, if I understand correctly, for my domain "abc.com", I could
> purposely choose to have my ECHConfig public_name be "google.com", and
>

As I said earlier, using "google.com" would be unwise because it
would allow Google to mount an attack where they terminated
the connection and replaced the ECHConfig. You should instead
use a name that is either unregistrable or that you control.


configure my server to handle it (or ignore the SNI in outer client
> hello altogether), and a client SHOULD NOT try and cancel the ECH
> attempt on seeing that the public_name in ECHConfig does not match the
> host the user is attempting to connect to?
>

As long as your server completes ECH, then it doesn't matter that
the certificate it presents is not valid for the public_name. However,
if you are unable to complete ECH (e.g., you have forgotten the
key and want to do the recovery mechanism), then this will
cause an error on the client.

-Ekr


> I guess this makes sense, since in the Cloudflare case, every ECHConfig
> advertises public_name as "cloudflare-ech.com", and the user is
> obviously connecting to a different website. In this case I guess it
> isn't as bad, since as a server operator I _could_ choose to just
> piggyback on the public_name of some popular CDN, even though I am not
> using it, to "hide" my real SNI / domain. I think this is a feasible
> workaround.
>
> Regards,
>
> Raghu Saxena
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Sofía Celi]

(not speaking as a chair of anything here)
The IETF, together with the IRTF, needs to make an independent judgement 
on whether using PQ-only algorithms is advisable, and if we do not think 
so, then we should not standardize them, regardless of what CNSA 2.0 
requires. The supported groups registry policies are designed explicitly 
to allow people to register non Standards Track algorithms, so nothing 
precludes the creation of an ML-KEM only code point if some vendors find 
that necessary, without the IETF standardizing them or marking them as 
Recommended=Y.


Agreed. A ML-KEM only code point can exist for the vendors that need it 
without the need of a IETF standarised document.


I think that the decision of standarising and allowing only one PQ KEM 
algorithm is more of the area of IRTF, as it might need the analysis. 
The complexity of hybrids seems minimal imho specially for some 
protocols. As Denis points out, switching to PQ-only seems strictly less 
secure given the decades long research that ECDH has had (with this I'm 
not implying that this means that ML-KEM or anything other of the 
PQ-KEMs are insecure, though).


I think we eventually will get there to only having the PQ algos, but 
right now it seems perhaps too soon ;). If right now is needed for 
experimentation or for some vendors, registering the code point without 
an IETF standard seems advisable.


Thank you,




A few specific comments:



1. In Section 1.1 (or Introduction - Motivation in the github
version), I would suggest that the second sentence ("Having a fully
post-quantum...") is not needed, i.e. that there need not be a
justification for why it is necessary to specify how to use ML-KEM
in TLS 1.3 (vs. hybrid). It could be appropriate to contextualize
the specification of ML-KEM w.r.t the advent of a CRQC, though I
also don't think that is necessary. As an example, we can compare to
the Introduction in draft-ietf-lamps-cms-kyber-03.



2. Section 3 (Construction on github) currently reads, "We align
with [hybrid] except that instead of joining ECDH options with a
KEM, we just have the KEM as a NamedGroup." I think it is a more
useful framing to base this specification (for the use of a
standalone algorithm) off of RFC 8446 instead of the draft spec for
a hybrid solution. I understand wanting to align the approach with
the approach taken for the hybrid solution, but I don't think that
fact needs to be explicitly documented in this draft. When this
draft is standardized, I think it's important that it is able to be
read, understood, and implemented without needing to refer to the
hybrid draft. It could be stated (how it is in the hybrid draft),
"ML-KEM-512 (if included), ML-KEM-768, and ML-KEM-1024 are
represented as a NamedGroup and sent in the supported_groups
extension."



3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses
the phrase "groups" to refer to key exchange algorithms -- for
example, the supported_groups extension -- since all key exchange
algorithms in TLS 1.3 are Diffie-Hellman-based. As a result, some
parts of this document will refer to data structures or messages
with the term "group" in them despite using a key exchange algorithm
that is not Diffie-Hellman-based nor a group."

This seems okay, but on the IANA registry for TLS Supported Groups,
it indicates 0-255 and 512-65535 are for elliptic curve groups, and
256-511 are for FFDH groups. Where does ML-KEM fit in? Do ranges
need to be re-evaluated? As an example, for IKEv2, RFC 9370 changes
the name of Transform Type 4 from Diffie-Hellman Group to Key
Exchange Method in order to accommodate QR KEMs.



4. In the Discussion section (on github), does the portion on
failures need to contain more information about how a failure should
be handled in TLS? Should a decrypt_error alert be sent?



5. In Section 4 (or Security Considerations on github), this may be
a silly question, but is the definition of "commits" well-understood
(in the first sentence on datatracker; in the first sentence of
Binding properties on github)? It is not used in RFC 8446 so it
might be worth explaining the meaning or using different phrasing in
this sentence.



Also, what are the WG's thoughts on including standalone PQC
signatures in the same draft?



Thanks in advance!



Rebecca

__ __

Rebecca Guthrie

she/her

Center for Cybersecurity Standards (CCSS)

Cybersecurity Collaboration Center (CCC)

National Security Agency (NSA)

__ __

*From:* TLS mailto:tls-boun...@ietf.org>> *On
Behalf Of * Deirdre Connolly
*Sent:* Tuesday, March 5, 2024 9:15 PM
*To:* TLS@ietf.org 

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

I would argue adding `ML-KEM` as a standalone NamedGroup is not more
complex than adding ECDH groups, the hybrid part is the already complex
part. To minimize complexity even more, one can 'just' do the X-Wing style
of having a hybrid NamedGroup that doesn't know anything about the other
available component NamedGroups, ie, no shared ephemeral ECDH or KEM
keypairs: less complex, a little more compute. I want there to be an option
to negotiate ML-KEM alone, and turn off / not compile in the hybrid
NamedGroups if I want to in my TLS 1.3 stack, and I think there will be a
non-trivial user base for such an option very soon.




On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson  wrote:

> On 14/03/2024 01:41, Deirdre Connolly wrote:
>
> Oh and one more consideration: hybrid brings complexity, and presenting
> the pure-PQ solutions and their strictly lesser complexity (at the tradeoff
> of maybe taking more risk against newer schemes no matter how good we feel
> about their fundamental cryptographic foundations) is worthwhile in my
> opinion.
>
> On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
> wrote:
>
>> [...] Shaking out all the negotiation decisions is desirable as well as
>> 'drawing the rest of the owl' for the pure PQ option implied in the
>> negotiation (are we going to copy the same ~1000 bytes for the PQ and
>> hybrid name groups, when sharing an ephemeral KEM keypair?).
>>
> This is an argument that supporting PQ-only and PQ-hybrid simultaneously
> will be more complex than just PQ-hybrids and require further changes at
> the TLS layer.
>
> Given we've already paid the (minimal) complexity cost of hybrids and
> switching to PQ-only seems strictly less secure, I'm really struggling to
> see the motivation at this point in time. Once we're in a position to
> remove the classical key exchanges from TLS entirely because we know
> they're ineffective, switching to PQ-only might then have more benefit
> since we could retire a lot of old code.
>
>
>> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS,
>> but a note that a non-trivial segment of users of standard TLS that have
>> been traditionally compliant will not be in a few years, and they will come
>> knocking anyway. This is trying to skate where the puck is going.
>>
>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>> agreement in the next ~6-9 years is a strong vote of confidence in any
>> protocol doing this at all, so, TLS wouldn't be out on a limb to support
>> this, basically.
>>
>> I don't have a strong opinion on whether this should be Recommended = Y.
>>
>> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie >> 40uwe.nsa@dmarc.ietf.org> wrote:
>>>
 Greetings Deirdre and TLS,



 I read through draft-connolly-tls-mlkem-key-agreement-00 (and
 https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
 and I have a few comments. First, though, I want to say thank you for
 writing this draft. I'll echo some of what has already been voiced on this
 thread and say that, while some plan to use composite key establishment, it
 makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
 another option. Other WGs (lamps and ipsecme) have already begun to specify
 the use of standalone FIPS 203, 204, and 205 in various protocols. With
 respect to this draft, there is certainly interest from National Security
 System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
 compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
 security).

>>>
>>> I wanted to address this CNSA 2.0 point, as I've now seen it brought up
>>> a couple of times.
>>>
>>> The IETF, together with the IRTF, needs to make an independent judgement
>>> on whether using PQ-only algorithms is advisable, and if we do not think
>>> so, then we should not standardize them, regardless of what CNSA 2.0
>>> requires. The supported groups registry policies are designed explicitly to
>>> allow people to register non Standards Track algorithms, so nothing
>>> precludes the creation of an ML-KEM only code point if some vendors find
>>> that necessary, without the IETF standardizing them or marking them as
>>> Recommended=Y.
>>> -Ekr
>>>
>>>
>>>
>>>

 A few specific comments:



 1. In Section 1.1 (or Introduction - Motivation in the github version),
 I would suggest that the second sentence ("Having a fully post-quantum...")
 is not needed, i.e. that there need not be a justification for why it is
 necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
 appropriate to contextualize the specification of ML-KEM w.r.t the advent
 of a CRQC, though I also don't think that is necessary. As an example, we
 can compare to the Introduction in 

Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Dennis Jackson]

I have a suggestion which keeps things technical but hopefully addresses 
Stephen's concern:


In Security Considerations:

"TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2, 
E.1). Using SSLKEYLOGFILE breaks this security property as it records 
the used session key and so invalidates many of the security claims made 
in RFC 8446. If SSLKEYLOGFILE is in use, the transferred data does not 
benefit from the security protections offered by RFC 8446 and systems 
using SSLKEYLOGFILE cannot be considered compliant with RFC 8446 or 
offering similar security to the protocol outlined in that draft."


I don't think the wording there is quite right, but I do think the 
Security Considerations should clearly call out the impact on forward 
secrecy and RFC 8446 in general and so dissuade use.


Best,
Dennis

On 12/03/2024 23:07, Eric Rescorla wrote:



On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell 
 wrote:



I'll argue just a little more then shut up...

On 12/03/2024 22:55, Martin Thomson wrote:
>
>> Sorry also for a late suggestion, but how'd we feel about adding
>> some text like this to 1.1?
>>
>> "An implementation, esp. a server, emitting a log file such as this
>> in a production environment where the TLS clients are unaware that
>> logging is happening, could fall afoul of regulatory requirements
>> to protect client data using state-of-the-art mechanisms."

> I agree with Ekr.  That risk is not appreciably changed by the
> existence of a definition for a file format.
I totally do consider our documenting this format increases
the risk that production systems have such logging enabled,
despite our saying "MUST NOT." So if there's a way to further
disincentivise doing that, by even obliquely referring to
potential negative consequences of doing so, then I'd be for
doing that. 



Aside from this particular case, I don't think technical specifications
should "obliquely" refer to things. Technical specifications should be
clear.

-Ekr

Hence my suggestion.

S.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Dennis Jackson]

On 14/03/2024 01:41, Deirdre Connolly wrote:

Oh and one more consideration: hybrid brings complexity, and 
presenting the pure-PQ solutions and their strictly lesser complexity 
(at the tradeoff of maybe taking more risk against newer schemes no 
matter how good we feel about their fundamental cryptographic 
foundations) is worthwhile in my opinion.


On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
 wrote:


[...] Shaking out all the negotiation decisions is desirable as
well as 'drawing the rest of the owl' for the pure PQ option
implied in the negotiation (are we going to copy the same ~1000
bytes for the PQ and hybrid name groups, when sharing an ephemeral
KEM keypair?).

This is an argument that supporting PQ-only and PQ-hybrid simultaneously 
will be more complex than just PQ-hybrids and require further changes at 
the TLS layer.


Given we've already paid the (minimal) complexity cost of hybrids and 
switching to PQ-only seems strictly less secure, I'm really struggling 
to see the motivation at this point in time. Once we're in a position to 
remove the classical key exchanges from TLS entirely because we know 
they're ineffective, switching to PQ-only might then have more benefit 
since we could retire a lot of old code.




For CNSA 2.0, it is cited not as a compatibility _requirement_ of
TLS, but a note that a non-trivial segment of users of standard
TLS that have been traditionally compliant will not be in a few
years, and they will come knocking anyway. This is trying to skate
where the puck is going.

But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_
key agreement in the next ~6-9 years is a strong vote of
confidence in any protocol doing this at all, so, TLS wouldn't be
out on a limb to support this, basically.

I don't have a strong opinion on whether this should be
Recommended = Y.

On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:



On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie
 wrote:

Greetings Deirdre and TLS,

I read through draft-connolly-tls-mlkem-key-agreement-00
(and

https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
and I have a few comments. First, though, I want to say
thank you for writing this draft. I'll echo some of what
has already been voiced on this thread and say that, while
some plan to use composite key establishment, it makes
sense to also specify the use of standalone ML-KEM in TLS
1.3 as another option. Other WGs (lamps and ipsecme) have
already begun to specify the use of standalone FIPS 203,
204, and 205 in various protocols. With respect to this
draft, there is certainly interest from National Security
System vendors in using standalone ML-KEM-1024 in TLS 1.3
for CNSA 2.0 compliance (as CNSA 2.0 does not require nor
recommend hybrid solutions for security).


I wanted to address this CNSA 2.0 point, as I've now seen it
brought up a couple of times.

The IETF, together with the IRTF, needs to make an independent
judgement on whether using PQ-only algorithms is advisable,
and if we do not think so, then we should not standardize
them, regardless of what CNSA 2.0 requires. The supported
groups registry policies are designed explicitly to allow
people to register non Standards Track algorithms, so nothing
precludes the creation of an ML-KEM only code point if some
vendors find that necessary, without the IETF standardizing
them or marking them as Recommended=Y.
-Ekr



A few specific comments:

1. In Section 1.1 (or Introduction - Motivation in the
github version), I would suggest that the second sentence
("Having a fully post-quantum...") is not needed, i.e.
that there need not be a justification for why it is
necessary to specify how to use ML-KEM in TLS 1.3 (vs.
hybrid). It could be appropriate to contextualize the
specification of ML-KEM w.r.t the advent of a CRQC, though
I also don't think that is necessary. As an example, we
can compare to the Introduction in
draft-ietf-lamps-cms-kyber-03.

2. Section 3 (Construction on github) currently reads, "We
align with [hybrid] except that instead of joining ECDH
options with a KEM, we just have the KEM as a NamedGroup."
I think it is a more useful framing to base this
specification (for the use of a standalone algorithm) off
of RFC 8446 instead of the draft spec for a hybrid
solution. I understand wanting to align the approach with

Re: [TLS] Working Group Last Call for ECH

[Dennis Jackson]

+1 to shipping it.

On 11/03/2024 22:00, Joseph Salowey wrote:
This is the working group last call for TLS Encrypted Client Hello 
[1].  Please indicate if you think the draft is ready to progress to 
the IESG and send any comments to the list by 31 March 2024.  The 
comments sent by Watson Ladd to the list [2] on 17 February 2024 will 
be considered last call comments.


Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls