Re: [TLS] Require deterministic ECDSA

[Filippo Valsorda]

Strong support for this. TLS will be deployed with broken
implementations and on broken systems. Anything the spec can do to
limit or prevent damage is more than appropriate.

However, agreed that a SHOULD makes more sense, to avoid having
discussions about OpenSSL not being compliant because of a different
PRF.

I've always been puzzled by pure-random ECDSA deployments anyway.

On Sat, Jan 23, 2016 at 7:13 PM, Joseph Birr-Pixton  wrote:
> Hi,
>
> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>
> For discussion, here's a pull request with possible language:
>
> https://github.com/tlswg/tls13-spec/pull/406
>
> Cheers,
> Joe
>
> ___
> 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] Static DH timing attack

[Filippo Valsorda]

I feel like there should be nothing controversial in the context of TLS.
 * Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a 
MUST NOT, because they can't be implemented securely.
 * Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS 
versions, because it's unnecessary and has been a requirement for many attacks 
now.
 * Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT, 
because again ECDH share reuse enables a whole class of attacks.
 * FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT, 
because they are specified in a dangerous way that is not secure if shares are 
reused.
If any of the above are not already the case, it should be a quick and easy 
document.

2020-09-11 16:06 GMT+02:00 Russ Housley :
> Peter:
> 
> > Achim Kraus  writes:
> > 
> >> Does using x25519 for ECDHE is significant less secure than using it with
> >> e.g. secp384r1?
> > 
> > The NIST curves AFAIK are never used that way, it's only done with 25519
> > (there was something about it in an OpenPGP draft, but I think GPG went
> > straight to 25519 and only used ECDSA for signatures).
> > 
> > What I'm specifically referring to is DH run sideways, as someone put it
> > during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
> > make it work like it's RSA.
> > 
> > In all the code audits I've done of 25519 used that way, I've never seen it
> > used correctly.  Usually there isn't just one mistake made but many of them.
> > It's such an obvious problem that that and misuse of RC4-equivalent modes/
> > algorithms like GCM and ChaCha20 are the first things I look for in crypto
> > code.
> 
> I am sure you know that ephemeral-static DH was original used for S/MIME.  
> The reasoning for ephemeral-static DH was not to make it work like RSA.  
> Rather, the idea was to provide authentication of the static DH key holder by 
> certifying the static DH public key.  Then, the ephemeral DH key pair is 
> generated using the parameters from the certificate.  One important aspect of 
> this approach was to avoid picking a single group for all of the DH keys.
> 
> Russ
> 
> ___
> 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] Static DH timing attack

[Filippo Valsorda]

2020-09-12 05:48 GMT+02:00 Peter Gutmann :
> Filippo Valsorda  writes:
> 
> >I feel like there should be nothing controversial in the context of TLS.
> >
> >   Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
> > MUST NOT, because they can't be implemented securely.
> >
> >   Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all
> > TLS versions, because it's unnecessary and has been a requirement for many
> > attacks now.
> >
> >   Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT,
> > because again ECDH share reuse enables a whole class of attacks.
> >
> >   FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT,
> > because they are specified in a dangerous way that is not secure if shares
> > are reused.
> 
> I agree with the first two but not the last.  Why is non-ephemeral DH a MUST
> NOT but non-ephemeral ECDH a SHOULD NOT?  There's nothing magic about the EC
> form that makes it any better or safer.

Non-ephemeral DH is affected by the Raccoon attack, ECDH is not.

> And for the FFDHE ciphersuites, they're not specified in a dangerous way,
> people implement them in a dangerous way.  You really have to go out of your
> way to get it wrong, in the case of RACCOON it's actually more effort to get
> it wrong (keep old copies of values floating around and reuse them over and
> over) than to get it right (generate a fresh value every time).  So it doesn't
> need a "don't do FFDHE", it needs a "here's a lot of stupid things you can do
> with FFDHE if you put your mind to it.  Don't do any of them".
> 
> Or maybe it can be turned into a more general "here are some dumb things that
> people have done with TLS over the years.  Check your server to make sure
> you're not doing them".  Posting your web server's private key as a .p12 file
> in a subdirectory below $DocumentRoot, for example, would be high on my list.

There are two peers involved in ciphersuite selection, so recommending everyone 
avoids an unsafe ciphersuite can protect connections even if only one side 
takes the advice, and even if it's not the side that made the implementation 
error.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Filippo Valsorda]

2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson  writes:
> 
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
> 
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.

Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Filippo Valsorda]

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig :
> Hi Carrick,

>  

> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.

>  

> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.

>  

> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  


By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.

> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?


(Again, no one is suggesting dropping anything, as far as I can tell.)

> Ciao

> Hannes

>  


> *From:* Carrick Bartle  
> *Sent:* Monday, September 21, 2020 6:19 PM
> *To:* Hannes Tschofenig 
> *Cc:* Carrick Bartle ; Filippo 
> Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>  

>> Can you justify your reasoning? 

>  

> Which part?

>  


> 

>> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
>> wrote:

>>  

>> Hi Carrick, 

>>  

>> Can you justify your reasoning? 

>>  

>> The challenge I have with the work on IoT in the IETF that the preferences 
>> for pretty much everything changes on a regular basis.

>>  

>> I don’t see a problem that requires a change. In fact, I have just posted a 
>> mail to the UTA list that gives an overview of the implementation status of 
>> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  

>>  

>> Ciao

>> Hannes

>>  


>> *From:* TLS  *On Behalf Of *Carrick Bartle
>> *Sent:* Monday, September 21, 2020 5:31 AM
>> *To:* Filippo Valsorda 
>> *Cc:* tls@ietf.org
>> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>>  

>> I'm also fine with marking psk_ke as not recommended to be consistent with 
>> the non-PFS ciphers, but there are plenty of valid use cases that justify 
>> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
>> cases are detailed in draft-ietf-tls-external-psk-guidance-00.

>>  

>>  

>>  

>>> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:

>>>  

>>> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :

>>>> John Mattsson  writes:

>>>>  

>>>> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke 
>>>> >and

>>>> >especially psk_ke are both marked as RECOMMENDED. If used in the initial

>>>> >handshake, both modes have severe privacy problems,

>>>>  

>>>> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

>>>> just because there's a concern for one specific environment doesn't mean it

>>>> should be banned for any use.  In particular, I think if a specific 
>>>> industry

>>>> has a particular concern, they should profile it for use in that industry 
>>>> but

>>>> not require that everyone else change their behaviour.

>>>  

>>> Indeed, if the SCADA industry has a particular need, they should profile 
>>> TLS for use in that industry, and not require we change the recommendation 
>>> for the open Internet.

>>>  

>>> Setting Recommended to N is not "banning" anything, it's saying it "has not 
>>> been through the IETF consensus process, has limited applicability, or is 
>>> intended only for specific use cases". SCADA sounds like a pretty specific 
>>> use case.

>>>  

&

Re: [TLS] The future of external PSK in TLS 1.3

[Filippo Valsorda]

2020-09-24 12:02 GMT+02:00 Peter Gutmann :
> Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
> generally "non-web use", [...]

"The web" and "resource-constrained use cases which can't afford ECDH" feels 
like a false dichotomy, and it sounds unlikely that most M2M cases would fit 
the latter description.

Anyway, David has made a better case than I did for marking psk_ke as N, like 
TLS_PSK_WITH_AES_128_GCM_SHA256 already is, so I don't want to distract from 
that thread.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Recommending ALPN / backwards compatibility

[Filippo Valsorda]

2021-05-08 05:11 GMT-04:00 ml+ietf-...@esmtp.org 
:
> On Fri, Apr 30, 2021, Martin Thomson wrote:
> > An existing application protocol might not have been assigned an
> > ALPN identifier.  For other protocols the ALPN identifier might
> > not have been part of the original protocol definition, or use of
> > ALPN might have been defined originally as being optional.
> 
> Sorry for this stupid/simple question but I cannot find a way for
> a client to determine whether a server
> 
> 1. does not support ALPN.
> 2. supports ALPN but did not select a protocol.
> 
> It seems it is only possible to return a selected protocol,
> not am "empty" protocol to indicate case 2, correct?

My understanding (and the Go implementation) is that a server running an 
application without ALPN does not support ALPN, so it will ignore the extension 
(even if the TLS stack does have code to handle it).

A migration would work like this: if the client updates before the server, the 
client will send ALPN but it will get ignored by the server, which doesn't 
support ALPN yet; if the server updates before the client, the client will not 
send ALPN, which the server will allow (because the no_application_protocol 
condition is "the server supports no protocols *that the client advertises*"). 
Once they both updated, the server is expected to close the connection if the 
client sent an ALPN extension without the right protocol in it, otherwise we 
lose most of the cross-protocol benefit of ALPN in the first place.

> IMHO this would be useful for backwards compatibility/ migrating a
> protocol to support ALPN.  RFC 7301 states the server "SHALL" abort
> in this case:
> 
> 3.2.  Protocol Selection
> ...  In the event that the server supports no
>protocols that the client advertises, then the server SHALL respond
>with a fatal "no_application_protocol" alert.
> 
> but that might not be a good way to support migration, which probably
> is why is just "SHALL" not "MUST"?

