> So, while I'm not that enthusiastic about paying a few K, I think on balance
> it's a better than doing this kind of major rearchitecture of TLS.
+1. KEMTLS is a great scheme but significantly changes the TLS state machine.
It introduces implicit and explicit auth concepts which do not exist
Hi Uri,
If we are talking NIST Level 5 (and I am assuming you are discussing mTLS),
have you calculated the total CertVerify+cert chain sizes there assuming 2 ICAs
let's say?
And would constrained devices or mediums that sweat about 5KB really be able to
support PQ KEMs and Sigs at NIST Level
er, then you will have to pay
the price of an extra round-trip to get the peer KEM public key.
-Original Message-
From: Blumenthal, Uri - 0553 - MITLL
Sent: Thursday, July 22, 2021 8:49 AM
To: Kampanakis, Panos
Cc: tls@ietf.org; Douglas Stebila ; Eric Rescorla
Subject: RE: [EXTER
/MozillaIntermediateCertsCSVReport
-Original Message-
From: internet-dra...@ietf.org
Sent: Sunday, February 13, 2022 2:34 PM
To: Bas Westerbaan ; Bytheway, Cameron
; Martin Thomson ; Kampanakis, Panos
Subject: [EXTERNAL] New Version Notification for
draft-kampanakis-tls-scas-latest-00.txt
CAUTION: This
ht?
-Original Message-
From: TLS On Behalf Of Ilari Liusvaara
Sent: Monday, February 14, 2022 2:43 AM
To: tls@ietf.org
Subject: RE: [EXTERNAL] [TLS] New Version Notification for
draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
CAUTION: This email originated from outside of the or
s you can confirm the sender and know the
content is safe.
On Sat, Feb 19, 2022 at 03:59:23AM +, Kampanakis, Panos wrote:
> - If we can assume an OOB mechanism to load the ICAs then we can
> simplify things. Practically we can assume there is no failure.
> Agreed, but I am not sure
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? Any public info
you can share about these buggy im
ments unless you can confirm the sender and know the
content is safe.
On Wed, Jul 27, 2022 at 02:27:12AM +0000, Kampanakis, Panos wrote:
> Hi Ilari,
>
> > - DTLS-level fragmentation. There are buggy implementations that
> > break if one tries this.
>
> DTLS servers have been
+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris.
From: TLS On Behalf Of Kris Kwiatkowski
Sent: Wednesday, August 17, 2022 3:31 PM
To: tls@ietf.org
Subject: RE: [EXTERNAL][TLS] WGLC for draft-ietf-tls-hybrid-design
CAUTION: This email originated from outside of the organization.
gate and memory cost is ~2^150 and
~2^90 approximately which they argue is better than AES. I think it would be
worth to call out the CoreSVP hardness and the refined estimate for Kyber-512
in the Sec Considerations section.
From: Kampanakis, Panos
Sent: Wednesday, August 17, 2022 4:26 PM
To
p. Getting this data is not straightforward, I
must say.
From: John Mattsson
Sent: Thursday, November 24, 2022 6:04 AM
To: Kampanakis, Panos ; tls@ietf.org
Cc: Bytheway, Cameron
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: New Version Notification for
draft-kampanakis-tls-scas-latest-01.txt
+1 on starting to see a little SHA-3 trickle down to TLS, IPsec, SSH and more
common protocols.
From: TLS On Behalf Of John Mattsson
Sent: Friday, January 27, 2023 6:25 AM
To: tls@ietf.org
Cc: hojarasca2022 ; Salz, Rich
Subject: RE: [EXTERNAL][TLS] about hash and post-quantum ciphers
CAUTIO
Hi David,
Interesting idea. Seems like a radical, hard change but I want to understand it
better. Some clarifications:
- Previously, in the ICA suppression draft you had correctly brought up the
challenge of keeping an up-to-date ICA cache while most browsers are not up to
date. The Merkle tre
Hi Hubert,
I am not an author of draft-davidben-tls-merkle-tree-certs, but I had some
feedback on this question:
RFC7924 was a good idea but I don’t think it got deployed. It has the
disadvantage that it allows for connection correlation and it is also
challenging to demand a client to eithe
then you no longer need to establish trust.
From: David Benjamin
Sent: Monday, March 20, 2023 2:43 PM
To: Kampanakis, Panos
Cc: ; Devon O'Brien
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
CAUTION: This email originated from outside of the organization. Do not click
links or
-Original Message-
From: Hubert Kario
Sent: Wednesday, March 22, 2023 8:46 AM
To: David Benjamin
Cc: Kampanakis, Panos ; ; Devon
O'Brien
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
CAUTION: This email originated from outside of the organization. Do not click
links o
+1 for NIST curve codepoints.
From: TLS On Behalf Of Krzysztof Kwiatkowski
Sent: Tuesday, March 28, 2023 10:00 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 outsi
> I would also like secp384r1_kyber1024 option, please.
Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary size
to the keyshare. like secp384r1_kyber768 combines two equivalent security
levels.
Those that want to be extra conservative can go secp521r1_kyber1024 which won
Hi Bas,
I prefer for the MTI to be P-256+Kyber768 for compliance reasons.
It would be trivial for servers to add support for both identifiers as they
introduce Kyber768, but you are right, the new draft should include an MTI
identifier.
From: TLS On Behalf Of Bas Westerbaan
Sent: Friday, Mar
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,
o have a stable reference for this
preliminary version of Kyber.
Best,
Bas
On Thu, May 11, 2023 at 4:17 PM Kampanakis, Panos
mailto:40amazon@dmarc.ietf.org>> wrote:
Great!
So to clarify, when Kyber gets ratified as MLWE_KEM or something like that,
will we still be using 0x6399 in the
Imo, we have been measuring handshake time as an indication or performance, but
time-to-last-byte or time-to-x%-byte should be used instead. There is nothing
wrong with your study Thom. It is pretty detailed and useful. I just think that
if these new algos get deployed, we would know if their im
Hi Dennis,
This is an interesting draft. The versioned dictionary idea for ICA and Root
CAs especially was something I was considering for the ICA Suppression draft
[1] given the challenges brought up before about outages with stale dictionary
caches. As you point out in the draft, cTLS uses s
ssage-
From: Dennis Jackson
Sent: Monday, July 10, 2023 7:23 AM
To: Kampanakis, Panos ; Dennis Jackson
; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can co
ially change often?
-Original Message-
From: TLS On Behalf Of Kampanakis, Panos
Sent: Tuesday, July 11, 2023 11:34 PM
To: Dennis Jackson ; Dennis Jackson
; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organizatio
Hi Dennis,
One more topic for general discussion.
The abridged certs draft requires a server who participates and fetches
dictionaries in order to make client connections faster. As Bas has pointed out
before, this paradigm did not work well with OSCP staples in the past. Servers
did not chose
o bad.
-Original Message-
From: TLS On Behalf Of Dennis Jackson
Sent: Wednesday, July 12, 2023 1:16 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server
participation)
CAUTION: This email originated from outside of the organization. Do not click
#x27;t have the
luxury of CT logs. But we would still want to option of compressing / omitting
the ICAs by using CCADB.
-Original Message-
From: Dennis Jackson
Sent: Wednesday, July 12, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certi
reason why?
-Original Message-
From: Dennis Jackson
Sent: Wednesday, July 12, 2023 1:01 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary
versioning)
CAUTION: This email originated from outside of the organization. Do not cl
ompressing the leaf fields
does not buy us anything.
-Original Message-
From: Dennis Jackson
Sent: Friday, July 14, 2023 6:28 AM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organizati
I support adoption as well.
There are some technical objections/ suggestions to address which I have shared
earlier, but the details can be figured out later.
-Original Message-
From: TLS On Behalf Of IETF Secretariat
Sent: Tuesday, August 1, 2023 3:38 PM
To: draft-jackson-tls-cert-abri
Personally, I am against any practical use of McEliece given all the other
available options. 1MB public keys are unnecessary, impact performance, and are
wasteful.
Regardless of the public key in the cert though, RFC7924 allows (with other
caveats) for not sending the server cert (and public k
> 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
+1 on making X-Wing a generic construction and stir in the KEM ciphertext.
In the ML-KEM case, the SHAKE256 cost of an additional 1-1.5KB ciphertext c2
will be miniscule compared to the other operations. And this will be similar
for other KEMs are well.
For example, from https://bench.cr.yp.to/
Hi Dennis,
I created a git issue
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but I am pasting
it here for the sake of the discussion:
What does the client do if the server only does Pass 1 and compresses / omits
the chain certs but does not compress the end-entity certs (Pas
T Logs were not available for some reason).
Am I overseeing something?
From: Dennis Jackson
Sent: Monday, March 4, 2024 10:47 AM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update
CAUTION: This email originated from outside of the organiz
ide of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
Hi Panos,
On 05/03/2024 04:14, Kampanakis, Panos wrote:
Hi Dennis,
> I can see two different ways to handle it. Either as you suggest, we have it
> be a runt
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
-
From: Martin Thomson
Sent: Thursday, March 7, 2024 10:26 PM
To: Kampanakis, Panos ; David Benjamin
; 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 outs
TLS handshake + 2 for the data
(30+42)
OK, this is just because of how 72KB aligns with the TCP congestion window
increasing.
From: Blumenthal, Uri - 0553 - MITLL
Sent: Wednesday, March 13, 2024 7:16 PM
To: resea...@bensmyth.com
Cc: Bas Westerbaan ; Kampanakis, Panos
; TLS@ietf.org; Childs-Klein, W
Hi Scott, David,
I think it would make more sense for the normative language about Client and
Server behavior (section 3.2, 3.4) in
draft-davidben-tls-key-share-prediction-00
(https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
) to go in draft-ietf-tls-hybrid-desig
ACK, thx, I had missed the discussions. It looks like what I was referring to
is addressed more prescriptively in rfc8446bis. That is great.
From: David Benjamin
Sent: Tuesday, March 19, 2024 4:42 PM
To: Kampanakis, Panos
Cc: Scott Fluhrer (sfluhrer) ; TLS@ietf.org
Subject: RE: [EXTERNAL] [TLS
+1 .
I was of the impression that
https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-10#name-iana-considerations
was going to get final codepoints for both combinations.
Also, “PQ hybrid automatically FIPSed with P256” is an important factor. Using
a FIPS certified ML-KEM imple
> and (crucially) for the verified modules with ML-KEM.
True, but the NIST queue is over 2+ years right now. Check out the Modules In
Process which go back to 2022
https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list
So, if we only go
Hi David,
Note I am not against draft-ietf-tls-key-share-prediction. It is definitely
better to not send unnecessary bytes on the wire.
> Yup. Even adding one PQ key was a noticeable size cost (we still haven't
> shipped Kyber/ML-KEM to mobile Chrome because the performance regression was
> mo
ct on real web metrics?
From: David Adrian
Sent: Thursday, September 12, 2024 11:26 PM
To: Kampanakis, Panos
Cc: David Benjamin ;
Subject: RE: [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-prediction next steps
CAUTION: This email originated from outside of the organization. Do not click
links
From draft-tls-reddy-slhdsa-00
> SLH-DSA can be preferred for CA certificates, making it ideal for long-term
> security as a trust anchor.
I think the standardized SLH-DSA parameters (designed for 2^64 signatures)
still make the ICA cert unnecessarily large.
If there is an SLH-DSA argument to
+1 Regarding the TCP initcwnd and QUIC Amplification topics. I would add
kInitialRtt which we found (
https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf,
section 7.3, Fig. 5) to introduce 60ms slowdowns due to QUIC's packet pacing.
Note t
Hi Bas,
That is interesting and surprising, thank you.
I am mostly interested in the ~63% of non-resumed sessions that would be
affected by 10-15KB of auth data. It looks like your data showed that each QUIC
conn transfers about 4.7KB which is very surprising to me. It seems very low.
In exper
I find Dennis’ writeup and most of his arguments convincing.
I don’t think the WG should adopt the draft.
From: Dennis Jackson
Sent: Tuesday, February 4, 2025 8:28 PM
To: TLS List
Subject: [EXTERNAL] [TLS] Re: Adoption Call for Trust Anchor IDs
CAUTION: This email originated from outside of t
> Is the WG consensus to run four separate adoption calls for the individual
> I-Ds in question?
I suggest to call for adoption of
- draft-kwiatkowski-tls-ecdhe-mlkem
- draft-tls-westerbaan-mldsa
- draft-reddy-tls-composite-mldsa
- draft-reddy-tls-slhdsa
Personally, I don't think all of tho
and rendering large sums of data like html, css,
javascript, images, json etc than on TLS handshakes.
From: Luke Valenta
Sent: Tuesday, November 19, 2024 3:19 PM
To: Kampanakis, Panos
Cc: Bas Westerbaan ;
; p...@ietf.org
Subject: [EXTERNAL] [Pqc] Re: [TLS] Re: Bytes server -> client
CAUT
52 matches
Mail list logo
