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

[tom petch <[e-mail]>]

<inline>
----- Original Message -----
From: Eric Rescorla [e-mail]
Sent: 01/05/2020 22:45:35


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

One requirement that was raised in the later stages of the work on TLS 1.3 related to audit, and was raised, I think, by representatives of the finance industry; the WG rejected the requirement. 


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.  If audit cannot take place, then it is easier for bad actors to use the technology be they pursuant of fraud, terrorism or whatever.  I think that concerns about the bad behaviour that the Internet facilitates is growing and we may get pushback on the IETF at large.  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.

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.

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

Tom Petch


Since then, I have seen suggestions on the TLS and other lists, and in the press, about the development of alternative protocols to meet the requirements that TLS 1.3 does not. 


Yes, I'm aware of at least one of those efforts (eTLS), however so far it seems to have only minimal adoption. At least in the Web environment, I am unaware of any browser or server which is interested in implementing it.


-Ekr