SHALL means MUST per RFC 2119. It's unfortunate we use a word that sounds like 
SHOULD to mean MUST, but that's a requirement, not a suggestion.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Filippo Valsorda]

(I am listed as author to one of the drafts, but haven't contributed 
significantly since suggesting the deprecation on the list, so I am going to 
renounce authorship and express my support for the adoption instead.)

As a TLS implementer, I don't want the specs to tell me what is *technically 
possible to implement correctly*. I want the specs to recommend the safer, most 
straightforward options for general purpose use.

*DH reuse is less safe than ephemeral shares.* I don't think we need to debate 
this fact. There is a mile-high pile of CVEs that include the words "if DH 
shares are reused". I personally turned a 2^-32 chance of a carry bug into a 
full key recovery against ES-DH , 
others have pulled off more and cooler attacks. None of these fun, 
job-security-providing stunts work with ephemeral shares, so it's with a heavy 
heart that I say we should absolutely deprecate all DH share reuses. (This 
includes all static kex, and an explicit MUST NOT for reuse in ephemeral kex.)

*Checking the safety of an arbitrary FFDH group is relatively hard, and slow.* 
Implementers tend to skip hard, slow operations with no visible outcome. 
Besides, it's also a compatibility risk, because the only recourse on a failed 
check is to terminate the connection, which again encourages implementers to 
skip or relax the check. The most straightforward path to retaining FFDH in TLS 
1.2 I see is requiring the use of a few, well known groups, that can be checked 
by memcmp. Still, I would rather support deprecating pre-TLS 1.3 FFDH entirely.

It's not like things in the wild suddenly stop working when the IETF deprecates 
a cipher suite (that's my job!), it just tells bystanders "this is not the best 
way to do things" and in the case of DH reuse "you'll be much safer if you 
generate fresh shares" and in the case of FFDH "if you want to do FFDH it will 
be safer and more reliable to use TLS 1.3".

I support adoption, and recommend merging all these deprecations into a single 
draft, which would be easier to refer to and communicate as an implementer.

2021-08-17 03:45 GMT+02:00 Joseph Salowey :
> Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
> provide forward secrecy, which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the citation 
> of the Raccoon attack or do you also feel that we should keep these 
> ciphersuites that do not provide forward secrecy around?
> 
> Cheers,
> 
> Joe
> 
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
>  wrote:
>> I agree with Rene’s points.
>> __ __
>> -- 
>> Regards,
>> Uri
>> __ __
>> __ __
>> *From: *TLS  on behalf of Rene Struik 
>> 
>> *Date: *Friday, August 13, 2021 at 09:58
>> 
>> Dear colleagues:
>> __ __
>> I think this document should absolutely *not* be adopted, without providing 
>> far more technical justification. The quoted Raccoon attack is an easy to 
>> mitigate attack (which has nothing to do with finite field groups, just with 
>> poor design choices of postprocessing, where one uses variable-size integer 
>> representations for a key). There are also good reasons to have key 
>> exchanges where one of the parties has a static key, whether ecc-based or 
>> ff-based (e.g., sni, opaque), for which secure implementations are known. No 
>> detail is provided and that alone should be sufficient reason to not 
>> adopt.
>> __ __
>> Rene
>> __ __
>> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>>> This is a working group call for adoption for Deprecating FFDH(E) 
>>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>>> ). We 
>>> had a presentation for this draft at the IETF 110 meeting and since it is a 
>>> similar topic to the key exchange deprecation draft the chairs want to get 
>>> a sense if the working group wants to adopt this draft (perhaps the drafts 
>>> could be merged if both move forward).  Please review the draft and post 
>>> your comments to the list by Friday, August 13, 2021.  
>>> __ __
>>> Thanks,
>>> __ __
>>> The TLS chairs
>>> 
>>> 
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> __ __
>> 
>> -- 
>> email: rstruik@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Filippo Valsorda]

2021-08-27 05:08 GMT+02:00 Joseph Salowey :
> Thanks for all the discussion on this topic.  There are several modes that 
> TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to 
> merge some of the cases covered by this draft into the obsolete keyex draft.  
> I'd like to see if there is some consensus to make this change before we 
> adopt it into the working group. 
> 
> 1. static-static where both client and server have DH certificates with long 
> term keys.  I think we have general consensus that this mode should be a must 
> not.  To deprecate this mode I think we need to state that clients MUST NOT 
> use certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT 
> request them.  Would the working group support merging this guidance into the 
> obsolete keyex draft?  
> 
> 2. ephemeral-static where the client uses an ephemeral key and the server 
> uses a long term key.  This mode does not provide forward secrecy.  I'm not 
> sure we have reached consensus on how far to deprecate this option.  Would 
> the working group support MUST NOT use these ciphersuites unless forward 
> secrecy does not matter for your use case and any implementation guidance 
> provided to avoid weaknesses is followed?

The implementation guidance to avoid weaknesses in any ephemeral-static 
exchange is "don't get anything wrong, anything at all, all the way down to 
your field arithmetic libraries". I don't think that's a workable 
recommendation, and I believe we should deprecate modes that are so unsafe to 
implement.

> 3. ephemeral-ephemeral  - I think these are already covered in the obsolete 
> keyex draft. 
> 
> Thanks,
> 
> Joe
> 
> On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:
>>> >   which is a main reason cited for deprecating RSA in 
>>> > draft-aviram-tls-deprecate-obsolete-kex.
>>>  
>>> Have the authors look at Post-Quantum KEMs?
>> 
>> I'm not sure why PQ KEMs are relevant here.
>> 
>> 
>>> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL 
>>>  wrote:
>>> 
>>> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do 
>>> > not provide
>>> >  forward secrecy,
>>> __ __
>>> Unless you use semi-static exchange, which in many cases makes sense.
>>> __ __
>>> >   which is a main reason cited for deprecating RSA in 
>>> > draft-aviram-tls-deprecate-obsolete-kex.
>>> __ __
>>> Have the authors look at Post-Quantum KEMs?
>>> __ __
>>> >  Do you object to just the citation of the Raccoon attack or do you also 
>>> > feel that we
>>> >  should keep these ciphersuites that do not provide forward secrecy 
>>> > around?
>>> __ __
>>> I think these suites should stay around. 
>>> __ __
>>> While static-static indeed do not provide forward secrecy (and many of us – 
>>> though not everybody! – carry for that), static-ephemeral DH and ECDH are 
>>> perfectly fine from that point of view.
>>> __ __
>>> __ __
>>> __ __
>>> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
>>>  wrote:
 I agree with Rene’s points.
  
 -- 
 Regards,
 Uri
  
  
 *From: *TLS  on behalf of Rene Struik 
 
 *Date: *Friday, August 13, 2021 at 09:58
 Dear colleagues:
  
 I think this document should absolutely *not* be adopted, without 
 providing far more technical justification. The quoted Raccoon attack is 
 an easy to mitigate attack (which has nothing to do with finite field 
 groups, just with poor design choices of postprocessing, where one uses 
 variable-size integer representations for a key). There are also good 
 reasons to have key exchanges where one of the parties has a static key, 
 whether ecc-based or ff-based (e.g., sni, opaque), for which secure 
 implementations are known. No detail is provided and that alone should be 
 sufficient reason to not adopt.
  
 Rene
  
 On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
> This is a working group call for adoption for Deprecating FFDH(E) 
> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
> ). We 
> had a presentation for this draft at the IETF 110 meeting and since it is 
> a similar topic to the key exchange deprecation draft the chairs want to 
> get a sense if the working group wants to adopt this draft (perhaps the 
> drafts could be merged if both move forward).  Please review the draft 
> and post your comments to the list by Friday, August 13, 2021.  
>  
> Thanks,
>  
> The TLS chairs
> __ __
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
  
 
 -- 
 email: rstruik@gmail.com | Skype: rstruik
 cell: +1 (64

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Filippo Valsorda]

2021-08-27 15:13 GMT+02:00 Blumenthal, Uri - 0553 - MITLL :
>> Thanks for all the discussion on this topic.  There are several modes that 
>> TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to 
>> merge some of the cases covered by this draft into the obsolete keyex draft. 
>>  I'd like to see if there is some consensus to make this change before we 
>> adopt it into the working group. 
>>  
>>  1. static-static where both client and server have DH certificates with 
>> long term keys.  I think we have general consensus that this mode should be 
>> a must not.  To deprecate this mode I think we need to state that clients 
>> MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and server 
>> MUST NOT request them.  Would the working group support merging this 
>> guidance into the obsolete keyex draft?  
>>  
>> Static-static is OK only when coupled with ephemeral (for forward secrecy), 
>> using the static part for implicit mutual authentication. Not good when used 
>> “alone”. Within the TLS context, OK to “MUST NOT”.
>>  
>>  1. ephemeral-static where the client uses an ephemeral key and the server 
>> uses a long term key.  This mode does not provide forward secrecy.  I'm not 
>> sure we have reached consensus on how far to deprecate this option.  Would 
>> the working group support MUST NOT use these ciphersuites unless forward 
>> secrecy does not matter for your use case and any implementation guidance 
>> provided to avoid weaknesses is followed?
>> Forward secrecy here is “asymmetric”: “server fails” -> “secrecy fails”. 
>> There are use cases…
>> I recommend “SHOULD NOT” here.
>  
> [FV] The implementation guidance to avoid weaknesses in any ephemeral-static 
> exchange is "don't get anything wrong, anything at all, all the way down to 
> your field arithmetic libraries". I don't think that's a workable 
> recommendation, and I believe we should deprecate modes that are so unsafe to 
> implement.
>  
> Static-ephemeral is _not_ “so unsafe to implement”, not any more than any 
> other mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

