Re: [Uta] [art] Artart last call review of draft-ietf-uta-rfc7525bis-09

[Rob Sayre <[e-mail]>]

Hi all,

I would like to state up front that I am not disputing the sentence
"Implementations MUST support TLS 1.2 [RFC5246]." If that's consensus, I
guess I'm just in the rough, and at least the text covering implementations
is much more encouraging than I expected.

But the document is still not consistent, because the rationale says "when
the recommendations in this document are followed [...] the use of TLS 1.2
is as safe as the use of TLS 1.3." But the document also states many valid
reasons for going TLS 1.3-only, not least of which is attack surface. I
think the document might be better if it said "Implementations SHOULD
support TLS 1.2, [for all of the reasons in the rationale below]". It seems
to be almost the textbook example of when SHOULD as defined in RFC2119 is
appropriate (almost never, imho).

There are so many details to track in supporting both versions that I just
can't see using MUST here. For example, something close to this TLS 1.3
extension came up at the last TLS WG meeting:
https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.6

But this was in the context of assuming TLS 1.2, and that's a different
protocol, whatever you think of the tradeoffs.

So, I've said my piece here, and will leave it to the authors.

thanks,
Rob


On Sun, Aug 14, 2022 at 1:27 PM Yaron Sheffer <[e-mail]> wrote:

> 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" <[e-mail]> wrote:
>
>     Peter Saint-Andre <[e-mail]> 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.
>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>