Re: [TLS] Time to first byte vs time to last byte

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-

Re: [TLS] Time to first byte vs time to last byte

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 we

Re: [TLS] Next steps for key share prediction

On Thu, Mar 7, 2024 at 2:56 PM David Benjamin wrote: > > Hi all, > > With the excitement about, sometime in the far future, possibly transitioning > from a hybrid, or to a to-be-developed better PQ algorithm, I thought it > would be a good time to remind folks that, right now, we have no way to

[TLS] Next steps for key share prediction

Hi all, With the excitement about, sometime in the far future, possibly transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I thought it would be a good time to remind folks that, right now, *we have no way to effectively transition between PQ-sized KEMs at all*. At IETF 118

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

Bas Westerbaan writes: > We think it's worth it now, but of course we're not going to keep > hybrids around when the CRQC arrives. I think this comment illustrates an important ambiguity in the "CRQC" terminology. Consider the scenario described in the following paragraph from https://blog.cr.yp.t

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

I would like to see Deirdre’s request satisfied, and a full number assigned. Regards, Uri > On Mar 7, 2024, at 09:19, Salz, Rich > wrote: > >  > This Message Is From an External Sender > This message came from outside the Laboratory. > Back to the topic at hand. I think it'd very bad if we'd

Re: [TLS] Time to first byte vs time to last byte

This is good work, but we need to be wary of getting too excited about TTLB, and then declaring performance solved. Ultimately, TTLB simply dampens the impact of postquantum by mixing in the (handshake-independent) time to do the bulk transfer. The question is whether that reflects our goals. Ulti

Re: [TLS] Time to first byte vs time to last byte

I agree the efficiency concerns are generally overstated, but this study should have measured QUIC etc, since the web pages will have all sorts of awful performance problems. But the thing you have to watch out for is when someone in the datacenter steps on the power cord or something (or DNS is wr

[TLS] Time to first byte vs time to last byte

"At the 2024 Workshop on Measurements, Attacks, and Defenses for the Web (MADweb), we presented a paper¹ advocating time to last byte (TTLB) as a metric for assessing the total impact of data-heavy, quantum-resistant algorithms such as ML-KEM and ML-DSA on real-world TLS 1.3 connections. Our paper

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

Here's a chart I sent CFRG a few weeks ago of recent claims regarding the exponent, including memory-access costs, of attacks against the most famous lattice problem, namely the "shortest-vector problem" (SVP): * November 2023: 0.396, and then 0.349 after an erratum: https://web.archive.o

Re: [TLS] TLS Digest, Vol 236, Issue 15

I do agree with Eric on that hybrid solutions may live for a very long term. Moreover, IMO, it could even become a popular way to increase crypto-agility as this can tolerate weak or seroius security flaws which may be introduced from algorithm design, key size selection, and or software coding

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

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. Currently the TLS designated experts really only look at the request itself,

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

On Thu, Mar 7, 2024 at 1:47 AM Dennis Jackson wrote: > On 07/03/2024 03:57, Bas Westerbaan wrote: > > We think it's worth it now, but of course we're not going to keep hybrids > around when the CRQC arrives. > > Sure, but for now we gain substantial security margin* against > implementation mista

Re: [TLS] Proposal: a TLS formal analysis triage panel

I'd be happy to help work on something like this, but it might make more sense to come present at UFMRG. One of the goals of the Research Group is to try and bring together experts and IETFers. Rather than adding formal process, having a low stakes way of engaging with the formal methods communit

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

On 07/03/2024 03:57, Bas Westerbaan wrote: We think it's worth it now, but of course we're not going to keep hybrids around when the CRQC arrives. Sure, but for now we gain substantial security margin* against implementation mistakes, advances in cryptography, etc. On the perf/cost side, we

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

True, Classic McEliece is not possible with the current length restrictions. FrodoKEM does not seem to get any open-access standard. Cryptographic algorithm standards behind paywalls are a cybersecurity risk. I have seen several implementations that claim to follow a paywalled standard but in re

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

Hi, Bas Westerbaan wrote: >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. I think that's up to the designated experts of the IANA registry. Agree. We plan to use hybrid key exchange as the default, but would like to offer pure M