This is empirically disproved by a number of vulnerabilities that are 
exploitable (or near-misses for other reasons) only in ephemeral-static mode, 
such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, 
CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and 
CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a 
good explanation of how these attacks work, and you might find 
https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf
 interesting as well.

Anyway, we keep going in circles around what deprecation is. In my opinion, an 
IETF deprecation doesn't "kill off" anything, it just says it's not encouraged, 
so it sounds like you support deprecation in those terms.

>  
>>  1. ephemeral-ephemeral  - I think these are already covered in the obsolete 
>> keyex draft. 
>> Absolutely no reason to deprecate or obsolete this mode.
>>  
>>  
>> On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:
 >   which is a main reason cited for deprecating RSA in 
 > draft-aviram-tls-deprecate-obsolete-kex.
  
 Have the authors look at Post-Quantum KEMs?
>>>  
>>> I'm not sure why PQ KEMs are relevant here.
>>>  
>>>  
 On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL 
  wrote:
  
 >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites 
 > do not provide
 >  forward secrecy,
  
 Unless you use semi-static exchange, which in many cases makes sense.
  
 >   which is a main reason cited for deprecating RSA in 
 > draft-aviram-tls-deprecate-obsolete-kex.
  
 Have the authors look at Post-Quantum KEMs?
  
 >  Do you object to just the citation of the Raccoon attack or do you also 
 > feel that we
 >  should keep these ciphersuites that do not provide forward secrecy 
 > around?
  
 I think these suites should stay around. 
  
 While static-static indeed do not provide forward secrecy (and many of us 
 – though not everybody! – carry for that), static-ephemeral DH and ECDH 
 are perfectly fine from that point of view.
  
  
  
 On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
  wrote:
> I agree with Rene’s points.
>  
> -- 
> Regards,
> Uri
>  
>  
> *From: *TLS  on behalf of Rene Struik 
> 
> *Date: *Friday, August 13, 2021 at 09:58
> 
> Dear colleagues:
>  
> I think this document should absolutely *not* be adopted, without 
> providing far more technical justification. The quoted Raccoon attack is 
> an easy to mitigate attack (which has nothing to do with finite field 
> groups, just with poor design choices of postprocessing, where one uses 
> variable-size integer representations for 

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Filippo Valsorda]

2021-08-27 17:25 GMT+02:00 Rene Struik :
> {officially on vacation till Labor Day, but weighing-in briefly}
> 
> Hi Filippo:
> 
> I had a brief look at the CVEs you referenced and at your Blackhat 2018 
> presentation. 
> 
> Some observations on your Blackhat 2018 presentaton: (a) the attack seems to 
> be a reincarnation of the so-called Goubin attack presented 19 years earlier 
> (in 1999); (b) the attack requires many (100s) of reuses of the same private 
> key string. Both the 1999 attack and your Blackhat 2018 version can be easily 
> prevented if one uses blinded private keys.
> 
> A closer look at your referenced CVEs suggests these can be classified as (i) 
> lack of checking for improperly generated DH groups; (ii) exploiting 
> overflow/underflow/carry bugs. To me, nothing seems to be new here and more 
> likely a failure of implementers to heed to results and advice predating the 
> CVEs by years (and sometimes decades) or in QA processes. E.g., with respect 
> to (i), one had not gotten oneself into trouble if one had actually bothered 
> to implement domain parameter checks. In the literature of implementation 
> attacks, OpenSSL has proven to be an excellent "implementation security flaw 
> paper generator".
> 
> I have yet to see evidence that ephemeral-static ECDH would be inherently 
> insecure.

If a consistent history of directly linked vulnerabilities across major 
implementations doesn't show something is unsafe, I don't think there is 
progress to be made in the discussion. Blaming the implementers is not 
particularly interesting to me.

Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it leads 
to Recommended: N in the registry.

> Rene
> 
> On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:
>> [snip] 
>> 
>> This is empirically disproved by a number of vulnerabilities that are 
>> exploitable (or near-misses for other reasons) only in ephemeral-static 
>> mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, 
>> CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and 
>> CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 
>> gives a good explanation of how these attacks work, and you might find 
>> https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf
>>  interesting as well.
>> OpenSSL:
>> 
>> CVE-2016-0701: improper generation of Diffie-Hellman group
>> 
>> The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 
>> before 1.0.2f does not ensure that prime numbers are appropriate for 
>> Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers 
>> to discover a private DH exponent by making multiple handshakes with a peer 
>> that chose an inappropriate number, as demonstrated by a number in an X9.42 
>> file.
>> 
>> CVE-2016-7055: carry-propagation bug
>> 
>> There is a carry propagating bug in the Broadwell-specific Montgomery 
>> multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that 
>> handles input lengths divisible by, but longer than 256 bits. Analysis 
>> suggests that attacks against RSA, DSA and DH private keys are impossible. 
>> This is because the subroutine in question is not used in operations with 
>> the private key itself and an input of the attacker's direct choice. 
>> Otherwise the bug can manifest itself as transient authentication and key 
>> negotiation failures or reproducible erroneous outcome of public-key 
>> operations with specially crafted input. Among EC algorithms only Brainpool 
>> P-512 curves are affected and one presumably can attack ECDH key 
>> negotiation. Impact was not analyzed in detail, because pre-requisites for 
>> attack are considered unlikely. Namely multiple clients have to choose the 
>> curve in question and the server has to share the private key among them, 
>> neither of which is default behaviour. Even then only clients that chose the 
>> curve will be affected.
>> 
>> CVE-2017-3732: carry-propagation bug
>> 
>> There is a carry propagating bug in the x86_64 Montgomery squaring procedure 
>> in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are 
>> affected. Analysis suggests that attacks against RSA and DSA as a result of 
>> this defect would be very difficult to perform and are not believed likely. 
>> Attacks against DH are considered just feasible (although very difficult) 
>> because most of the work necessary to deduce information about a private key 
>> may be performed offline. The amount of resources required for such an 
>&

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Filippo Valsorda]

2021-11-04 11:12 GMT-04:00 David Benjamin :
> Indeed it's *because* there is still an existing 1.2 deployment that we 
> should be judicious with backports. Today, nearly every TLS implementation 
> needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it 
> is not possible for a client to say "I implement xyz extension only at 1.3". 
> That means anyone implementing a backported extension *must* implement and 
> test it in 1.2, even though it'll be virtually unused. Existing 1.2 peers 
> don't implement it and new peers will use it at 1.3.

What David mentions here resonates and is worth underscoring. Specifying an 
extension for both TLS 1.2 and TLS 1.3 forces almost every stack to support it 
at both versions. We don't get to choose "no, we only implement new stuff in 
TLS 1.3", which as far as Go is concerned, is the policy we want.

I understand that IoT devices are not running dual stacks, but that's not the 
point. This is an ecosystem cost analysis. If the extension is defined at both 
TLS 1.2 and TLS 1.3, all dual stacks out there will need to support it at both 
versions.

I think the condition in the charter that Sean mentioned is good, and should be 
abided. If an extension is about TLS 1.2 compatibility or transition, or if 
it's important not to fracture the ecosystem, it might be worth backporting; if 
it's just convenient for stacks that have not updated yet, it should not.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

[Filippo Valsorda]

This is excellent, especially the explicit decision to make concrete primitive 
choices, which allow the scheme to be both secure and efficient.

I have an implementation at filippo.io/mlkem768/xwing 
 which passes the test vectors in 
draft-connolly-cfrg-xwing-kem-00, Appendix A.

By the way, I really appreciate specifying "derandomized" versions of the 
functions for testing. It solves the problem of "randomness from the sky" 
 while 
providing a clear mandate not to expose the random input in high-level APIs. I 
would love to see this pattern adopted widely.

As Bas already mentioned, I suggested making sk = `concat(sk_M, sk_X, pk_X), to 
avoid the pk input to Decapsulate and mirroring in a sense the presence of pk_M 
in sk_M. We've learned with Ed25519 
 that designing APIs where 
key mismatches are possible is dangerous. In this case I *think* there would be 
no security impact, but it leads to questions like "what is the expected 
behavior of Decapsulate if the ML-KEM pk is invalid?" (This change is again 
cheap/possible because X-Wing targets `ML-KEM-768 and X25519 specifically, 
which further validates the team's decision to make concrete choices.)

