Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

[Eric Rescorla <[e-mail]>]

> On Tue, Apr 28, 2020 at 1:41 AM tom petch <[e-mail]> wrote:

> It's worth noting that to the extent that this is a requirement, it is
> already violated by any installation which is compliant with RFC
> 7525. The auditing techniques in question depend un using static RSA
> cipher suites, but 7525
> https://tools.ietf.org/rfcmarkup?doc=7525#section-4.1 *already*
> prohibits those at the SHOULD level and requires forward that forward
> secure cipher suites be implemented and preferred at the MUST level:
>
>
>    o  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.
>
>    o  Implementations MUST support and prefer to negotiate cipher suites
>       offering forward secrecy, such as those in the Ephemeral Diffie-
>       Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and
>       "ECDHE") families.
>
>       Rationale: Forward secrecy (sometimes called "perfect forward
>       secrecy") prevents the recovery of information that was encrypted
>       with older session keys, thus limiting the amount of time during
>       which attacks can be successful.  See Section 6.3 for a detailed
>       discussion.
>
> <tp>
> Yes and it is a SHOULD not a MUST.

Well, there is actually both a SHOULD and a MUST. Therefore any two
7525-compliant endpoints will negotiate a PFS algorithm (because of
the MUST). Any 7525-compliant endpoint SHOULD NOT negotiate a non-PFS
algorithm even with a (non-7525-compliant) peer which only supports
that, though, as you say, that's only at SHOULD.

As far as I can tell, any proposed TLS 1.3 requirement would have
no impact on this (at least for existing protocols w/o TLS bindings)
in that it would most likely require TLS 1.3 support/preference as
MUST, but as you could still do TLS 1.2, you would have the same
outcome matrix wrt PFS as you have now,

Now, it's possible that a 7525-bis could forbid static RSA at the MUST
level (and I think there's a reasonable argument for this) but that's
a distinct question from updating it to include TLS 1.3.


> I see TLS 1.3 as emphasising privacy
> at a time when the world at large is waking up to the abuses that that
> enables.

I don't think it's useful to engage on the broader political question
-- although I don't really agree with this -- but this feature is not
primarily about privacy, but rather about security. There is wide
consensus that modern protocols should have PFS and there was even
back when 7525 was written (hence the text I quoted above). TLS 1.3 is
just following the consensus in that respect.


> As others have said, beyond adding a 'bis' this I-D seems devoid of
> anything new and so, to me, seems too risky to adopt.  It is a blank
> slate.

This seems like a misguided process objection. It's not uncommon in WGs
to first agree to do a bis with a list of proposed changes, and then
start with an unchanged version of the original document, adding one
change at a time. The WG's agreement to adopt the document doesn't
imply consensus for any particular change or the final document, and
there will be plenty of opportunity to object to any specific text.

-Ekr