Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 15:04:54 -0400

With this extension, any middlebox anywhere
can drop traffic that is not tappable.  Regardless of who controls
the clients and servers, we are now enabling entities to block
traffic unless you acquiesce. For example, an inflight wifi could
use this.  Maybe, ultimately, many/most of the servers that the
passengers connect to will not support it, but some might.

Rich,

You've brought up this example of in-flight WiFi and other
middleboxes on the Internet uses this extension as a means of
coercing individuals into allowing their TLS traffic with servers to
be intercepted, but I fail to see how the scenario is at all
realistic.

Yes, any box that sits between the client and the server can drop
traffic for whatever reason it wants. Such a box could today drop
any traffic that is protected using TLS.

In order for a middlebox to be able to use this draft to intercept
traffic that is TLS protected, it would need to:

1) get the server to agree to allow it to intercept the traffic; and

2) get the client to include the new extension in its ClientHello.

How would the middlebox get the client to include the extension. You
previously said:

I believe I know why people want this now.
They are worried that if TLS 1.3 goes out without something like
this, then the market (standard widely available browsers) will
not implement it. Let me assure you that this isn’t an issue. The
extension would *never ever* make it to the MUST state, and the
browsers would be unlikely to ever implement it anyway.

I partially agree with this and partially disagree. I agree that
browsers (and other similar clients) would be unlikely to ever
implement it. I disagree with the suggestion that proponents of this
draft want for browsers to implement this or want it to be a MUST.
Proponents of this draft are interested in visibility within the
data center, and have no interest in using this capability in any
scenario in which a browser would be the client.

So, given your agreement that browsers would be unlikely to ever
implement this extension, how would the in-flight WiFi (or other
middlebox) be able to get clients to include the extension if the
software they are using doesn't support it? It seems that the only
way would be to coerce the clients into using a browser (or other
client) provided by the attacker (i.e., in order to use the Internet
while in flight you must install Evil Airline's browser/app). But
then, if the attacker is able to get the client to install and use
its own software, then it would easily be able to intercept all
traffic from the client, not just traffic to cooperating servers, so
why would it bother using this draft at all in this case?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 15:17:49 -0400

On Oct 24, 2017, at 3:04 PM, David A. Cooper <[email-masked]> wrote:
> In order for a middlebox to be able to use this draft to intercept traffic that is TLS protected, it would need to:
> 
> How would the middlebox get the client to include the extension.

Block all TLS connections that don't use it.

>> I believe I know why people want this now. They are worried that if TLS 1.3 goes out without something like this, then the market (standard widely available browsers) will not implement it. Let me assure you that this isn’t an issue. The extension would *never ever* make it to the MUST state, and the browsers would be unlikely to ever implement it anyway.
> 
> I partially agree with this and partially disagree. I agree that browsers (and other similar clients) would be unlikely to ever implement it. I disagree with the suggestion that proponents of this draft want for browsers to implement this or want it to be a MUST. Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.

Let's be clear.   While I may have made some statements about the balance of concern over who pays for this, nobody is saying that the proponents of this draft intend a nefarious use of this extension.   The concern is not that BCBS is going to invade my privacy.   It is that if BCBS gets its way, someone _else_ will use this technology to invade my privacy, or to trojan horse some malware onto my computer, or some other attack.

> So, given your agreement that browsers would be unlikely to ever implement this extension, how would the in-flight WiFi (or other middlebox) be able to get clients to include the extension if the software they are using doesn't support it? It seems that the only way would be to coerce the clients into using a browser (or other client) provided by the attacker (i.e., in order to use the Internet while in flight you must install Evil Airline's browser/app). But then, if the attacker is able to get the client to install and use its own software, then it would easily be able to intercept all traffic from the client, not just traffic to cooperating servers, so why would it bother using this draft at all in this case?

You've inverted the chain of causality here.   The chain is (to the best of my ability to explain it, anyway):

1. Standardize this extension
2. Someone with a service people want to use starts blocking connections that don't enable it.
3. Browser vendors are forced to implement it, or end users are forced to download special browser software.
4. Now an attack surface exists on the user's machine that hadn't previously existed.
5. The user's machine is now subject to attack by a larger set of attackers than it had been previously, using a larger set of attacks than were available previously.

None of this is a smoking gun.   If everybody keeps all the plates spinning, we won't have a problem.   The problem is that everybody keeping the plates spinning is something that pretty much doesn't happen in the real world, as we've seen if we follow the news.   And some of the everybodies in this equation are operating infrastructure that we really, really need to be well protected.   And others are being stalked.   And still others are trying to do secure transactions online.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 19:23:12 +0000

I use an airplane as an example of a “captive” population, substitute any similar group you want.

  *   Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.

True, but that’s not the point.  The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic.  I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying.

As for how would such clients get promulgated?  Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.”    How many people on the plane would click and download?

> Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.

How do you propose to guarantee that?  As Stephen pointed out, we have no way to prevent this from “escaping” on to the public Internet, and no way to prevent captive audiences from being forced to comply.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Oct 2017 15:24:16 -0400

> On Oct 24, 2017, at 3:17 PM, Ted Lemon <[email-masked]> wrote:
> 

...with the assumption that a client would automatically revert to trying the connection with the visibility extension if it can't make a connection without the extension.  Why would that assumption be useful?  How is this situation different than the current practice of using HTTP if HTTPS fails?

> Let's be clear.   While I may have made some statements about the balance of concern over who pays for this, nobody is saying that the proponents of this draft intend a nefarious use of this extens…

Can you demonstrate how such an attack would work without the assumption that a client (e.g., browser) would, as policy, downgrade to using the extension if it can't connect without the extension.  I understand the general concern.

> 5. The user's machine is now subject to attack by a larger set of attackers than it had been previously, using a larger set of attacks than were available previously.

I still don't see how step 2 is different than forcing a connection without using TLS at all?  Why is the visibility extension more dangerous than only allowing connections with no TLS?

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Oct 2017 15:27:22 -0400

> On Oct 24, 2017, at 3:23 PM, Salz, Rich <[email-masked]> wrote:
> 
> 	• Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.
> 

Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all?   That is, I don't see why this scenario is specific to the visibility extension.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 19:32:36 +0000

➢ Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all?   That is, I don't see why this scenario is specific to the visibility extension.
    
Because you can’t do that with TLS right now.  This adds that ability.   The idea of having a plaintext signal that allows intermediaries to force users into weakening their security seems to go against the very grain of what TLS tries to do.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Oct 2017 22:36:00 +0300

> On 24 Oct 2017, at 22:27, Ralph Droms <[email-masked]> wrote:
> 
> 

Think of the children.

We can’t just let them loose on the Internet, there’s predators out there. So we will snoop on their traffic.  To do that, we block all traffic that isn’t snoopable, and we do it at the edge router in schools.  All schools in our state are required by law to install a firewall that does this. And we get the mobile operators to do so as well (only for handsets in schools).

Now either the mobile OS vendors make a browser that works in schools (at least with a setting), or the school recommends a third party browser that works in school. And best of all, this is *more secure* than regular TLS 1.3, because it also protects your children from Internet predators. Think of the children.

You can’t make a claim like that for an HTTP-only browser, and worse still, it won’t work on much of today’s Internet.

Yoav

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 15:41:22 -0400

> ...with the assumption that a client would automatically revert to trying the connection with the visibility extension if it can't make a connection without the extension.  Why would that assumptio…

More likely the client would be failed with one that just automatically negotiates the visibility extension, because that's easier and quicker.

> Can you demonstrate how such an attack would work without the assumption that a client (e.g., browser) would, as policy, downgrade to using the extension if it can't connect without the extension.…

I don't think it's necessary to demonstrate that, because the browser that implements this extension will just automatically negotiate it.

> I still don't see how step 2 is different than forcing a connection without using TLS at all?  Why is the visibility extension more dangerous than only allowing connections with no TLS?

There's no fig leaf of security if you allow connections with no TLS.

The problem with these proposals generally is that they push us in the direction of picking and choosing who we will allow to eavesdrop on us, and make it non-negotiable in order to access services we want.   You and I are smart enough to say "no" when presented with this choice; unfortunately, at least at present, many people are not, and see things like browser security warnings as annoyances.   This is why UAC failed in Windows Vista, and why Vista was widely reviled for its poor usability.

It is demonstrably the case that users will say yes to things that are not in their self interest to get to the resources they want.   Every time I visit my mom, she has new malware installed on her Chromebook that I removed on my previous visit.

So if we do not say no to this, it's likely that ultimately not enough people will, and a lot of end users will suffer as a result, some of them operating things we'd like to remain secure.   That is the discussion we should be having right now.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2017 20:49:21 +0100

Ralph,

> You can’t make a claim like that for an HTTP-only browser, and worse still, it won’t work on much of today’s Internet.

Just to note that the only substantive difference between
draft-green and this is the please-screw-me extension in
the ClientHello and Yoav's argument above (with or without
all the obvious corollaries/variations) destroys that as
a defence for your latest effort to square this circle. (This
has been stated at least a couple of times/ways already.)

If you Ralph or Russ have some new arguments for your draft
that have not been countered already or wrt draft-green
then I wish you would raise those, because I've not seen any
that have survived. And if you have no such arguments then
I think it'd be a fine thing to admit that truth openly.

The underlying idea remains as bad as ever, for all the
reasons I tried to summarise at [1] (to which I'll add Yoav's
description above when I get a chance as it's a nice
illustration).

S.

[1] https://github.com/sftcd/tinfoil

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 15:54:51 -0400

Why would these schools settle for a half measure that only allows them 
to snoop on traffic between their students and servers provide the keys 
to their Internet traffic to the schools? If a school wants to snoop on 
its students' traffic, it would do so in a much easier way than using 
draft-rhrd-tls-tls13-visibility, in the same way that some enterprises 
today use middleboxes to inspect all outgoing traffic.

This browser that students would be required to use would be one that 
has a CA controlled by the middlebox installed as a trust anchor. 
Whenever one of the students' clients tries to connect to an external 
secure site, the middlebox-controlled CA issues a certificate for that 
site so that the connection can be terminated at the middlebox. The 
middlebox then establishes a secure connection with the end server, thus 
setting up the middlebox as a MiTM.