2024-01-10 21:13 GMT+01:00 Bas Westerbaan :
> Dear tls and cfrg working groups,
> 
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to 
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to 
> recommend.
> 
> # Status quo
> 
> For TLS at the time of writing there are two PQ/T hybrids registered: 
> X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed widely 
> [3]. Both are instances of the hybrid-design draft [4], which use the simple 
> combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not for other 
> applications such as HPKE, as it’s not IND-CCA2 robust [5].
> 
> For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a 
> different combiner that mixes in the X25519 ephemeral key, by using HPKE’s 
> DHKEM construction instead of raw X25519.
> 
> There is also the ounsworth-kem-combiners I-D [7] that informed by [5] 
> proposes the generic combiner
> 
>   KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )
> 
> From a security standpoint that would be suitable for HPKE and TLS. To TLS it 
> is somewhat unattractive as it requires hashing the typically large PQ 
> ciphertexts, and adds some extra hashing in the conversion of the ECDH into a 
> KEM. On the other hand, for TLS it would be nice to have a KEM that is also 
> suitable for HPKE, as HPKE is used in ECH.
> 
> From a usability perspective, ounsworth-kem-combiners requires the user to 
> make several choices: which KEMs and in particular which method to use to 
> turn ECDH into a KEM, which security levels, which KDF, etc.
> 
> # The proposal: X-Wing
> 
> Let us introduce X-Wing [0]. The goal of X-Wing is to be *the* go-to PQ/T 
> hybrid KEM for the majority of use cases (including TLS and HPKE): no need to 
> make choices, or understand the subtleties.
> 
> X-Wing aims for 128-bit security, and for that combines the time-tested 
> X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
> 
>   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 )
> 
> Here ss_X25519 is the plain X25519 shared secret; ct_X25519 is the ephemeral 
> public key; xwing-label a 6-byte label. Note that it doesn’t hash in the 
> ML-KEM ciphertext. For a generic KEM one cannot leave out the ciphertext, but 
> in the case of ML-KEM we can, assuming we can model SHA3/SHAKE as a random 
> oracle. This is proven in [0]. The gist is that FO transform in ML-KEM makes 
> it “ciphertext collision resistant”: even if the underlying lattice problem 
> is broken, it’s infeasible to create from one ciphertext another different 
> ciphertext with the same shared secret.
> 
> # Not final
> 
> We would love to hear your input: X-Wing is not final. For one, ML-KEM itself 
> might still change (presumably only in minor ways) before final 
> standardization. We think the CFRG would be a good venue to standardize 
> X-Wing — do you concur?
> 
> Best,
> 
> Bas, Deirdre, Karolin, Manuel, Peter
> 
> 
> PS. We want to mention explicitly that we see value in the kem-combiners and 
> hybrid-design drafts as generic safe methods to construct hybrids for those 
> use cases where X-Wing would not suffice.
> 
> 
> [0] Spec: https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/
> Proof: https://eprint.iacr.org/2024/039
> [1] Full name X25519Kyber768Draft00. 
> https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/
> [2] Full name SecP256r1Kyber768Draft00. 
> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
> [3] 
> https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
> https://twitter.com/bwester

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

[Filippo Valsorda]

+1 to adoption. I found myself unsure of how many tickets to send in the new Go 
implementation, which is notoriously averse to configuration knobs, and would 
love to have the client pick.

2018-11-07 14:47 GMT+0700 Sean Turner :
> At TLS@IETF103, there was consensus in the room to adopt draft-wood-tls-
> ticketrequests.  This message is to confirm that consensus.  If you do 
> not support adoption of draft-wood-tls-ticketrequests as WG item please 
> say so by 2359UTC on 30 November 2018 (and say why).
> 
> Thanks,
> Joe and Sean
> ___
> 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] TLS Impact on Network Security draft updated

[Filippo Valsorda]

Before any technical or wording feedback, I am confused as to the nature of 
this document. It does not seem to specify any protocol change or mechanism, 
and it does not even focus on solutions to move the web further.

Instead, it looks like a well edited blog post, presenting the perspective of 
one segment of the industry. (The perspective seems to also lack consensus, but 
I believe even that is secondary.) Note how as of 
draft-camwinget-tls-use-cases-05 there are no IANA considerations, no security 
considerations, and no occurrences of any of the BCP 14 key words (MUST, 
SHOULD, etc.).

Is there precedent for publishing such a document as an RFC?

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

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

[Filippo Valsorda]

2019-12-12 06:51 GMT-05:00 Hubert Kario :
> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote:
> > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara 
> > wrote:
> >
> >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
> >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
>  
>  One test I just tried:
>  
>  - Smartcard capable of raw RSA.
>  - OpenSC PKCS#11 drivers.
>  - Firefox ESR 68
>  - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is
>    enabled[2]).
>  
>  Result: Failed. Client hits internal error code
>  SEC_ERROR_LIBRARY_FAILURE
>  [3].
> >>> 
> >>> That doesn't match my understanding of how NSS works – AFAIK, NSS (and as
> >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the
> >>> token,
> >>> depending on what kind of algorithms the token advertises.
> >>> 
> >>> I think the issue was the old version of OpenSC, new versions can do
> >>> rsa-pss
> >>> with rsa-raw:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1595626
> >>> https://github.com/OpenSC/OpenSC/pull/1435
> >> 
> >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes
> >> client certificates in TLS 1.3 in Firefox work with that card (works even
> >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side).
> >> 
> >> There is apparently no release with the fix. One needs 0.20-rcX or recent
> >> git master.
> >> 
> >
> > Chrome likewise tries to polyfill PSS support out of raw RSA when the
> > underlying keys support it, but PSS support is still a problem. In
> > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with
> > raw padding. (Oddly, the spec does reference OAEP, but signing is only
> > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Between
> > the negotiation ordering and the client certificate privacy flaw fixed in
> > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus,
> > the draft. It's true that it adds some transitionary codepoints to TLS 1.3,
> > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus on
> > top of *much* more important changes.
> >
> > Most properties negotiated by TLS can be unilaterally updated by the
> > TLS-related components of a system. This is great because it means we can
> > deploy TLS 1.3's improvements. The long-term credentials are one of the big
> > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519.
> > We wanted to maintain continuity with existing RSA keys, but since it was
> > possible to switch them to RSA-PSS we went ahead and did that. Sadly, it
> > appears that last point can be more true for server keys than client keys.
> > :-(
> 
> If TLS 1.2 was looking insecure, I would be with you on this one. But given
> that TLS 1.2 can be configured to be as secure as TLS 1.3

TLS 1.3 provides privacy for client certificates, which TLS 1.2 does not.

> I think introducing
> weak points to TLS 1.3, weak points we will have to live with for the next
> decade, if not two, is counter-productive and will only delay deployemnt of 
> RSA-PSS capable HSMs.

This draft is only about client authentication, it does not release
pressure from server-side HSMs.

I just had to hold back a Go crypto/tls deployment from TLS 1.3 due to
the same issue that David encountered, so I'd support this draft.

Leaving behind entire client hardware generations is not the same thing
as enforcing progress in software implementations.

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

Re: [TLS] Bikeshedding ECHO

[Filippo Valsorda]

As a data point, I was fairly confused when ECHO came up in conversation, and 
had to stop to ask what it was. I think I would have had a better chance of 
figuring it out from context or search if it were called ECH, but don't have a 
strong preference for any specific name.

ECH does have a remarkable short Wikipedia disambiguation list, FWIW. 
https://en.wikipedia.org/wiki/ECH

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

[TLS] Add max_early_data_size to TicketEarlyDataInfo

[Filippo Valsorda]

Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a
client sent early data, there's no way to accept only a part of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

https://github.com/tlswg/tls13-spec/pull/674

[Please keep me in the CC of replies]

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

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

[Filippo Valsorda]

2016-10-07 22:06 GMT+ David Benjamin :
> Units is a little interesting. For those purposes, this limit would
> kick in whether or not the early data could be decrypted, so the server-
> side limit would be measured in ciphertext, possibly even including
> record headers. (Although any inaccuracies in converting could be done
> by just advertising an underestimate and breaking peers that send
> pathologically silly things like all one-byte records. So it doesn't
> matter much.)

Yeah, I've been thinking about that. I went for plaintext because it
seemed to simplify the API on the client side, but maybe it's best to
count  the whole record size, and let the client worry about not doing
some silly splitting or padding.

I'll update the PR.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Filippo Valsorda]

I'm definitely for 1.3.

I get where 4 is coming from, but 1.2 is not going anywhere soon, and we
spent the last 10 years training people that the high-numbered one is
bad, and that the 1.x ones are cool.

I really don't want to have the following conversation, with the exact
same people the proponents of 4 are trying to help:

"You only support 1.2, you should support 4"
"Oh, wasn't it that weird other way around where the high one was
broken?"
"Ah, no, 4 is the latest and greatest"
"Oh, ok, then I should support only 4 and 3?"
"Nono, 3 is terribly broken."
"Oh, so only 4? Do all clients support it?"
"Uh, you should keep 1.2"
"Ah, so 1.2 is better than 3 but worse than 4?"
"Yeah... I'm sorry"

"4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad, 1.2 is
good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great" would
be.

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

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

[Filippo Valsorda]

2024-04-15 20:14 GMT+02:00 Joseph Salowey :
> Should the draft deprecate these ClientCertificateTypes and mark the entries 
> (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' 
> discouraged?

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

Re: [TLS] [EXT] Re: Deprecating Static DH certificates in the obsolete key exchange document

[Filippo Valsorda]

2024-04-21 23:26 GMT+02:00 Blumenthal, Uri - 0553 - MITLL :
> I see two possibilities:
>  
>  1. Nobody in the real world employs static DH anymore – in which case this 
> draft is useless/pointless; or
>  2. On private networks people employ static DH to implicitly authenticate 
> their peers (a-lá MQV) – in which case this draft is harmful.
>  
> Overall, I’m amazed by drafts like this one. Is nothing constructive remains 
> out there to spend time and efforts on?

As an implementer, these drafts help me avoid annoying conversations about why 
I don't support X or Y, and it looks like there are other implementations that 
aim (explicitly or implicitly) to implement anything that's not deprecated.

In my experience, most of the time these drafts take is due to procedural or 
"shouldn't we spend time on other things" concerns. Which is unfortunate.

> --
> V/R,
> Uri
> * *
> *There are two ways to design a system. One is to make it so simple there are 
> obviously no deficiencies.*
> *The other is to make it so complex there are no obvious deficiencies.*
> * 
> -  C. A. R. Hoare*
>  
>  
> *From: *TLS  on behalf of Viktor Dukhovni 
> 
> *Date: *Sunday, April 21, 2024 at 14:07
> *To: *tls@ietf.org 
> *Subject: *[EXT] Re: [TLS] Deprecating Static DH certificates in the obsolete 
> key exchange document
> !---|
>   This Message Is From an External Sender
>   This message came from outside the Laboratory.
> |---!
> 
> On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote:
> 
> > I realise that absence of evidence != evidence of absence, but in response 
> > to
> > my previous request for anyone who has such a thing to comment on it, and 
> > even
> > better to send me a sample so I can see one, no-one has mentioned, or
> > produced, even one example of "a legitimate CA-issued [static-epmeheral DH
> > certificate] rather than something someone ran up in their basement for 
> > fun".
> > 
> > So is the draft busy deprecating unicorns and jackalopes?  Nothing against
> > that, but it's probably worth adding a note that such certificates are
> > currently not known to exist so you probably don't have to worry about it 
> > too
> > much.
> 
> Can't say I've seen any static DH certificates in the wild, but
> I have seen code to support these, and perhaps the point is to
> bless deprecating/disabling/removing such code?
> 
> In any case, this feels like cosmetic cleanup, rather than an
> effort to migrate a significant population of existing users
> to better practice.
> 
> -- 
> Viktor.
> 
> ___
> 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]Re: Curve-popularity data?

[Filippo Valsorda]

I expect X25519 to be the most commonly *selected *(as opposed to supported) 
TLS key exchange on the open Internet, due to browsers preferring it for its 
marginal performance benefit. This is not a popularity contest though and 
that's not the most useful metric for choosing the ECC component of a PQC 
hybrid.

The most important performance consideration in TLS is avoiding Hello Retry 
Request round-trips due to the server supporting none of the client's key 
shares. Moreover, clients want to reuse the ECC component of the hybrid key 
share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, 
X25519+ML-KEM-768 so that the X25519 key generation can be reused).

