Hi Peter,
Thank you for your comments and sorry for the delayed response.
The abstract of the Racoon paper mentions TLS-DH(E) five times, so clearly the
authors believe it applies to both TLS-DH and DHE. I think the disconnect is
that Racoon is about public key reuse which you would characterize as
static-ephemeral, but to most users this is just normal DHE with a very common
(though dangerous) optimization.
Section 4.1 now includes references to both Sec. 7.3 and 7.4 (see editor's
draft [1]).
I agree we should add a SHOULD NOT for TLS-ECDH, referencing [Jager2015],
"Practical invalid curve attacks on TLS-ECDH". See pull request [2].
The internal implementation of ECC algorithms is out of scope of the BCP, which
focuses on the use of algorithms within TLS. In other words, the target
audience for the BCP is TLS administrators more than the people who write the
internals of crypto libraries. This is why we never mentioned [Brumley11] in
RFC 7457 and I don't think we should add it here.
Thanks,
Yaron
[1] https://www.sheffer.org/I-D/draft-ietf-uta-rfc7525bis.html
[2] https://github.com/yaronf/I-D/pull/480
On 04/08/2022, 13:00, "Peter Gutmann" <pgut...@cs.auckland.ac.nz> wrote:
Peter Saint-Andre <stpe...@stpeter.im> writes:
>Given that we already discuss these matters in Section 7.4, I don't see the
>need for additional text.
The issue that I pointed out is in section 4.1, "General Guidelines", while
what you're referring to is buried in the security considerations right at
the
end. What's in 4.1 at the moment is wrong (Raccoon is static-ephemeral DH,
not ephemeral-ephemeral DH), so I think it needs to be changed. 4.1 refers
to
7.3 but not 7.4, so anyone reading the doc who doesn't read into every
corner,
including the parts buried after the IANA considerations at the end, will
get
an incorrect idea of what the issues are.
Also what 4.1 is in effect saying is "implementations MUST use ECC
algorithms"
(via SHOULD NOT RSA (key transport), SHOULD NOT DH, SHOULD NOT DHE), and
that
includes TLS_ECDH_*, not just TLS_ECDHE_* (section 4.1 says, about *_DH_*,
"These cipher suites, which have assigned values prefixed by 'TLS_DH_*',
have
several drawbacks, especially the fact that they do not support forward
secrecy", but omits any mention of the equivalent *_ECDH_* which is no
better).
Since the ECC algorithms are notoriously vulnerable to nonce issues as well
as
various others (e.g. forgetting to perform validity checks on received
values), it's just moving the insecurity from one algorithm over to another.
There's no mention in the security considerations of any issues with
replacing
DHE with ECC algorithms, it's just "badly implemented DH is insecure" but no
mention that badly-implemented ECC is also insecure. For example Brumley
et
al's attack on ECDHE takes advantage of the same not-really-ephemeral nature
that Raccoon uses against DHE, but it's never mentioned. Anyone reading the
draft would be forgiven for thinking that all you need to do to magically
make
all security problems go away is switch to ECC (and GCM, the other universal
solution to all problems, despite it also having led to endless
vulnerabilities around nonce reuse).
Peter.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
