Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Bas Westerbaan]

>
> I'm not sure I would agree that a 3-8 MB handshake to preserve the status
> quo is exactly low hanging fruit.
>

If we use Dilithium2 for every signature, we're looking at about 17kB extra
— not 3-8MB. ICA suppression removes one public key and signature, so 3.7kB.

This is where looking to see what can be done to remove the necessity of
> those SCTs and OCSPs, rather than trying to patch them into a PQ world.
>

If Rainbow or GeMMS doesn't make the cut, then replacing SCTs by inclusion
proofs (to some daily picked side-loaded STHs) could be interesting (as
they're ~1kB each), but that's not low hanging fruit.


> The viability of CT itself becomes more suspect in a world of ginormous
> signatures,
>

Dilithium2 and Falcon signatures+public keys are 2.4+1.3kB and 666+897B
respectively. That won't cause trouble for CT.

Best,

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

Re: [TLS] PQC key exchange sizes

[Bas Westerbaan]

On the QUIC side, there is the "*Q*uantum Ready" interop test:


https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370



On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos  wrote:

> Gotcha. This is a reasonable explanation for a potential problem, but I
> would also like to see experimental proof that DTLS implementation X, Y, Z
> have the problem. TLS implementations don't deal with big ClientHellos
> today so we could assume they would have a problem, but when tested they do
> OK for the most part.
>
>
> -Original Message-
> From: TLS  On Behalf Of Ilari Liusvaara
> Sent: Wednesday, July 27, 2022 10:42 AM
> To:  
> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> > Hi Ilari,
> >
> > > - DTLS-level fragmentation. There are buggy implementations that
> > >   break if one tries this.
> >
> > DTLS servers have been fragmenting and sending cert chains that don’t
> > fit in the MTU for a long time. Is this buggy on the TLS client side?
>
> These problems are specific to fragmenting Client Hello. Handling
> fragmented DTLS Client Hello is different from handling fragmented DTLS
> Certificate (and even more so in DTLS 1.3). I think DTLS specification just
> pretends both cases are the same. They are not.
>
>
> QUIC implementations could have similar issues with multiple initial
> packets, but operating QUIC with fast failure-independent fallback would
> make failures soft.
>
>
> There is the general principle that if some protocol feature is not used
> in the wild, it tends to break, even if required part of the protocol.
> Either by implementation being poorly tested and buggy, assuming the
> feature does not exist, or being missing entierely.
> Combine this with interop failures having outsize impact and old versions
> sticking around far longer than desriable. And I do not think fragmented
> Client Hellos in DTLS or multiple initials in QUIC are seen much.
>
>
> One trick with DTLS would be sending client hello with no key shares.
> Causes extra round-trip, but any server that selects PQC causing
> fragmentation would presumably be capable of handling that.
>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Bas Westerbaan]

>
> That is not the only model of quantum computing. If it was, I would be
> saying this entire effort is a silly waste of time because the approach is
> fundamentally unscalable. They can throw lots of gates onto a chip but the
> entanglement collapses before they can be used.
>

The whole point of quantum error correction is that it preserves
entanglement. (QEC in practice is not a panacea, for instance, transmons
can escape in higher harmonics which are not corrected for.) For the claim,
"fundamentally unscalable" however you should bring some evidence.

Best,

 Bas


PS, for those that want to get into the topic, I recommend Nielsen &
Chuang.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Why both X25519+Kyber512 and P256+Kyber512?

Note that Anything+Kyber512, in particular X25519+Kyber512, will be FIPS
certifiable after NIST standardized Kyber512.*

Best,

 Bas

—
* With the tiny caveat that apparently the order of the shares does matter
atm. [insert facepalm.]



> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768
>
> I don't see the point of including finite field groups.  I would hope to
> hold off on national curves, such as Brainpool and the GOST curves
> (although they're likely to be forced on us anyways).  I personally see
> Kyber1024 as overkill (of course, if you disagree, please say so).
>
> Of course, it's possible that NIST will tweak the definition of Kyber;
> that's just a possibility we'll need to live with (and wouldn't change what
> hybrid combinations we would initially define)
> ___
> 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] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.


I also prefer fewer choices initially.

The only reason we're testing both X25519+Kyber512 and X25519+Kyber768 is
that there is a possibility that Kyber768 becomes the default [1] and
because of its size, X25519+Kyber768 causes fragmentation in some cases
where X25519+Kyber512 doesn't.

* (2) to be able to declare security of generated keys in FIPS-mode for
>   _both_ - classical and post-quantum schemes (once Kyber is
> standardized).—


Why is this required? NIST writes

Current NIST standards, which were not necessarily designed to provide
post-quantum security, can accommodate several hybrid key establishment
constructions in “FIPS mode,” as defined in FIPS 140. For example, assume
that the value Z is a shared secret that was generated within a
NIST-approved cryptographic scheme, and that a value T is generated or
distributed through other scheme(s), which could be the output of a key
encapsulation method (KEM). The following are the different ways to
incorporate the value T in the key derivation procedure to achieve a hybrid
mode which is permitted by current standards: [...]

Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?

Best,

 Bas

[1] Not expressing an opinion on whether that's good or not.
[2] https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs




On Thu, Aug 18, 2022 at 1:05 AM Martin Thomson  wrote:

> On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> > Well, if we were to discuss some suggested hybrids (and we now know the
> > NIST selection), I would suggest these possibilities:
> >
> > - X25519 + Kyber512
> > - P256 + Kyber512
> > - X448 + Kyber768
> > - P384 + Kyber768
>
> Any specific pairs of primitives should be specified in a different
> document to this one.
>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.  Partly because I think that
> there might be better options available to us than compression, partly
> because compression will be annoying to implement correctly, and partly
> because we're still in the phase where this is being trialed.
>
> ___
> 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] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

For TLS on the Web it would be ideal if we can find a single[1] hybrid
which we can all be happy with because that will make keyshare negotiation
easier.

To wit, BoringSSL, when SSL_OP_CIPHER_SERVER_PREFERENCE is set, will pick
the group based on the supported_groups that the client sends.

Thus, in this case if the server prefers X25519 over P-256, and a client
sends a P-256 keyshare but also advertises support for X25519, the server
will send an HRR to get an X25519 agreement.

In practice this is not a problem, because X25519 has become the de facto
standard. Before that was the case, many clients sent both a P-256 and
X25519 keyshare.

The PQ hybrid situation is more painful. Suppose we end up with two
essentially equivalent hybrids, say P-256+Kyber768 and X25519+Kyber768, and
different servers have a different preference. Then clients are forced to
either send both keyshares or suffer an HRR.

Of course, we can change the server logic, but it isn't simple.

An OpenSSL server, for instance, with SSL_OP_CIPHER_SERVER_PREFERENCE set,
will accept a keyshare it supports even if the client announces support for
another group that the server prefers.

This has a disadvantage[2]: if a client sends a X25519 keyshare but
announces support for a PQ keyshare, we would want the server to HRR to
establish a PQ connection (as BoringSSL will do if the PQ groups are
preferred.)

Best,

 Bas

[1] That shouldn't prevent us from assigning code points for many hybrids.
[2] Thanks to David Benjamin for pointing that out to me.


On Tue, Aug 23, 2022 at 10:30 AM Kris Kwiatkowski 
wrote:

>
> On 23/08/2022 01:39, Martin Thomson wrote:
>
> On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
>
> As X25519 is not FIPS-approved, the lab won't be able to test it,
>
> OK, hypothetical question, but maybe an important one.
>
> Why would a certification lab care?  We compose secrets with non-secrets all 
> the time, so even if X25519 were replaced with a public value, as long as 
> Kyber is approved, can they not proceed to certify on the basis of the 
> strength of the Kyber algorithm and its implementation?
>
> FIPS lab won't care, as I've mentioned Kyber+x25519 can be certified when 
> Kyber is FIPS-approved. The customers may
> care. As FIPS developer, I would like to be able to provide hybrid 
> construction in which both algorithms are FIPS
> approved, so that in case Kyber gets broken, the key exchange is still is 
> safe (as per FIPS standards), rather then
> Kyber gets broken and now you are not FIPS compliant.
> Makes sense?
>
> Or, more realistically, maybe the composition method can be approved, just as 
> composing a secret with "chickenchickenchicken" can be rendered safe.  That 
> way, composing with an arbitrary primitive might be considered safe if the 
> composition method is approved.
>
> Composition method is an approved technique, see SP800-56Cr2 (point 2).
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Bas Westerbaan]

On Tue, Oct 25, 2022 at 6:30 AM Rob Sayre  wrote:

> I don't think anyone actually uses it,
>

1% of Cloudflare's TLS 1.3 handshakes today used an HRR.

I hope a de facto PQ kex will emerge — the old strategy of just sending
multiple keyshares is more expensive with large PQ public keys (~1kB). We
probably will need to complicate how the server picks the keyshare [1]

By the way, forcing an HRR by not sending any keyshares might be a useful
workaround if it turns out large initial ClientHello's are problematic for,
say, QUIC load balancers.

For those reasons I think it's a bit early to consider retiring HRR.

Best,

 Bas


[1] https://mailarchive.ietf.org/arch/msg/tls/pmJMSyf1-PGlLwcgF_jtEYKxQ-g/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Bas Westerbaan]

>
> OK, that's more than I expected, although I kind of wonder what
> combinations are doing this.
>

It varies a bit over time, but today most were caused by a certain client
sending a P-384 keyshare while also announcing support for P-256.

 On the other hand, most clients today send x25519 key share
> by default, which seems to be the weakest supported group in TLS 1.3.


I'd say that title goes to ffdhe2048.

Best,

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> In essence, I'm proposing that user agents should trust a fully DNSSEC
> domain with a TLS certificate set up using DANE, along with changes to CT
> log submission process to allow self-signed certificates (looking to
> suggest via rfc9162).
>

How do you propose we prevent CT from being DoSed by a deluge of
self-signed certificates?

Best,

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> On the other hand, the actual certificates are not what one
> would want to log anyway.  Instead one would only want to log DS RRsets
> or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> 2LD, 3LD, ...  suffixes operated by TLD registries).


This is the case if you run your own authoritative DNS server. Most do not.
So you'd want transparency on the TLSA records as well.

Similar spamming would be possible by
> obtaining certificates from many CAs and rolling them over as frequently
> as possible.
>

CAs have quite strict rate-limits in place for free certificate issuance,
so it's not a problem.

Best,

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

I don't see how your proposal prevents spam. With your proposal as is,
nothing stops me from adding trillions of self-signed certificates to the
CT logs.

Best,

 Bas

On Wed, Nov 30, 2022 at 8:55 PM Ollie 
wrote:

> Hi Bas,
>
> Good question - my suggestion is for CT logs to check for the DANE records
> as explained in this git repo:
> https://github.com/OllieJC/justselfsigned.org
> Here's a copy:
>
> Unfortunately, existing CT logs do not support SSCs (self-signed
> certificates) due to spam concerns (rfc6962). The suggestion (being raised
> in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA
> records when generating a CT log entry for SSCs, which would work in the
> following way:
>
> 1. a new SSPC (Self-Signed Pre-Certificate) is generated with the
> following:
> - only valid domains
> - less than 90-day expiry (although this may start in the future)
> 2. the SSPC signature is added to tlsa._dane TLSA record for every domain
> 3. SSPC is submitted to a CT log
> 4. CT log checks for valid domains and associated TLSA signatures and
> issues an SCT (Signed Certificate Timestamp)
> 5. SSC (Self-Signed Certificates) is generated from the SSPC to include
> the SCT
> 6. SSC signature is added to TLSA records (likely replacing the
> pre-certificate signature)
> 7. SSC is submitted to the CT log
> 8. CT log checks for valid domains, associated TLSA records and a valid SCT
>
> Thanks,
> Ollie
>
>
>  Original Message 
> On 29 Nov 2022, 00:04, Bas Westerbaan < bas=
> 40cloudflare@dmarc.ietf.org> wrote:
>
>
> In essence, I'm proposing that user agents should trust a fully DNSSEC
>> domain with a TLS certificate set up using DANE, along with changes to CT
>> log submission process to allow self-signed certificates (looking to
>> suggest via rfc9162).
>>
>
> How do you propose we prevent CT from being DoSed by a deluge of
> self-signed certificates?
>
> Best,
>
>  Bas
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> I don't see this as different to the current spam potential with CT logs
> right now - anyone could distribute out the creation of a bunch certificate
> requests with the likes of Let's Encrypt and submit a bunch of certificate
> chains to CT logs.


Let's Encrypt (and other free CAs) have tight rate limits [1], which would
be unreasonably tight for all applications. There is an escape hatch: if
the rate limit is a problem, you can just buy a certificate with some other
CA.

Best,

 Bas


[1] https://letsencrypt.org/docs/rate-limits/

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Bas Westerbaan]

>
> And of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
>

More to the point, I'd say the post-quantum transition is the natural
moment to move from ≤1.2 to 1.3.

(TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades during
the transition because of CurveSwap like attacks.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Merkle Tree Certificates

[Bas Westerbaan]

>
> Unpopular pages are much more likely to deploy a solution that doesn't
> require
> a parallel CA infrastructure and a cryptographer on staff.
>

CAs, TLS libraries, certbot, and browsers would need to make changes, but I
think we can deploy this without webservers or relying parties having to
make any changes if they're already using an ACME client except upgrading
their dependencies, which they would need to do anyway to get plain X.509
PQ certs.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

>
> The draft draft-tls-westerbaan-xyber768d00-00 references
> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
> since fixed in editor's copy.
>
> And then, the correct reference for X25519 is probably RFC7748 instead
> of RFC8037...
>
>
> Really quick and dirty way to fix this would be to publish editor's
> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
> the references.
>

Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Best,

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Regarding additional key agreements.

For the (public) web it would be best if we can agree on a default key
agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768,
then clients will either HRR half the time or need to send both. Neither
are ideal.

Obviously this point is moot for internal networks. So I do not
oppose specifying additional preliminary key agreements, but I do not like
to actively support it. What about specifying further preliminary key
agreements in yet again a separate draft?

Best,

 Bas

On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan  wrote:

> The draft draft-tls-westerbaan-xyber768d00-00 references
>> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
>> since fixed in editor's copy.
>>
>> And then, the correct reference for X25519 is probably RFC7748 instead
>> of RFC8037...
>>
>>
>> Really quick and dirty way to fix this would be to publish editor's
>> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
>> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
>> the references.
>>
>
> Thanks, done. Posted -02 of both the Kyber and Xyber drafts.
>
> Best,
>
>  Bas
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

FYI IANA has added the following entry to the TLS Supported Groups registry:

Value: 25497
Description: X25519Kyber768Draft00
DTLS-OK: Y
Recommended: N
Reference: [draft-tls-westerbaan-xyber768d00-02]
Comment: Pre-standards version of Kyber768

Please see
https://www.iana.org/assignments/tls-parameters

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
wrote:

> It looks like we have consensus for this strategy. We’ll work to remove
> codepoints from draft-ietf-tls-hybrid-design and then get experimental
> codepoints allocated based on draft-tls-westerbaan-xyber768d00.
>
> Best,
> Chris, for the chairs
>
> > On Mar 28, 2023, at 9:49 PM, Christopher Wood 
> wrote:
> >
> > As discussed during yesterday's meeting, we would like to assess
> consensus for moving draft-ietf-tls-hybrid-design forward with the
> following strategy for allocating codepoints we can use in deployments.
> >
> > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> > 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
> >
> > The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
> >
> > Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
> >
> > Best,
> > Chris, Joe, and Sean
> >
> > [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
>
> ___
> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Hi Panos,

No, for the final version of Kyber we'd need a different code point. (And
that one will presumably be defined in Douglas' hybrid I-D.)

The raison d'être of draft-schwabe-cfrg-kyber-02 and
draft-westerbaan-tls-xyber768d00 is to have a stable reference for this
preliminary version of Kyber.

Best,

 Bas

On Thu, May 11, 2023 at 4:17 PM Kampanakis, Panos  wrote:

> Great!
>
> So to clarify, when Kyber gets ratified as MLWE_KEM or something like
> that, will we still be using 0x6399 in the keyshare when we are
> negotiating? Or is  0x6399 just a temporary codepoint for Kyber768 Round 3
> combined with X25519?
>
>
>
>
>
> *From:* TLS  *On Behalf Of * Bas Westerbaan
> *Sent:* Wednesday, May 10, 2023 3:09 PM
> *To:* Christopher Wood 
> *Cc:* tls@ietf.org
> *Subject:* RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for
> draft-ietf-tls-hybrid-design
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> FYI IANA has added the following entry to the TLS Supported Groups
> registry:
>
>
> Value: 25497
> Description: X25519Kyber768Draft00
> DTLS-OK: Y
> Recommended: N
> Reference: [draft-tls-westerbaan-xyber768d00-02]
> Comment: Pre-standards version of Kyber768
>
> Please see
> https://www.iana.org/assignments/tls-parameters
>
>
>
> On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
> wrote:
>
> It looks like we have consensus for this strategy. We’ll work to remove
> codepoints from draft-ietf-tls-hybrid-design and then get experimental
> codepoints allocated based on draft-tls-westerbaan-xyber768d00.
>
> Best,
> Chris, for the chairs
>
> > On Mar 28, 2023, at 9:49 PM, Christopher Wood 
> wrote:
> >
> > As discussed during yesterday's meeting, we would like to assess
> consensus for moving draft-ietf-tls-hybrid-design forward with the
> following strategy for allocating codepoints we can use in deployments.
> >
> > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> > 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
> >
> > The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
> >
> > Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
> >
> > Best,
> > Chris, Joe, and Sean
> >
> > [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
>
> ___
> 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] Merkle Tree Certificates

[Bas Westerbaan]

> > Thanks! That’s indeed inconsistent, we’ll fix it.
> > https://github.com/davidben/merkle-tree-certs/issues/32
>
> Hmm... Looking at that construct, why is the pad there?


We pad to the hash block size. When computing the full Merkle tree, or
verifying an authentication path, the values before the pad are the same,
and thus we can precompute the hash state after digesting those fixed
values.

(With the current inputs and sha256, it will only make a difference for
HashAssertion though.)


> And there does not seem to be any way to salt the hash. WebPKI requires
> what effectively amounts to salting the hash via serial number (even
> for SHA-256).
>

Please elaborate.

Best,

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

Re: [TLS] Merkle Tree Certificates

[Bas Westerbaan]

>
> I mean, is there a cryptographic reason for it?


No.


> (However, absent cryptographic reasons, this all is way premature.)
>

Indeed. We like to have a concrete proposal, but thinking through these
details is premature at this point.

[snip] What that in effect does
> is to make it much more difficult to exploit chosen-prefix collisions in
> hash function.



However, that requirement holds irrespective of the hash function used,

and it has in fact been held for SHA-256 (regardless of there not being
> any known even remotely feasible attacks) instead of just being a dead
> letter from the past with much worse hash functions.
>

Ah, it would indeed be neat if we could design this, so that we do not
require (chosen prefix) collision resistance of the hash. I'd say it's nice
to have, but not a must. Tracking in
https://github.com/davidben/merkle-tree-certs/issues/45

Best,

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

Re: [TLS] CRYSTALS Kyber and TLS

[Bas Westerbaan]

Hi Stephan,

>From your e-mail it's unclear which attack you worry about, but in the
attached document, you describe the problem unique to the implementation of
Kyber in TLS as:

If the random number generated
> for the encryption operation is weak, an attacker may sniff the pk sent
> over the wire and “guess” the random number to obtain the shared secret ss.


This is not unique to Kyber. If an attacker can successfully guess server
randomness, then they can guess the private key of the server's ephemeral
ECDH keypair (checking against the server keyshare), and compute the shared
secret as well.

Adding an extra ephemeral server KEM keypair to which the client
encapsulates doesn't change the situation: the attacker you describe can
still guess the KEM private key, and then decrypt the extra shared secret.

Best,

 Bas

On Mon, Jun 19, 2023 at 10:24 AM Stephan Müller  wrote:

> Hi,
>
> Post-quantum computing cryptographic algorithms are designed and available
> for
> use. Considering that the Kyber algorithm is going to be mandated by US
> authorities in the future as a complete replacement for asymmetric key
> exchange and agreement, a proposal integrating Kyber into TLS is specified
> with [1].
>
> This proposal, however, has one central shortcoming: only the TLS server
> contributes to the security strength of the shared secret generated by
> Kyber.
> This shortcoming can be solved with a slightly improved approach where the
> client and the server both independent of each other contribute to the
> security of the communication channel where the channel even retains its
> security when one side has insufficient entropy.
>
> The entire analysis and the suggested proposal to address the outlined
> issue
> is provided with [2]. I would like to share this proposal to contribute to
> the
> discussion how Kyber can be applied to TLS.
>
> [1] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-06.txt
>
> [2] http://www.chronox.de/papers/TLS_and_Kyber_analysis.pdf
>
> Ciao
> Stephan
>
>
> ___
> 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] CRYSTALS Kyber and TLS

[Bas Westerbaan]

I do have to add to Thom's remarks that KEMTLS (a.k.a. AuthKEM) offers an
advantage here. If the private key of the leaf cert is not compromised (for
instance when it was generated elsewhere), then the attacker Stephan
describes cannot learn the shared secret.


On Mon, Jun 19, 2023 at 5:02 PM Thom Wiggers  wrote:

> Hi all,
>
> The attack that is described by Stephan is something that we considered
> while we were initially designing KEMTLS (in the papers, we also covered
> the ephemeral key exchange). I'll quickly write what we were thinking of
> and why we did not choose to do anything similar to what Stephan proposes.
>
> I will be correcting for the misunderstanding in the document put forward
> by Stephan, which suggests that Kyber is an asymmetric encryption scheme.
> Encapsulation and Decapsulation should not be confused with encryption and
> decryption, which are not part of the public API of Kyber and will not be
> part of the NIST standard as far as I'm aware.
>
> I believe we can summarize the argument as follows: in the straightforward
> replacement of ECDH by a KEM, the client generates a keypair and the server
> (through the encapsulate operation) computes a shared secret and a
> ciphertext. If either the secret key or the shared secret are made public,
> for example, due to an implementation flaw of either keygen or
> encapsulation, then the ephemeral handshake key is no longer secret.
>
> Bas correctly points out that this is not different from ECDH, where
> compromise of one of the two exponents leads to shared secret computation,
> but that in itself shouldn't necessarily be a reason not to investigate if
> we can do better.
>
> But, in my view, the proposed defense and the argument put forward assumes
> that the flaw that affects encapsulation does not affect the key generation
> (or vice versa); in particular, in the scenario of the broken server-side
> random number generator it seems far-fetched that the busted random number
> generator or implementation flaw affecting encapsulation won't *also*
> affect the keygen (or in other scenarios such as side-channel
> vulnerabilities, decapsulate) operation of the server. This, in my view,
> makes the additional security offered by the additional key exchange very
> marginal.
>
> The reason why we were investigating this issue was a bit different:
> having two KEM key exchanges gives the server more control to ensure that
> there will be at least one freshly-generated KEM keypair in the mix. This
> could improve the forward secrecy for handshakes (modeled via secret key
> exposure) in which the client just re-uses the ephemeral keypair every
> single time. But we also saw this as not significant enough to suffer the
> additional, significant transmission requirement of another full Kyber key
> exchange. Hopefully, we now have enough experience with evaluating
> implementations of TLS to find and fix these sorts of key-reuse flaws more
> easily, earlier, and in automated ways [1]. And again, this is the same
> situation with ECDH today.
>
> Cheers,
>
> Thom Wiggers
> PQShield
>
> [1] see e.g. https://github.com/tls-attacker/TLS-Scanner. Relying on
> implementers not to make mistakes is a dangerous game, but I do believe
> that it needs to factor into the cost/benefit analysis.
>
> PS: for marketing reasons I oppose comparisons between the post-quantum
> KEM schemes (which are primitives that easily can be used in fully
> ephemeral ways) and RSA key wrapping (which pretty much exclusively refers
> to the much-derided non-forward-secure RSA transport in TLS-old). ;-)
>
> Op ma 19 jun 2023 om 16:01 schreef Stephan Mueller :
>
>> Am Montag, 19. Juni 2023, 15:56:57 CEST schrieb Scott Fluhrer (sfluhrer):
>>
>> Hi Scott,
>>
>> > I do not believe that Müller is correct - we do not intend use the
>> Kyber CPA
>> > public key encryption interface, but instead the Kyber CCA KEM
>> interface.
>> > And, with that interface, the server does contribute to the shared
>> secret:
>> >
>> > The shared secret that Kyber KEM (round 3) generates on success is:
>> >
>> > KDF( G( m || H(pk)) || H(c) )
>> >
>> > where:
>> >   - m is the hash of a value that the server selects
>> >   - pk is the public key selected by the client
>> >   - c is the server's keyshare
>> >   - H is SHA3-256, G is SHA3-512, KDF - SHAKE-256
>> > Note that this formula includes a value (pk) that is selected solely by
>> the
>> > client; hence we cannot say that this value contains only values
>> selected
>> > by the server. (reference: algorithms 8, 9 of the round 3 Kyber
>> submission)
>>
>> My concern is that the security strength cannot depend on the pk, because
>> the
>> PK is sent in clear over the wire. Thus it cannot contain entropy. Thus,
>> entropy only comes from the message m in your listing which is a random
>> number
>> that is generated by the server. Further, c depends on m and thus does
>> not add
>> any entropy either.
>>
>> Ciao
>> Stephan
>>
>>
>> _

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Bas Westerbaan]

Thanks for preparing the excerpt; this will be helpful for many use cases.
(For the WebPKI, as you already mention, we also need to consider SCTs and
realistically crappy networks.)

 "this is LTE in a city", and "this is what a poor-quality rural 3G link
> looks like". But alas, these don't seem to exist either.
>

Unfortunately, it will not be as simple as plugging in a single packet loss
number and then dropping that fraction of packets. Because TCP interpets
packet loss as congestion, it grinds down to a halt much earlier than at a
loss of 2%. Instead, lossy links such as WiFi and cellular have their own
retransmission protocols hidden from TCP.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Bas Westerbaan]

>
> On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek  40digicert@dmarc.ietf.org> wrote:
>
>> SCTs have always seemed surprisingly large to me, and it has always seemed
>> like there should be a more compact representation that has the same
>> security
>> properties, but I've never found the time to look more closely at it.  If
>> someone
>> does have the time, figuring out how to reduce the size of SCTs would be
>> quite
>> helpful.
>>
>
> I've always said SQI-Sign for this.
>

The 40ms verification time per SCT makes it a non-starter.

Best,

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

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

[Bas Westerbaan]

I support adoption and am willing to review.

On Tue, 1 Aug 2023 at 21:36, Christopher Wood  wrote:

> Hi all,
>
> Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates"
> (draft-jackson-tls-cert-abridge).
>
> The datatracker page for this document can be found here:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>
> And the GitHub repository can be found here:
> https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
>
> Please indicate whether or not your support adoption of this document in
> its current state. Procedure questions raised during the WG meeting last
> week can be ironed out in the event of this item being adopted.
>
> This call for adoption will conclude on August 16.
>
> Thanks,
> Chris, for the chairs
> ___
> 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] Abridged Certificate Compression

[Bas Westerbaan]

>
> If you are going to do this, you might as well go the whole hog and
> provide a mechanism that allows the client to say if it already has a cert
> on file for that particular host, e.g. by means of a digest.
>

If clients cache intermediates as they go, then reporting that list to a
server is an obvious privacy issue. When you restrict to a fixed set,
updated in unison, we essentially return to reach Dennis' proposal.

Best,

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

This is a useful and very timely draft — I would like to see it adopted.

I'll argue it's more urgent than sketched by David.

We have been investigating turning on post-quantum key agreement for
connections from Cloudflare to origin servers. In testing, we found that
0.34% of origins will fail to establish a connection if we send
X25519Kyber768Draft00 keyshare directly (while still advertising support
for classical keyshares.)  As expected, a significant portion of failures
seem to be caused by the large ClientHello. Interestingly though, the
majority of these failures don't seem to be specific to the size of the
ClientHello, but are rather caused by the origin not supporting
HelloRetryRequest correctly. We're still digging into it, and will share
our findings later on.

Anyway, even though it's a small fraction of origins, we cannot send a PQ
keyshare immediately and completely break the websites in front of those
few origins. Instead, we are going [1] for the following approach: we send
a X25519 keyshare, but advertise support for Xyber. A server that supports
Xyber can then use HelloRetryRequest for a post-quantum connection.
Undoubtedly due to GREASE (thanks David), we did not see any issues with
this approach. [2]

This comes at the cost of an extra roundtrip. To get rid of it, we're
scanning key agreement support of origins, and in the future will send
Xyber immediately if we see the origin supports it without failing.

Now we come to the usefulness of this draft: without it we cannot guarantee
that we will negotiate PQ even if both the client and server are configured
to prefer it. The problem is that many TLS servers are content with a
supported keyshare, and will not HRR even if a more preferred key agreement
is available. Indeed: a MitM can break our PQ test connections, which will
make us send X25519, while advertising support for Xyber. Despite
advertising support for Xyber, many TLS servers will now be content with
X25519.

Best,

 Bas

[1] https://blog.cloudflare.com/post-quantum-to-origins/
[2] Of course, when a server that can't handle large ClientHello or HRR
adds Xyber, it will still need to fix those issues, but importantly they
don't block the rest anymore.

PS. We have also included some stats on classical key agreement support and
preference of origins in [1].




On Tue, Sep 26, 2023 at 6:46 PM David Benjamin 
wrote:

> Hi all,
>
> A while back, we discussed using a DNS hint to predict key shares and
> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In
> thinking through post-quantum KEMs and the various transitions we'll have
> in the future, I realized we actually need to address those downgrade
> issues now. I've published a draft below which is my attempt at resolving
> this.
>
> We don't need a DNS hint for the *current* PQ transition—most TLS
> ecosystems should stick to the one preferred option, and then clients can
> predict that one and move on. However, I think we need to lay the
> groundwork for it now. If today's round of PQ supported groups cannot be
> marked "prediction-safe" (see document for what I mean by that),
> transitioning to the *next* PQ KEM (e.g. if someone someday comes up with
> a smaller one that we're still confident in!) will be extremely difficult
> without introducing downgrades.
>
> Thoughts?
>
> David
>
> -- Forwarded message -
> From: 
> Date: Mon, Sep 25, 2023 at 6:56 PM
> Subject: New Version Notification for
> draft-davidben-tls-key-share-prediction-00.txt
> To: David Benjamin 
>
>
> A new version of Internet-Draft
> draft-davidben-tls-key-share-prediction-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-key-share-prediction
> Revision: 00
> Title:TLS Key Share Prediction
> Date: 2023-09-25
> Group:Individual Submission
> Pages:11
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction
>
>
> Abstract:
>
>This document clarifies an ambiguity in the TLS 1.3 key share
>selection, to avoid a downgrade when server assumptions do not match
>client behavior.  It additionally defines a mechanism for servers to
>communicate key share preferences in DNS.  Clients may use this
>information to reduce TLS handshake round-trips.
>
>
>
> The IETF Secretariat
>
>
> ___
> 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] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

> If the client is happy with either X25519 alone or X25519Kyber768, why not
> send shares for both in the first ClientHello?
>

This is what Chrome does, and what we do if the user opts for "preferred"
mode. [1]

Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a
> blessed implementation choice, or conversely disrecommends it and explains
> why.
>

Ah, you mean using the same X25519 key in both the X25519 and Xyber
keyshare? We do not use that optimisation, but I do not see anything wrong
with it from a protocol perspective. I would not want to encourage it, as
it complicates code to generate keyshares as it crosses abstraction layers.

Best,

 Bas

[1] The issue is, as I described in my previous e-mail, that a small
fraction of origins breaks on a large ClientHello. Whether we send X25519
along with X25519Kyber768 in the CH doesn't make a difference. It does
prevent issues with origins that have broken HRR, and do not support Kyber.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

>
> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
> just let them break in case (a), and then maybe try again with (b), that
> opens up a downgrade attack. Intermediaries can observe the size of the
> Client Hello and make it break
>

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

> But if we can at least make it secure, that gives us a bit more breathing
> room in case anyone needs it.
>