Given those goals, the important metric is server support. *We should indeed 
collect data on what are the most supported key exchanges server-side*, 
probably weighted by website or implementation popularity. (I expect X25519 and 
P-256 to have nearly equivalent support, maybe with some FIPS-related delta in 
favor of P-256.)

I actually meant to bring this up, because as an implementer I also want to 
avoid proliferation of hybrid options, but *it would actually make my life much 
easier if the one universal hybrid (and/or default client key share) was 
P-256+ML-KEM-768*.

The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by 
the CA/B Baseline Requirements. This is not changing soon. That means I am on 
the hook to carry an optimized and secure P-256 implementation no matter what.

If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am 
*also *on the hook to carry an optimized and secure X25519 implementation. 
That's double the work, double the opportunity for mistakes, double the 
complexity, double the attack surface.

If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 
becomes much less important, and I can carry a simpler less efficient (e.g. 
without assembly) implementation for it, and focus my limited resources on 
P-256.

P-256+ML-KEM-768 also has the added benefit of being FIPS 140 compliant today, 
without waiting for ML-KEM-768 modules to get certified (which can take years), 
speeding up PQC adoption in settings that—unfortunately—are constrained by FIPS 
140. It also avoids divergence between regular and compliance modes, again 
reducing implementer workload and attack surface.

For what it's worth, implementing P-256 these days is way easier than when 
X25519 was designed. First, Renes, Costello, and Batina published complete 
formulas for it in https://eprint.iacr.org/2015/1060 (although interestingly 
P-256 still has a red False in the "complete" column in version 2017.01.22 of 
https://safecurves.cr.yp.to, which maybe I am misinterpreting). Second, we have 
formally verified field implementation generators such as fiat-crypto. Third, 
we learned to make key shares always ephemeral which makes invalid curve 
attacks irrelevant.

2024-06-02 20:47 GMT+02:00 D. J. Bernstein :
> Information about the popularity of specific cryptosystems plays a role
> in decisions of what to standardize and deploy. I've been pointed to a
> surprising statement (quoted below) regarding popularity of curves, in
> particular in TLS handshakes. The statement is from one of the current
> TLS co-chairs, a month before the co-chair appointment. I'm wondering
> what data the statement is based on; the statement doesn't have a
> description of the data sources, and the statement seems impossible to
> reconcile with various public statements that have clear data sources.
> 
> A specific reason that I'd like to resolve this is that I'm concerned
> about the impact on post-quantum deployment. To explain:
> 
>* We're failing to protect confidentiality of most user data against
>  future quantum attacks---but switching to a post-quantum system has
>  an unacceptably high chance of making security even worse. See
>  https://cr.yp.to/papers.html#qrcsp for how much has been broken.
> 
>* The obvious path forward is to immediately roll out ECC+PQ hybrids,
>  as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
>  in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024,
>  X25519+kyber512 in 
> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/,
>  etc. Then we're not making security worse, and _hopefully_ we're
>  making it better.
> 
>* This still leaves the challenge of minimizing post-quantum risks.
>  That's hard enough without the combinatorial explosion of combining
>  each post-quantum option with a profusion of curves. Adding many
>  curve choices is the sort of thing that _sounds_ simple until you
>  start writing software, tests, etc. (I designed X25519 after
>  suffering through implementing an example of NSA/NIST ECDH; see
>  https://cr.yp.to/nistp224.html and the accompanying talks. NSA's
>  harder-to-implement approach to ECC also ends up mor

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 12:07 GMT+02:00 Martin Thomson :
> Some numbers from our telemetry.  This is purely connection-volume-based (so 
> sites with lots of connections will be over-represented), but overall fairly 
> stable.
> 
> Key exchange:
>   ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
> ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
> RSA size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%

Thank you for sharing those! Could you filter down to TLS 1.3 only (since we 
are not going to add hybrids to TLS 1.2 anyway)? I assume that after filtering 
to TLS 1.3, any non-X25519 connections are Hello Retry Requests, since you only 
send an X25519 key share?

I think the relevant question to selecting an ECC hybrid is "how many of the 
X25519 connections would have supported P-256, and vice-versa?" If you are 
sending a X25519 key share and getting an HRR to P-256, I guess the 
would-also-support-X25519 number is zero. The would-also-support-P256 number is 
harder to get: either you sample a small percentage of connections and send a 
P-256 key share, or we rely on internet scan data like Censys's.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 14:38 GMT+02:00 Bas Westerbaan :
> We're not just a server, but also a client proxying requests to our 
> customer's origins. We routinely scan customer's origin servers for their 
> support of keyshares. [...]
> 
> We also measure server support for each. (We send just the single keyshare 
> for the group and only advertise support for that group.)
> 
> 97.6% P-256
> 97.0% X25519
> 94% P-384
> 89% P-521
> 0.54% X25519Kyber768

Thank you for collecting and sharing these numbers! I think this here is the 
most interesting bit in terms of curve popularity, since any difference in CPU 
time is ultimately marginal compared to the cost of a HRR. It looks like X25519 
and P-256 are approximately as popular, as expected, but {P-256, 
P-256+ML-KEM-768} would save a round-trip compared to {X25519, 
X25519+ML-KEM-768} for one connection every ~170 (on top of the 
complexity/maintenance advantage of reusing the certificate signature 
implementation).___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
> More importantly, there are servers that will HRR to X25519 if presented a 
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't 
> have data at hand how often that happens.

Are you saying that some of the 97.6% of servers that support P-256 still HRR 
to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported groups 
list, and that's BoringSSL's default behavior? I find that very surprising and 
would be curious about the rationale.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-05 15:17 GMT+02:00 Peter Gutmann :
> Nick Harper  writes:
> 
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
> >be present in the key_share extension if that extension is non-empty.
> 
> Just because it's possible to rules-lawyer your way around something doesn't
> make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
> can't reformat your hard drive, for example, so presumably that's OK too).
> The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
> keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

