Hi Cullen, having looked more closely at the text that's already in
7525bis, I have a few questions inline...
On 8/1/22 4:18 PM, Peter Saint-Andre wrote:
On 8/1/22 2:58 PM, Cullen Jennings wrote:
On Jul 30, 2022, at 1:40 PM, Peter Saint-Andre <stpeter@xxxxxxxxxx>
wrote:
Hi again,
The authors have conferred on this and at this time we don't think
that we can recommend anything other than EC ciphers, for several
reasons:
1. DHE negotiation is broken.
Perhaps a bit more explanation in the draft about the issues with
DHE-RSA (in context of 7919) would help.
For sure. We weren't crafting text yet, merely pointing out the basic
rationale behind exclusing non-EC ciphersuites. We can definitely
explain each of these three reasons more fully in text to follow. >
I was under the perhaps mistaken perception that the RFC 7919 was not
subject to the Raccoon attack and that there were mitigation for the
Racoon timing attacks. Given the reliance on a single class of
algorithms, I think it would be worth highlighting the risks and
provide good info on why alternatives don’t work.
Agreed.
Section 2.1 already says:
* Implementations SHOULD NOT negotiate cipher suites based on non-
ephemeral (static) finite-field Diffie-Hellman key agreement.
Rationale: These cipher suites, which have assigned values
prefixed by "TLS_DH_*", have several drawbacks, especially the
fact that they do not support forward secrecy.
Do you see the need for further explanation?
2. Static RSA is out of the question.
I agree but would prefer that was phrased as things don’t provide PFS
are out of the question, not that RSA is not usable.
That makes sense.
Section 2.1 already says:
* Implementations SHOULD NOT negotiate cipher suites based on RSA
key transport, a.k.a. "static RSA".
Rationale: These cipher suites, which have assigned values
starting with the string "TLS_RSA_WITH_*", have several drawbacks,
especially the fact that they do not support forward secrecy.
Do you see the need for further explanation?
I see lots of confusion of those two. I will note that, if EC was
broken by quantum or optical computers but RSA was not, I’m pretty
sure I would be switching to something with no PFS vs something that
was broken.
Very likely. :-)
Although I agree with the sentiment, it's not clear to me that 7525bis
needs to include text on this somewhat speculative point.
3. Post-quantum (PQ) methods aren't ready yet.
agree (thought I think they are getting surprising close and probably
plan to ship them well ahead of any schedule I imagine the IETF
getting around to agreeing on )
Our forecast is that a few years from now the PQ methods will be
ready for recommending in 7525ter, but for now EC is the best we can do.
I suspect that 7525ter will be published after the PQ methods have been
standardized at the IETF, but as we know it's never smart to make
specific forecasts about standardization schedules. ;-)
Here again I'm not sure that we need more text beyond what is already in
version -10 (see Section 1):
Naturally, future attacks are likely, and this document does not
address them. Those who implement and deploy TLS/DTLS and protocols
based on TLS/DTLS are strongly advised to pay attention to future
developments. In particular, although it is known that the creation
of quantum computers will have a significant impact on the security
of cryptographic primitives and the technologies that use them,
currently post-quantum cryptography is a work in progress and it is
too early to make recommendations; once the relevant specifications
are standardized in the IETF or elsewhere, this document should be
updated to reflect best practices at that time.
Peter
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
