With David's clarifications, this is good.
On Tue, Apr 16, 2024, at 04:46, David Benjamin wrote:
> From the meeting, I remember there being some confusion around a table
> that split things up between TLS 1.2 and TLS 1.3, and differences in
> how they negotiate things, which makes this listing
On Tue, Apr 16, 2024, at 04:14, Joseph Salowey wrote:
> Should the draft deprecate these ClientCertificateTypes and mark the
> entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh)
> as 'D' discouraged?
Yes.
___
TLS mailing list
Reviewer: David Blacka
Review result: Ready with Issues
This is an early review, so the actual status simply means that I didn't find
anything alarming in this draft.
At its core, this I-D is a registration for a well-known URI, using the
criteria described in RFC 8615. The use of this
>From the meeting, I remember there being some confusion around a table that
split things up between TLS 1.2 and TLS 1.3, and differences in how they
negotiate things, which makes this listing a bit ambiguous. In particular,
there aren't any *cipher suites* with FFDH or FFDHE in their name in TLS
At IETF 119 we had discussion that static DH certificates lead to static key
exchange which is undesirable. Although the current draft deprecates static DH
ciphersuites, it seems that RFC 5246 allows the client to provide a certificate
with a static DH keypair to provide static parameters in
Yes.
-Ekr
On Mon, Apr 15, 2024 at 11:14 AM Joseph Salowey wrote:
> At IETF 119 we had discussion that static DH certificates lead to static
> key exchange which is undesirable. Although the current draft deprecates
> static DH ciphersuites, it seems that RFC 5246 allows the client to provide
At IETF 119 we had discussion that static DH certificates lead to static
key exchange which is undesirable. Although the current draft deprecates
static DH ciphersuites, it seems that RFC 5246 allows the client to provide
a certificate with a static DH keypair to provide static parameters in
I don't really feel strongly about this issue, but the document left me
feeling a little lost concerning ECDH.
I think documents should always explain the concerns around an RFC 2119
"SHOULD" or "SHOULD NOT". It's fine if "there may exist valid reasons in
particular circumstances when the
At IETF 119 we had discussion on how to mark the ciphersuites deprecated by
draft-ietf-tls-deprecate-obsolete-kex in the IANA Registry. At the meeting
there was support for ('D' means discouraged):
RSA ciphersuites should be marked with a "D"
FFDH ciphersuites should be marked with a "D"
FFDHE
Hi all,
I have just pushed a minor update to the AuthKEM [1] and AuthKEM-PSK [2]
drafts. I also have a new “reference” implementation of AuthKEM.
AuthKEM allows authentication via KEM public keys, which in particular might
save a lot of handshake traffic if you can replace ML-DSA by ML-KEM.
10 matches
Mail list logo