This is not rules lawyering. P-256 is MTI as a supported group, and Chrome 
supports it and will successfully negotiate with a server that only supports 
P-256 (through a Hello Retry Request, which is a perfectly valid—if 
inefficient—mechanism). That's following both the letter and the spirit of the 
MTI requirement. If the spec wanted to make a key share mandatory, it could 
have said so.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

[Filippo Valsorda]

If P-386+ML-KEM-1024 is there for CNSA compliance, I see no need to provide an 
Edwards counterpart to it: there is no Edwards National Security Algorithm 
Suite. Also, isn't X448 TLS deployment nearly non-existent?

2024-09-09 15:16 GMT+02:00 Alicja Kario :
> Not explicitly, but it is definied in other protocols, like CMS where it
> was asked for explicitly.
> 
> I can remove it, but I think that omiting it will make the document
> appear more biased towards NIST curves than Edwards ones...
> 
> On Monday, 9 September 2024 15:09:45 CEST, Bas Westerbaan wrote:
> > Did anyone ask for X448?
> >
> > On Mon, Sep 9, 2024 at 3:00 PM Alicja Kario  wrote:
> > On Monday, 9 September 2024 02:04:48 CEST, kris wrote:
> >> Hello,
> >>
> >> I'm sorry, possibly I've missed some emails.
> >> If there is an interest I propose we add it to existing draft, 
> >> publish version -03 and request a code point.
> >> The repo is here:
> >> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem
> >>
> >> Feel free to open PR
> >
> > done:
> > https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/22
> >
> >> Cheers,
> >> Kris
> >> From: Alicja Kario 
> >> Sent: Saturday, September 7, 2024 12:39:30 AM
> >> To: kris; tls@ietf.org
> >> Subject: draft-kwiatkowski-tls-ecdhe-mlkem and P-384
> >>  
> >> Hello,
> >>
> >> What's the situation with other groups for TLS 1.3?
> >> Specifically, are there any plans to specify SecP384r1MLKEM1024?
> >>
> >> As mentioned in multiple emails already, high security system
> >> already have a strict requirement to use P-384 curve exclusively.
> >> Similarly, for post-quantum resistance they will be required
> >> to use ML-KEM-1024.
> >>
> >> Will you add it to the draft, or should we start work on a
> >> separate one that defines those hybrid algorithms?
> >
> 
> -- 
> 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: MLKEM or Khyber KX

[Filippo Valsorda]

We (Go) also generate fresh keys for each handshake and would warmly welcome it 
being a MUST in the IETF specification of the ML-KEM TLS hybrids.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Filippo Valsorda]

2025-01-07 14:16 GMT+01:00 John Mattsson 
:
> Alicja Kario wrote:
> >Can you point to examples of people actually using x448 (TLS group ID 30) in 
> >practice?
>  
> I think that is the wrong question.

If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I 
see no reason to standardize it.

The reason to deploy SecP384r1MLKEM1024 is compliance. Like it or hate it.

The obvious set of hybrids to standardize and implement is:
 1. the one everyone should use;
 2. one that everyone who can't use (1) can use.
I personally liked SecP256r1MLKEM768 for (1) because I need to carry an 
optimized P-256 implementation for WebPKI certificates anyway, but 
X25519MLKEM768 is fine, too.

SecP384r1MLKEM1024 fits the bill for (2) while X448MLKEM1024 does not, both for 
compliance transition reasons, and for "many libraries don't offer a X448 
implementation" reasons.

(I *also* generally disagree with ephemeral ECDH over NIST P curves being "far 
from the state of the art," I actually think it's perfectly fine, but we don't 
have to resolve that disagreement: it's not an input to the argument above.)

> I think the right question is which hybrids do IETF recommend people to use 
> in the future. I think the answer is hybrids with X25519, X448, Ed25519, and 
> Ed448.
>  
> I don't think IETF should standardize much more P-256, P-384, P-521, ECDSA, 
> RSA, and SHA-2. For new products, Ericsson is currently asking all our 
> suppliers for X25519, X448, Ed25519, Ed448, and SHA-3 and we are willing to 
> pay for that. P-256, P-384, P-521, ECDSA, RSA, and SHA-2 were all quite good 
> algorithms when they were standardized decades ago, but today they are far 
> from state-of-the art.
>  
> Cheers,
> John
>  
> *From: *Alicja Kario 
> *Date: *Tuesday, 7 January 2025 at 13:52
> *To: *Loganaden Velvindron 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448
> (I originally proposed PR that added that codepoint, together with the
> secp384r1mlkem1024, so I'm really not against it, but...)
> 
> Can you point to examples of people actually using x448 (TLS group ID 30) 
> in
> practice?
> 
> If you want to experiment, then there's the whole private range, what would
> making a public ID add to that experiment?
> 
> On Tuesday, 7 January 2025 10:01:20 CET, Loganaden Velvindron wrote:
> > How about having x448mlkem1024 allocated as an experimental codepoint
> > for those who
> > wish to use it ?
> >
> >
> > On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni  wrote:
> >> On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: ...
> >
> 
> -- 
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: 
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cbbc800fcb3474cec48ed08dd2f1a1b11%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638718511346705932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dig7Bh9QRBv523MgDQnegB48hAQdcMpomAo64uZB5b0%3D&reserved=0
> 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 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

[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: Changing WG Mail List Reputation

[Filippo Valsorda]

2024-10-25 14:30 GMT+02:00 Sean Turner :
> • Repetition of arguments without providing substantive new information 
> • Requesting an unreasonable amount of work to provide information

Personally, the reason I find the list (and generally the IETF) unwelcoming is 
that arguments can easily prevail by attrition. Some participants have the time 
and determination to reply to every email, nitpick every argument, 
systematically reiterate their position, attack other's positions and 
motivations, and demand explanation of every assertion, while others don't.

I know at least a few implementers that don't engage with the IETF because they 
don't have time for all that. Myself I go months without opening the list inbox 
because I know engaging is a tiny campaign every time.

Two participants sending a dozen emails in support of solution A, and six 
participants sending one email each in support of solution B can look a lot 
like there is no consensus, or that there is consensus for solution A, 
especially if not all objections to solution B are painstakingly addressed.

I think this is what these two points in the reminder are getting at, but I am 
curious how moderating such behavior would look like, because every individual 
instance can be defended by arguing (probably at length!) that actually there 
is new information in each post, or that the amount of work being demanded is 
perfectly appropriate.

I want to acknowledge this is a common and difficult problem to solve. 
Famously, Wikipedia suffers from the same pathology. Maybe it's just the 
downside of open forums and it should be accepted, but if the goal is improving 
the reputation of the list, I feel there needs to be willingness to engage 
these behaviors, which will not make everyone happy.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[Filippo Valsorda]

I supported and support prohibiting key reuse, and seem to remember multiple 
other supporting voices not named John. My impression (which could be mistaken 
because these debates are really painful to keep track of) is actually that 
objections are in the rough, if we count From headers rather than Message-ID 
headers.

Yes, there is no protocol police, and implementations feeling the Need for 
Speed might still do reuse. They might also use all zeroes in place of random 
bytes, since memset is faster than any DRBG! It's also easier. The good news is 
that we won't have to waste time thinking about how reuse-based attacks might 
apply to compliant implementations.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Filippo Valsorda]

Joining the chorus to support adoption and a speedy path to WGLC.

We have already shipped X25519MLKEM768 in Go 1.24.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Filippo Valsorda]

I support adoption.

I also would like to prohibit key reuse, but opposing adoption feels like a bad 
way to reach that outcome: if the document is published by the ISE or just 
lives on as a widely deployed draft, the WG will have no say in what 
requirements it has.

It also seems clear to me the WG consensus will be for the codepoints to remain 
"Recommended: N" at least for now. Opposing adoption to force the document to 
be published in a way that can't be "Recommended: Y" feels like (unnecessarily) 
meta-gaming the IETF process.

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

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Filippo Valsorda]

2025-04-02 17:39 GMT+02:00 Salz, Rich :
> Opposing adoption to force the document to be published in a way that can't 
> be "Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process.
>  
> I am not aware of any of those opposed who are doing it for this reason. 
> Perhaps speculating on their reasons isn’t a good thing to do?

I interpreted at least one opposing statement in the sibling thread as 
expressing a preference for the ISE for this reason, but I chose to address the 
concern (Recommended Y or N) and not the individuals.

If I misinterpreted, then great: my argument is a non-sequitur that applies to 
no one.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

2025-05-16 17:46 GMT+02:00 Richard Barnes :
> It would also be useful to understand why an RFC adds value over just having 
> an IANA code point.  Since the registry is Specification Required and FIPS 
> 205 exists, someone could send email to IANA today and get code points as 
> soon as Yoav/Rich/Nick response to email.

Indeed. I don't support adoption and would like to see this alternative path 
get better use: register a codepoint, deploy it, and then if appropriate come 
back with adoption and performance data for a Recommended = Y RFC.