For those who missed it: we need it for Edge -> Origin connections, as some
origins do break on split ClientHello. (See e-mail sept 29th.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

Thanks for bringing this up. There are a bunch of (implicit) questions in
your e-mail.

1. Do we want rfc describing the final NIST standards? And for which? I'm
ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

2. For which algorithms do we want to assign codepoints once the NIST
standards are out? Codepoints are cheap and use cases/rules are different,
but especially with the hybrids, I'd encourage us to try to be disciplined
and keep the list as short as we can for now, so that early adopters for
which it doesn't matter, all choose the same thing. The DNS mechanism
of draft-davidben-tls-key-share-prediction helps on the performance side,
but it doesn't solve the duplicate engineering/validation if there are a
dozen essentially equivalent KEMs.

3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them
yet, but others might.

4. Do we need hybrid signatures for the TLS handshake? I don't see the use,
but could be convinced otherwise.

5. What is the future of AuthKEM? That's definitely a different e-mail
thread.

Concretely, after ML-KEM is finished, I was planning to update
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

Best,

 Bas


On Mon, Nov 6, 2023 at 10:10 AM John Mattsson  wrote:

> Hi,
>
>
> NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final
> standards are expected in Q1 2024.
>
>
> https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
>
>
>
> I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM
> and ML-DSA (all security levels standardized by NIST) as soon as possible
> after the final NIST standards are ready. 3GPP is relying almost
> exclusively on IETF RFCs for uses of public key cryptography (the exception
> is ECIES for IMSI encryption but that will likely use HPKE with ML-KEM in
> the future).
>
>
>
> Looking at the TLS document list, it seems severely lacking when it comes
> to ML-KEM, ML-DSA…
>
>
>
> The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with
> the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> AuthKEM is a quite big change to TLS
>
> https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/
>
>
>
> This is not adopted, informal, and dealing with the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
>
>
>
> What is the TLS WG plan for quantum-resistant algorithms? My current view
> is that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44,
> ML-DSA-65, and ML-DSA-87 registered asap. For hybrid key exchange I think
> X25519 and X448 are the only options that make sense. For hybrid signing,
> ECDSA, EdDSA, and RSA could all make sense.
>
>
>
> Cheers,
> John
>
>
>
> *From: *TLS  on behalf of internet-dra...@ietf.org <
> internet-dra...@ietf.org>
> *Date: *Friday, 8 September 2023 at 02:48
> *To: *i-d-annou...@ietf.org 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
>
> Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is
> a
> work item of the Transport Layer Security (TLS) WG of the IETF.
>
>Title:   Hybrid key exchange in TLS 1.3
>Authors: Douglas Stebila
> Scott Fluhrer
> Shay Gueron
>Name:draft-ietf-tls-hybrid-design-09.txt
>Pages:   23
>Dates:   2023-09-07
>
> Abstract:
>
>Hybrid key exchange refers to using multiple key exchange algorithms
>simultaneously and combining the result with the goal of providing
>security even if all but one of the component algorithms is broken.
>It is motivated by transition to post-quantum cryptography.  This
>document provides a construction for hybrid key exchange in the
>Transport Layer Security (TLS) protocol version 1.3.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-c404f4af2592f2f4&q=1&e=367fabf2-370b-4cec-b657-05a8499decf6&u=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design
> .
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-09
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/li

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

> (3)-(5) are exactly the hard problems I’ve been thinking a lot about
> lately.  I’d actually be tempted to say that AuthKEM vs signatures is
> something we should figure out ASAP.  I read AuthKEM again this morning,
> and it has a lot of attractive features, but I’m not quite sure what the
> right answer is yet.
>

I don't think we can settle the future of PQ authentication in TLS just yet
— there are still many unknowns. To name a few:

1. What signature schemes are on the horizon? MAYO [1] from the NIST
signatures on-ramp would be great, if it doesn't turn out to be broken.

2. How will the confidence in existing schemes develop? AuthKEM will look
different depending on whether it can use Kyber-512 or Kyber-1024. Also,
will it replace Dilithium5 or Dilithium2?

3. What other higher level changes is the ecosystem able to adopt? For
instance Merkle Tree Certs [2].

These are all hard questions, and although I do not believe we can answer
them now, we should be thinking about them right now. I think we should
have different pots on the fire, so to say.

Best,

 Bas

[1] https://pqmayo.org/params-times/
[2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

On Mon, Nov 6, 2023 at 5:40 PM Kampanakis, Panos  wrote:

> > Concretely, after ML-KEM is finished, I was planning to update
> draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
> for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.
>
>
>
> Agreed, but I would suggest three (x25519-mlkem768, p256-mlkem768,
> p384-mlkem1024) to cover FIPS and CNSA 2.0 compliance. More than three
> combinations is unnecessary imo.
>

x25519-mlkem768 will be FIPS thanks to mlkem768. Have you seen x25519 is in
SP 800-186 now? So I say we can leave out p256-mlkem768.

Best,

 Bas

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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

On Mon, Nov 6, 2023 at 7:06 PM Kris Kwiatkowski  wrote:

> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186
> does not impact the curves permitted under SP 800-56Arev3. Curves that are
> included in SP 800-186 but not included in SP 800-56Arev3 are not approved
> for key agreement. E.g., the ECDH X25519 and X448 key agreement schemes
> (defined in RFC 7748) that use Curve25519 and Curve448, respectively, are
> not compliant to SP 800-56Arev3…”. This may potentially be a problem, right?
>

SP 800-56Crev2 allows a hybrid mode Z' := Z || T (§2, page 2). "Z" would be
ML-KEM and "T" X25519. That means we have to put ML-KEM first (instead of
X25519 now.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip

[Bas Westerbaan]

I would like to see examples of these use cases where using QUIC is
impossible, but using TurboTLS is.

Best,

 Bas

On Wed, Nov 15, 2023 at 6:37 PM David Joseph  wrote:

> Hi everyone,
>
> We wanted to speak about this draft on *TurboTLS* at 118 but didn't
> manage to squeeze into the packed session.
>
> Forwarding a new draft here that describes an idea for UDP handshaking in
> parallel to setting up the TCP stream, then switching back to TLS-over-TCP
> for the session portion. This enables *removing one round trip from all
> TLS versions* in the best case, and in the worst case scenario, falling
> back to TLS-over-TCP with an extremely small latency boost.
>
> TurboTLS doesn't change the contents of any TLS messages, only how some
> handshake messages are delivered over UDP instead of TCP. This technique
> supports *transparent proxying*, whereby standard TLS requests can be
> intercepted and turbo charged, by sitting one proxy in front of both client
> and server. First client requests are intercepted, translated to UDP,
> received by the server proxy, translated back to TCP, and sent back without
> client nor server being aware that their exchange has been turbo charged.
>
> Proxying enables legacy systems using all versions of TLS to obtain faster
> connection establishment without touching their network stack. TurboTLS has
> most potential *where migration to QUIC is not possible *in the near
> term due to legacy servers, or due to firewall visibility/deep packet
> inspection concerns, yet for systems which handle many short-lived TLS
> connections per second with non-trivial network latency.
>
> We managed to speak with a few of you privately about your thoughts on the
> benefits and drawbacks of this technique, and would like you to share any
> more opinions with us below so that we can understand whether it is worth
> developing this draft further.
>
> If this sounds like it might be useful to you/your use case, please get in
> touch!
>
> Kind regards,
> David
>
> -- Forwarded message -
> From: 
> Date: Sun, Nov 5, 2023 at 12:43 AM
> Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt
> To: Carlos Aguilar-Melchor , David Joseph <
> d...@sandboxaq.com>, Douglas Stebila , Jason
> Goertzen 
>
>
> A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been
> successfully submitted by Deirdre Connolly and posted to the
> IETF repository.
>
> Name: draft-joseph-tls-turbotls
> Revision: 00
> Title:TurboTLS for faster connection establishment
> Date: 2023-11-05
> Group:Individual Submission
> Pages:16
> URL:  https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/
> HTML:
> https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls
>
>
> Abstract:
>
>This document provides a high level protocol description for
>handshaking over UDP in the Transport Layer Security (TLS) protocol
>(version independent).  In parallel, a TCP session is established,
>and once this is done, the TLS session reverts to TCP.  In the event
>that the UDP handshaking portion fails, TurboTLS falls back to TLS-
>over-TCP as is usually done, resulting in negligible latency cost in
>the case of failure.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design
>
>
>
> The IETF Secretariat
>
>
> ___
> 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 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

The draft itself is an exercise in clear communication, and mentioning PQC
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich  wrote:

>
>- that is implied by a "feature freeze". No reason to highlight PQC
>(even though it is a hype topic right now).
>
> Yes, to both of these.  But I still think it should be explicitly called
> out.  If the WG thinks otherwise, then fine, the document is that much
> shorter :)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> I think there is a companion point to be made.  I suggest:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 256 bits.
>

Not true.128 bit symmetric keys are fine for PQ.

Right, I think that means that ECH as-is can be used, but in the face
> of a CRQC, ECH as-is won't protect against the leakage about which
> John was concerned.


Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)

 Best,

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> PS: I do not want us to hold up producing the ECH RFC while
> we figure that out - we should get the current thing out the
> door first!
>

Completely agree.

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

> By contrast the PQ version "just" has key size issues to worry about
> with the DNS advertising bits and maybe some structures that get
> tight.
>

I have the same intuition. Instead of guessing, we should plop Kyber in ECH
and see if it works.

If not then there are still other paths besides PSK — for instance using
BAT [1].

Best,

 Bas

[1] https://eprint.iacr.org/2022/031
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

sgtm

On Wed, Dec 13, 2023 at 4:36 PM Russ Housley  wrote:

> Bas:
>
> Thanks.  I've adjusted the proposed text to address your comments:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 128 bits.  While Grover’s algorithm (described in
>Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum
>computer to perform a brute force key search using quadratically
>fewer steps than would be required with classical computers, there
>are a number of mitigating factors suggesting that Grover’s algorithm
>will not speed up brute force symmetric key search as dramatically as
>one might suspect.  First, quantum computing hardware will likely be
>more expensive to build and use than classical hardware.  Second, to
>obtain the full quadratic speedup, all the steps of Grover’s
>algorithm must be performed in series.  However, attacks on
>cryptography use massively parallel processing, the advantage of
>Grover’s algorithm will be smaller.
>
>Implementations must use sufficiently large external PSKs.  For
>protection against the future invention of a CRQC, the external PSK
>needs to be at least 128 bits.
>
> Russ
>
>
> On Dec 13, 2023, at 8:18 AM, Bas Westerbaan  wrote:
>
> I think there is a companion point to be made.  I suggest:
>>
>>Implementations must use a ciphersuite that includes a symmetric
>>encryption algorithm with sufficiently large keys.  For protection
>>against the future invention of a CRQC, the symmetric key needs to be
>>at least 256 bits.
>>
>
> Not true.128 bit symmetric keys are fine for PQ.
>
> Right, I think that means that ECH as-is can be used, but in the face
>> of a CRQC, ECH as-is won't protect against the leakage about which
>> John was concerned.
>
>
> Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
> deployable, and whether its performance is acceptable, is something we
> should figure out.)
>
>  Best,
>
>  Bas
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

On Tue, Jan 2, 2024 at 3:30 PM Salz, Rich 
wrote:

> Those who can move to 1.3+, will do so, regardless of this draft. Those
> who can’t, would do whatever’s appropriate in their case – again,
> regardless of this draft.
>
>
>
> Same as for any other IETF document. :)
>
>
>
> One difference in the current wording is that it would become trivially
> more difficult to get a multi-vendor PQ solution for current TLS 1.2
> implementations.  Assuming, of course, that “just use what was defined for
> TLS 1.3 or later” somehow doesn’t occur to everyone.
>

It is more difficult than "just use what was defined for TLS 1.3 or later".
TLS 1.2 has a downgrade attack where a MitM can force a broken commonly
supported group even if the handshake signature is secure/PQ (CurveSwap).
TLS 1.3 fixed that. I do have to add that the scope (I can imagine now) is
limited: it affects clients that can disable classical authentication, but
cannot disable classical key agreement everywhere.

Best,

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

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

[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/bwesterb/status/1734586155868287457
[4] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
[5] https://link.springer.com/chapter/10.1007/978-3-319-76578-5_7
[6] https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/
[7] https://datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/
[8] Following earlier deployment of X25519Kyber768, despite targeting 128
bits, we use ML-KEM-768 instead of ML-KEM-512 to hedge against advances in
lattice attacks.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bas Westerbaan]

Hi Dan,

Thanks for your detailed comments.

Bas Westerbaan writes:
> > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> > )
>
> 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
> This makes the construction more generic,


This construction is not meant to be generic, and we have security proof of
the IND-CCA robustness. I would be in favor of having Mike's draft
alongside X-Wing, so that people that are not satisfied with X-Wing, have a
safe recipe to create their own.


> 2. I think it's good that both of the X25519 public keys are included
> where some hybrid constructions would include just one (labeled as
> ciphertext). Rationale: less chance of confusion regarding which key to
> include; better fit with some existing uses of X25519; might marginally
> simplify security review; even smaller performance cost than including
> the post-quantum ciphertext.
>

And it is required for the IND-CCA robustness: without it, it's not.


> 3. There are papers that recommend also including at least a 32-byte
> prefix of the post-quantum pk:


ML-KEM already includes the public key in the derivation of the shared
secret (line 6 algorithm 17), so we see no need to include it a second
time. Again, we do not aim to be a generic construction with X-Wing.


> I think the hybrid construction is a good place to put this hash. If
> there are many different hybrid constructions then factoring out another
> layer might be useful for reviewers, but I'd rather settle on a minimal
> number of hybrid constructions.
>

At the moment the choice of hybrid is left to the application/protocol.
This has led to many different proposals for hybrids, which wastes a lot of
engineering, standardisation and security review time. I think it's better
if hybridisation is done at the level of cryptographic primitive.


> 4. I'd put ss_X25519 before the post-quantum session key. This has a
> two-part rationale.
>

All inputs fit within one SHA3-256 block. Because of that, if I understand
correctly, the order is inconsequential.

Best,

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

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

[Bas Westerbaan]

> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners;
>

I agree.


> We could consider adding a section with concrete instantiations, and the
> first one would be X-Wing 😊 (followed by ML-KEM + P-256, Brainpool, and
> RSA variants).
>
>
>
> I guess that leads to the following question: @Bas Westerbaan
> , @Deirdre Connolly
> , Peter, would you be open to merging X-Wing
> into the generic combiner draft, or is there value in it being standalone?
>

X-Wing explicitly trades genericity for simplicity. We will not get such a
simple and efficient construction if it is the instantiation of an
easy-to-use generic construction.

Best,

 Bas


>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *Bas Westerbaan
> *Sent:* Wednesday, January 10, 2024 2:14 PM
> *To:* IRTF CFRG ;  
> *Cc:* k...@cupdev.net
> *Subject:* [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> 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
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-Y-JP2DY$>
> Proof: https://eprint.iacr.org/2024/0

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

[Bas Westerbaan]

>  Because for embedded devices that don’t have enough memory to hold all
> of those objects in simultaneously, this is likely the order in which it
> would have those things available to stream into SHA3.
>

That will not make a difference: the SHA3-256 rate is 136 bytes.


> Another thing to consider: thinking of how crypto libraries and HSMs are
> structures, will an X25519 decrypter necessarily have access to its own
> public key? For example I could imagine that to do X25519 based protocols
> today, an HSM only needs to store the X25519 private key. It’s probably
> worth a bit of a survey to see if adding a requirement for the HSM to know
> the X25519 public key will cause chaos with existing X25519 implementations.
>

Good point. Filippo also pointed out that having the pk as an argument to
decapsulate is inconvenient. He suggests to simply add the X25519 public
key to the X-Wing private key (similar to what ML-KEM also does), and that
makes sense to me.
https://github.com/dconnolly/draft-connolly-cfrg-xwing-kem/issues/8


>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *D. J. Bernstein
> *Sent:* Thursday, January 11, 2024 6:47 AM
> *To:* c...@irtf.org; tls@ietf.org
> *Subject:* [EXTERNAL] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Do we have a survey of hybrid patents? To be clear, for security reasons I
> recommend a straightforward policy of always using hybrids (https:
> //urldefense. com/v3/__https: //blog. cr. yp. to/20240102-hybrid.
> html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$).
>
>
> Do we have a survey of hybrid patents?
>
>
>
> To be clear, for security reasons I recommend a straightforward policy
>
> of always using hybrids 
> (https://urldefense.com/v3/__https://blog.cr.yp.to/20240102-hybrid.html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$
>  
> <https://urldefense.com/v3/__https:/blog.cr.yp.to/20240102-hybrid.html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$>).
>
> NIST reportedly bought out some hybrid patents; I'm not aware of hybrid
>
> patents that predate the clear prior art; and in any case it has been
>
> obvious for many years to try hashing any selection of the available
>
> inputs that both sides see, such as ciphertexts, public keys, session
>
> keys, and/or context labels. But I worry that a profusion of hybrid
>
> mechanisms could have someone getting into trouble with a non-bought-out
>
> patent on some specific hybrid mechanism, because of an unfortunate
>
> choice of details matching what the patent happens to cover. A patent
>
> survey would reduce concerns here.
>
>
>
> Bas Westerbaan writes:
>
> > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
>
> > )
>
>
>
> 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
>
> This makes the construction more generic, and simplifies security
>
> review. There's negligible performance cost compared to the cost of
>
> communicating the ciphertext in the first place. (For quantification of
>
> costs of communication etc., see 
> https://urldefense.com/v3/__https://cr.yp.to/papers.html*pppqefs__;Iw!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHM0iBL7o$
>  
> <https://urldefense.com/v3/__https:/cr.yp.to/papers.html*pppqefs__;Iw!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHM0iBL7o$>.)
>
>
>
> 2. I think it's good that both of the X25519 public keys are included
>
> where some hybrid constructions would include just one (labeled as
>
> ciphertext). Rationale: less chance of confusion regarding which key to
>
> include; better fit with some existing uses of X25519; might marginally
>
> simplify security review; even smaller performance cost than including
>
> the post-quantum ciphertext.
>
>
>
> 3. There are papers that recommend also including at least a 32-byte
>
> prefix of the post-quantum pk: (1) 
> https://urldefense.com/v3/__https://eprint.iacr.org/2021/708__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHFgGO8fn$
>  
> <https://urldefense.com/v3/__https:/eprint.iacr.org/2021/708__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHFgGO8fn$>
>
> recommends including some sort of user identifier and claims that it
>
> isn't "robust" to have ciphertexts that might be decryptable by multiple
>
> users; (2) 
> https://urldefense.com/v3/__https

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

[Bas Westerbaan]

On Thu, Jan 11, 2024 at 3:56 PM Mike Ounsworth  wrote:

> Right. I’m just thinking out loud here.
>
>
>
> If the Generic is
>
>
>
> KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)
>
>
>
> And X-Wing is:
>
>
>
> SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )
>
>
>
> It looks pretty close to me; you’ve dropped the ML-KEM CT, added the
> X25519 recipient public key, and moved the fixedInfo from the end to the
> beginning.
>
>
>
> The question is: is that close enough to be considered a profile? Do we
> want to adapt the Generic so that X-Wing is properly a profile?
>