There are already middleboxes on the market today that do this. They 
work for all outgoing connections and don't require any cooperation 
whatsoever from the outside servers that the clients are trying to 
connect to, and only expert users would notice the presence of the MiTM.

Given that such an effective and simple-to-implement solution is already 
available today, why would these schools be so anxious to use a 
complicated-to-implement and largely ineffective solution such as 
subverting draft-rhrd-tls-tls13-visibility for improper purposes?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 15:59:17 -0400

On Oct 24, 2017, at 3:54 PM, David A. Cooper <[email-masked]> wrote:
> There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.

They are also quite expensive because they have to generate certs on the fly.   If you look at environments where these are in use, they tend to be either high-margin, or else low-use.   So e.g. you only redirect TLS connections that you absolutely need to intercept through the box; other connections are terminated normally.   Practically speaking, I don't see any cash-strapped school spending money on one of these devices.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 16:01:30 -0400

On Oct 24, 2017, at 3:59 PM, Ted Lemon <[email-masked]> wrote:
> On Oct 24, 2017, at 3:54 PM, David A. Cooper <[email-masked] <mailto:[email-masked]>> wrote:

BTW, if you find this argument unconvincing, consider why these boxes aren't being proposed for use as an alternative to draft-rhrd-tls-tls13-visibility-00.   :)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 20:07:53 +0000

The phrase “subverting for improper purposes” is inaccurate, and perhaps misleading.  We would be providing another cleartext signal and we have to expect that someone will use it; anything else would be naïve. All the discussions about “ossification” in the past two years should make that painfully obvious.

As for “improper purposes,” it’s something enabled by the protocol, even if it’s not what the proposers intended it for.  But isn’t the whole story of the Internet? If the purposes are really improper, define things in a way that it can only be used properly, for whatever that definition is.

So far, we’ve seen that it can be used to segregate clients, open them up to stream modification, and the only justification has been that this is perceived easier to keep visibility as currently built by sharing static RSA keys.

Do I have that right?

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 16:21:39 -0400

I'm not suggesting that cash strapped
schools would use one of these devices. I'm simply saying that
such a solution would be simpler and far more effective than
trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing
traffic.

Those who are suggesting draft-rhrd-tls-tls13-visibility could be
used to snoop on outgoing traffic are imagining a scenario in
which the school (or other snooper) would make arrangements with
each TLS-protected server that they would allow their clients to
connect to receive copies of the keys that would be needed to
decrypt the traffic. How effective would that be? How expensive
would that be?

Besides, the scenario I described previously is just one
possibility (although perhaps the easiest to implement). The
software that the middlebox requires clients to use could just
send the traffic in plaintext to the middlebox while falsely
indicating to the client that the connection is secure. Plainly,
if the attacker developed the software that the client is running,
then there is no protection from the attacker.

On 10/24/2017 04:01 PM, Ted Lemon wrote:

On Oct 24, 2017, at 3:59 PM, Ted Lemon <[email-masked]>
wrote:

On Oct 24, 2017, at 3:54 PM,
David A. Cooper <[email-masked]> wrote:

There are already
middleboxes on the market today that do this. They
work for all outgoing connections and don't require
any cooperation whatsoever from the outside servers
that the clients are trying to connect to, and only
expert users would notice the presence of the MiTM.

They are also quite
expensive because they have to generate certs on the fly.
If you look at environments where these are in use, they
tend to be either high-margin, or else low-use.   So e.g.
you only redirect TLS connections that you absolutely need
to intercept through the box; other connections are
terminated normally.   Practically speaking, I don't see
any cash-strapped school spending money on one of these
devices.

BTW, if you find this argument unconvincing,
consider why these boxes aren't being proposed for use as an
alternative to draft-rhrd-tls-tls13-visibility-00.   :)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 16:24:20 -0400

On Oct 24, 2017, at 4:21 PM, David A. Cooper <[email-masked]> wrote:
> I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that such a solution would be simpler and far more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Again, if that were true, then it would also be true that these devices would nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Oct 2017 23:38:20 +0300

> On 24 Oct 2017, at 22:54, David A. Cooper <[email-masked]> wrote:
> 
> Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.

> This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others).  It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students” and “MustangBrowser for Mountain Crest High School students"

> There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are try…

Unless they had to configure their browser themselves.  The support costs of these is tremendous.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 16:40:38 -0400

On 10/24/2017 04:24 PM, Ted Lemon
wrote:

I'm not suggesting that cash strapped schools
would use one of these devices. I'm simply saying that
such a solution would be simpler and far more effective
than trying to use draft-rhrd-tls-tls13-visibility to
snoop on outgoing traffic.

Again, if that were true, then it would also be true
that these devices would nicely solve the problem that
draft-rhrd-tls-tls13-visibility solves.

Not at all. Visibility in the data center is a totally different
problem than inspecting outgoing traffic. In the data center case
the same organization controls the clients, servers, and the
authorized listeners. That is very different from a scenario in
which the organization that wants to listen in is different from the
organizations that control the servers, and in which the
organizations that control the servers are unlikely to want to grant
this intermediary the ability to listen in on the traffic between it
and its clients.

