Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Salz, Rich]

> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ 
> 
> 
> The WG Last Call will end 3 October 2023 @ 2359 UTC.

I read the draft over the weekend.  I am not a DTLS person, but I think this is 
a good document.  It highlights both the security issues and a way to approach 
the problem.  I couldn't find anything wrong, but see disclaimer :)

Ship it.

___
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

[Joseph Birr-Pixton]

On Fri, 29 Sept 2023 at 15:45, Bas Westerbaan  wrote:

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

If the client is happy with either X25519 alone or X25519Kyber768, why not
send shares for both in the first ClientHello? Yes, that adds more bloat
there (but it's already large) but it need not require any additional
computation (because the prefix of a X25519Kyber768 share is a valid X25519
share, and the server can only proceed with one).

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

Thanks,
Joe
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls