Re: [TLS] IANA Recommendations for Obsolete Key Exchange
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 a bit ambiguous. In
> particular, there aren't any *cipher suites* with FFDH or FFDHE in
> their name in TLS 1.2. Also some of these constructions have analogs in
> TLS 1.3 and some don't, but none as cipher suites.
>
> Agreed with the proposal, but specifically, this is what I understand
> the proposal to mean:
>
> TLS 1.2 RSA cipher suites (TLS_RSA_WITH_*) should be marked with a "D"
> -- These lack forward secrecy and use a broken encryption scheme.
> -- There is no analog to RSA key exchange in TLS 1.3, so leave it alone.
>
> TLS 1.2 static DH cipher suites (TLS_DH_*_WITH_*) should be marked with
> a "D"
> -- These lack forward secrecy and the DH(E) construction in TLS 1.2 is
> broken. It lacks parameter negotiation, and uses a variable-length
> secret that is vulnerable to the Raccoon attack, particularly in this
> context with a static DH key.
> -- There is no analog to static DH in TLS 1.3, so leave it alone.
>
> TLS 1.2 DHE cipher suites (TLS_DHE_*_WITH_*) should be marked with a "D"
> -- While these do provide forward secrecy, the DH(E) construction in
> TLS 1.2 is broken. It lacks parameter negotiation, and uses a
> variable-length secret that is vulnerable to the Raccoon attack. In
> this context, the Racoon attack is less fatal, but it is still a side
> channel leakage that the protocol should have avoided.
> -- In theory RFC 7919 addressed the lack of parameter negotiation, but
> by reusing the old construction's cipher suites, it is undeployable. It
> also does not fix the side channel.
> -- There *is* an analog in TLS 1.3 (the ffdhe* named groups). However,
> they do not share the TLS 1.2 construction's problems, so we can leave
> them alone. They're just slow and kinda pointless given ECC exists.
>
> TLS 1.2 static ECDH cipher suites (TLS_ECDH_*_WITH_*) should be marked
> with a "D"
> -- These lack forward secrecy
> -- There is no analog to static ECDH in TLS 1.3, so leave it alone.
>
>
>
> On Mon, Apr 15, 2024 at 1:30 PM Joseph Salowey wrote:
>> 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 ciphersuites should be marked with a "D"
>> ECDH ciphersuites should be marked with a "D"
>>
>> This aligns with the deprecation intent of the draft. The draft states ECDH
>> are a SHOULD NOT instead of a MUST NOT, but the sentiment was they should be
>> generally discouraged.
>>
>> Please respond with any comments on this proposal by April 30,2024.
>>
>> Thanks,
>>
>> Sean, Deirdre and Joe
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Dnsdir early review of draft-ietf-tls-wkech-04
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 well-known URI is that a separate software component from the web server itself can poll the URI and, based on the response, update DNS RRsets. This seems pretty straightforward. The JSON format is encoding of the SVCB ServiceParams, plus the priority, target, and "regeninterval" fields. This makes sense, since we are asking the "Zone Factory" to generate a SVCB or HTTPS record from the data. This leads to some obvious questions: * What happens if there are unknown keys in the JSON? (e.g, is the response considered invalid? Or does the Zone Factory ignore them and create the RRs anyway?) * how are changes to the underlying SVCB service parameter registry handled? This I-D asks IANA to create another registry for the JSON fields. Does this have to "keep up" with the SVCB IANA registry? This I-D talks about web servers running in "split mode". Is this a common term in the web world? Is there a reference to this practice? If not, could it be described more completely? I found the abbreviation "BE" to be jarring, possibly more so because it is used without any English articles. Since I don't really understand "split-mode" (which is presumed to be the norm based on the example), I don't understand why the distinction is relevant to the proposal? Does the Zone Factory behave differently if the web server is in "split-mode"? Section 5 suggests that is does, but I'm not sure exactly what is going on there. I found the term "Zone Factory" a bit odd as well, but I couldn't think of a better name. "Zone Agent"? "SVCB Update Client"? The I-D in section 6 says: ZF SHOULD set a DNS TTL short enough so that any cached DNS resource records are likely to have expired before the JSON object's content is likely to have changed. The ZF MUST attempt to refresh the JSON object and regenerate the zone before this time. This aims to ensure that ECHConfig values are not used longer than intended by BE. This could be couched more precisely in terms of "regeninterval". We might want to avoid being overly prescriptive, though. Something like "The ZF SHOULD set a DNS TTL less than 'regeninterval'", perhaps. In Section 6 (and maybe section 3), it isn't spelled out how the Zone Factory determines the "owner" of the SVCB and or HTTPS records. I only ask about this because, if it isn't the domain part of the well-known URI used, then it should be accounted for in the JSON format. I'll also note that this early I-D does have a number of obvious typos, at least one was noticed by the ART reviewer: * "For many applications, that requires publication of ECHConflgList data structures in the DNS" -- there is an ell masquerading as an i. * "Zone factory (ZF): an entity that has write-accsss to the DNS" -- should be "access". There are likely others. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Recommendations for Obsolete Key Exchange
>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
1.2. Also some of these constructions have analogs in TLS 1.3 and some
don't, but none as cipher suites.
Agreed with the proposal, but specifically, this is what I understand the
proposal to mean:
TLS 1.2 RSA cipher suites (TLS_RSA_WITH_*) should be marked with a "D"
-- These lack forward secrecy and use a broken encryption scheme.
-- There is no analog to RSA key exchange in TLS 1.3, so leave it alone.
TLS 1.2 static DH cipher suites (TLS_DH_*_WITH_*) should be marked with a
"D"
-- These lack forward secrecy and the DH(E) construction in TLS 1.2 is
broken. It lacks parameter negotiation, and uses a variable-length secret
that is vulnerable to the Raccoon attack, particularly in this context with
a static DH key.
-- There is no analog to static DH in TLS 1.3, so leave it alone.
TLS 1.2 DHE cipher suites (TLS_DHE_*_WITH_*) should be marked with a "D"
-- While these do provide forward secrecy, the DH(E) construction in TLS
1.2 is broken. It lacks parameter negotiation, and uses a variable-length
secret that is vulnerable to the Raccoon attack. In this context, the
Racoon attack is less fatal, but it is still a side channel leakage that
the protocol should have avoided.
-- In theory RFC 7919 addressed the lack of parameter negotiation, but by
reusing the old construction's cipher suites, it is undeployable. It also
does not fix the side channel.
-- There *is* an analog in TLS 1.3 (the ffdhe* named groups). However, they
do not share the TLS 1.2 construction's problems, so we can leave them
alone. They're just slow and kinda pointless given ECC exists.
TLS 1.2 static ECDH cipher suites (TLS_ECDH_*_WITH_*) should be marked with
a "D"
-- These lack forward secrecy
-- There is no analog to static ECDH in TLS 1.3, so leave it alone.
On Mon, Apr 15, 2024 at 1:30 PM Joseph Salowey wrote:
> 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 ciphersuites should be marked with a "D"
> ECDH ciphersuites should be marked with a "D"
>
> This aligns with the deprecation intent of the draft. The draft states
> ECDH are a SHOULD NOT instead of a MUST NOT, but the sentiment was they
> should be generally discouraged.
>
> Please respond with any comments on this proposal by April 30,2024.
>
> Thanks,
>
> Sean, Deirdre and Joe
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
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 (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). Yes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
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 > a certificate with a static DH keypair to provide static parameters in > (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). > > 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? > > Please respond with any comments on this proposal by April 30,2024. > > Thanks, > > Sean, Deirdre and Joe > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Deprecating Static DH certificates in the obsolete key exchange document
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 (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). 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? Please respond with any comments on this proposal by April 30,2024. Thanks, Sean, Deirdre and Joe ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Recommendations for Obsolete Key Exchange
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 particular behavior is acceptable or even
useful", but what are they?
thanks,
Rob
On Mon, Apr 15, 2024 at 10:30 AM Joseph Salowey wrote:
> 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 ciphersuites should be marked with a "D"
> ECDH ciphersuites should be marked with a "D"
>
> This aligns with the deprecation intent of the draft. The draft states
> ECDH are a SHOULD NOT instead of a MUST NOT, but the sentiment was they
> should be generally discouraged.
>
> Please respond with any comments on this proposal by April 30,2024.
>
> Thanks,
>
> Sean, Deirdre and Joe
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] IANA Recommendations for Obsolete Key Exchange
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 ciphersuites should be marked with a "D"
ECDH ciphersuites should be marked with a "D"
This aligns with the deprecation intent of the draft. The draft states ECDH
are a SHOULD NOT instead of a MUST NOT, but the sentiment was they should
be generally discouraged.
Please respond with any comments on this proposal by April 30,2024.
Thanks,
Sean, Deirdre and Joe
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Bumped AuthKEM draft
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. This approach is particularly interesting if we can mitigate the overhead of the other signatures of the handshake using e.g. Merkle Tree Certificates. The reference implementation lives at [3]. I have only implemented AuthKEM server authentication right now; PSK and client auth will follow at some later point. The diff with the main branch of Rustls [4] might be particularly interesting if you want to see what the impact of an implementation of AuthKEM might be. Note that a large part of this diff is just instantiating Rustls' pluggable crypto provider API. The updates to the drafts include some things that I found when implementing the specified scheme, and I pinned some code points for experimental use (though with a note that these are not stable). As always, if you have questions or comments, you know where to find us. Cheers, Also on behalf of my co-authors, Thom [1]: https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ [2]: https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/ [3]: https://github.com/kemtls/rustls-authkem/ [4]: https://github.com/rustls/rustls/compare/rustls:793553e...kemtls:a9ca69b ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
