Subject: [TLS] Draft RHRD

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Nov 2017 14:18:23 +0000

In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick Sullivan concluded:

>- on the other hand using draft-rhrd is safer than allowing organizations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret cipher suites

I think this sets up a false comparison.  Existing TLS 1.3 debugging systems – Wireshark – can debug individual TLS sessions with the session key information being made available.  This is what the RHRD draft would require an organization to do, but it adds the additional signaling that the client is willing to allow it. The Wireshark example shows that the signaling is not needed.  Servers can unilaterally do it now.

I maintain that the cleartext signal servers no useful purpose, except to provide a mechanism for entities to segregate traffic.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Nov 2017 14:24:33 +0000

On 01/11/17 14:18, Salz, Rich wrote:
>> - on the other hand using draft-rhrd is safer than allowing
>> organizations to hack single-key escrow into TLS 1.3 or continue to
>> use TLS 1.2 with non-forward-secret cipher suites
> 
> I think this sets up a false comparison.  Existing TLS 1.3 debugging
> systems – Wireshark – can debug individual TLS sessions with the
> session key information being made available.  This is what the RHRD
> draft would require an organization to do, but it adds the additional
> signaling that the client is willing to allow it. The Wireshark
> example shows that the signaling is not needed.  Servers can
> unilaterally do it now.
> 
> I maintain that the cleartext signal servers no useful purpose,
> except to provide a mechanism for entities to segregate traffic.

I agree. I'd also like to point out that that in no
way implies that the absence of the visible signal
is any better. As we saw with draft-green, it was not.

S.

> 
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Nov 2017 10:51:35 -0400

Rich:

> On Nov 1, 2017, at 10:18 AM, Salz, Rich <[email-masked]> wrote:
> 
> In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html <https://www.ietf.org/mail-archive/web/tls/current/msg24789.html>, Nick Sullivan concluded:
>  

Indeed, anyone can implement the approach in draft-green, which has no opt-in capability.  In Prague, we heard that a lot of people would be more comfortable with an opt-in capability, so we specified an extension that does so.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Nov 2017 15:03:45 +0000

*   Indeed, anyone can implement the approach in draft-green, which has no opt-in capability.  In Prague, we heard that a lot of people would be more comfortable with an opt-in capability, so we specified an extension that does so.

I get it.  And in retrospect, I am convinced that was a bad decision.  Like the quote from the movie _Animal House_ about trust. ☺

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 01 Nov 2017 16:08:07 +0000

Rich,

I think you're mixing things up a bit. There is no false comparison. I am
not comparing draft-rhrd to the Wireshark option, they are fundamentally
different. I'm comparing draft-rhrd to draft-green. The wireshark option
requires storage of n keys to inspect n connections, both draft-rhrd and
draft-green only require a single master key to inspect n connections.

The Wireshark option is always possible with TLS, it just has scaling
issues. You export the session keys on a connection-by-connection basis
from one of the endpoints and can then use them to decrypt the transcript
after the fact. This is possible with TLS 1.2, TLS 1.3 and every version of
TLS that uses symmetric keys for encryption. This keeps TLS a two-party
protocol, and is my preferred solution to datacenter visibility, and I
assume Stephen's as well. There have been arguments here that this is not a
tenable solution in some environments, but I haven't found them convincing
for the datacenter visibility case.

The other two options, the master key options draft-rhrd and draft-green,
turn TLS into a quasi three-party protocol. Server operators can just
implement draft-green (or a variant thereof that doesn't repeat DH keys,
but instead generates them deterministically) no matter what the IETF says.
It's not prohibited by TLS 1.3 either structurally or by policy. If
datacenter operators want a master key option and there is no standard to
use, they can just implement draft-green and the client will have no idea
this is happening.

Your rejection of the cleartext signal expresses implies a preference for
draft-green over draft-rhrd, not a preference for the wireshark option
over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets
implemented whether it's standardized or not and no client will be able to
opt out or even know that it's happening.

In the situation where draft-green become the de facto standard for key
escrow in TLS, the public debates around national firewalls trying to force
clients to opt into wiretapping will become moot, firewalls won't have to
block users who have the cleartext signal, they'll just force servers to
implement draft-green unbeknownst to users. Users won't have any option, or
any knowledge that servers are using a master key to protect the
confidentiality of their connection and that their security may be lessened
because of it (compared to a Wireshark-type system which is more difficult
to implement at nation-scale due to how many keys you need to manage).
Furthermore, researchers won't be able to measure the prevalence of this
type of technology. With draft-green, civil society goes dark, with
draft-rhrd, there will be public data to inform a public debate.

Nick

On Wed, Nov 1, 2017 at 7:19 AM Salz, Rich <[email-masked]> wrote:

> >- on the other hand using draft-rhrd is safer than allowing organizations
> to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
> non-forward-secret cipher suites
>
>
>
> systems – Wireshark – can debug individual TLS sessions with the session
> key information being made available.  This is what the RHRD draft would
> require an organization to do, but it adds the additional signaling that
> the client is willing to allow it. The Wireshark example shows that the
> signaling is not needed.  Servers can unilaterally do it now.
>
>
>
> I maintain that the cleartext signal servers no useful purpose, except to
> provide a mechanism for entities to segregate traffic.
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Nov 2017 16:27:16 +0000

*   I think you're mixing things up a bit.

That’s quite possible.

  *   I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and draft-green only require a single master key to inspect n connections.

Draft-green requires limited use of ECDH keys, so that they can be sent to the third party.  Draft-rhrd allows limited use, but does not require it.  It allows a great deal of flexibility, from one key for days, to one key for each session.  Right?

We can’t control what a server will do, and we never could.  No matter how much we jump up and down and say “don’t give away the keys unless you see the RHRD extension” we’ll never know.  An unforceable rule is a very bad rule and shouldn’t be a rule.  Draft-green is much more intellectually honest, and doesn’t provide the cleartext signal.

  *   Your rejection of the cleartext signal expresses implies a preference for draft-green over draft-rhrd, not a preference for the wireshark option over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets implemented whether it's standardized or not and no client will be able to opt out or even know that it's happening.

Yes; I am surprised that’s being questioned, but after this note it should be obvious to all.  In fact, I think it was before Matt’s proposal that I stood at the mic and said we should treat it like prohibition: “this is grape juice, but if you do this… and this… and this… it will become wine. That’s illegal so don’t do that.”

  *   Users won't have any option, or any knowledge that servers are using a master key to protect the
confidentiality of their connection and that their security may be lessened because of it

They still don’t. We might all like to think that they do, but with or without either draft, there is no way to ensure anything about the server’s behavior beyond the bits it sends on the wire.  It was always so, and hoping that some text will make it more than this is a disservice to the end users.