This document does a good job of documenting current practice,
and hence I support
(and my thanks to Martin for addressing an issue I communicated to him
off-list).
I think that timestamping and/or autosegmenting entries in the file format
would be a useful extension
(current implementations, such
I support adoption of this document.
Y(J)S
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Bootstrapping is REALLY not appropriate, since this is not TLS with ECH
enabling itself,
but rather a DNS mechanism enabling ECH.
But the document is ready for LC.
Y(J)S
-Original Message-
From: Salz, Rich
Sent: Tuesday, August 20, 2024 8:00 PM
To: tls@ietf.org
Subject: [TLS]Re: I-D A
All,
I fully support standardizing the SSLKEYLOGFILE Format.
While it is a debugging tool, that doesn’t mean it doesn’t have to be
standardized.
Where I work we maintain a large set of protocol analysis tools
used to verify correct operation of various programs, and document variant
behaviors.
> Even with Recommended=N, I can imagine many managers reacting to a
> presentation on "YOU NEED TO USE PQC LIKE ML-KEM BECAUSE ELSE..." by googling
> "deploy ML-KEM now" and being recommended this rather than a safer hybrid[1].
> I am not convinced that such a person, if given more knowledge, "
I support adoption of pure PQC KEMs drafts with Intended status: Informational
(meaning that the IETF is not recommending using).
Any IPR that can be asserted against Kyber can be asserted against already
adopted hybrid methods incorporating Kyber.
If anything, one may attempt to argue that hybri