I will note that to make that path viable we need to collectively agree not to 
make backwards-incompatible changes (without assigning a new codepoint) to 
things that have non-experimental IANA codepoints, otherwise deployments will 
always want an RFC for stability.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

2025-05-19 12:41 GMT+02:00 John Mattsson :
> OpenSSL 3.5 has already shipped with the Values 0x0911 – 0x91C that are in 
> the draft. 

Frankly, this is a bit irritating, especially given the precedent of seed 
encodings, where we all got saddled with a fractal encoding to appease the 
"legacy" of a handful of early adopters. Now OpenSSL ships a production feature 
in a LTS version with 12 commandeered unregistered codepoints from the public 
range. Ok.

It's tempting to learn the lesson that as an implementor I should just design 
stuff to my liking, ship it, and then expect the IETF to retcon it since it's 
in production.

However, an alternative, more productive lesson is that codepoints can indeed 
be treated as stable without an RFC (sometimes without even registering them!), 
suggesting there is indeed no need to adopt this document.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

2025-05-19 13:53 GMT+02:00 Viktor Dukhovni :
> On Mon, May 19, 2025 at 01:29:40PM +0200, Filippo Valsorda wrote:
> > 2025-05-19 12:41 GMT+02:00 John Mattsson :
> > > OpenSSL 3.5 has already shipped with the Values 0x0911 – 0x91C that
> > > are in the draft. 
> > 
> > Frankly, this is a bit irritating, especially given the precedent of
> > seed encodings, where we all got saddled with a fractal encoding to
> > appease the "legacy" of a handful of early adopters. Now OpenSSL ships
> > a production feature in a LTS version with 12 commandeered
> > unregistered codepoints from the public range. Ok.
> 
> OpenSSL 3.5 DOES NOT have TLS codepoints for SLH-DSA.  I don't know
> where John Mattsson got that impression.  The only PQ signature TLS
> codepoints in OpenSSL 3.5 are:
> 
> 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
> 
> 0x0904  mldsa44 N   [draft-tls-westerbaan-mldsa-00]
> 0x0905  mldsa65 N   [draft-tls-westerbaan-mldsa-00]
> 0x0906  mldsa87 N   [draft-tls-westerbaan-mldsa-00]
> 

That's good to hear! Sorry for not double-checking.

Since the mldsaNN codepoints also reference a draft, I think they similarly go 
to show that it's ok to consider assigned codepoints stable and there is no 
need for an RFC. (Which to be clear I agree with. Go shipped X25519MLKEM768 
with IANA-assigned draft-based codepoints.)___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Filippo Valsorda]

2025-06-19 09:52 GMT+02:00 Viktor Dukhovni :
> One might, for example, instead dedicate to this end
> intermediate issuer CAs having a serverAuth EKU, that will in many (be
> they for now ad hoc, rather than RFC5280-blessed) TLS stacks be
> intepreted as restricting any issued EE certificates to that EKU
> (implicit or explicit).

If making a serverAuth intermediate is acceptable, then it sounds like there is 
no issue here: just self-sign it and submit that to the Chrome Root Program. 
The policy doesn't say anything about the parents of the roots. (That would be 
indeed outrageous!)___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Filippo Valsorda]

Getting roots to ship with operating systems is certainly a hard multi-year 
project, but why does ejabberd or an MTA need to use the OS root store?

If the XMPP and/or SMTP ecosystems feel the need for a PKI which behaves 
differently from the WebPKI, can't they ship the roots of such a PKI with their 
code?

Boulder is open source and ACME is an extensible protocol, so the barrier to 
standing up a PKI has never been lower.

2025-06-19 00:46 GMT+02:00 Klaus Frank 
:
> On 2025-06-17 20:16:19, David Benjamin wrote:
> > (As always, wearing an individual hat here. In particular, I am *not*
> > speaking on behalf of the Chrome Root Program.)
> >
> > This draft is not the way to solve this problem.
> >
> > The point of markers like EKUs is to avoid cross-protocol attacks. Client
> > and server here do not refer to abstract classifications of entities. They
> > are specific, well-defined roles in the TLS protocol. Whether the TLS
> > client represents a human or a backend service, it is a client as far as
> > TLS is concerned. This draft breaks this. TLS stacks that implement it risk
> > cross-protocol attacks.
> 
> I thought I was only re-aligning with your interpretation of a client 
> being a end-device? Considering all of the discussions regarding this 
> topic the common theme appears to be you at the Chromium project (and 
> CAs that started to follow your policy change) ONLY considering 
> clientAuth being used for end user authentication like with smart cards. 
> server-to-server was overlooked everywhere. And within the discussions 
> to this topic way too much was spent on trying to point out that a 
> TLS-client is the initiator of a TLS connection and not an device held 
> by and enduser.
> 
> Frankly if there is no way to get a clientAuth certificate for a server 
> to be used in a similar way like a server certificate and the 
> understanding at the CA-level appears to be "server means device" and 
> "client means end-user" then the only logical step is to re-align the 
> definition within the RFCs to unbreak all of these usecases.
> 
> At least to me that is a way better approach than just disabling TLS 
> validation entirely. Which is basically what people will be forced to 
> do. Changing the protocols takes time. "Just" allowing a server-cert to 
> be considered valid by a TLS-server that is expecting to be 
> communicating in a P2P-fashing within a decentralized network only with 
> other server and never with end users is way better. It also allows you 
> at Chromium to just not care about them at all as this special kind of 
> validation would be limited to software expecting server-to-server 
> connections only.
> 
> Also it shouldn't cause any additional impact. As the required 
> assurances are the ones being provided "there is a server with this dns 
> name or ip address".
> 
> And regarding the cross-protocol attack part, well if the only commonly 
> trusted certificates are of EKU serverAuth then that is basically the 
> only EKU in existance. Everything else may as well not exist at all at 
> that point as it will fail validation anyway.
> 
> > As for PKI hierarchies, the Web PKI, as curated by web clients,
> > authenticates web servers. All the policies and expectations around it,
> > from monitoring to domain validation to Certificate Transparency, are
> > maintained with web servers in mind. This blog discusses some of this:
> > https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/
> I understand your thought process. However that still doesn't change the 
> reality that it is basically the **only** PKI hierarchie in existance.
> 
> It would be a different thing if not literally everything in existance 
> would share the Web-PKI browsers use.
> 
> > That is not to say that backend services shouldn’t authenticate as TLS
> > clients with certificates. If a backend service needs to take the role of a
> > TLS client, a certificate from some PKI is a fine way to solve that. But
> > there is no reason for that to use the same PKI hierarchies as web server
> > authentication.
> 
> Ok, I'll play along for now. Name a single CA that I can go to right now 
> to get a certificate with EKU clientAuth issued towards 
> dNSName=myserver.frank.fyi that your devices would trust without 
> additional configuration. There is none. Therefore this argument is invalid.
> 
> In addition having clientAuth and serverAuth within the same certificate 
> was also used as a cheap way to do channel binding. When you've two 
> systems where either of these systems can initiate a connection like 
> with e.g. IPSec then having a single certificate with both clientAuth 
> and serverAuth within it allows to securely mutually authenticate the 
> connection regardless of what side initiated it. And that is the 
> scenariou in common here. Well now you may say EKU 1.3.6.1.5.5.7.3.17 
> exists, however what CA coud I go to to get such a certificate that you 
> trust without having t

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Filippo Valsorda]

2025-06-19 07:39 GMT+02:00 Viktor Dukhovni :
> On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> 
> > This draft is not the way to solve this problem.
> 
> I should mention, that though that is also my reaction, we are by no
> means on the same page here.  I find the Google position in:
> 
> 
> https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies
> 
> to be substantively indefensible.  Google are not merely saying that
> Chrome will not trust certificates with a "mixed" client/server EKU
> (which is a nuisance position I can live with), rather they are coërcing
> the CAs to not issue any client certificates even for non-Chrome
> use-cases.

No, they are requiring CAs who wish to have a root included in Chrome for the 
purposes of TLS server authentication to issue roots dedicated to TLS server 
authentication.

CAs as entities can operate multiple roots and are not constrained in what they 
issue from other roots. (That would be indeed outrageous!)___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Filippo Valsorda]

2025-06-19 01:41 GMT+02:00 Klaus Frank 
:
> On 2025-06-19 00:57:35, Filippo Valsorda wrote:
> > Getting roots to ship with operating systems is certainly a hard multi-year 
> > project, but why does ejabberd or an MTA need to use the OS root store?
> >
> > If the XMPP and/or SMTP ecosystems feel the need for a PKI which behaves 
> > differently from the WebPKI, can't they ship the roots of such a PKI with 
> > their code?
> >
> > Boulder is open source and ACME is an extensible protocol, so the barrier 
> > to standing up a PKI has never been lower.
> >
> Simply but cause ejabberd isn't the only XMPP software in existance, 
> same for an MTA (however the issue there is mostly caused by microsoft 
> demanding such a certificate to accept mails within a hybrid deployment, 
> as someone from Microsoft was so kind to jump in I think we can leave 
> that part to them to answer)
> 
> mutual SMTP between the MX servers is basically considered to have 
> failed. Exactly for what the Chrome Policy wants everyone to do. Because 
> it lacked a common trust store for the PKI certificates. RFC7672 even 
> talks about this in problem and come to the conclusion that reliance on 
> a common trust store is impractical. Others went the route of re-using 
> the OS root store, which basically reuses the web browsers Web-PKI for 
> the most part, but in hind sight probably should have followed the same 
> approach as RFC7672.
> See section 3.1.3 https://www.rfc-editor.org/rfc/rfc7672#section-3.1.3 
> and section 10 https://www.rfc-editor.org/rfc/rfc7672#section-10 already 
> explain a lot about why it isn't as easy as "standing up a PKI".

