Re: [TLS] IANA Recommendations for Obsolete Key Exchange
On Monday, 15 April 2024 19:30:29 CEST, 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.
I still don't like deprecating/discouraging/SHOULD NOTig FFDHE, but
I'm still for the proposal, and OK with using "D" for marking in IANA.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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] 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] 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