The X-Wing combiner is not necessarily secure when instantiated with other
primitives. The big one is that we need a ciphertext collision resistant
KEM. Also we use that ML-KEM mixes in its own public key in the shared
secret. And then there are more assumptions: assuming fixed length
ciphertext/shared secrets, assuming we fit within the KDF block size (see
Dan's e-mail).

We could make the generic combiner simpler depending on the
primitives used, but that will make the generic combiner specification much
more complex/subtle.


Binding to the ECC public keys is probably not a bad idea in general.
> Certainly it would make no sense for some IETF protocols to use X-Wing
> while others use the ML-KEM + X25519 instantiation of the generic. I think
> I’m convincing myself that the Generic should be adjusted so that X-Wing is
> the obvious instantiation for ML-KEM + X25519.
>
>
>
> Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We
> chose suffix simply because it more obviously aligns with SP 800-56Cr2, and
> we’ve all had the experience of FIPS labs being picky about things like
> that.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Bas Westerbaan 
> *Sent:* Thursday, January 11, 2024 7:07 AM
> *To:* Mike Ounsworth 
> *Cc:* IRTF CFRG ;  ; Deirdre
> Connolly ; k...@cupdev.net
> *Subject:* Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could
> consider adding a section with concrete instantiations, and the first one
> would be X-Wing 😊 (followed
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners;
>
>
>
> I agree.
>
>
>
> We could consider adding a section with concrete instantiations, and the
> first one would be X-Wing 😊 (followed by ML-KEM + P-256, Brainpool, and
> RSA variants).
>
>
>
> I guess that leads to the following question: @Bas Westerbaan
> , @Deirdre Connolly
> , Peter, would you be open to merging X-Wing
> into the generic combiner draft, or is there value in it being standalone?
>
>
>
> X-Wing explicitly trades genericity for simplicity. We will not get such a
> simple and efficient construction if it is the instantiation of an
> easy-to-use generic construction.
>
>
>
> Best,
>
>
>
>  Bas
>
>
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *Bas Westerbaan
> *Sent:* Wednesday, January 10, 2024 2:14 PM
> *To:* IRTF CFRG ;  
> *Cc:* k...@cupdev.net
> *Subject:* [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> 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
>
> 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

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

[Bas Westerbaan]

On Thu, Jan 11, 2024 at 10:48 PM Martin Thomson  wrote:

>
>
> On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote:
> > 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 )
>
> At least for TLS, I'm not convinced that any combiner is necessary, in
> line with the analysis done for draft-ietf-tls-hybrid-design.
>

I agree, for TLS this is not required for security.

For TLS the trade-off is this: we add one single keccak permutation, so
that we can eliminate the need of two different KEMs both called
X25519Kyber768, which are both used in PQ TLS with PQ ECH.

Best,

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

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

[Bas Westerbaan]

>
> The arguments for multiple KEMs are
> stronger than the arguments for multiple combiners.
>

X-Wing is a KEM — not a combiner. I agree there should preferably be one
go-to generic combiner. Insisting that X-Wing use that generic combiner, is
not dissimilar to insisting that every KEM that uses an FO transform,
should use the same generic FO transform.

Best,

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

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

[Bas Westerbaan]

The cost of hybrids is not high, but it's certainly not negligible. I can't
share the exact number of servers we'd be able to cut if we'd go pure PQ,
but with a back of the envelope calculation I think you can convince
yourself that we could've at least hired an engineer instead. We think it's
worth it now, but of course we're not going to keep hybrids around when the
CRQC arrives.

Best,

 Bas

On Thu, Mar 7, 2024 at 1:56 AM Dennis Jackson  wrote:

> I'd like to understand the argument for why a transition back to single
> schemes would be desirable.
>
> Having hybrids be the new standard seems to be a nice win for security
> and pretty much negligible costs in terms of performance, complexity and
> bandwidth (over single PQ schemes).
>
> On 07/03/2024 00:31, Watson Ladd wrote:
> > On Wed, Mar 6, 2024, 10:48 AM Rob Sayre  wrote:
> >> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla  wrote:
> >>>
> >>>
> >>> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly <
> durumcrustu...@gmail.com> wrote:
> > Can you say what the motivation is for being "fully post-quantum"
> rather than hybrid?
>  Sure: in the broad scope, hybrid introduces complexity in the
> short-term that we would like to move off of in the long-term - for TLS 1.3
> key agreement this is not the worst thing in the world and we can afford
> it, but hybrid is by design a hedge, and theoretically a temporary one.
> >>>
> >>> My view is that this is likely to be the *very* long term.
> >>
> >> Also, the ship has sailed somewhat, right? Like Google Chrome,
> Cloudflare, and Apple iMessage already have hybrids shipping (I'm sure
> there many more, those are just really popular examples). The installed
> base is already very big, and it will be around for a while, whatever the
> IETF decides to do.
> > People can drop support in browsers fairly easily especially for an
> > experimental codepoint. It's essential that this happen: if everything
> > we (in the communal sense) tried had to be supported in perpetuity, it
> > would be a recipe for trying nothing.
> >
> >> thanks,
> >> Rob
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bas Westerbaan]

Back to the topic at hand. I think it'd very bad if we'd have a codepoint
for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
wise, I think that's up to the designated experts of the IANA registry.

Best,

 Bas


On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
> Cheers,
> Deirdre
> ___
> 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] Time to first byte vs time to last byte

[Bas Westerbaan]

>
> Given that especially for the web, CDNs used much higher initcwnds,


Please, let us not assume every website is behind a CDN.



> let's focus on Figure 10. Based on Fig 10, 50-100KB of data over a PQ
> connection, the TTLB would be 10-15% slower for 1Mbps and 200ms RTT. At
> higher speeds, this percentage is much less (1-1.5% based on Fig 9b), but
> let's focus on the slow link.
>
> If we consider the same case for handshake, then the PQ handshake slowdown
> is 30-35% which definitely looks like a very impactful slowdown. A 10-15%
> for the TTLB is much less, but someone could argue that even that is a
> significant slowdown. Note we are still in a slow link, so even the
> classical conn transferring 72KB is probably suffering. To quantify that I
> looked at my data from these experiments. A classical connection TTLB for
> 50-100KB of data at 1Mbps and 200ms RTT and 0% loss was ~1.25s. This is not
> shown in the paper because I only included text about the 10% loss case.
> 1.25s for a 72KB page to start getting rendered on a browser over a
> classical conn vs 1.25*1.15=1.44s for a PQ one. I am not sure any user
> waiting for 1.25s will close the browser at 1.44s.
>
> Btw, the Google PageSpeed Insights TTFB metric which includes (DNS lookup,
> redirects and more) considers 0.8s - 1.8s as "Needs improvement". In our
> experiments, the handshake time for 1Mbps and 200ms RTT amounted to 436ms
> and 576ms for the classical and PQ handshakes respectively. I am not sure
> the extra 140ms (30-35% slowdown) for the PQ handshake would even throw the
> Google PageSpeed Insights TTFB metric to the "Needs improvement" category.
>
>
>
> -Original Message-
> From: Martin Thomson 
> Sent: Thursday, March 7, 2024 10:26 PM
> To: Kampanakis, Panos ; David Benjamin <
> david...@chromium.org>; Deirdre Connolly ; Rob
> Sayre 
> Cc: TLS@ietf.org; Childs-Klein, Will 
> Subject: RE: [EXTERNAL] [TLS] Time to first byte vs time to last byte
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Hi Panos,
>
> I realize that TTLB might correlate well for some types of web content,
> but it's important to recognize that lots of web content is badly bloated
> (if you can tolerate the invective, this is a pretty good look at the
> situation, with numbers:
> https://infrequently.org/series/performance-inequality/).
>
> I don't want to call out your employer's properties in particular, but at
> over 3M and with relatively few connections, handshakes really don't play
> much into page load performance.  That might be typical, but just being
> typical doesn't mean that it's a case we should be optimizing for.
>
> The 72K page I linked above looks very different.  There, your paper shows
> a 20-25% hit on TTLB.  TTFB is likely more affected due to the way
> congestion controllers work and the fact that you never leave slow start.
>
> Cheers,
> Martin
>
> On Fri, Mar 8, 2024, at 13:56, Kampanakis, Panos wrote:
> > Thx Deirdre for bringing it up.
> >
> > David,
> >
> > ACK. I think the overall point of our paper is that application
> > performance is more closely related to PQ TTLB than PQ TTFB/handshake.
> >
> > Snippet from the paper
> >
> > *> Google’s PageSpeed Insights [12] uses a set of metrics to measure
> > the user experience and webpage performance. The First Contentful
> > Paint (FCP), Largest Contentful Paint (LCP), First Input Delay (FID),
> > Interaction to Next Paint (INP), Total Blocking Time (TBT), and
> > Cumulative Layout Shift (CLS) metrics include this work’s TTLB along
> > with other client-side, browser application-specific execution delays.
> > The PageSpeed Insights TTFB metric measures the total time up to the
> > point the first byte of data makes it to the client. So, PageSpeed
> > Insights TTFB is like this work’s TTFB/TLS handshake time with
> > additional network delays like DNS lookup, redirect, service worker
> > startup, and request time.*
> >
> > Specifically about the Web, TTLB (as defined in the paper) is directly
> > related to FCP, LCP, FID, INP, TBT, CLS, which are 6 of the 7 metrics
> > in Google’s PageSpeed Insights. We don’t want to declare that TTLB is
> > the ultimate metric, but intuitively, I think it is a better indicator
> > when it comes to application performance than TTFB.
> >
> > That does not intend to underestimate the importance of the studies on
> > handshake performance which was crucial to identify the best
> > performing new KEMs and signatures. It also does not intend to
> > underestimate the importance of slimming down PQ TLS 1.3 handshakes as
> much as possible.
> >
> > Side note about Rob’s point:
> > We have not collected QUIC TTLB data yet, but I want to say that the
> > paper’s TTLB experimental results could more or less be extended to
> > QUIC be subtracting one RTT. OK, I don’t have experimental
> > measurements to prove it yet. So I w

Re: [TLS] A suggestion for handling large key shares

[Bas Westerbaan]

Hi Scott,

I generally agree with David, in particular that the keyshare prediction
draft is the way forward.

There is a different use-case for your mechanism, which you didn't mention:
it's less likely to trip over buggy servers / middleboxes. We use it as the
default mechanism to talk to our customer's origins.
https://blog.cloudflare.com/post-quantum-to-origins

Thanks to Chrome's efforts, for browsers, we luckily don't need to use this
slower mechanism.

One inline comments down below.

Best,

 Bas


On Tue, Mar 19, 2024 at 5:47 AM Scott Fluhrer (sfluhrer)  wrote:

> Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and
> me) about a suggestion about one way to potentially improve the performance
> (in the ‘the server hasn’t upgraded yet’ case), and asked if we should add
> that suggestion to our draft.  It occurs to me that this suggestion is
> equally applicable to the pure ML-KEM draft (and future PQ drafts as well);
> hence putting it in our draft might not be the right spot.
>
>
>
> Here’s the core idea (Matt’s original scenario was more complicated):
>
>
>
>- Suppose we have a client that supports both P-256 and P256+ML-KEM.
>What the client does is send a key share for P-256, and also indicate
>support for P256+ML-KEM.  Because we’re including only the P256 key share,
>the client hello is short
>- If the server supports only P256, it accepts it, and life goes on as
>normal.
>- If the server supports P256+ML-KEM, what Matt suggested is that,
>instead of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM.
>We then continue as expected and end up negotiating things in 2 round 
> trips.
>
>
>
> Hence, the non-upgraded scenario has no performance hit; the upgraded
> scenario does (because of the second round trip), but we’re transmitting
> more data anyways
>

The roundtrip is quite a bit more costly than the extra kilobyte of upload
with respect to latency.


> (and the client could, if it communicates with the server again, lead off
> with the proposal that was accepted last time).
>
>
>
> Matt’s suggestion was that this should be a SHOULD in our draft.
>
>
>
> My questions to you: a) do you agree with this suggestion, and b) if so,
> where should this SHOULD live?  Should it be in our draft?  The ML-KEM
> draft as well (assuming there is one, and it’s not just a codepoint
> assignment)?  Another RFC about how to handle large key shares in general
> (sounds like overkill to me, unless we have other things to put in that
> RFC)?
>
>
>
> Thank you.
> ___
> 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 1.3, Raw Public Keys, and Misbinding Attacks

[Bas Westerbaan]

On Thu, Mar 28, 2024 at 4:22 PM John Mattsson  wrote:

> Hi,
>
>
>
> I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly
> stated in RFC 8446, TLS 1.3 with signatures and certificates is an
> implementation of SIGMA-I:
>
>
>
> SIGMA does however require that the identities of the endpoints (called A
> and B in [SIGMA]) are included in the messages. This is not true for TLS
> 1.3 with RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with
> RPKs is vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:
>
>
>
> “This attack, to which we refer as an “identity misbinding attack”,
> applies to many seemingly natural and intuitive protocols. Avoiding this
> form of attack and guaranteeing a consistent binding between a session key
> and the peers to the session is a central element in the design of SIGMA.”
>
>
>
> “Even more significantly we show here that the misbinding attack applies
> to this protocol in any scenario where parties can register public keys
> without proving knowledge of the corresponding signature key.”
>

With a bit more context (emphasis my own):

Yet, no proof of security of the *STS protocol*
exists (see more on this below). Even more significantly we show here that
the
misbinding attack applies to this protocol in any scenario where parties can
register public keys without proving knowledge of the corresponding
signature
key. (We note that while such “proof of possession” is required by some CAs
for
issuing a certificate, this is not a universal requirement for public key
certificates;
in particular it is not satisfied in many “out-of-band distribution”
scenarios, webs
of trust, etc.) In this case Eve can register A’s public key as its own and
then
simply replace A’s identity (or certificate) in the third message of STS
with her
own. B verifies the incoming message and accepts it as coming from Eve.
Thus,
in this case the STS protocol fails to defend against the misbinding
attack. Thus,
for the STS to be secure one must assume that a secure external mechanism
for
proof of possession of signature keys is enforced. *As we will see both the
ISO*
*protocol discussed in Section 4 and the SIGMA protocols presented here do
not*
*require such a mechanism.*





>
>
> As stated in Appendix E.1, at the completion of the handshake, each side
> outputs its view of the identities of the communicating parties. On of the
> TLS 1.3 security properties are “Peer Authentication”, which says that the
> client’s and server’s view of the identities match. TLS 1.3 with PRKs does
> not fulfill this unless the out-of-band mechanism to register public keys
> proved knowledge of the private key. RFC 7250 does not say anything about
> this either.
>
>
>
> I think this needs to be clarified in RFC8446bis. The only reason to ever
> use an RPK is in constrained IoT environments. Otherwise a self-signed
> certificate is a much better choice. TLS 1.3 with self-signed certificates
> is SIGMA-I.
>
>
>
> It is worrying to find comments like this:
>
>
>
> “I'd like to be able to use wireguard/ssh-style authentication for my app.
> This is possible currently with self-signed certificates, but the proper
> solution is RFC 7250, which is also part of TLS 1.3.”
>
> https://github.com/openssl/openssl/issues/6929
>
>
>
> RPKs are not the proper solution.
>
>
>
> (Talking about misbinding, does RFC 8446 say anything about how to avoid
> selfie attacks where an entity using PSK authentication ends up talking to
> itself?)
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>
>
> ___
> 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] WG Adoption for TLS Trust Expressions

[Bas Westerbaan]

On Tue, Apr 30, 2024 at 6:17 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> but you could just as easily do this with a simple extension from the
> private range, so I'm not sure that was a big blocker.
>

No need for a new extension: a government can use a specific signature
algorithm for that (say, a national flavour of elliptic curve, or a
particular PQ/T hybrid).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Bas Westerbaan]

I support adoption, and am happy to review.

On Sat, May 4, 2024 at 12:05 AM Joseph Salowey  wrote:

> This is a working group call for adoption
> for draft-davidben-tls-key-share-prediction.  This document was presented
> at IET 118 and has undergone some revision based on feedback since then.
> The current draft is available here:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
> Please read the document and indicate if and why you support or do not
> support adoption as a TLS working group item. If you support adoption
> please, state if you will help review and contribute text to the document.
> Please respond to this call by May 20, 2024.
>
> Thanks,
>
> Joe, Deidre, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

Numbers from Cloudflare server-side in the last hour. Restricted to TLS 1.3
and counting by handshake. "sent" column lists the group identifiers for
the keyshares sent by the cleint, and "supported" lists the identifiers for
the groups the client reports being supported. Both lists are sorted, and
grease has been removed. Recall X25519=29, X25519Kyber768=25497, P-256=23.
[1] "frac" is percents.

┌─frac─┬─sent───┬─supported──┐
│46.08025597692571 │ [29]   │ [23,24,29]
  │
│19.10472730561162 │ [29]   │ [23,24,25,29]
 │
│   12.634492333471034 │ [29]   │ [23,24,25,29,30]
  │
│9.969397483263833 │ [29,25497] │ [23,24,29,25497]
  │
│7.245082433725522 │ [29]   │ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.9836423280948468 │ [23,29]│ [23,24,25,29,256,257]
 │
│   0.9693757351437323 │ [23,29]│ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.7147137542915519 │ [23]   │ [16,19,21,23,24,25,256]
 │
│   0.5387597287371817 │ [23]   │ [23,24,25]
  │
│   0.3216808337902684 │ [24]   │ [23,24]
 │
│   0.3077268972274922 │ [29]   │ [23,24,29,30]
 │
│   0.2895491193771448 │ [23]   │ [23,24,25,256,257,258,259,260]
  │
│   0.2310142062284145 │ [23,29]│ [23,24,25,29]
 │
│  0.13238812679791004 │ [29]   │ [23,24,25,29,25497,65074]
 │
│   0.0837752734900604 │ [23]   │ [23]
  │
│ 0.057858939606985335 │ [29]   │ [23,24,25,29,256,257,258,259,260]
 │
│   0.0405672284711662 │ [29]   │ [23,24,25,29,30,249]
  │
│ 0.036025019042332365 │ [23]   │ [23,24]
 │
│ 0.027518977252528012 │ [23]   │
[9,10,11,12,13,14,22,23,24,25,256,257,258,259,260] │
│ 0.021650399459822143 │ [23,29]│ [23,24,25,29,256,257,258,259,260]
 │
└──┴┴┘

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. [2]

When we sent an empty ClientHello, advertising support for X25519,
X25519Kyber768, P-256, P-384 and P-521, those origins that support TLS 1.3
(and HelloRetryRequest [3]) picked as follows. We can call this server
preference.

96.7% X25519
1.8% P-384
0.7% P-256
0.54% X25519Kyber768
0.15% P-521

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

Best,

 Bas


[1] For your convenience link to the full list:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
[2] https://blog.cloudflare.com/post-quantum-to-origins
[3] About 1% of origins fails to do HelloRetryRequest.


On Mon, Jun 3, 2024 at 12:09 PM Martin Thomson  wrote:

> 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%
>
> Authentication:
>   RSA Sign 70.10%, ECDSA 29.14%, RSA KEA 0.76%
> ECDSA curve:  P-256 99.69%, P-384 0.31%
> RSA size: 1024 0.09% (!), 2048 97.22%, 3072 0.28%, 4096 2.41%
>
> We do not expose Ed25519 signing in TLS at this stage, even though we
> could use delegated credentials so that it could be enabled without needing
> certificate support.
>
> On Sun, Jun 2, 2024, at 19:47, D. J. Bernstein wrote:
> > 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 Ope

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 3:24 PM Salz, Rich 
wrote:

> 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.
>
>
>
> I’m not so sure.   This is really CDN to origin, or server-to-server
> traffic. You’d expect latency to not be as important as client to server,
> but more importantly that persistent connections and resumption would
> amortize the cost hugely.
>

