On Thursday, 23 March 2023 03:00:53 CET, Kampanakis, Panos wrote:
Hi Hubert,
I totally agree on your points about time-to-first-byte vs
time-to-last-byte. We (some of my previous work too) have been
focusing on time-to-first byte which makes some of these
handshakes look bad for the tails of
Because that’s what CNSA requires.
Regards,
Uri
> On Mar 29, 2023, at 00:45, Kampanakis, Panos wrote:
>
>
>
> > 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_kyb
Dear TLS Working Group,
Thank you for your response to our previous message from Eric Rescorla. We
appreciate your clarification on the use of ECDH ephemeral for encrypting
the exchange of certificates in the TLS 1.3 handshake.
Based on this information, we have a new proposal to make TLS u
Why are you calling Let's Encrypt low-assurance? The ACME protocol verifies
that the requester of the certificate controls the domain.
Honestly, I don't understand the problem you're trying to solve. Obtaining
a TLS certificate is not a hurdle any more nowadays, as it can trivially be
done automat
I wish people would stop citing the Cloudflare example as if something
nefarious is going on there. It is absolutely, 100% false that the identity in
a certificate should identify who Cloudflare is getting the certificate on
behalf of. Cloudflare requests the certificates, holds the keys, and
https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.
I opened a few issues, but the TLS 1.3 revision is very much ready to be
published.
For the 8447 revision, I found that our decision to remove the definition of
the fields for each r
Hi,
I watched the conversation at the end of this conference here:
https://youtu.be/u_sFyz4F7dc
It was good. The only thing I would add is that I think client
authentication is already much different in 1.3, and that new extensions
such as ECH are already not being done for 1.2.
The thing to do
It was good. The only thing I would add is that I think client authentication
is already much different in 1.3, and that new extensions such as ECH are
already not being done for 1.2.
Do you think discussion of client auth should be described in the draft?
Yes, new work is not being done for 1.
On Wed, Mar 29, 2023 at 10:48:32AM +0900, 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 codepo
On Wed, Mar 29, 2023 at 02:59:51PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Because that’s what CNSA requires.
I don't think that is the case. CNSA1 does not consider the Kyber part,
and CNSA2 requires something that is not currently available.
> > On Mar 29, 2023, at 00:45, Kampanakis,
10 matches
Mail list logo