I'm sorry, I am losing track. Sounds like mutual TLS in SMTP was already not a 
thing *before* the policy change, except for one vendor, then? That would leave 
only XMPP as affected, correct? How many XMPP server implementations are there? 
I see eight on this page <https://xmpp.org/software/?platform=all-platforms>.

I think something that would help the conversation move forward would be 
getting details of affected software and protocols *as they are actually 
deployed*, and then of the alternatives they have, so the group can assess 
whether this or another is the most appropriate solution.

> The central idea behind my draft is basically that it is more feasible 
> to add allowing serverAuth certificates to be used by systems expecting 
> server-to-server connections even on the TLS-Client side before the 
> deadline hits, where as re-architecting all current usages to use DANE 
> and have every operator arround the world populate their DANE records 
> within DNS is not (esp because still not all TLDs have DNSSEC support, 
> and even for some that do have it (like e.g. ".de" or ".eu") domain 
> registrars like e.g. namecheap don't offer it citing that the TLD 
> supossidly wouldn't support it).
> 
> 
> 
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-ietf-tls-mlkem

[Filippo Valsorda]

2025-06-15 19:15 GMT+02:00 Scott Fluhrer (sfluhrer) 
:
> The normative portion of this draft (sections 4, 5) is pretty boring (in the 
> best possible way); it pretty much says "insert ML-KEM into TLS in the 
> obvious way, and use these code points".
> 
> On a minor note: when talking about failures (5.2), well, yes, decryption 
> failure (that is, both sides do the protocol honestly, both sides receive the 
> key shares correctly, but the two sides generate different secrets) is 
> possible; however the probability is so low that almost certainly no such 
> failure will ever occur anywhere in the world for this protocol.  A failure 
> is far more likely to be due to a transmission error, an implementation bug 
> or an active attack (each of which have, in my estimation, a probability 
> greater than 2^-138 of happening).

Indeed, I think it’s the responsibility of specification authors who understand 
the concept of cryptographically negligible probability to omit these virtual 
impossibilities from implementor-aimed documents.

A chance of 2^-138 is 1000x smaller than the chance of deriving the obviously 
insecure all-1s AES-128 key. It’s also likely to be smaller than the chance of 
a cosmic ray corrupting the flags register flipping the direction of an if 
check.

I disagree that “implementers should be aware” of this eventuality. They will 
at best do nothing (correctly) and at worst add useless complexity.

> On the other hand, if we look at the security considerations (section 6), it 
> looks misguided.  In my view, the security considerations of a draft or RFC 
> should give actionable advice on how to implement the protocol securely.  
> This does that only to a limited extent.
> 
> Section 6.1 mainly talks about the dangers of variable length secrets.  This 
> has nothing to do with ML-KEM, which has fixed length secrets.  In addition, 
> it cites Aviram et al which talks about the possible weaknesses when using a 
> hybrid construction with a non-collision resistant hash function - that 
> doesn't apply for several reasons.
> 
> Section 6.2 starts to talk about IND-CCA2 and Fujisaki-Okamoto transforms 
> (academic concepts that may mean little to an implementor) and DH (which has 
> nothing to do with this draft).  On the other hand, at the bottom of the 
> section, it does give some advice ("recommended not to reuse KEM public keys; 
> if you have to, abide by any a bound on the number of reuses that the KEM 
> mandates (ML-KEM has no such bound); MUST NOT reuse randomness in the 
> generation of KEM ciphertexts).
> 
> Section 6.3 talks about binding properties and admits that they don't apply 
> to TLS 1.3 (in which case, why bring it up?)
> 
> IMHO, this security considerations section should be replaced with only those 
> things relevant to the implementor and things he can address, such as:
> -  Public key reuse (the current draft permits it; I can see the argument 
> that it should be forbidden, especially given how cheap key generation is in 
> ML-KEM)
> -  MUST NOT reuse randomness in the generation of KEM ciphertexts - that text 
> from the draft is good
> -  Good randomness is essential
> -  Possibly some statements about side channels (although, without reuse, the 
> attacker gets only a single trace, and there are likely larger side channel 
> vulnerabilities available in a TLS implementation).
> 
> Also, why is RFC 9180 a normative reference?
> ___
> 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: ML-KEM recommended column

[Filippo Valsorda]

2025-06-07 19:49 GMT+02:00 Loganaden Velvindron :
> ML-KEM implementations may suffer from compiler optimizations that could 
> weaken
> the security properties of a pure ML-KEM implementation such as Kyberslash.

That is both a general risk independent of the algorithm, and in the specific 
case only applicable when reusing public keys. (Yet another discussion that 
could be avoided by forbidding key reuse!)___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

2025-07-15 15:32 GMT+02:00 Salz, Rich :
> If specification required means "get an RFC", why do we have it
> instead of standards action?
> There are some folks who take that sentence in the I-D boilerplate with as 
> much importance as other content in a draft. There are some who don’t. 
> Sometimes there’s an external document. In this case, maybe pointing to the 
> FIPS document suffices; I don’t know.

"Should an I-D-assigned codepoint be enough for folks or is the boilerplate too 
scary" is an interesting conversation to have, but I don't see how it is 
relevant to the adoption of this document, where the alternative is indeed to 
email i...@iana.org requesting TLS SignatureScheme codepoints with Recommended 
= N, Reference = FIPS 205, and Comment = For TLS 1.3 or later (per 
draft-ietf-tls-tls12-frozen).___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

2025-07-15 17:47 GMT+02:00 Salz, Rich :
> "Should an I-D-assigned codepoint be enough for folks or is the boilerplate 
> too scary" is an interesting conversation to have, but I don't see how it is 
> relevant to the adoption of this document, where the alternative is indeed to 
> email i...@iana.org requesting TLS SignatureScheme codepoints with 
> Recommended = N, Reference = FIPS 205, and Comment = For TLS 1.3 or later 
> (per draft-ietf-tls-tls12-frozen).
>  
> The authors have decades of experience in the IETF and want the TLS WG to 
> work on this doc. How is that not relevant? Is it going to get the full and 
> focused attention of most of the WG members?  Nope; this isn’t TLS 1.3. So 
> why not?

I am not saying this document is not relevant to the WG, and I am certainly not 
trying to impugn the authors' stature.

I am saying the scary "It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as ‘work in progress.’" sentence in the I-D 
boilerplate is not relevant to *this* conversation, because I see two options, 
neither of which ultimately involves referencing an I-D:
 1. adopt this document and publish an RFC;
 2. request TLS SignatureScheme codepoints with Reference = FIPS 205.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Filippo Valsorda]

I did not support adoption then and I do not support it now. My issue with the 
document was not that it overstated applicability, but its limited 
applicability itself, which is not addressed by acknowledging it.

I don’t see the need to develop an RFC to assign Recommended = N codepoints in 
a Specification Required registry for an algorithm of marginal utility that 
already has a specification. Just register the codepoints with reference to the 
FIPS.

If the answer is “but it will be less widely implemented without an RFC” then 
1) some projects are applying sub-optimal criteria to choose what to implement, 
and 2) that sounds like a good thing for an algorithm with limited 
applicability: only those that really know they need it will implement it.

2025-07-15 00:05 GMT+02:00 Sean Turner :
> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We 
> called consensus [1], and that decision was appealed. We have reviewed the 
> messages and agree that we need to redo the adoption call to get more input.
> 
> What appears to be the most common concern, which we will take from Panos' 
> email, is that "SLH-DSA sigs are too large and slow for general use in TLS 
> 1.3 applications". One way to address this concern is to add an applicablity 
> statement to address this point. We would like to propose that this (or 
> something close to this) be added to the I-D:
> 
> Applications that use SLH-DSA need to be aware that the signatures sizes are 
> large; the signature sizes for the cipher suites specified herein range from 
> 7,856 to 49,856 bytes. Likewise, the cipher suites are considered slow. While 
> these costs might be amoritized over the cost of a long lived connection, the 
> cipher suites specified herein are not considered for general use in TLS 1.3.
> 
> With this addition in mind, we would like to start another WG adoption call 
> for draft-reddy-tls-slhdsa. If you support adoption with the above text (or 
> something similar) and are willing to review and contribute text, please send 
> a message to the list. If you do not support adoption of this draft with the 
> above text (or something similar), please send a message to the list and 
> indicate why. This call will close at 2359 UTC on 28 July 2025.
> 
> Cheers,
> Deirdre, Joe, and Sean
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
> [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
> ___
> 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