>
> 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
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, b
>
> 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 o
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 + Kyb
>
> 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 X25
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,
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
>
> 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 s
>
> 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
>
> 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
id 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 T
>
> 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 tigh
>
> 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 be
>
> 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
m
>
> 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 thi
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:
>
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-parame
y 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 stra
> > 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
>
> 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
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
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
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 t
>
> 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
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
>
> 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 a
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
> 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
>
> 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.
___
> 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.)
___
T
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
> (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
> righ
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 su
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 ag
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 sessi
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
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
>
> 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
>
> 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
> 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
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
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
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]
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 gener
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 tra
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:
>
> >
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
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
> >
> > S
>
> 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
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
wort
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
>
> 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, th
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 cus
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
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
algorith
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.
> T
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
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.
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 da
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/
>
>
>
> 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
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 secu
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 al
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 inclu
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 requ
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 define
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:*
> *
or 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
>
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 hybr
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.
&g
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
decade
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 t
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?
> ___
> 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
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 RF
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,
> >
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 wro
t;
> *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!)
>
>
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-we
ttps://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
>>
>
east, 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.
>&
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. T
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
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
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 n
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
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
pus
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
>
>
> > 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
> > pe
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.
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
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 adopti
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.
> Ple
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,
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 publ
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 sup
>
> 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
> speak
>
> 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
>
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 bet
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
1 - 100 of 110 matches
Mail list logo