Also, in the data center case, there is no middlebox. Others, who
know much more than I do about operational constraints in data
center environments, have already argued that setting up a bunch of
middleboxes would not be a viable solution.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Oct 2017 16:51:55 -0400

> On Oct 24, 2017, at 4:24 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 24, 2017, at 4:21 PM, David A. Cooper <[email-masked] <mailto:[email-masked]>> wrote:

I think your suggestion is addressed as one of the alternative solutions in draft-rhrd-tls-tls13-visibility.  Enterprise network operators say that deploying these devices to provide the same visibility as the visibility extension would, at best, be highly complicated and expensive, if not altogether impossible.

- Ralph

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Oct 2017 16:51:30 -0400

On Tue, Oct 24, 2017 at 4:24 PM, Ted Lemon <[email-masked]> wrote:
> I'm not suggesting that cash strapped schools would use one of these
> devices. I'm simply saying that such a solution would be simpler and far
> more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop
> on outgoing traffic.
>
>
> Again, if that were true, then it would also be true that these devices
> would nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

These are two different problems and although you could use a proxy
solution inside a datacenter, it doesn't scale or make sense.  IMO,
David countered Yoav's clever scenario very well.

Now, the proponents are asking for alternatives to consider and a
serious look at their proposal.  Can we look at this request
constructively and provide a cohesive set of alternate solutions?

IPsec [1] might be possible, but requires a change in tooling for
intercepting traffic.  In hosted environments, it also could change
who is managing the encryption (TCP/application vs. IP layer).
I also received a comment that you could also tie in use of IPv6 and
label sessions with the IPsec approach and that makes sense.

What about the experimental drafts in TCPInc?  [2]
This provides opportunistically encrypted TCP, so you could MiTM it.

Are there other alternate solutions that have been discussed or should
be?  Maybe it would be helpful to list them out for comparison and
evaluation by those interested - not on list as that's off-topic.

[1] https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward
[2] https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/?include_text=1

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 17:09:52 -0400

As difficult as what you describe below
would be, using draft-rhrd-tls-tls13-visibility to snoop would be
much more complicated. They would need to need to get their
"special" browsers onto all of the students' devices, but then,
unlike in the scenario below, that would only be the beginning of
what they need to do. They would need to active cooperation of
every TLS-protected server that the students could connect to and
they would need an infrastructure for obtaining and managing all
of the keys that they would be getting from all of these servers.
[In practice, of course, there wouldn't be that many keys since
practically no servers would cooperate in this scheme.]

So, yes, setting up a scheme to snoop on all outgoing
TLS-protected traffic would not be easy. However,
draft-rhrd-tls-tls13-visibility would not make it easier than it
currently is, as implementing something based on
draft-rhrd-tls-tls13-visibility would be far more difficult than
using currently available methods.

And, I don't buy the idea that if this extension is standardized
that it will be implemented in commonly-used browsers. We don't
have to "keep all the plates spinning" in order to prevent this
extension from "escaping" on to the public Internet. This isn't
something that could "accidentally" be implemented in browsers if
browser vendors don't take extreme precautions to prevent it from
happening. Browser vendors would have to pro-actively decide to
implement this, and I don't see that happening. The idea that
someone would set up a service that would only work if browsers
implemented this extension, and then browsers would be "forced" to
implement the extension so that this service would work isn't
realistic.

A server that wanted to allow third party interception of traffic
between itself and its clients wouldn't require this extension and
then wait for browsers to implement the extension. It would just
use TLSv1.2 with RSA key exchange (or something like
draft-green-tls-static-dh-in-tls13), and then set up the
interception capability without the client's knowledge.

On 10/24/2017 04:38 PM, Yoav Nir wrote:

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 21:18:05 +0000

*   And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers.

And that is a risk you are willing for the entire public Internet to take?

And what about the fact that it provides a cleartext signal as to whether or not a client is willing to let itself be MiTM’d, does that bother you?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 21:28:54 +0000

>  Enterprise network operators say that deploying these devices to provide the same visibility as the visibility extension would, at best, be highly complicated and expensive, if not altogether impossible.

Based on the contacts you’ve had, what’s their cost estimate for modifying the servers and monitoring infrastructure?  Zero?  Thousands per device?  Based on  the contacts you’ve had, how does the cost of modifications to support *this* draft, compare to the cost of modifying the server and monitoring infrastructure to report and use negotiation PFS session keys?

And hey, you’re an author.  Does your draft allow an intermediate such as a firewall to modify the traffic that passes through?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 17:55:39 -0400

On Oct 24, 2017, at 4:40 PM, David A. Cooper <[email-masked]> wrote:
> Also, in the data center case, there is no middlebox. Others, who know much more than I do about operational constraints in data center environments, have already argued that setting up a bunch of middleboxes would not be a viable solution.

I was not actually suggesting this as a solution.   Rather, I was pointing out that it's a lousy solution for both use cases.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Oct 2017 18:39:05 -0400

On 10/24/2017 05:18 PM, Salz, Rich
wrote:

And, I don't
buy the idea that if this extension is standardized that it
will be implemented in commonly-used browsers.

And that is a risk you are willing for the
entire public Internet to take?