We do care about it. We're scanning origins so that we can send a supported
keyshare immediately and avoid HRR (not rolled out yet.) That's not just
for performance, but also to deal with origins that don't support HRR.

I also don't think this data supports the conclusion that P-256 will have
fewer HRRs. As you mention the population is quite skewed: only origins
that configured Cloudflare in front. 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.

Best,

 Bas

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

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 4:02 PM Filippo Valsorda 
wrote:

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

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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Bas Westerbaan]

X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today.
We just need to wait for the final standard, and (crucially) for the
verified modules with ML-KEM.

On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell 
wrote:

>
> I'm afraid I have no measurements to offer, but...
>
> On 03/06/2024 19:05, Eric Rescorla wrote:
> > The question is rather what the minimum set of algorithms we need is. My
> >   point is that that has to include P-256. It may well be the case that
> > it needs to also include X25519.
>
> Yep, the entirely obvious answer here is we'll end up defining at least
> x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS
> WG) seems pretty pointless to me. (That said, the measurements offered
> are as always interesting, so the discussion is less pointless than
> the argument:-)
>
> Cheers,
> S.
> ___
> 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: Curve-popularity data?

[Bas Westerbaan]

>
>
>
> One more thing: we are finalizing RFC 8446-bis right now, so if there is
> WG consensus to require that clients offer all MTI curves in the key_shares
> of their initial CH, then that would be a straightforward text change.
>
> I think we are closer to going in the other direction and allow TLS1.3
> spec-compliant implementations aiming at post-quantum support to drop
> support for P-256 entirely.
>
Agreed.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

Hi all,

We are planning to replace X25519Kyber768Draft00 (0x6399)
with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and X25519.

We will support X25519Kyber768Draft00 and X25519MLKEM768 at the same time
for a while to allow clients the opportunity to migrate without losing
post-quantum security.

Apart from these two, we also supported X25519Kyber768Draft00 under
codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We logged zero uses of
these two in the last week with a 1/100 sample rate. We will disable
0xfe31, 0xfe30 over the common weeks.

Best,

 Bas


PS. Not sure I shared it here already, but we have public graph tracking
client PQ key agreement deployment:
https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
At the time of writing about 17% of all human traffic (by request count)
with us is using X25519Kyber768Draft00.

[1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

Both.

On Mon, Sep 9, 2024 at 2:32 PM Kris Kwiatkowski  wrote:

> Sweet!
> Does this migration includes also cloudflare->origin (egress) connections
> or just eyeballs->cloudflare?
>
> Cheers,
> Kris
> On 06/09/2024 12:02, Bas Westerbaan wrote:
>
> Hi all,
>
> We are planning to replace X25519Kyber768Draft00 (0x6399)
> with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and X25519.
>
> We will support X25519Kyber768Draft00 and X25519MLKEM768 at the same time
> for a while to allow clients the opportunity to migrate without losing
> post-quantum security.
>
> Apart from these two, we also supported X25519Kyber768Draft00 under
> codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We logged zero uses of
> these two in the last week with a 1/100 sample rate. We will disable
> 0xfe31, 0xfe30 over the common weeks.
>
> Best,
>
>  Bas
>
>
> PS. Not sure I shared it here already, but we have public graph tracking
> client PQ key agreement deployment:
> https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
> At the time of writing about 17% of all human traffic (by request count)
> with us is using X25519Kyber768Draft00.
>
> [1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>
> ___
> 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: Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

If you were referring to the graph on Cloudflare Radar: that's just eyeball
-> edge.

On Mon, Sep 9, 2024 at 2:34 PM Bas Westerbaan  wrote:

> Both.
>
> On Mon, Sep 9, 2024 at 2:32 PM Kris Kwiatkowski 
> wrote:
>
>> Sweet!
>> Does this migration includes also cloudflare->origin (egress) connections
>> or just eyeballs->cloudflare?
>>
>> Cheers,
>> Kris
>> On 06/09/2024 12:02, Bas Westerbaan wrote:
>>
>> Hi all,
>>
>> We are planning to replace X25519Kyber768Draft00 (0x6399)
>> with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and X25519.
>>
>> We will support X25519Kyber768Draft00 and X25519MLKEM768 at the same time
>> for a while to allow clients the opportunity to migrate without losing
>> post-quantum security.
>>
>> Apart from these two, we also supported X25519Kyber768Draft00 under
>> codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We logged zero uses of
>> these two in the last week with a 1/100 sample rate. We will disable
>> 0xfe31, 0xfe30 over the common weeks.
>>
>> Best,
>>
>>  Bas
>>
>>
>> PS. Not sure I shared it here already, but we have public graph tracking
>> client PQ key agreement deployment:
>> https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
>> At the time of writing about 17% of all human traffic (by request count)
>> with us is using X25519Kyber768Draft00.
>>
>> [1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>>
>> ___
>> 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: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

[Bas Westerbaan]

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: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

[Bas Westerbaan]

On Mon, Sep 9, 2024 at 10:56 PM Andrei Popov  wrote:

> Yes, we need SecP384 hybrids.
>
> More generally, I see two separate hybrid key exchange drafts under
> discussion in the TLS WG:
> - draft-ietf-tls-hybrid-design-10 refers to pre-standard Kyber;
> - draft-kwiatkowski-tls-ecdhe-mlkem-01 defines hybrids with ML-KEM 768.
>

The latter is merely an instantiation of the former. A few IETF ago we
wanted to add codepoints to hybrid-design for X25519Kyber768Draft00, but
the working group felt that a separate document was more appropriate.
hybrid-design only mentions pre-standards Kyber, because it wasn't updated
to reflect the release of ML-KEM. It doesn't define codepoints.



>
> Both drafts are on the Informational track. Do we really need two separate
> documents? Also, shouldn't this work be on the Standards track?
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Alicja Kario 
> Sent: Friday, September 6, 2024 4:40 AM
> To: Kris Kwiatkowski ; tls@ietf.org
> Subject: [EXTERNAL] [TLS] 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: http://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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

[Bas Westerbaan]

Same.

On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov  wrote:

> I support staying the course, continuing work on the key share prediction
> draft and allocating the code point.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* David Benjamin 
> *Sent:* Tuesday, September 10, 2024 2:40 PM
> *To:*  
> *Subject:* [EXTERNAL] [TLS] draft-ietf-tls-key-share-prediction next steps
>
>
>
> Hi all,
>
>
>
> Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's
> awkwardness around key share prediction is becoming starkly visible. (It is
> difficult for clients to efficiently offer both Kyber and ML-KEM, but a
> hard transition loses PQ coverage for some clients. Kyber was a draft
> standard, just deployed by early adopters, so while not ideal, I think the
> hard transition is not the end of the world. ML-KEM is expected to be
> durable, so a coverage-interrupting transition to FancyNewKEM *would* be
> a problem.)
>
>
>
> We adopted draft-ietf-tls-key-share-prediction in June to address this.
> There hasn't been a whole lot to do on it since. I've cut a new draft,
> draft-ietf-tls-key-share-prediction-01, with some very minor changes that
> were queued up in GitHub. I'd like to sort out next steps and move forward.
>
>
>
> Beyond that, there are a couple of minor issues in the issue tracker. I
> don't believe either of these need to block getting a codepoint.
>
> https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless
> folks think otherwise, I plan to just leave this alone and close this
>
> https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks
> think otherwise, I plan to just leave this alone and not require the
> receiver to check
>
>
>
> Finally, there's the question of downgrade protection:
>
> https://github.com/tlswg/tls-key-share-prediction/issues/11
>
>
>
> For some background if folks have forgotten, the original key share
> prediction draft included a ton of complexity to accommodate existing
> server behavior that would preferentially pick groups out of key_share even
> if an otherwise more preferred group was in supported_groups. Depending on
> what the server was trying to do there, this could be perfectly fine (if
> the server believes the groups are comparable in security) or a downgrade
> risk (if the server actually believed they were in different security
> classes---PQ vs classical---but implemented a key_share-first selection
> algorithm anyway). Pre-adoption, my original draft took the position that
> it was ambiguous and we cannot safely assume the server knew what it was
> doing. It designed a scheme to clarify the semantics going forward and use
> codepoints to ratchet in whether the server implemented the new semantics.
>
>
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
>
>
>
> After WG discussion, I think we broadly concluded the semantics were
> actually already present in RFC 8446, and it was not worth the trouble to
> second-guess the servers here. That led to the much simpler draft, which
> simply discusses why this is OK in security considerations:
>
>
> https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations
>
>
>
> As I wrote that text, I unsurprisingly agree with and am fine with this
> outcome. :-) But there was some chatter about it in the adoption thread
> (see GitHub link), so I filed the issue so we continued to discuss it. I
> think perhaps now is the time to discuss it, if we're going to. Do folks
> want to discuss it? Are there alternate proposals, or should we just stay
> the course? Unless we have an alternate proposal, I propose we just stay
> the course and go with [what I understand the conclusion to be from] the
> previous WG discussion.
>
>
>
> If there are no further significant changes that folks want to make, I
> would like to propose we get a codepoint for this and unblock
> implementation. The earlier this is ready, the more likely that we will be
> prepared by the time the next KEM transition happens.
>
>
>
> Thoughts?
>
>
>
> David
> ___
> 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: [Pqc] Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

On Tue, Oct 15, 2024 at 1:52 PM Alicja Kario  wrote:

> Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024?
>

Not at this time. We want clients to guess correctly which PQ kex the
server supports, and that's easier if there are fewer deployed. Hopefully
clients will adopt
https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/


> Running the tlsfuzzer script against pq.cloudflareresearch.com I see
> that it doesn't handle the errors correctly: it sends decode_error
> instead of illegal_parameter for malformed client key shares.
>

Thanks for checking. This was a slight oversight in BoringSSL, which has
been fixed last month [1], but we've not rebased our patches yet. To state
the obvious: this does not affect security in any way.


> Also, it looks to me like the encapsulation key checks are
> missing/incorrect,
> it accepts a malformed ML-KEM encapsulation key.
>

We will add the encapsulation key check once we remove Kyber support from
our edge. Again, this does not affect security.


> (You can find the test script in
> https://github.com/tlsfuzzer/tlsfuzzer/pull/963)
>

Thanks for putting this test suite together.

Best,

 Bas


[1]
https://boringssl.googlesource.com/boringssl/+/72a60506ded3407454d6ddc1d848c266020c0c82


>
> On Tuesday, 15 October 2024 10:44:52 CEST, Bas Westerbaan wrote:
> > As of today, we support X25519MLKEM768 (0x11ec) on essentially
> > all websites served through Cloudflare.
> >
> > Best,
> >
> >  Bas
> >
> > On Fri, Sep 6, 2024 at 1:02 PM Bas Westerbaan 
> wrote:
> > Hi all,
> >
> > We are planning to replace X25519Kyber768Draft00 (0x6399)
> > with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and
> > X25519.
> >
> > We will support X25519Kyber768Draft00 and X25519MLKEM768 at the
> > same time for a while to allow clients the opportunity to
> > migrate without losing post-quantum security.
> >
> > Apart from these two, we also supported X25519Kyber768Draft00
> > under codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We
> > logged zero uses of these two in the last week with a 1/100
> > sample rate. We will disable 0xfe31, 0xfe30 over the common
> > weeks.
> >
> > Best,
> >
> >  Bas
> >
> >
> > PS. Not sure I shared it here already, but we have public graph
> > tracking client PQ key agreement
> > deployment:
> https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
> > At the time of writing about 17% of all human traffic (by
> > request count) with us is using X25519Kyber768Draft00.
> >
> > [1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>
> --
> 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] Re: Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

As of today, we support X25519MLKEM768 (0x11ec) on essentially all websites
served through Cloudflare.

Best,

 Bas

On Fri, Sep 6, 2024 at 1:02 PM Bas Westerbaan  wrote:

> Hi all,
>
> We are planning to replace X25519Kyber768Draft00 (0x6399)
> with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and X25519.
>
> We will support X25519Kyber768Draft00 and X25519MLKEM768 at the same time
> for a while to allow clients the opportunity to migrate without losing
> post-quantum security.
>
> Apart from these two, we also supported X25519Kyber768Draft00 under
> codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We logged zero uses of
> these two in the last week with a 1/100 sample rate. We will disable
> 0xfe31, 0xfe30 over the common weeks.
>
> Best,
>
>  Bas
>
>
> PS. Not sure I shared it here already, but we have public graph tracking
> client PQ key agreement deployment:
> https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
> At the time of writing about 17% of all human traffic (by request count)
> with us is using X25519Kyber768Draft00.
>
> [1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [Pqc] Re: Planned changes to Cloudflare's post-quantum deployment

[Bas Westerbaan]

On Tue, Oct 15, 2024 at 4:50 PM Jan Schaumann  wrote:

> Bas Westerbaan  wrote:
> > As of today, we support X25519MLKEM768 (0x11ec) on essentially all
> websites
> > served through Cloudflare.
>
> To clarify: this is for traffic from clients to
> Cloudflare


Yes.


> or is this also enabled for traffic to the
> origin (provided the origin supports it)?


Not yet, but we're working on it as we speak.

Best,

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

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

[Bas Westerbaan]

The number of people that actually implement these hybrid KEMs is much
smaller than the number of people that need to make a choice based on their
name. How do we explain that one is called MLKEM768X25519 and the other
SecP256r1MLKEM768? That'll cause more confusion worldwide over the coming
decades, than the few implementers who confuse the order on the wire
this year.


On Thu, Oct 17, 2024 at 10:54 AM CJ Tjhai  wrote:

> Personally, I prefer a name change to MLKEM768X25519.
>
> Cheers,
> CJ
>
> On Thu, 17 Oct 2024 at 08:57, Kris Kwiatkowski 
> wrote:
>
>> Yes, we switched the order. We want MLKEM before X25519, as that
>> presumably can be FIPS-certified.
>> According to
>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf,
>> section 2,
>> the shared secret from the FIPS-approved algorithm must precede the one
>> that is not approved. X25519
>> is not FIPS-approved hence MLKEM goes first. P-256 is FIPS-approved.
>>
>> The ordering was mentioned a few times, and there was some discussion on
>> github [1] about it. But,
>> maybe the conclusion should be just to change the name X25519MLKEM768 ->
>> MLKEM768X25519 (any opinion?)
>> That would be just a name change, so the code point value should stay the
>> same.
>>
>> Cheers,
>> Kris
>>
>> [1]
>> https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942
>> On 17/10/2024 08:24, Watson Ladd wrote:
>>
>> Did we really switch the order gratuitously on the wire between them?
>>
>> On Thu, Oct 17, 2024 at 12:02 AM CJ 
>> Tjhai 
>>  wrote:
>>
>> Hello,
>>
>> The X25519MLKEM768 scheme defined in the document is a concatenation of 
>> MLKEM768 and X25519, why is it not named MLKEM768X25519 instead?
>>
>> For SecP256r1MLKEM768, the naming makes sense since it's a concatenation of 
>> P256 and MLKEM768.
>>
>> Apologies if this has already been asked before.
>>
>> Cheers,
>> CJ
>>
>>
>>
>> 
>> PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited 
>> company incorporated in England and Wales with registered number 06808505.
>>
>> This email is meant only for the intended recipient. If you have received 
>> this email in error, any review, use, dissemination, distribution, or 
>> copying of this email is strictly prohibited. Please notify us immediately 
>> of the error by return email and please delete this message from your 
>> system. Thank you in advance for your cooperation.
>>
>> For more information about Post-Quantum, please visit www.post-quantum.com.
>>
>> In the course of our business relationship, we may collect, store and 
>> transfer information about you. Please see our privacy notice at 
>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>> information.
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>>
> --
> PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited
> company incorporated in England and Wales with registered number 06808505.
>
> This email is meant only for the intended recipient. If you have received
> this email in error, any review, use, dissemination, distribution, or
> copying of this email is strictly prohibited. Please notify us immediately
> of the error by return email and please delete this message from your
> system. Thank you in advance for your cooperation.
>
> For more information about Post-Quantum, please visit www.post-quantum.com
> .
>
> In the course of our business relationship, we may collect, store and
> transfer information about you. Please see our privacy notice at
> www.post-quantum.com/privacy-policy/ to learn about how we use this
> information.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[Bas Westerbaan]

On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein  wrote:

> Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
> potentially relevant here).
>
> Peter C writes:
> > Under realistic network conditions, TLS handshakes with full SLH-DSA
> > certificate chains seem to be about 5-10 times slower than traditional
> > certificate chains and, in some cases, can take on the order of
> > seconds.
>
> For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake
> from 2015 handles 85 signatures per second and 1300 verifications per
> second. (Source: dividing 12 billion cycles/second by the cycle counts
> given in https://bench.cr.yp.to/results-sign/amd64-samba.html.)
>
> Sure, one can come up with scenarios where this isn't fast enough or
> where 17KB for a signature is a problem. But there are also environments
> where these costs are negligible compared to the transmission and
> processing of user data.
>

Agreed. That SLH-DSA is clearly not suited for all use cases for TLS,
doesn't mean we should withhold it for those where it's acceptable.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: MLKEM or Khyber KX

[Bas Westerbaan]

BoringSSL (Chrome) generates a new keypair for each connection. We do too.
ML-KEM keygen is quite cheap anyway.

On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich 
wrote:

> Are folks generating a new key every connection or just using a
> longer-lived keypair and not re-using the random?
> ___
> 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-DSA in TLS

[Bas Westerbaan]

>
> I'm not sure I agree that there is no value. In general, we try to roll
> out new mechanisms slowly so that we get some experience with how they
> perform in the wild. Given the experience with PQ key establishment, we
> should probably have some concern that ML-DSA won't just work in all cases,
> and we'd like to find that out now, which requires some level of deployment.
>

I am well aware, and we will, as we have before.

But I think we've strayed from the original question you asked:

In particular, we should have a discussion of whether we want to
standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
towards the latter, but I, at least, would like to hear arguments to the
contrary.


I think we should at least standardize pure ML-DSA. That does not prevent
us from standardising a hybrid as well. These are independent matters.

Best,

 Bas


PS. Majority of testing can be done without hybrids. Don't run it on
production traffic. Or pad a P-256 key to the length of ML-DSA. If it's
compute we want to test, run a dummy ML-DSA verify. If we do want the full
thing with a hybrid, we can use an ad hoc hybrid (as CECPQ2 was ad hoc too.)




>
>
>> The proposal you sketch also requires an update at the time CRQCs are
>> near to disable the non-PQ certificates.
>>
>
> Absolutely. We're just in an asymmetrical position in that we're already
> exposed to the risk of non-PQ but not to the risk of PQ.
>
> -Ekr
>
>
>> If you have a system that cannot have an update, then you indeed need a
>> hybrid.
>>
>>
>>> In general, the client is exposed to the union of the risks of
>>> compromise of the signature algorithms it supports. Thus, in a world
>>> where the client supports: [ECDSA, ML-DSA], then compromise of either
>>> algorithm is an issue. By contrast, if the client supports [ECDSA,
>>> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
>>> result in an attack. This is of course the same logic that leads
>>> to hybrids for key establishment.
>>>
>>> An obvious response here is "if something goes wrong with ML-DSA,
>>> we'll just turn it off quickly". This is certainly true for browsers,
>>> but I'm less sure it's true for other systems. If you think that
>>> it takes a long time to disable algorithms, then it seems like
>>> that's an argument that hybrid signatures are safer.
>>>
>>> -Ekr
>>>
>>>
>>> [0] There is benefit in the servers supporting PQ ahead of time
>>> because the client will have to make a cost/benefit decision in
>>> terms of breakage, and the more servers support PQ, the easier
>>> this decision is.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> It's uncomfortable though if the first blessed SignatureScheme would be
>>>> a non-hybrid. (Also regulators don't make the distinction between
>>>> authentication and encryption, but at least most of them insist on hybrids
>>>> for both though.)
>>>>
>>>> So I agree it makes sense to set recommended=N for now.
>>>>
>>>> Best,
>>>>
>>>>  Bas
>>>>
>>>>
>>>>
>>>> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:
>>>>
>>>>> I think an adoption call is a bit premature here. We've got some time,
>>>>> especially in the WebPKI setting.
>>>>>
>>>>> In particular, we should have a discussion of whether we want to
>>>>> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
>>>>> towards the latter, but I, at least, would like to hear arguments to the
>>>>> contrary.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson >>>> 40ericsson@dmarc.ietf.org> wrote:
>>>>>
>>>>>> Let’s have an adoption call asap.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I made some minor suggestions
>>>>>> https://github.com/bwesterb/tls-mldsa/pull/3
>>>>>>
>>>>>>
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Alicja Kario 
>>>>>> *Date: *Wednesday

[TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06

[Bas Westerbaan]

Nit: we have two HPKE IDs registered. (X25519Kyber768Draft00 at KEM id
0x0030 and X-Wing at 0x647a).

Otherwise I agree with Eric and Rich.

Best,

 Bas

On Mon, Nov 11, 2024 at 2:15 PM Eric Rescorla  wrote:

> Unlike TLS itself defines cipher suites, ECH just depends on the HPKE
> registry from RFC 9180 (
> https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids). While
> there aren't currently any PQ-safe HPKE IDs registered, we do have
> proposals for them (
> https://www.ietf.org/archive/id/draft-connolly-cfrg-hpke-mlkem-04.html)
> and when one is registered, ECH should "just work", so I don't think there
> probably is an action here for ECH.
>
> -Ekr
>
>
> On Mon, Nov 11, 2024 at 1:48 AM Gianpaolo Angelo Scalone, Vodafone
>  wrote:
>
>> Hi, not sure if this has to go under ECH or under DNS SVCB/HTTPS RR, but
>> given current status ECH will provide E2E privacy today , but is not
>> Quantum Safe.
>>
>> Would it make sense to have a specific section on making ECH quantum safe
>> and provide privacy also in perspective?
>>
>> C2 General
>> ___
>> 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: [Pqc] Re: QUIC, amplification and PQC message sizes (was: Bytes server -> client)

[Bas Westerbaan]

On Mon, Nov 11, 2024 at 12:51 PM Michael Richardson 
wrote:

>
> Christian Huitema  wrote:
> > To summarize, the QUIC handshake will require an extra RTT:
>
> > * if the server flight is larger than 3 times the Client Hello,
> > * if the Client Hello is larger than 12,000 bytes,
> > * if the Server Hello is larger than 12,000 bytes.
>
> > If would be very nice to have PQC variants that fit inside that
> budget.
>
> might it be worth doing a "legacy" crypto operation first, even if that is
> broken by a CRQC, if the time to break it is less than the RTT?
>

The attacker has more time than just the RTT: you can perform a key
recovery on any of the classical signatures within their validity time, and
have the recovered private key ready to go for the next active attack.

A proposal in similar spirit would be to keep using classical signatures
for leaf and/or intermediate certificates, but reduce their validity time
significantly. You still need a PQ signature from the root. Thus in the
end, the saving would be similar as pursuing intermediate elission, but
it's much more frail.

Stepping back, I'm uncomfortable with the "quantum computers will take a
long time to break a single key". That'll be the case for the first key
broken. However, we need continued exponential progress in quantum
computing if we are to reach a CRQC in our lifetimes. It'd be strange to
expect that progress stops then.

Best,

 Bas



>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*
>
>
>
> --
> Pqc mailing list -- p...@ietf.org
> To unsubscribe send an email to pqc-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Bas Westerbaan]

That was before the release of FIPS 203.

On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly 
wrote:

> Two meetings ago there was a consistent vibe in the room that
> Recommend'ing any PQ parameters, hybrid or no, was premature; has that
> changed?
>
> On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario  wrote:
>
>> On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote:
>> > Hello,
>> >
>> > As discussed during the TLS session at IETF 121, we would like
>> > to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem.
>>
>> Very much in favour of adopting this draft.
>>
>> > There are a few open questions that need to be addressed:
>> >
>> > 1. **Alignment of NamedGroup X25519MLKEM768** with the order of
>> > shared secrets, as per Section 3.2 of
>> > draft-ietf-tls-hybrid-design.
>> >- I suggest updating the name to mlkem768_x25519, while
>> > keeping the codepoint unchanged (if that is acceptable). If
>> >  this change is made, I also recommend changing the name of
>> > Secp256r1MLKEM768 to align with x25519.
>>
>> while I'd /like/ for the name to remain, I'm not opposed to changing it,
>> especially if we make it so that the order in the name matches the order
>> in the shares and derived secrets
>> (I've already seen names all over the place for the codepoint, so the
>> name isn't consistent across different implementations already...)
>>
>> no preference for mlkem768_x25519 vs MLKEM768X25519 vs mlkem768x25519
>>
>> OTOH, if NIST doesn't change their stance, then having name represent the
>> order, and there still being interest in hybrid at a time when P-256 and
>> P-384 are not approved, would give a clear description for the new point,
>> new name, with the order reversed
>>
>> Given how widely it is already deployed, I'm very strongly opposed to
>> changing the codepoint or its meaning.
>>
>> > 2. **Changing the order of shares in Secp256r1MLKEM768**.
>> >- The current order is based on requirements from
>> >  SP800-56C-r2, and it was chosen to facilitate the migration of
>> >  the TLSv1.3
>> >  handshake in a flow requiring FIPS certification. Although
>> >  the switched order of shares aligns with FIPS, it necessitates
>> >  the re-certification of the cryptographic module. The
>> >  current order supports modules that are already deployed in the
>> >  field.
>> >  My (slight) personal preference would be to proceed with
>> >  adoption but switch the order only if NIST relaxes the
>> >  requirement
>> >  regarding the order of shares in SP800-56C-r2, which we
>> >  know is under discussion. Otherwise, I believe the current
>> >  choice
>> >  better supports migration to non-hybrid MLKEM, but I would
>> >  appreciate feedback on this decision (ideally from others who
>> >  have a requirement for FIPS).
>>
>> I'm opposed to changing the order. The way it is right now (for all three
>> codepoints) is good. Especially speaking as a vendor intersted in FIPS
>> compliance.
>>
>> Even *if* NIST relaxes the requirements, we don't know *when* that will
>> happen.
>> We have explicit confirmation that as long as the first algorithm is
>> FIPS approved, then the whole SP800-56Cr2 scheme is, so I think, for FIPS
>> compliance, we're good.
>>
>> If in the future it will turn out that we want a hybrid with ML-KEM-1024
>> first, registering it won't be too much work.
>> (Or NIST may say that ML-KEM is fine as the second one iff the first
>> shared secret was "formely NIST approved algorithm", we don't know.)
>>
>> And even without it, we already have codepoints for pure ML-KEM of all
>> sizes.
>>
>> So, I think the three codepoints are the minimal set to handle:
>>  * the general Internet
>>  * FIPS compliance
>>  * Common Criteria Protection Profile compliance
>>
>> with as little friction to roll them out as possible.
>>
>> I think this is the main thing we should have in mind: we want people
>> using PQC key exchanges as soon as possible as widely as possible.
>>
>> > 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**.
>>
>> Since all three (secp256r1, secp384r1, and x25519) are RECOMMENDED=Y,
>> I think we should set "Y" for those three algorithms too.
>>
>> > Additionally, we plan to register Secp384r1MLKEM1024, but I
>> > believe this should only be done once we reach a consensus
>> > regarding
>> > point 2.
>> >
>> > Thank you!
>>
>> --
>> 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: ML-DSA in TLS

[Bas Westerbaan]

Alicja, John, thanks for your review.

Onto Alicja's open comments:

 - illegal_parameter alert if the peer used algorithm not advertised, or
>signature algorithm does not match the certificate
>  - decrypt_error when verification of the signature failed


Good points, but these stipulations are not specific to ML-DSA and belong,
if not already present, in rfc8446(bis).

Best,

 Bas

On Wed, Oct 23, 2024 at 9:44 PM Tim Hollebeek  wrote:

> Agree completely, the only thing that can go wrong with this draft is
> scope creep.
>
>
>
> -Tim
>
>
>
> *From:* Deirdre Connolly 
> *Sent:* Wednesday, October 23, 2024 3:22 PM
> *To:* Alicja Kario 
> *Cc:* Bas Westerbaan ; 
> 
> *Subject:* [TLS] Re: ML-DSA in TLS
>
>
>
> I would rather have a separate I-D for anything beyond ML-DSA (and thanks,
> this is great!)
>
>
>
> On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario  wrote:
>
> On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote:
> > Let’s have an adoption call asap.
> >
> > I made some minor suggestions
> > https://github.com/bwesterb/tls-mldsa/pull/3
>
> good catch on the signature_algorithms_cert part!
>
> and on that front, I wonder if we shouldn't also include SLH-DSA
> codepoints as those may be used by the CA certs, even if the EE use
> ML-DSA...
>
> or make it a separate I-D?
>
> > John
> >
> > From: Alicja Kario 
> > Date: Wednesday, 23 October 2024 at 19:59
> > To: Bas Westerbaan 
> > Cc: 
> > Subject: [TLS] Re: ML-DSA in TLS
> >
> > Hi,
> >
> > Thanks for the draft, will definitely be helpful.
> >
> > Few issues:
> >  * The range 0x0900-0x0903 is reserved for backwards compatibility
> >I think it will be better to continue the numbering in the 0x08..
> space
> >  * the must in "must use id_ML-DSA(...)" probably should be capitalised,
> as
> >if it doesn't match, the connection needs to be aborted
> >
> > open question is if we should document error handling explicitly:
> >  - illegal_parameter alert if the peer used algorithm not advertised, or
> >signature algorithm does not match the certificate
> >  - decrypt_error when verification of the signature failed
> >
> > On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
> >> Hi all,
> >>
> >> Unless I overlooked something, we don't have a draft out to
> >> assign a SignatureAlgorithm to ML-DSA for use in TLS.
> >>
> >> It's two days past the I-D submission deadline, but I wanted to
> >> point you to a short draft we put together to fill this gap.
> >>
> >>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0
> <https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html>
> >>
> >> So far, I see only one open question: whether to set a non-zero
> >> context string.
> >>
> >> Best,
> >>
> >>  Bas
> >>
> >>
> >>
> >
>
> --
> 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] ML-DSA in TLS

[Bas Westerbaan]

Hi all,

Unless I overlooked something, we don't have a draft out to assign a
SignatureAlgorithm to ML-DSA for use in TLS.

It's two days past the I-D submission deadline, but I wanted to point you
to a short draft we put together to fill this gap.

https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html

So far, I see only one open question: whether to set a non-zero context
string.

Best,

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

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

Today for the WebPKI there is no security benefit to enabling post-quantum
certificates (in stark contrast with post-quantum key agreement.) On the
other hand, there is a big cost with extra bytes on the wire. As it stands,
we do not intend to enable post-quantum certificates by default before the
CRQC is near. At that point, there is little value in hybrid certificates.
There is value in having post-quantum certificates ready-to-go now (without
flipping the switch.) And for that pure ML-DSA makes more sense.

It's uncomfortable though if the first blessed SignatureScheme would be a
non-hybrid. (Also regulators don't make the distinction between
authentication and encryption, but at least most of them insist on hybrids
for both though.)

So I agree it makes sense to set recommended=N for now.

Best,

 Bas



On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:

> I think an adoption call is a bit premature here. We've got some time,
> especially in the WebPKI setting.
>
> In particular, we should have a discussion of whether we want to
> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
> towards the latter, but I, at least, would like to hear arguments to the
> contrary.
>
> -Ekr
>
>
> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson  40ericsson@dmarc.ietf.org> wrote:
>
>> Let’s have an adoption call asap.
>>
>>
>>
>> I made some minor suggestions
>> https://github.com/bwesterb/tls-mldsa/pull/3
>>
>>
>>
>> John
>>
>>
>>
>> *From: *Alicja Kario 
>> *Date: *Wednesday, 23 October 2024 at 19:59
>> *To: *Bas Westerbaan 
>> *Cc: *
>> *Subject: *[TLS] Re: ML-DSA in TLS
>>
>> Hi,
>>
>> Thanks for the draft, will definitely be helpful.
>>
>> Few issues:
>>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>>I think it will be better to continue the numbering in the 0x08.. space
>>  * the must in "must use id_ML-DSA(...)" probably should be capitalised,
>> as
>>if it doesn't match, the connection needs to be aborted
>>
>> open question is if we should document error handling explicitly:
>>  - illegal_parameter alert if the peer used algorithm not advertised, or
>>signature algorithm does not match the certificate
>>  - decrypt_error when verification of the signature failed
>>
>> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
>> > Hi all,
>> >
>> > Unless I overlooked something, we don't have a draft out to
>> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
>> >
>> > It's two days past the I-D submission deadline, but I wanted to
>> > point you to a short draft we put together to fill this gap.
>> >
>> >
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0
>> <https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html>
>> >
>> > So far, I see only one open question: whether to set a non-zero
>> > context string.
>> >
>> > Best,
>> >
>> >  Bas
>> >
>> >
>> >
>>
>> --
>> 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%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%3D&reserved=0
>> <http://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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

Hi Eric,


> Hi Bas,
>
> I'm not sure I agree with this analysis, but perhaps it depends on
> what you mean by "ready-to-go".
>
> I would think that the natural thing to do here is to get fairly
> widespread deployment of support for PQ certificates but then prefer
> non-PQ certificates. I.e.,
>
> 1. Clients would support both PQ and non-PQ certificates.
> 2. Servers would have both PQ and non-PQ certificates, but would
>provide the non-PQ certificate if the client supported it.
>
> This would enable clients to decide that the risk from non-PQ was high
> (as you say "the CRQC is near") and disable non-PQ.  Note that it
> doesn't matter whether the server supports non-PQ as well, as the
> security benefit comes from the client refusing it [0]. Do we agree so
> far?
>

Unless a CRQC is near, there is no value, only risk to advertise support
for ML-DSA. Thus I'd say clients would add support, but not advertise it.
That requires an update at the time CRQC are near. The proposal you sketch
also requires an update at the time CRQCs are near to disable the non-PQ
certificates.

If you have a system that cannot have an update, then you indeed need a
hybrid.


> In general, the client is exposed to the union of the risks of
> compromise of the signature algorithms it supports. Thus, in a world
> where the client supports: [ECDSA, ML-DSA], then compromise of either
> algorithm is an issue. By contrast, if the client supports [ECDSA,
> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
> result in an attack. This is of course the same logic that leads
> to hybrids for key establishment.
>
> An obvious response here is "if something goes wrong with ML-DSA,
> we'll just turn it off quickly". This is certainly true for browsers,
> but I'm less sure it's true for other systems. If you think that
> it takes a long time to disable algorithms, then it seems like
> that's an argument that hybrid signatures are safer.
>
> -Ekr
>
>
> [0] There is benefit in the servers supporting PQ ahead of time
> because the client will have to make a cost/benefit decision in
> terms of breakage, and the more servers support PQ, the easier
> this decision is.
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> It's uncomfortable though if the first blessed SignatureScheme would be a
>> non-hybrid. (Also regulators don't make the distinction between
>> authentication and encryption, but at least most of them insist on hybrids
>> for both though.)
>>
>> So I agree it makes sense to set recommended=N for now.
>>
>> Best,
>>
>>  Bas
>>
>>
>>
>> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:
>>
>>> I think an adoption call is a bit premature here. We've got some time,
>>> especially in the WebPKI setting.
>>>
>>> In particular, we should have a discussion of whether we want to
>>> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
>>> towards the latter, but I, at least, would like to hear arguments to the
>>> contrary.
>>>
>>> -Ekr
>>>
>>>
>>> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson >> 40ericsson@dmarc.ietf.org> wrote:
>>>
>>>> Let’s have an adoption call asap.
>>>>
>>>>
>>>>
>>>> I made some minor suggestions
>>>> https://github.com/bwesterb/tls-mldsa/pull/3
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> *From: *Alicja Kario 
>>>> *Date: *Wednesday, 23 October 2024 at 19:59
>>>> *To: *Bas Westerbaan 
>>>> *Cc: *
>>>> *Subject: *[TLS] Re: ML-DSA in TLS
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the draft, will definitely be helpful.
>>>>
>>>> Few issues:
>>>>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>>>>I think it will be better to continue the numbering in the 0x08..
>>>> space
>>>>  * the must in "must use id_ML-DSA(...)" probably should be
>>>> capitalised, as
>>>>if it doesn't match, the connection needs to be aborted
>>>>
>>>> open question is if we should document error handling explicitly:
>>>>  - illegal_parameter alert if the peer used algorithm not advertised, or
>>>>signature algorithm does not match the certificate
>>>>  - decrypt_error when verification of the signature failed
>

[TLS] Re: TLS client puzzles revival

[Bas Westerbaan]

This is a bit of a tangent, but PQC seems to have the opposite effect of
what you might think if you use fast implementations.

A typical ClientHello with X25519 is, say, about 350 bytes. A modern Intel
core can do about 20,000 X25519 keyshare and P-256 sign together per
second. That's 56 Mbit/s. Thus you need at least 18 cores per gigabit/s of
ClientHello.

ML-KEM-768 encapsulation is vast: around 50,000/s per core. If we add that
on top of X25519, we can process about 14,000 ClientHello's. Those are
bigger at 1534 bytes. Thus we process hybrid ClientHello's at 171Mbit/s.
Thus you need about 6 cores per gigabit/s of ClientHello.

Now, adding post-quantum signatures will depress that number again. It
depends on which we'll end up using. With ML-DSA-44 it'll still be higher
than 73 Mbit/s. Here we're not accounting for the new bottleneck on server
upload which these post-quantum signatures add. But that's a bandwidth
issue — not a compute one.

Best,

 Bas


On Fri, Nov 1, 2024 at 9:27 AM John Mattsson  wrote:

> I would like to see more discussion and work on DoS protection. I think
> many services are quite unprepared for massive DDoS attacks. Si vis pacem,
> para bellum.
>
>
>
> >so burning CPU on a hash puzzle in those contexts is unappealing
>
> My understanding is that the server would only use the puzzle when it
> thinks it is under attacks, so I think the impact when not under attack is
> negliable. That said introducing I agree that something like this would
> take a long time.
>
>
>
> I agree that the best current defense is to swith to the fastest
> state-of-the art algorithms, which are x25519 and Ed25519. This becomes
> even more important i the future when most TLS connections will do hybrid
> ECH, and hybrid key exchange and maybe hybrid signing/verification in
> certs and CRL/OCSP.
>
>
> Regarding batch signatures ,I found the performance figures Nina Bindel
> presented in a NIST PQC Seminar interesting [1].
>
>
>
> Cheers,
>
> John
>
>
>
> [1]
>
>
> https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/pqc-seminars/presentations/7-batch-me-if-you-pq-sign-07212023.pdf
>
>
>
> https://www.nist.gov/video/pqc-seminar-batch-me-if-you-pq-sign
>
>
>
>
>
> *From: *David Benjamin 
> *Date: *Thursday, 31 October 2024 at 16:53
> *To: *David Venhoek 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] Re: TLS client puzzles revival
>
> I'm not very excited about this DoS approach. Many user-facing clients run
> on battery-constrained devices, so burning CPU on a hash puzzle in those
> contexts is unappealing. Before we resort to mitigating a server's high
> energy cost by increasing energy cost across the board, we should exhaust
> avenues for decreasing the energy cost across the board. In particular...
>
>
>
> I don't think the 10x figure for RSA certificates matters here. Any
> approach with a new extension, like client puzzles, will only be available
> in newer clients. This means, as a baseline, you're already assuming the
> server can reduce service to older clients that don't support
> the extension. (Or deny service if all supported clients have it.) Rather
> than ask clients to implement this extension, you could instead ask newer
> clients to support ECC-based server certificates[*], and then reduce or
> deny service to older RSA-requiring clients instead. Client puzzle's DoS
> capacity is only meaningful when you're already using more efficient server
> credentials.
>
>
>
> If, even with ECC-based server certificates, DoS is a concern, I would
> suggest reviving draft-ietf-tls-batch-signing instead. That was adopted by
> the WG, but it was parked because interest (including from my end) waned.
> But I would be much more interested in building that than in building an
> extension whose sole purpose is to burn CPU. Batch signing means the cost
> of the server signature is basically irrelevant. If you get a storm of
> requests from batch-capable clients, they all can be serviced with a single
> signature. Even if you only have the capacity to globally generate one
> signature at a time, you can still batch together all your incoming
> connections to be serviced by that one batch.
>
>
>
> David
>
>
>
> [*] Of course, if you are a hosting provider whose customers provide keys
> and certificates, they might not have provided an ECC credential. But, in
> that scenario, encouraging ECC credential from your customers is a much
> more impactful DoS capacity win because ECC-capable clients are already
> widely deployed.
>
>
>
> On Thu, Oct 31, 2024 at 10:14 AM David Venhoek  wrote:
>
> Dear TLS working group,
>
> Given recent experiences by some parties of DDoS attacks that abuse
> the TLS handshake to force a server into spending significant
> computational resources (see Eirik Øverby's talk at
> https://www.youtube.com/watch?v=pBNMWvfL05g for an example), we have
> decided to give adding handshake DDoS protections another go. The
> draft is available at
> https://github.com/tweedegolf/dr

[TLS] Re: [EXTERNAL] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

[Bas Westerbaan]

If we want a new name, then I propose kex_hint — keyshare is a DH concept.
I'm happy with all proposals so far though — we have been bad at naming,
but fortunately consistently so.

On Wed, Sep 25, 2024 at 7:06 PM Andrei Popov  wrote:

> I think it's more important to keep consistent naming between TLS and DNS
> than to come up with some perfect terminology for this concept.
> Publishing the full list of groups supported by the server also appears to
> be more useful: any partial list is but a partial solution to the problem.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Stephen Farrell 
> Sent: Wednesday, September 25, 2024 9:30 AM
> To: David Benjamin 
> Cc: TLS List 
> Subject: [EXTERNAL] [TLS] Re: Consensus Call: early code point request for
> draft-ietf-tls-key-share-prediction
>
>
> Two quick bits...
>
> On 9/25/24 16:59, David Benjamin wrote:
>
> > If you publish L1+oddballs for all routes to T1 and the client then
> > predicts oddballs to S1, *this is not a failure*.
>
> Yeah, I was imprecise again:-) Yes HRR will kick in, but I think that
> scenario highlights a failure for this spec to help.
>
> That said...
>
> >> In that case ISTM the right thing is to publish L1 for T1 and
> >> L1+oddballs
> > for T2.
> >
> > That would *also* suboptimal for T1. Suppose the client supports
> > oddballs, saw L1, and predicted something in L1. Then they connect to
> > S2 but actually
> > S2 really wants oddballs when the client supports it. Then S2 will HRR.
>
> With s/would/could/ that's a fair point, though I don't think we're trying
> to represent that "really wants...when"
> via this spec, so one could argue that's out of scope.
>
> Anyway, I reckon I've made my point, if others agree they'll chime in, if
> not, I assume we'll stick with the current presentation syntax, maybe with
> a bit more clarification, and the DEs will like that or not.
>
> Cheers,
> S.
>
> ___
> 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: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

[Bas Westerbaan]

 Please let the list know by 8 October 2023 if you support this “early"
> allocation.
>

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

[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-tlsflags

[Bas Westerbaan]

I support this.

On Fri, Sep 27, 2024 at 9:00 PM Sean Turner  wrote:

> Hi! We paused progression of draft-ietf-tls-tlsflags until we had
> implementations. We (the chairs) have gotten requests for an early IANA
> code point; if you remember draft-ietf-tls-cross-sni-resumption, a WG I-D
> that is now expired, and draft-jhoyla-req-mtls-flag, a individual I-D,
> would both need this code point.  Note that like draft-ietf-tls-dtls-rrc,
> draft-ietf-tls-tlsflags also creates a new sub-registry, but IANA cannot
> create a temporary registry and then manage it for us. We will do that in
> the WG/I-D; there is not much to manage because at this point it’s only two
> values. With that said ….
>
> We (the Chairs) would like to determine whether there is consensus to
> request an early code point request for "tls_flags” in the TLS
> ExtensionType Values registry registry; see Section 4 of the I-D [0].  The
> point of this consensus call is to determine whether you think this I-D is
> stable enough to request a code point from the DEs.  Please let the list
> know by 11 October 2024 if you support this request.
>
> Cheers,
> spt
> (as TLS Co-Chair)
>
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> ___
> 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] Bytes server -> client

[Bas Westerbaan]

Hi all,

Just wanted to highlight a blog post we just published.
https://blog.cloudflare.com/another-look-at-pq-signatures/  At the end we
share some statistics that may be of interest:

On average, around 15 million TLS connections are established with
> Cloudflare per second. Upgrading each to ML-DSA, would take 1.8Tbps, which
> is 0.6% of our current total network capacity. No problem so far. The
> question is how these extra bytes affect performance.
> Back in 2021, we ran a large-scale experiment to measure the impact of big
> post-quantum certificate chains on connections to Cloudflare’s network over
> the open Internet. There were two important results. First, we saw a steep
> increase in the rate of client and middlebox failures when we added more
> than 10kB to existing certificate chains. Secondly, when adding less than
> 9kB, the slowdown in TLS handshake time would be approximately 15%. We felt
> the latter is workable, but far from ideal: such a slowdown is noticeable
> and people might hold off deploying post-quantum certificates before it’s
> too late.



Chrome is more cautious and set 10% as their target for maximum TLS
> handshake time regression. They report that deploying post-quantum key
> agreement has already incurred a 4% slowdown in TLS handshake time, for the
> extra 1.1kB from server-to-client and 1.2kB from client-to-server. That
> slowdown is proportionally larger than the 15% we found for 9kB, but that
> could be explained by slower upload speeds than download speeds.


> There has been pushback against the focus on TLS handshake times. One
> argument is that session resumption alleviates the need for sending the
> certificates again. A second argument is that the data required to visit a
> typical website dwarfs the additional bytes for post-quantum certificates.
> One example is this 2024 publication, where Amazon researchers have
> simulated the impact of large post-quantum certificates on data-heavy TLS
> connections. They argue that typical connections transfer multiple requests
> and hundreds of kilobytes, and for those the TLS handshake slowdown
> disappears in the margin.


> Are session resumption and hundreds of kilobytes over a connection typical
> though? We’d like to share what we see. We focus on QUIC connections, which
> are likely initiated by browsers or browser-like clients. Of all QUIC
> connections with Cloudflare that carry at least one HTTP request, 37% are
> resumptions, meaning that key material from a previous TLS connection is
> reused, avoiding the need to transmit certificates. The median number of
> bytes transferred from server-to-client over a resumed QUIC connection is
> 4.4kB, while the average is 395kB. For non-resumptions the median is 7.8kB
> and average is 551kB. This vast difference between median and average
> indicates that a small fraction of data-heavy connections skew the average.
> In fact, only 15.8% of all QUIC connections transfer more than 100kB.


> The median certificate chain today (with compression) is 3.2kB. That means
> that almost 40% of all data transferred from server to client on more than
> half of the non-resumed QUIC connections are just for the certificates, and
> this only gets worse with post-quantum algorithms. For the majority of QUIC
> connections, using ML-DSA as a drop-in replacement for classical signatures
> would more than double the number of transmitted bytes over the lifetime of
> the connection.


> It sounds quite bad if the vast majority of data transferred for a typical
> connection is just for the post-quantum certificates. It’s still only a
> proxy for what is actually important: the effect on metrics relevant to the
> end-user, such as the browsing experience (e.g. largest contentful paint)
> and the amount of data those certificates take from a user’s monthly data
> cap. We will continue to investigate and get a better understanding of the
> impact.


Best,

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

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

On Thu, Oct 24, 2024 at 8:55 AM John Mattsson 
wrote:

> I have gotten the understanding, see e.g., [1-2], that the WebPKI might
> wait for FN-DSA or wait even longer for something like MAYO, UOC, HAWK, and
> SQISign.
>

>From a performance perspective MAYO looks really nice, but we'd be really
pushing our luck on its security given its age. We must have a plan B.
Using UOV for SCTs doesn't seem as risky, but that doesn't cut enough bytes.

I would like us to consider more drastic directions to solve the
post-quantum authentication problem, such as for instance
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/

Best,

 Bas

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Bas Westerbaan]

I do not support adoption.

On Tue, Nov 5, 2024 at 5:27 PM Sean Turner  wrote:

> REQUEST: Let’s not rehash all the context.  It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann suggested that another way to “fix” TLS was to specify a
> version of TLS that indicates a “known-good config drawn from the maybe 10
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for
> Long-term Support”; see [1]. There was some list discussion; see [2]. Peter
> asked us about adopting the I-D; see [3]. He made changes based on that
> feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the
> sense of the room was to not adopt the I-D; see [5]. Progress on this
> document was paused while the WG worked on TLS 1.3. Once RFC 8447 was
> published, a code point was assigned for the “tls-lts” extensions; see [6]
> and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2
> [8][9] we want to make sure that the working group sentiment has not
> changed over time so we are running an adoption call for TLS-LTS.
>
> MESSAGE: This message is to judge consensus on whether there is support to
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this draft, please
> send a message to the list and indicate why.  This call will close on
> November X, 2024.
>
> Thanks,
> spt
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> [6]
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
>Thanks to Peter because he helped us iron out the
>wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> ___
> 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: Bytes server -> client

[Bas Westerbaan]

>
>
> > On average, around 15 million TLS connections are established with
> > Cloudflare per second. Upgrading each to ML-DSA, would take
> > 1.8Tbps, which is 0.6% of our current total network capacity. No
> > problem so far. The question is how these extra bytes affect
> > performance.
> > Back in 2021, we ran a large-scale experiment to measure the
> > impact of big post-quantum certificate chains on connections to
> > Cloudflare’s network over the open Internet. There were two
> > important results. First, we saw a steep increase in the rate of
> > client and middlebox failures when we added more than 10kB to
> > existing certificate chains.
> >
> Would you be willing to share some numbers around the increase in
> failures?


Details are in our 2021 blog post
https://blog.cloudflare.com/sizing-up-post-quantum-signatures/


> What do you think might've been the cause for increased
> failures at clients and middleboxes?

One hypothesis I have is
> TLS-related DPI might allocate a certain buffer to capture the
> handshake, which was now being crossed.
>

That could well be one cause. 16MB chains are allowed by the spec, but most
TLS libraries reject shorter chains. Back in 2021 I saw that OpenSSL
rejected chains longer than 106kB, and Go rejects them if they're longer
than 64kB. That's still well above 13kB, but there could be middleboxes
that picked a shorter buffer length.

Note that this is problematic for those that only want to deploy a single
certificate "chameleon hybrids".

Best,

 Bas


>
> Regards,
>
> Raghu Saxena
>
> ___
> 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-DSA in TLS

[Bas Westerbaan]

We have posted a -00.

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00



On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan  wrote:

> Hi all,
>
> Unless I overlooked something, we don't have a draft out to assign a
> SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to point you
> to a short draft we put together to fill this gap.
>
> https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
>
> So far, I see only one open question: whether to set a non-zero context
> string.
>
> Best,
>
>  Bas
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

On Fri, Nov 15, 2024 at 5:09 PM Rebecca Guthrie  wrote:

> I also support WG adoption.
>
>
>
> One suggestion in the Introduction:
>
>
>
> "ML-DSA [FIPS204] is a post-quantum signature schemes standardised by
> NIST. It is a module-lattice based scheme." -> "ML-DSA is a
> module-lattice-based digital signature algorithm standardised by NIST in
> [FIPS204]."
>
>
>
> And one suggestion in Section 3:
>
>
>
> "Note that these are the pure versions and should not be confused with
> prehash variants such as HashML-DSA-44 also defined in [FIPS204]." -> "Note
> that these values represent ML-DSA and not HashML-DSA [FIPS204, Section
> 5.4]."
>
>
>
> Those who read this later who have not been following mailing list
> discussions might not understand what is meant by "pure versions" since the
> word "pure" is not used in FIPS 204- so it is probably best to just call
> these ML-DSA and HashML-DSA. It may also be helpful to include a pointer to
> the specific section in FIPS 204 where HashML-DSA is defined.
>

Thank you — made changes accordingly:
https://github.com/bwesterb/tls-mldsa/commit/c38a19c996fe064d40fc8e0a802a0a4132aee9b8


>
>
> Rebecca Guthrie
>
> she/her
>
> Center for Cybersecurity Standards (CCSS)
>
> Cybersecurity Collaboration Center (CCC)
>
> National Security Agency (NSA)
>
>
>
> *From:* John Mattsson 
> *Sent:* Friday, November 15, 2024 9:41 AM
> *To:* Alicja Kario ; Bas Westerbaan  40cloudflare@dmarc.ietf.org>
> *Cc:*  
> *Subject:* [TLS] Re: ML-DSA in TLS
>
>
>
> > Very happy to see it.
> >
> >I'm for workgroup adoption of it.
>
>
>
> +1
>
>
>
> *From: *Alicja Kario 
> *Date: *Friday, 15 November 2024 at 15:34
> *To: *Bas Westerbaan 
> *Cc: *
> *Subject: *[TLS] Re: ML-DSA in TLS
>
> Very happy to see it.
>
> I'm for workgroup adoption of it.
>
> On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> > https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
> >
> >
> >
> > On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan 
> wrote:
> > Hi all,
> >
> > Unless I overlooked something, we don't have a draft out to
> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
> >
> > It's two days past the I-D submission deadline, but I wanted to
> > point you to a short draft we put together to fill this gap.
> >
> > https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
> >
> > So far, I see only one open question: whether to set a non-zero
> > context string.
> >
> > Best,
> >
> >  Bas
> >
> >
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: https://www.redhat.com/en/global/czech-republic?oh=www.cz.redhat.com
> <http://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: ML-DSA in TLS

[Bas Westerbaan]

On Fri, Nov 15, 2024 at 5:18 PM John Mattsson 
wrote:

> Agree with Rebecca's comments on ML-DSA and HashML-DSA. After discussing
> ML-DSA a lot with developers, I have noticed that after being used with
> RSA and ECDSA where they needed to combine RSA and ECDSA with a hash
> function, they have a hard time to understand that ML-DSA does not need an
> additional hash function. I think it would be good to explain this for many
> readers.
>

Good point. We can add some words to that affect in LAMP's
dilithium-certificates. For this TLS document it feels a bit out of place.


>
> John
>
>
>
> *From: *Rebecca Guthrie 
> *Date: *Friday, 15 November 2024 at 17:09
> *To: *, Bas Westerbaan 
> *Cc: *John Mattsson , Alicja Kario <
> hka...@redhat.com>
> *Subject: *RE: [TLS] Re: ML-DSA in TLS
>
> I also support WG adoption.
>
>
>
> One suggestion in the Introduction:
>
>
>
> "ML-DSA [FIPS204] is a post-quantum signature schemes standardised by
> NIST. It is a module-lattice based scheme." -> "ML-DSA is a
> module-lattice-based digital signature algorithm standardised by NIST in
> [FIPS204]."
>
>
>
> And one suggestion in Section 3:
>
>
>
> "Note that these are the pure versions and should not be confused with
> prehash variants such as HashML-DSA-44 also defined in [FIPS204]." -> "Note
> that these values represent ML-DSA and not HashML-DSA [FIPS204, Section
> 5.4]."
>
>
>
> Those who read this later who have not been following mailing list
> discussions might not understand what is meant by "pure versions" since the
> word "pure" is not used in FIPS 204- so it is probably best to just call
> these ML-DSA and HashML-DSA. It may also be helpful to include a pointer to
> the specific section in FIPS 204 where HashML-DSA is defined.
>
>
>
> Rebecca Guthrie
>
> she/her
>
> Center for Cybersecurity Standards (CCSS)
>
> Cybersecurity Collaboration Center (CCC)
>
> National Security Agency (NSA)
>
>
>
> *From:* John Mattsson 
> *Sent:* Friday, November 15, 2024 9:41 AM
> *To:* Alicja Kario ; Bas Westerbaan  40cloudflare@dmarc.ietf.org>
> *Cc:*  
> *Subject:* [TLS] Re: ML-DSA in TLS
>
>
>
> > Very happy to see it.
> >
> >I'm for workgroup adoption of it.
>
>
>
> +1
>
>
>
> *From: *Alicja Kario 
> *Date: *Friday, 15 November 2024 at 15:34
> *To: *Bas Westerbaan 
> *Cc: *
> *Subject: *[TLS] Re: ML-DSA in TLS
>
> Very happy to see it.
>
> I'm for workgroup adoption of it.
>
> On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> > https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
> >
> >
> >
> > On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan 
> wrote:
> > Hi all,
> >
> > Unless I overlooked something, we don't have a draft out to
> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
> >
> > It's two days past the I-D submission deadline, but I wanted to
> > point you to a short draft we put together to fill this gap.
> >
> > https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
> >
> > So far, I see only one open question: whether to set a non-zero
> > context string.
> >
> > Best,
> >
> >  Bas
> >
> >
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: https://www.redhat.com/en/global/czech-republic?oh=www.cz.redhat.com
> <http://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: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Bas Westerbaan]

Nit: second paragraph of section 3 starts with "While the industry is
waiting for NIST to finish standardization". That's not true anymore.

Otherwise it's good to go.

On Tue, Dec 3, 2024 at 10:28 PM Sean Turner  wrote:

> This is the working group last call for TLS 1.2 is in Feature Freeze.
> Please review draft-ietf-tls-tls12-frozen [1] and reply to this thread
> indicating if you think it is ready for publication or not.  If you do not
> think it is ready please indicate why.  This call will end on December 17,
> 2024.
>
> Cheers,
> spt
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Bas Westerbaan]

Didn't CNSA 2 only allow hybrids if there is no alternative? There is a
codepoint for MLKEM1024 in TLS now.

On Mon, Jan 6, 2025 at 9:57 AM Kris Kwiatkowski  wrote:

> Sure, but for the record the same applies to SecP3841MLKEM1024
>
>
> I think the main motivation for ECDH/P-384 is CNSA compliance, so I don't
> think it is "the same applies". Yes,
> it is slower than x25519 or ECDH/p256.
> ___
> 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] Fwd: [pqc-forum] Recommendations for Key-Encapsulation Mechanisms | Draft SP 800-227 is Available for Comment

[Bas Westerbaan]

This might be of interest to some.

-- Forwarded message -
From: 'Moody, Dustin (Fed)' via pqc-forum 
Date: Tue, Jan 7, 2025 at 4:15 PM
Subject: [pqc-forum] Recommendations for Key-Encapsulation Mechanisms |
Draft SP 800-227 is Available for Comment
To: pqc-forum 


The initial public draft of NIST Special Publication (SP) 800-227,
*Recommendations
for Key-Encapsulation Mechanisms
*,
is now available for public comment.

NIST recently published Federal Information Process Standard (FIPS)
203, *Module-Lattice-Based
Key-Encapsulation Mechanism Standard
*,
to update its cryptographic standards with an algorithm designed to provide
protection from quantum attacks. In addition, NIST will select one or two
additional quantum-resistant key-encapsulation mechanisms (KEMs) for
standardization. To provide guidance on using KEMs, NIST is introducing SP
800-227, *Recommendations for Key-Encapsulation Mechanisms*. This draft
document describes the basic definitions, properties, and applications of
KEMs. It also provides recommendations for implementing and using KEMs in a
secure manner.

The public comment period is open through *March 7, 2025*. See the *publication
details
*
for
a copy of the draft and instructions for submitting comments.

NIST will also hold a *virtual Workshop on Guidance for KEMs
*
on
February 25-26, 2025, to gather additional feedback on SP 800-227.


Dustin Moody
NIST PQC

-- 
You received this message because you are subscribed to the Google Groups
"pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to pqc-forum+unsubscr...@list.nist.gov.
To view this discussion visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH0PR09MB8667B8EBCD77C12889F5CA65E5112%40PH0PR09MB8667.namprd09.prod.outlook.com

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

[TLS] Re: Trust Anchor IDs and PQ

[Bas Westerbaan]

Not addressing your main question, I'd like to refine your sketched
migration path for PQ certificates.

On the negative side, I think it's not clear whether we'll reach 4 (clients
stop advertising traditoinal algs) when the CRQC arrives: there could well
be sufficiently many servers that don't support PQ EE certs yet.

On the positive side, I think we might be able to get more security than
you suggest before 4.

At some point in the hopefully not-too-distant future we can have browser
root programs demand that each trusted CA also offers full PQ chains and
include PQ SCTs even on traditional certificates.

A server that support PQ EE certs would then install two certificates:

  Ia. One traditional EE cert with traditional chain.
  Ib. One PQ EE cert with PQ chain.

It chooses the certificate based on whether the client supports PQ.

A server that does not support PQ EE certs would install a specially-issued
*transitional *traditional EE cert with both a traditional and PQ chain.
It's important that this *transitional* traditional EE cert is different
from the one used in the full traditional chain, and is not issued by
default: it signals that the server for the cert does not support PQ.

(*) Now, browsers wouldn't accept fully traditional chains, but they would
accept these transitional traditional EE certs, which come with PQ SCTs and
a PQ chain. For PQ security, server operators need to watch CT and check if
such transitional traditional certs are issued for their domains (as they
should watch for regular misissuances.)

There are quite a few bumps in the road:

1. Unmodified servers might not like the big PQ+trad double chain.
2. Middleboxes/clients might not like the big PQ+trad double chain (as
we've seen some evidence of).
3. Browsers need to wait for every last trusted CA to start offering these
chains, and for every last traditional EE to expire before enforcing (*).


On Sat, Feb 1, 2025 at 7:02 PM Eric Rescorla  wrote:

> Starting a new thread to keep it off the adoption call thread.
>
> I'm still forming my opinion on this topic. To that end, perhaps it's
> most useful to focus in on the post-quantum case, as I think that's
> the one that the WG finds most compelling. This message tries to work
> through that case and the impact of TAI.
>
> I apologize in advance for the length of this message, but I wanted
> show my thinking, as well as make it easier to pinpoint where I may
> have gone wrong if people disagree with this analysis.
>
>
> CURRENT SETUP
> Here's what I take as the setting now:
>
> 1. We have a set of existing CAs, numbered, 1, 2, 3...
> 2. CA_i has a trust anchor TA_i which is embedded in clients and then
>used to sign an intermediate certificate I_i.
> 3. Servers have end-entity certificates signed by intermediates,
>so we can denote server s's certificate signed by CAI i as
>EE_s_i. The chain for this certificate is (proceeding from the
>root): T_i -> I_i -> EE_s_i
>
> These all use traditional algorithms (assume there's just one
> traditional algorithm for simplicity).
>
>
> ADDING PQ
> When the CA wants to roll out PQ certificates, the following happens.
>
> 1. It generates a new separate PQ trust hierarchy, that looks like:
>Tp_i -> Ip_i -> EEp_s_i.
> 2. It cross-signs its own PQ trust anchor with its traditional trust
>anchor.
>
> So abusing notation a bit, a server would have two certificate chains:
>
> - Traditional: T_i -> I_i -> EE_s_i
> - PQ:  T_i -> Tp_i -> Ip_i -> EEp_s_i
>
> Note that I'm assuming that there's just one CA, but of course
> there could be two CAs, in which case the chains will be entirely
> distinct:
>
> - Traditional: T_i -> I_i -> EE_s_i
> - PQ:  T_j -> Tp_j -> Kp_j -> EEp_s_j
>
> This actually doesn't matter (I think) for the purposes of this
> analysis because the server can only send one EE cert.
>
>
> CERTIFICATE CHAIN NEGOTIATION
> When the client connects, it signals which algorithms it supports in
> signature_algorithms. The server then selects either the traditional
> chain or the PQ chain and sends it to the client depending on the
> algorithm. This is how we've done previous transitions so there
> shouldn't be anything new here.
>
> The entire logic above is rooted in trusting whatever traditional
> algorithm is in T_i. But the reason we want to deploy PQ certificates
> is not for efficiency (as with EC) but because we want to stop
> trusting the traditional algorithms. We do that by a two-step process
> of:
>
> 1. Clients embed Tp_i in their trust list.
> 2. At some point in the (probably distant) future, they just deprecate
>support for existing traditional trust anchors.
>
> This means that there (again simplifying) there are at least four kinds of
> clients.
>
> 1. Trust T_i. No PQ support.
> 2. Trust T_i. Traditional and PQ support.
> 3. Trust T_i and Tp_i. Traditional and PQ support.
> 4. Trust Tp_i. No traditional support.
>
> However, the server only gets the "signature_algorithms" ext

[TLS] Re: Trust Anchor IDs and PQ

[Bas Westerbaan]

>
> I think HSTS provides the basis for a more effective solution. It needs
> only to be extended with a single additional bit ("Enforce use of PQ
> signatures") and it's already well-understood by website operators.
> Managing the preload list is a bit unpleasant for browsers, but strictly
> speaking the preload list is an optional component of HSTS which is used
> only to protect the very first connection between a client and a site
> (non-preload HSTS protects all subsequent connections) and in any case I
> don't think there's an alternative for first-connection protection.
>

I just sketched one with a signal in the certificate. You point out some
valid deployment challenges, but they're far from disqualifying the
approach from the start, and we should give the general direction a chance.
PQ HSTS (plus preload)  is interesting and worthwhile for popular domains,
but it can't carry the weight for the whole Internet, as it requires
turning off classical crypto after the CRQC arrives. May I first challenge
you to turn off plain HTTP in Firefox :)?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Bas Westerbaan]

>
> Silly clarification: the TAI identifier is just a compact identifier
> for the root cert, like (making it up) a 4 byte identifier? So the
> client sends the entire list of root certs supported, so about 100, so
> 400 bytes?
>
> In that case I think you can inject it into an end-entity cert on
> issuance, and into the root representations in the trust store.


Yeah, this is an interesting alternative design. You can reduce the size
quite a bit more with simple compression techniques. See

  https://github.com/davidben/tls-trust-expressions/issues/64
  https://github.com/bwesterb/go-ncrlite



> Where
> this doesn't work out well is on cross signs where the cert can root
> to multiple places/when more than one cert is needed to cover and the
> config only has one, but this would solve a bunch of the issues for
> command line programs where the trust store format is a bag of certs
> on disk. It could also work for cross signs since the intermediates
> used are known by the CA.
>
> Sincerely,
> Watson
>
> ___
> 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: Adoption Call for Trust Anchor IDs

[Bas Westerbaan]

Last year for the interim Chris Wood asked if we could share our views on
the trust tussle. After consulting with the relevant engineers, we shared
the following four points.

   - Today server operators have very little insight in which roots clients
   trust. This makes it painful [1] to move between root certificates: we
   learn by breaking clients, and we often don’t even discover that we break a
   client.From an availability and observability perspective, it would be
   ideal for clients to signal which roots they trust. Alternatively, [as the
   present draft proposes], having clients choose one chain among several
   installed on the server would also improve availability.
   - We recognise the introduction of either such a mechanism has indirect
   consequences, which must be anticipated and carefully considered not to
   decrease security and privacy.
   - Existing signature_algorithms negotiation is sufficient to deploy
   drop-in post-quantum certificates. For practical post-quantum certificates
   a new negotiation mechanism is likely required to signal how up-to-date the
   client is. Such a mechanism might coincide with those discussed above, but
   could well be simpler.

For the balance of this email I’ll speak in a personal capacity.

To start, it’s been hard to follow this email thread. Sometimes people that
are close in values fight the hardest over small differences., don’t they?
The intensity and absolutes uttered have made it hard to engage.

Let me give it a try. Martin, thank you for sharing your thoughts in a
succinct and lucid email [2]. I’ll let you enjoy the rest of your holiday.
I agree on a lot of points with Martin: chiefly I agree that a vanishing
intersection of root programs is an outcome that should be avoided (for
more reasons than Martin states). Also I’m humming in agreement that we
should put the burden in the right place, and that we shouldn’t fix
something just because we can.

Where the argument for the bad outcomes is unconvincing to me is that it
presupposes that a trust negotiation mechanism will be deployed
ubiquitously on the server-side. I simply do not see that happening.
Deploying trust negotiation is hard (as Dennis indeed points out), and at
the very least requires multiple certificates to be installed. Also, unless
the intersection has already vanished, there is no incentive for a server
operator to bother. The long tail of server operators that do not do
certificate automation today will surely not adopt trust negotiation
either. All root programs will need to continue to take that long tail of
server operators into consideration.

Recall: we’re here because long tails are hard!

This is my current thinking, and I could well be missing a dynamic. I would
like to see the working group think through plausible scenarios. The
details of the negotiation mechanism will have an impact (eg. whether the
client advertises its trust or not). Thus I feel it’s appropriate for the
working group to adopt. We can always stop before standardizing, or not
deploy this stuff, when it becomes clear we were wrong.

Best,

 Bas

[1]
https://blog.cloudflare.com/upcoming-lets-encrypt-certificate-chain-change-and-impact-for-cloudflare-customers/
[2] https://mailarchive.ietf.org/arch/msg/tls/JZl0U7gKNYn1FWVFjzlL-qZXzF8/


On Wed, Jan 15, 2025 at 5:01 PM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> pl

[TLS] Re: [EXTERNAL] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Bas Westerbaan]

Following the feedback from the last TLS meeting at IETF@121, I have opened
> this PR to change the name from X25519MLKEM768 to MLKEM768X25519. This
> change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2).
>
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26
>

I don't believe there was consensus to swap (or keep) the name.
X25519MLKEM768 has already been assigned and deployed under that name.


> 2. **Changing the order of shares in Secp256r1MLKEM768**.
>- The current order is based on requirements from SP800-56C-r2, and it
> was chosen to facilitate the migration of the TLSv1.3
>  handshake in a flow requiring FIPS certification. Although the
> switched order of shares aligns with FIPS, it necessitates
>  the re-certification of the cryptographic module. The current order
> supports modules that are already deployed in the field.
>  My (slight) personal preference would be to proceed with adoption but
> switch the order only if NIST relaxes the requirement
>  regarding the order of shares in SP800-56C-r2, which we know is under
> discussion. Otherwise, I believe the current choice
>  better supports migration to non-hybrid MLKEM, but I would appreciate
> feedback on this decision (ideally from others who
>  have a requirement for FIPS).
>
> According to the message from
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0, NIST
> plans to permit the ordering of shares in either direction. This approach
> addresses the previously mentioned issue, so no further changes are needed
> in this regard. I believe it is now appropriate to register an additional
> code point for Secp384r1MLKEM1024, as currently outlined in the draft.
>
>
> 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**.
>
> I think this can only be done once draft if adopted. Hence, no change here
> (for now).
>

Agreed.


> > On 11/11/2024 23:14, Andrei Popov wrote:
> > I support adoption. The question of explicitly prohibiting key share
> reuse is orthogonal; this can be done in a separate document.
> I agree that the PR was submitted to change the text in the draft, but I
> think it would be better to include this text in
> draft-ietf-tls-hybrid-design. I have opened this PR
> https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/39.
>

LGTM.

> With that I hope the draft is ready for adoption.
>

Ageed.

Thanks Kris,

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