I'm not taking any risk.  The ability for a server to allow a third
party to have access to data it is exchanging with a client already
exists, and that ability isn't going away whether this proposal (or
something similar) is standardized or not. As I've already pointed
out, for the scenarios people are concerned about, the "attacks"
being described would be much more easily carried out by some means
other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated
way for servers and middleboxes to collude to do something that they
can already do now in a simpler way.

And what about the fact that it provides a
cleartext signal as to whether or not a client is willing to
let itself be MiTM’d, does that bother you?

No. As I noted before, servers can already allow middleboxes to MiTM
connections with clients with asking the client's permission. Public
facing servers that want to allow this (even if as a result of
coercion) won't use this extension. They'll just enable it without
informing the clients.

There are also other ways a server could allow a middlebox to MiTM
the connections that it has with clients that don't require the
client's cooperation (or knowledge) and that wouldn't require any
changes on the client side; ways that would be easier than trying to
use draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be
MiTM'd required getting clients' permission, then this might be a
concern, I don't see servers that want to (or are coerced into)
allowing connections to be MiTM'd asking clients whether they are
willing. Given this, we aren't going to see browsers that are
configurable to signal that the client is willing to "allow" the
connection to be MiTM'd.

I haven't even gotten into the question of what does it mean for a
connection to be MiTM'd. If Company X decides to have its web site
operated by Hosting Provider Y is the connection between the client
and Company X being MiTM'd? The client might think it has a secure
end-to-end connection with Company X, but in reality its data is
being intercepted and read by Hosting Provider Y, without the
client's permission (and most likely without the client's
knowledge). How does TLS, currently, prevent this? Why isn't anyone
demanding that TLS cannot be standardized until it can be proven
that such a scenario is impossible?

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 25 Oct 2017 00:41:52 +0000

Excellent points/questions and I just wanted to add that your final example, regarding  hosting providers actually being a MitM,  is EXTREMELY prevalent in Enterprises today and is a management/ monitoring issue specifically pointed out by Steven Fenter in his presentation to the TLS WG in Prague.
Without the ability to decrypt these sessions our ability to manage/monitor/secure is severely reduced.
And TLS, being a point to point protocol,  cannot help in its current form.

From: TLS [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Tuesday, October 24, 2017 6:39 PM
To: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/24/2017 05:18 PM, Salz, Rich wrote:

I'm not taking any risk.  The ability for a server to allow a third party to have access to data it is exchanging with a client already exists, and that ability isn't going away whether this proposal (or something similar) is standardized or not. As I've already pointed out, for the scenarios people are concerned about, the "attacks" being described would be much more easily carried out by some means other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated way for servers and middleboxes to collude to do something that they can already do now in a simpler way.

No. As I noted before, servers can already allow middleboxes to MiTM connections with clients with asking the client's permission. Public facing servers that want to allow this (even if as a result of coercion) won't use this extension. They'll just enable it without informing the clients.

There are also other ways a server could allow a middlebox to MiTM the connections that it has with clients that don't require the client's cooperation (or knowledge) and that wouldn't require any changes on the client side; ways that would be easier than trying to use draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be MiTM'd required getting clients' permission, then this might be a concern, I don't see servers that want to (or are coerced into) allowing connections to be MiTM'd asking clients whether they are willing. Given this, we aren't going to see browsers that are configurable to signal that the client is willing to "allow" the connection to be MiTM'd.

I haven't even gotten into the question of what does it mean for a connection to be MiTM'd. If Company X decides to have its web site operated by Hosting Provider Y is the connection between the client and Company X being MiTM'd? The client might think it has a secure end-to-end connection with Company X, but in reality its data is being intercepted and read by Hosting Provider Y, without the client's permission (and most likely without the client's knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be standardized until it can be proven that such a scenario is impossible?

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 00:59:18 +0000

> I'm not taking any risk.  The ability for a server to allow a third party to have access to data it is exchanging with a client already exists, and that ability isn't going away whether this propos…

Yes, you are taking a risk.  Or, rather, you are providing a way for any middlebox to force clients to acquiesce.  You might think it’s complicated, but it’s not.  There’s a perl script in the OpenSSL distribution that does something very similar (look for the TLS Proxy).

Servers have always had the ability to share whatever information they want with other entities.  We are not trying to change that.  What this draft does is force clients to become parties in that interaction and signal in the clear that they are doing so.  This is a really fundamental change to TLS.

> So, no I am not worried about the "risk" of creating a complicated way for servers and middleboxes to collude to do something that they can already do now in a simpler way.

I think you’re not getting it.  Sorry, probably my fault for not being a very good explainer.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 03:01:11 +0100

Michael,

What, in your message below, has not been said a number
of times in this thread? (And countered effectively IMO.)
I don't see anything - repeating points already countered
is just disruptive noise, sorry.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 03:13:23 +0100

David,

I'll go back over your mails tomorrow but was struck by this...

On 24/10/17 23:39, David A. Cooper wrote:
> I haven't even gotten into the question of what does it mean for a connection to 
> be MiTM'd. If Company X decides to have its web site operated by Hosting 
> Provider Y is the connection between the client and Company X being MiTM'd? The 
> client might think it has a secure end-to-end connection with Company X, but in 
> reality its data is being intercepted and read by Hosting Provider Y, without 
> the client's permission (and most likely without the client's knowledge). How 
> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be 
> standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 25 Oct 2017 03:30:49 +0000

Sorry,
My turn to disagree.  
I don't believe any points  stated by David or myself had been stated previously nor "Countered".  
And if "Countered" means you disagree with the assertions,  then you are saying that hosting providers are NOT doing MitM and that TLS is a multipoint protocol.    And once again I disagree.  
But since I too deplore "Noise",  I will comment no further on these aspects of the conversation and we can agree to disagree.  

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2017 10:01 PM
To: Ackermann, Michael <[email-masked]>; David A. Cooper <[email-masked]>; [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Michael,

What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry.

Thanks,
S.

On 25/10/17 01:41, Ackermann, Michael wrote:
> And what about the fact that it provides a cleartext signal as to whether or not a client is willing to let itself be MiTM'd, does that bother you?
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 12:48:00 +0000

Before you leave, there are a number of questions still unanswered.

1 Can this draft enable an active attacker to modify traffic?  If not, then then how is that prevented?

2 Can this draft be used to segregate traffic so that only those willing to be intercepted can be handled separately from those unwilling?

3 Do you think that this draft will require zero changes to your infrastructure?  How does that cost estimate compare with, say, the server just sending the PFS session key to the infrastructure?

4 What percentage of traffic in your enterprise is TLS 1.2 now?  (Yes, that’s a new question I admit)

5 When do you think you will “have” to move to TLS 1.3, round it to, say five years.

6 What is the justification for this approach, other than you think it will be a “hard sell” to convince executives to do the work needed?  I’ve seen no other reasons discussed and am curious to see how this response and #3 align.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 25 Oct 2017 10:23:22 -0400

Everything I have stated is my personal opinion.

Note that I never suggested that I like or am espousing a certain 
approach, I was simply stating a fact. In many cases today, a TLS 
connect that appears to a client to be terminating a one place (Company 
X) is actually terminating somewhere else (Hosting Provider Y) without 
any clear indication to the client that the connection is terminating at 
Hosting Provider Y. Nobody has suggested that this is unacceptable or 
that TLS is broken if it can't prevent that.

TLS is not an end-to-end protocol, it is a point-to-point protocol, and 
as noted in hosting company example, which you claim to find so 
troubling, it isn't always clear to either party what's at the other end 
of the connection. It might be the entity the client thinks its 
connecting to (Company X), it might be a hosting provider acting on 
behalf of Company X, or it might be something else. The best the client 
can hope for with things like TLS, PKIX, TRANS, etc., is that the server 
end of the connection is either Company X or some entity authorized by 
Company X to act as Company X for the purpose of being the connection 
endpoint (and, yes, Company X may have been coerced into authorizing 
some other entity to covertly act as the server endpoint). I am not 
saying that I like this or am "espousing" it, I am simply pointing out a 
fact.

Similarly, the best that TLS can offer in terms of privacy is that the 
contents of the communication between the two endpoints is not seen by 
anyone else *unless* at least one of the two endpoints (client or 
server) chooses to provide the contents of the communication to some 
other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

It is also a fact that once a client provides data to a server, there 
are no technical mechanisms that would allow the client to limit what 
the server does with that data. As has been show over and over again, 
including by you, it is very frequently the case that the server that 
initially receives the data passes it on to others. The others may be 
back-end database servers or anti-virus scanners, but the client has no 
control over what happens to the data once the server receives it.

I have not tried to argue that draft-rhrd-tls-tls13-visibility is the 
best solution for addressing the need for visibility within the data 
center. Perhaps it is, perhaps it isn't. But, I'm tired of the abusive 
and false suggestions that draft-rhrd-tls-tls13-visibility is a 
"wiretapping" draft or that it is defining a "please-screw-me 
extension." These suggestions have been repeated over and over again, 
even though they have already been countered effectively - "repeating 
points already countered is just disruptive noise."

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 14:28:20 +0000

➢     Similarly, the best that TLS can offer in terms of privacy is that the 
    
Yes it does.  It signals on the wire to any observer that the client and server agree to this.  TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently.

Do you agree with that?

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 25 Oct 2017 10:50:00 -0400

This question is based on your that belief that this protocol will 
"escape" onto the public Internet, that browsers and other clients used 
by individuals will feel forced to implement it, and that clients will 
then be forced to enable the extension in order to get through 
middleboxes that would filter traffic based on whether or not the 
extension is present in the ClientHello. I've already explained why I 
believe that scenario will never happen, and so no I do not agree that 
it is a "fundamental change."

The idea of a client extension was added based on feedback at the Prague 
meeting in order to help prevent the protocol from being used over the 
public Internet, by preventing the protocol from being used without the 
client's knowledge. Obviously you believe that the method being proposed 
to address one concern introduces another concern. I do not share those 
concerns for the reasons that I've already stated.

I don't plan to comment on this issue any further, and doing so would 
just be repeating myself, thus just adding to the noise.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 14:56:20 +0000

>    This question is based on your that belief that this protocol will "escape" onto the public Internet

Yes.  Are you saying that you don’t believe that the enterprise visibility will stop at their firewall?  That they will allow ‘stock’ TLS 1.3 to work connecting to their sites?  That the airplane/wifi provider won’t say ‘download our free browser’?

I think you’re being very naïve to think otherwise.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 25 Oct 2017 11:18:02 -0400

I've already responded to this! Why are you wasting everyone's time by 
asking the same questions over and over, even though I've already 
clearly answered them?

An airplane/wifi provider might say "download our free browser," but it 
won't rely on draft-rhrd-tls-tls13-visibility to snoop on its customers. 
If the airplane/wifi provider controls the software on its customers' 
computers, it doesn't need the cooperation of the servers that the 
customers are connecting to in order to snoop, so it wouldn't go through 
the effort of trying to get that cooperation. And, if the airplane/wifi 
provider has the cooperation of the servers that the customers are 
connecting to it doesn't need to convince its customers to download any 
software or in any other way get the customers to cooperate in allowing 
the snooping, so it won't bother.. If you believe otherwise, then you 
are the one who is being very naïve.

I can't guarantee that enterprise visibility will stop at the enterprise 
firewall. My argument is simply that use of the protocol in this draft 
will stop at the enterprise firewall since outside the firewall, when 
communicating with clients outside of the enterprise's control, the 
enterprises that want to enable "visibility" into such traffic will use 
other means that don't require the the cooperation or knowledge of the 
clients, since those other means would be easier and more effective. You 
have done nothing to suggest otherwise.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 16:06:46 +0000

> since those other means would be easier and more effective. You 
  
Public-key pinning and CT seem like they would prevent those other mechanisms.  No?

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 25 Oct 2017 16:11:39 +0000

" idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge."

Responding ONLY to the above sentence,  as I agree with Stephen that this has  gotten too NOISY.  

But at the end of the WG meeting in Prague,  the Chairs asked for the two sides to work together to find common ground.   We tried very hard to set up as many meetings as we could.  Very few would meet with us.   Ted Lemon was one.   As is evident,  Ted and I don't always agree,  but he went out of his way to meet with us and exchange views,  which was greatly appreciated and the type of effort it will take for two sides that do not agree, to find some form of compromise.    
The only person that gave us constructive ideas in the common ground, was Martin Thompson,  who we all greatly appreciate meeting with us as well.   Out of that meeting came the idea that having the client be aware,  could address some of the issues brought up in the WG meeting.  
My point here is that we are trying hard to find ANY common ground and want to work towards this.   The client aware feature being added is NOT something that Enterprises want or need,  but was an effort to compromise and attempt to gain mutual consensus.  
And if this is not a feature that everyone wants,  then so be it.   But at least it was an attempt by a small number of people to try to find common ground and make any form of progress.  
If we could do more of this and less of the negative, duplicative and sometimes insulting rhetoric on this list,  perhaps we can make progress.   

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Wednesday, October 25, 2017 10:50 AM
To: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that would filter traffic based on whether or not the extension is present in the ClientHello. I've already explained why I believe that scenario will never happen, and so no I do not agree that it is a "fundamental change."

The idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge. Obviously you believe that the method being proposed to address one concern introduces another concern. I do not share those concerns for the reasons that I've already stated.

I don't plan to comment on this issue any further, and doing so would just be repeating myself, thus just adding to the noise.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Oct 2017 12:12:23 -0400

> Public-key pinning and CT seem like they would prevent those other

Remember that non-default, user-installed root certificates are exempted
from those mechanisms in all current browsers.

--Richard

---

From: Roland Zink <[email-masked]>
Date: Wed, 25 Oct 2017 18:21:39 +0200

It could but RFC 7469 section 2.6 
(https://tools.ietf.org/html/rfc7469#section-2.6) says:

"  It is acceptable to allow Pin
    Validation to be disabled for some Hosts according to local policy.
    For example, a UA may disable Pin Validation for Pinned Hosts whose
    validated certificate chain terminates at a user-defined trust
    anchor, rather than a trust anchor built-in to the UA (or underlying
    platform)."

and most browsers seem to follow this mitm exception.

Regards,
Roland

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 25 Oct 2017 12:42:53 -0400

No, they would not prevent those other
mechanisms. Where is your evidence that they would?

If the "attacker" controls the software that the client is using,
then it would set up the software to not check public-key pinning
or CT, if necessary. As Richard noted, this may not even require
developing custom software. It may be as simple as distributing a
standard browser with its own CA added as a "user-installed" root
certificate.

In the case that the "attacker" has the cooperation of the server,
and the client is using unmodified software, then the data sent
between the client and server (including the server's certificate)
would be no different than if the server wasn't allowing the
"attacker" to have access to the data. There would be no
information available to the client at all that would distinguish
between scenarios in which the server either is or isn't allowing
another party to have access to the data being transmitted over
the TLS session.

If public-key pinning and CT would prevent other mechanisms from
working, please explain in detail how they would do so. Or better
yet, let's end this line of discussion and work on finding
mutually agreeable solutions to the underlying problem.

On 10/25/2017 12:12 PM, Richard Barnes wrote:

Public-key pinning and CT seem like they would
prevent those other mechanisms.  No?

Remember that non-default, user-installed root
certificates are exempted from those mechanisms in all
current browsers.

--Richard

TLS mailing list

[email-masked]

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 25 Oct 2017 13:27:42 -0400

> and most browsers seem to follow this mitm exception.

The browsers are also complicit in the coverup. Reporting the broken
pinset to the user or site is a  "should not", even though
organizational policies and regulations may require it.

Jeff

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 22:34:13 +0100

Replying to just a couple of bits...

> other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.

> But, I'm tired of the abusive
> extension." 

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 22:47:48 +0100

On 25/10/17 17:11, Ackermann, Michael wrote:
> And if this is not a feature that everyone wants,  then so be it.
> But at least it was an attempt by a small number of people to try to
> find common ground and make any form of progress. 

I do not accept that there is an onus on IETF participants
to acquiesce to bad ideas in the name of finding common ground.
The IETF is not that kind of SDO (at least I hope not).

When a thing is a sufficiently bad idea, then it is not a good
plan to try meet it half-way. That is the case with the basic
idea here.

So, sorry, no - compromise is not a goal.

OTOH, investigating non-damaging means of meeting data centre
requirements that do not involve TLS is an entirely fine thing
to do IMO. (Though maybe not the oft-quoted but *never* so far
substantiated claims related to PCI;-).

I would encourage you and others to go do that. If that calls
for the development of a new multi-party security protocol
that can be used in such environments, that is also just fine
and could have other interesting uses.

One could also do work to try make it easier for sites to
evolve towards use of (closer to, but not, perfect) forward
secrecy.

But breaking TLS is very different to both and is not fine.

S.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Oct 2017 23:37:41 +0100

On Oct 25, 2017 22:34, "Stephen Farrell" <[email-masked]> wrote:

Sorry, what?  The current draft proposes an extension, literally the
opposite of a standard, supported feature.  It's explicitly optional.

I don't really have a dog in this fight, but let's please be accurate.

--Richard

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 23:40:40 +0100

> opposite of a standard, supported feature.  It's explicitly optional.

Optional is not the opposite of standard.

See the intended status below.

> I don't really have a dog in this fight, but let's please be accurate.

Accuracy level is just fine I think.

S.

Network Working Group                                         R. Housley
Internet-Draft                                            Vigil Security
Intended status: Standards Track                                R. Droms
Expires: April 2, 2018                              Interisle Consulting
                                                      September 29, 2017

     TLS 1.3 Option for Negotiation of Visibility in the Datacenter
                   draft-rhrd-tls-tls13-visibility-00

---

From: Peter Bowen <[email-masked]>
Date: Wed, 25 Oct 2017 15:58:24 -0700

> Accuracy level is just fine I think.

So, to be completely clear, no one is arguing that Nick's three
options (quoted below) are wrong or do not work.  The objection is
that the IETF should not be publishing a RFC that documents them, is
that right?

Nick Sullivan wrote:
> 1) use TLS 1.2 with RSA -> one single key
> 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to draft-green)
> 3) use any version of TLS and export the session keys -> corpus of keys equal to number of connections

Thanks,
Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Oct 2017 00:10:46 +0100

> that the IETF should not be publishing a RFC that documents them, is

No, it's not that simple.

For myself, I disagree with some aspect's of Nick's analysis, which
we can go into as needed. I don't think that's needed in this mail.

On your second point...

The IETF has a range of policies (BCPs etc) that call for use of
strong and not-weakened cryptography in protocols. Some of that
is mentioned in places at [1] but I'm sure a more complete job
could be done. There are sound technical reasons why the IETF has
consensus on a bunch of those positions. For some of those, it
is also true that the consensus has always been rough, e.g. I
think it's true there have always been IETFers who would actually
like to MitM security protocols for what they consider good
reasons. (That doesn't make those people either bad or correct.)

One particular relevant RFC (2804) does explicitly envisage that
people who want to do snooping might document their ways of doing
that in independent stream RFCs (which are not IETF RFCs despite
almost no RFC-readers grokking any difference there;-). But in
this case the authors say they want standards-track. And in the
previous case, from talking with Russ, he didn't see any benefit
in the independent stream route (which I didn't understand at the
time tbh).

So the situation is actually sort-of clear, but not simple. It's
true that appreciating the clarity requires quite a bit of IETF
lore ;-)

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Oct 2017 23:50:55 +0000

➢ options (quoted below) are wrong or do not work.  The objection is
    that the IETF should not be publishing a RFC that documents them, is
    that right?
    
Not at all.

But maybe I’m mistaken; do you have links to messages that said that?

The draft in the subject line is a different item altogether.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 29 Oct 2017 20:10:41 -0700

On 25 Oct 2017, at 15:37, Richard Barnes wrote:

> opposite of a standard, supported feature.

I agree with Stephen on this (narrow) point. The draft is on Standards 
Track, which means is proposes a standard. The fact that it is an 
"extension" is irrelevant in TLS: lots of things that are part of the 
standard; see Section 4.2 draft-ietf-tls-tls13.

> It's explicitly optional.

I can find nothing in the draft that says that.

> I don't really have a dog in this fight, but let's please be accurate.

Agree on both counts.

--Paul Hoffman