Subject: [TLS] datacenter TLS decryption as a three-party protocol

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Jul 2017 08:09:55 -0500

As Stephen noted in his presentation, a lot of the proposals for passive
decryption can be seen as trying to turn TLS from a two-party protocol
into a three-party protocol.  Which is probably the right way to think
about it, even when all (three) parties are within the same
administrative domain.

Stephen also said something about it being hard to shoehorn a
three-party protocol into the API for a two party protocol.  But
depending on the specifics, maybe it's not so bad.  For example, if the
only semantics you need are a new API for "this is the list of third
parties I authorize to wiretap this connection", the scope seems fairly
limited.

Another thought spawned from today's session is that, given concerns
about preventing/noticing if schemes intended for the datacenter leak
out onto the internet, it's not really clear that "minimizes changes to
the wire protocol" should be considered a benefit of proposals in this
space.  If there are clear changes to the wire protocol, that makes it
easy to detect when the scheme is in use.

-Ben

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 15:43:36 +0200

This is exactly right.   We have a *real* problem here.   We should *really*
solve it.   We should do the math.   :)

On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk <[email-masked]> wrote:

> decryption can be seen as trying to turn TLS from a two-party protocol into
> a three-party protocol.  Which is probably the right way to think about it,
> even when all (three) parties are within the same administrative domain.
>
> Stephen also said something about it being hard to shoehorn a three-party
> protocol into the API for a two party protocol.  But depending on the
> specifics, maybe it's not so bad.  For example, if the only semantics you
> need are a new API for "this is the list of third parties I authorize to
> wiretap this connection", the scope seems fairly limited.
>
> Another thought spawned from today's session is that, given concerns about
> preventing/noticing if schemes intended for the datacenter leak out onto
> the internet, it's not really clear that "minimizes changes to the wire
> protocol" should be considered a benefit of proposals in this space.  If
> there are clear changes to the wire protocol, that makes it easy to detect
> when the scheme is in use.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 19 Jul 2017 15:51:08 +0200

On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <[email-masked]> wrote:

> This is exactly right.   We have a *real* problem here.   We should
> *really* solve it.   We should do the math.   :)
>

Is there appetite to do this work? If we restrict this to two paths, one of
which is spending years designing and implementing a new multi-party
security protocol, the other of which is silently and undetectably (at
least on private networks) modifying the standardized protocol for which
lots of well-tested code already exists... my money is on the latter
happening.

In every decision we make with respect to the static DH approach, we have
to keep in mind that this change can be implemented unilaterally, i.e.,
without any modifications for interop. Consequently, I think the work we
really need to do is to design and implement a FS-breakage detector so we
can at least tell when this is happening on the public internet. Beyond
that, the best we can really do is ask implementors to be polite and
intentionally make their implementations not interoperate silently with TLS
1.3.

Kyle

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 16:02:31 +0200

Bear in mind that what we (or at least I) want out of not publishing a spec
is that this technology not be present by default in TLS implementations.
If someone wants to maintain a set of patches, there's not much we can do
about it, and I don't honestly care *because* there isn't much that we can
do about it.   What I do not want to see is *the IETF* recommending this
solution.

It would be very nice if the people who are hot on a solution to this
problem were willing to do the work to do the three-way protocol.   But the
purpose of pointing out that that is the right solution is to say "if you
want to solve this problem in the IETF, here is what we could do that might
get IETF consensus."

On Wed, Jul 19, 2017 at 3:51 PM, Kyle Rose <[email-masked]> wrote:

> Is there appetite to do this work? If we restrict this to two paths, one
> of which is spending years designing and implementing a new multi-party

---

From: Kyle Rose <[email-masked]>
Date: Wed, 19 Jul 2017 16:12:18 +0200

On Wed, Jul 19, 2017 at 4:02 PM, Ted Lemon <[email-masked]> wrote:

> Bear in mind that what we (or at least I) want out of not publishing a
> spec is that this technology not be present by default in TLS
> implementations.   If someone wants to maintain a set of patches, there's
> not much we can do about it, and I don't honestly care *because* there
> isn't much that we can do about it.   What I do not want to see is *the
> IETF* recommending this solution.
>

Agreed. <req:newsletter-subscribe />

---

From: Roland Zink <[email-masked]>
Date: Wed, 19 Jul 2017 16:22:22 +0200

Am 19.07.2017 um 15:51 schrieb Kyle Rose:
> On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This is exactly right.   We have a /real/ problem here.   We
>     should /really/ solve it. We should do the math.   :)
>
>
> Is there appetite to do this work? If we restrict this to two paths, 
> one of which is spending years designing and implementing a new 
> multi-party security protocol, the other of which is silently and 
> undetectably (at least on private networks) modifying the standardized 
> protocol for which lots of well-tested code already exists... my money 
> is on the latter happening.
>
There is a good chance that this "cheaper" solution is what will happen. 
However the multi-party protocol may be a safer and better approach and 
may even forced in by some regulators when it exists as an implemented 
alternative.

> In every decision we make with respect to the static DH approach, we 
> have to keep in mind that this change can be implemented unilaterally, 
> i.e., without any modifications for interop. Consequently, I think the 
> work we really need to do is to design and implement a FS-breakage 
> detector so we can at least tell when this is happening on the public 
> internet. Beyond that, the best we can really do is ask implementors 
> to be polite and intentionally make their implementations not 
> interoperate silently with TLS 1.3.
>
> Kyle
>
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 19 Jul 2017 15:07:03 +0000

>>> This is exactly right.   We have a real problem here.   We should really solve it.  
>>> We should do the math.   :)
>>
>>  Is there appetite to do this work? If we restrict this to two paths, one of which is
>> spending years designing and implementing a new multi-party security protocol, 
>> the other of which is silently and undetectably (at least on private networks) modifying
>> the standardized protocol for which lots of well-tested code already exists...
>> my money is on the latter happening.
>

Sure. The point is that IETF *must not* support such “undetectable modifications of a standard protocol”.
The fact that crime invariably happens does not imply that we should become criminals. ;-)

> However the multi-party protocol may be a safer and better approach and may even
> forced in by some regulators when it exists as an implemented alternative.

IETF is supposed to be about designing and (until a decade or so ago) implementing the *right* solutions. In this case multi-party protocol  appears to be “it”. 

So let those who need this capability spearhead the design, with cryptographers and academia helping that work or at least auditing the results.

>> In every decision we make with respect to the static DH approach, we have to keep
>> in mind that this change can be implemented unilaterally, i.e., without any modifications
>> for interop. Consequently, I think the work we really need to do is to design and implement
>> a FS-breakage detector so we can at least tell when this is happening on the public internet.

I agree. Though I don’t know off-hand if this is technically possible. Because as you pointed out, an end-point can always choose to leak its part out-of-band, and there’s nothing his communicating peer can do about it (AFAIK). (We can at least make sure that the official implementations such as OpenSSL and GnuTLS do not include such “extensions”.)

Still, a multi-party protocol that makes the presence or absence of such monitoring explicit, would be the best option, IMHO.

>> Beyond that, the best we can really do is ask implementors to be polite and intentionally
>> make their implementations not interoperate silently with TLS 1.3.

I agree.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Jul 2017 18:02:19 +0200

> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 

At the very least, a standards-track multi-party protocol like that can be something that standards like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without backdoors unless you really need to and in that case use *this*”.

That is better guidance than “Do TLS 1.3 without backdoors, unless you really need to and in that case do whatever works for you"

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 19 Jul 2017 16:28:32 +0000

> At the very least, a standards-track multi-party protocol like that can be something that standards
> like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without backdoors unless you really
> need to and in that case use *this*”.
  
One emphatic YES.

---

From: Derrell Piper <[email-masked]>
Date: Wed, 19 Jul 2017 18:36:40 +0200

> On Jul 19, 2017, at 6:02 PM, Yoav Nir <[email-masked]> wrote:
> 
> That is better guidance than “Do TLS 1.3 without backdoors, unless you really need to and in that case do whatever works for you”

Yes, that’s what I would like to see after today’s meeting too.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 17:49:39 +0100

> parties I authorize to wiretap this connection", the scope seems fairly

I would question the size of the set of applications for which the
semantics of such a list/interface could make sense. For example,
asking a person if they're ok with some random IPv6 address spying
on a TLS session makes zero sense for example.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Jul 2017 11:58:52 -0500

> on a TLS session makes zero sense for example.

Sure, some random IPv6 address makes no sense, and is not
cryptographically bound to anything.
On the other hand, "this (semi-)static DH key is one currently used by
my enterprise's network monitoring system, and is allowed to read my
traffic" seems closer to what is being asked for.

As has been said downthread, the recommendation is not "you should
always use this thing", it's "you should do TLS 1.3 without backdoors,
but if you really need to, this is a way to do so with known and limited
properties".

-Ben

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 18:33:40 +0100

> traffic" seems closer to what is being asked for.

I don't know how that kind of identifier can be made meaningful
for almost any application where the identifier is not already
meaningful, and in many such cases I would guess there are
already hop-by-hop behaviours where TLS is not e2e for the
application layer (MTAs etc.) But sure, someone could do the
work to describe some applications that might have a need for
a multiparty security protocol like that I guess. As I said,
my guess is that the size of that set of applications is small.

> but if you really need to, this is a way to do so with known and limited

I can see why people might consider that some kind of compromise
that's less bad, but I think searching for "less bad" is not at all
the right approach. I don't mean that we oughtn't investigate
possible scenarios, but searching for a compromise is not in itself
a good goal here.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 19:38:44 +0200

The problem is that the actual solution to this problem is to accept that
you aren't going to be able to decrypt the streams, and then figure out
what to do instead.   Which is work the proponents of not doing that are
not interested in doing, understandably, and which is also not the work of
this working group.

I'm skeptical that there is a way for this working group to solve the
proposed problem, but if there is, it involves figuring out a way to do
this that doesn't make it easy to MiTM *my* connections, or, say, those of
activists in dangerous places.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 10:45:13 -0700

On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <[email-masked]> wrote:

> this that doesn't make it easy to MiTM *my* connections, or, say, those
> of activists in dangerous places.
>

I find this a very bizarre outcome that works against our collective goals.
If there is no mechanism at all, then it is quite likely that organizations
will use static-DH or stay on TLS1.2. Those are bad options, in my opinion,
because there's no signaling or opt-in to the client. We can do much better
than that.  Client opt-ins are far from academic. For example, browser's
incognito modes may refuse to support such sessions, if they knew what was
going on.

It's also bad if organizations end up deploying static-DH and that means we
can't do things like checking for changing DH parameters.

It seems like we would be rejecting a good opportunity to make what the
network operators want work in a better and more secure way, while making
it harder for passive observers and coercive authorities, to use the same
mechanism for other purposes. What do we gain? beyond a hollow moral
victory.

-- 
Colm

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 19:55:15 +0200

Sorry, the more I think about how to do this in a way that doesn't make
things worse, the less faith I have that it is possible.   But if you know
of a way to do it, I certainly don't oppose you doing it.   I'm not an
expert: the fact that I don't see how to do it doesn't mean it can't be
done.

On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh <[email-masked]>
wrote:

> I find this a very bizarre outcome that works against our collective
> goals. If there is no mechanism at all, then it is quite likely that
> organizations will use static-DH or stay on TLS1.2. Those are bad options,
> in my opinion, because there's no signaling or opt-in to the client. We can
> do much better than that.  Client opt-ins are far from academic. For
> example, browser's incognito modes may refuse to support such sessions, if
> they knew what was going on.
>
> It's also bad if organizations end up deploying static-DH and that means
> we can't do things like checking for changing DH parameters.
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 11:01:03 -0700

> expert: the fact that I don't see how to do it doesn't mean it can't be

I think it was Nick who had the idea of adding a message to the TLS
transcript that encrypts the PMS or session key under a public key. This
had some advantages:

* Static-DH can be banned and clients can check for changing DH parameters.
* The technique would be signaled and opt-in to clients; they can terminate
the connection if they don't want it. Clients could insist on being
configured to support it, not support it in incognito mode, etc.
* The PMS/key could be encrypted under a different key than the key pair
used to authenticate the server; this means that the servers needn't have a
key that can decrypt these transcripts. It can be kept offline. It also
means that the investigation team needn't have access to the servers
certificate private key. Much better all-round.
* Still can work with tcpdump/wireshark etc, but not very useful to three
letter agencies, etc.

>>> The problem is that the actual solution to this problem is to accept
>>> that you aren't going to be able to decrypt the streams, and then figure
>>> out what to do instead.   Which is work the proponents of not doing that
>>> are not interested in doing, understandably, and which is also not the work
>>> of this working group.
>>>

-- 
Colm

---

From: BITS Security <[email-masked]>
Date: Wed, 19 Jul 2017 18:05:53 +0000

> It seems like we would be rejecting a good opportunity to make what the network operators want work in a better and more secure way, while making it harder for passive observers and coercive authorities, to use the same mechanism for other purposes. What do we gain? beyond a hollow moral victory.

+1 and this is fundamentally why we’ve made significant effort to work within the IETF process.  We strongly believe a consensus outcome will be better for all, including those who are currently in disagreement.  What we’d like to avoid is being told the solution is to ignore (or admire) the problem.  Finding a workable solution will reduce the risk of forking TLS and will increase the broad adoption of 1.3.

-Andrew

From: TLS [mailto:[email-masked]] On Behalf Of Colm MacCárthaigh
Sent: Wednesday, July 19, 2017 1:45 PM
To: Ted Lemon <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
The problem is that the actual solution to this problem is to accept that you aren't going to be able to decrypt the streams, and then figure out what to do instead.   Which is work the proponents of not doing that are not interested in doing, understandably, and which is also not the work of this working group.

I'm skeptical that there is a way for this working group to solve the proposed problem, but if there is, it involves figuring out a way to do this that doesn't make it easy to MiTM my connections, or, say, those of activists in dangerous places.

I find this a very bizarre outcome that works against our collective goals. If there is no mechanism at all, then it is quite likely that organizations will use static-DH or stay on TLS1.2. Those are bad options, in my opinion, because there's no signaling or opt-in to the client. We can do much better than that.  Client opt-ins are far from academic. For example, browser's incognito modes may refuse to support such sessions, if they knew what was going on.

It's also bad if organizations end up deploying static-DH and that means we can't do things like checking for changing DH parameters.

It seems like we would be rejecting a good opportunity to make what the network operators want work in a better and more secure way, while making it harder for passive observers and coercive authorities, to use the same mechanism for other purposes. What do we gain? beyond a hollow moral victory.

--
Colm

---

From: [email-masked] (Martin Rex)
Date: Wed, 19 Jul 2017 22:25:15 +0200 (CEST)

I just watched the presentation on static DH / TLS decryption in Enterprise
settings of todays TLS session

  https://youtu.be/fv1AIgRdKkY?t=4473

and I'm seriously appalled by the amount of cluelessness in the
Networking & IT Departments on the one hand, and by what seems like
woefully inadequate apps on the other hand.

I've been doing middleware development and customer support of
SSL/TLS-protected communication for our company's (legacy) app
as well as maintenance & customer support for the TLS stack we're
shipping with it for the past 17 years, and I can't stop shaking
my head about the perceived problems, that *NEVER*EVER* occurred
to me, nor our IT & Hosting and neither any of our customers using our app
(and I would definitely know about it).

Although we do ship our own TLS implementation, we don't have any APIs
to export cryptographic keys, simply because it's completely unnecessary.

With extremely few exceptions, an API-level trace at the endpoints
is totally sufficient for finding app-level problems, such as
unexpected "expensive" requests.  App-level traces on *EITHER* side
should provide *ALL* information that is necessary to determine _which_
particular requests are taking longer than expected.  If your Apps do
not provide meaningful traces, then you have an *APPS* problem, and
should be fixing or replacing apps, rather than mess around with TLS.

There were a few issues with F5 loadbalancers (that were just forwarding
traffic, _not_ acting as reverse proxy) related to a borked F5 option called
"FastL4forward", which occasionally caused the F5 box to truncate TCP streams
(the box received&ACKed 5 MByte of TCP data towards the TLS Server, but
forwarded only 74 KBytes to the client before closing the connection with
a TCP FIN towards the TLS client.

And once I saw another strange TCP-level data corruption caused by some Riverbed WAN accellerator.

I remember exactly _two_ occasions during that 17 years when I produced
a special instrumented version of our library for the server endpoint,
which dumped stuff into a local trace file, but I never ever thought
about exporting crypto keys (because it wouldn't help, and those
weren't _my_ keys (but those of a customer):

   (1) it dumped the decrypted RSA block from the ClientKeyExchange
       handshake message when encountering a PKCS#1 BT02 padding
       encoding failure

   (2) it dumped the final decrypted block of a TLS record for
       when the CBC-padding-verification failed the check.

(1) was caused by a bug in the long integer arithmetic of an F5 load balancer
    which ocassionally produced bogus (un-decryptable) PreMasterSecrets

(2) was caused by a design flaw in JavaSE 1.6 by Java's SSL when it was used with GenericBlockCipher over native-IO interfaces.

I firmly believe that if you have a desire to decrypt TLS-protected
traffic to debug APPS issues, then your APPS must be crap, and seriously
lack capabilities to trace/analyze endpoint behaviour at the app level.

With respect to "monitoring" SSL/TLS-protected traffic in the
enterprise environment:

At least here in Germany, we're in the lucky position that wiretapping
network traffic has been made a criminal offense in 2004.  If IT/Networking
folks in the enterprise settings don't want to spend up to 4 years behind
bars, they don't even try to decrypt SSL/TLS-protected traffic.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 19 Jul 2017 22:32:04 +0200 (CEST)

> some Riverbed WAN accellerator.

I forgot to mention how I analyzed the breakage created by the middleboxes:

network capture (tcpdump) with a IP-address capture filter for a dedicated
client machine was *perfectly* sufficient to determine the TCP-level breakage.

For the F5 cockup, we used a concurrent tcpdump capture on the box in both
directions, again with IP-address capture filter, in order to prove to the
vendor that his box is corrupting/truncating the TCP stream between
TLS client and TLS server.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Jul 2017 21:25:17 +0000

> I find this a very bizarre outcome that works against our collective goals. If there is no mechanism at all, then it is quite likely that organizations will use static-DH or stay on TLS1.2. Those are bad options, in my opinion, because there's no signaling or opt-in to the client. We can do much better than that. 

If an organization needs to decrypt the network traffic, then it should probably continue to use a scheme that has a static key so that it can do that.

At least for the next three years.

---

From: Roland Zink <[email-masked]>
Date: Wed, 19 Jul 2017 23:34:12 +0200

> TLS client and TLS server.
In many companies the app is from one vendor and the loadbalancer from 
another one. Both vendors are telling you the other is causing the 
problem. Then you will have some fun to turn on undocumented app level 
tracing. However the proposed solution will have the same problem when 
the app doesn't support it.

One question to the company proponents, would you allow the end / home 
users the same capabilities? E.g. some equipment at home/cellular  is 
phoning back to the vendor. The owner of the equipment can't see what is 
transferred and need to trust the vendor, so should end users get the 
keys? It can be a similar problem, e.g. the app doesn't work as expected 
and the vendor says this must be the home / cellular network. How to 
proof that it is the app fault and not the home network?

Regards,
Roland

P.S. Be careful as I think preparing for wiretapping and having tools 
for it may already bring you behind bars in Germany, although I think 
this law wasn't used so far.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 23:50:32 +0100

On 19/07/17 18:45, Colm MacCárthaigh wrote:
> For example, browser's

That is a perfect example of the hideous dangers of all of this.
The implication in the above is that browsers would/should turn
on wiretapping support in the normal case.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 23:57:59 +0100

Just to note that Martin's mail contains specific examples
and detailed argument. That should be the lowest bar that
needs to be met in this discussion, not the arm-waving about
"TLS as a DoS attack" or "what about grandma" nonsense that
we heard today. The contrast between such non-argument and
the care that has been taken, and continues to be taken, in
the development of TLS1.3 is stark.

S.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 16:05:13 -0700

> on wiretapping support in the normal case.

Today browsers do turn on wiretapping support in the normal case. There's
nothing they can do about it, and it works right now.

If static-DH is permitted, and I don't mean if we release a document
describing it, I mean if we don't forbid static DH parameters; this will
also continue to be the case. My take: I think we should forbid static DH
for this reason.

Next, if proxies are deployed as the mechanism, this will also continue to
be the case. Again, nothing a browser can do, and I argue that real-world
security is left much much worse for users too.

On the other hand, if we standardize a signaled, opt-in, mechanism; then
browsers have more fine-grained options. I suspect that browsers would NOT
support this by default, just as they don't accept private CAs by default.
Instead the browser would have to configured per a corporate policy. But
they could /also/ choose to disable incognito mode in such circumstances,
to be more fair to end-users. It's an example of something that can't be
done today at all.

Such a mode is likely fine for the corporate users and what they want, but
is not so useful for intelligence agencies and so on, precisely because its
signaled and a bit more transparent. In real world terms, I would regard it
much /less/ likely to create the kind of MITM infrastructure that's useful
for that case.

-- 
Colm

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 19 Jul 2017 16:09:40 -0700

On Wed, Jul 19, 2017 at 6:09 AM, Benjamin Kaduk <[email-masked]> wrote:

> protocol into the API for a two party protocol.
>

Trying to turn a two-party protocol into a three party protocol is a
classical source of confused deputy vulnerabilities:

http://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf

This is why I have been such a strong proponent of using something like a
TLS extension for this sort of thing if it is to happen. At least that way
we get mutual client and server consent.

-- 
Tony Arcieri

---

From: Andrei Popov <[email-masked]>
Date: Thu, 20 Jul 2017 06:40:21 +0000

Hi Colm,

  *   Today browsers do turn on wiretapping support in the normal case. There's nothing they can do about it, and it works right now.

This is news to me; which browsers do this (so that I can avoid using them)?

Thanks,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Colm MacCárthaigh
Sent: Thursday, July 20, 2017 1:05 AM
To: Stephen Farrell <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
That is a perfect example of the hideous dangers of all of this.
The implication in the above is that browsers would/should turn
on wiretapping support in the normal case.

Today browsers do turn on wiretapping support in the normal case. There's nothing they can do about it, and it works right now.

If static-DH is permitted, and I don't mean if we release a document describing it, I mean if we don't forbid static DH parameters; this will also continue to be the case. My take: I think we should forbid static DH for this reason.

Next, if proxies are deployed as the mechanism, this will also continue to be the case. Again, nothing a browser can do, and I argue that real-world security is left much much worse for users too.

On the other hand, if we standardize a signaled, opt-in, mechanism; then browsers have more fine-grained options. I suspect that browsers would NOT support this by default, just as they don't accept private CAs by default. Instead the browser would have to configured per a corporate policy. But they could /also/ choose to disable incognito mode in such circumstances, to be more fair to end-users. It's an example of something that can't be done today at all.

Such a mode is likely fine for the corporate users and what they want, but is not so useful for intelligence agencies and so on, precisely because its signaled and a bit more transparent. In real world terms, I would regard it much /less/ likely to create the kind of MITM infrastructure that's useful for that case.

--
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 23:57:03 -0700

On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov <[email-masked]>
wrote:

> Hi Colm,
>
>
>
>    - Today browsers do turn on wiretapping support in the normal case.
>    There's nothing they can do about it, and it works right now.
>

Like I said, all of them. I don't know of a single browser that forces
DH-only and insists on unique DH parameters today, and it wouldn't be
practical.  So if we're going to refer to an operator who has the server's
private key using their own key to decrypt traffic as wire-tapping, then in
those terms currently all browsers have support for that turned on, as it's
part of existing versions of TLS.

-- 
Colm

---

From: Andrei Popov <[email-masked]>
Date: Thu, 20 Jul 2017 07:33:33 +0000

Ah, I get what you’re saying.

DH parameter reuse for performance reasons is not a good thing, and it is not something recommended in the TLS RFCs. But offering standardized ways of exporting/importing keys for wiretapping/surveillance/discovery/analysis purposes is quite different. If a browser were to support this, I would want to avoid using such a browser.

Industry or corporate standards could define key import/export/escrow methods, and certainly SW vendors may choose to support them.
At the IETF, IMHO, we can better contribute by focusing on key protection, non-exportability and attestation.

Cheers,

Andrei

From: Colm MacCárthaigh [mailto:[email-masked]]
Sent: Thursday, July 20, 2017 8:57 AM
To: Andrei Popov <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Colm,

Like I said, all of them. I don't know of a single browser that forces DH-only and insists on unique DH parameters today, and it wouldn't be practical.  So if we're going to refer to an operator who has the server's private key using their own key to decrypt traffic as wire-tapping, then in those terms currently all browsers have support for that turned on, as it's part of existing versions of TLS.

--
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Jul 2017 07:44:00 +0000

It’s like saying “all browsers that support TLS support wiretapping because of the static RSA key exchange.”

It’s a little disingenuous

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 20 Jul 2017 09:43:57 -0700

> It’s a little disingenuous

It sure is! and hyperbolic, but that's the term that people keep applying,
so it's clarifying to use it consistently whenever we talk about this.

While I'm at it, I can't make sense of:

"Using the RSA key to decrypt traffic to your server is wire-tapping."
"Using the RSA key to impersonate and MITM your server isn't wire-tapping."

We'll still support the latter, which is much worse than the former :( I
can't see how offering something /between/ the two, more secure than the
latter, isn't a net improvement on where we'll be with TLS1.3.

-- 
Colm

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Jul 2017 17:55:20 +0100

On 20/07/17 17:43, Colm MacCárthaigh wrote:
> that's the term that people keep applying,

That term was appropriate for draft-green as justified in [1]
That's disputed by some folks but it's the correct term.

Claiming that current browsers "support" wiretapping is plain
odd to me and not that useful for the discussion but isn't a
TLS protocol issue as we don't currently have, and don't have
a WG proposal for a draft-green like wiretapping API as part
of the TLS WG set of RFCs.

S.

[1] https://github.com/sftcd/tinfoil#why-is-this-wiretapping

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 20 Jul 2017 10:08:12 -0700

> That's disputed by some folks but it's the correct term.

If you maintain that draft-green is Wiretapping, then that is also the
correct term for what is happening today. Today, operators are using a
static key, used on the endpoints they control, to decrypt traffic
passively. The only difference is DH vs RSA, and I know you'll agree that's
not material.

> of the TLS WG set of RFCs.

It is odd ... and I'm being deliberately provocative to get at the
doublethink. It is impossible to consider this mode wiretapping and not
claim the browsers support it today. Plainly, they do.

We don't live in an abstract theoretical world in which this is not already
happening, and is not already possible. It will also continue to be
possible to MITM traffic, if you have the RSA key, and some dh-static
opponents even advocate for this. I have seen no intellectually consistent
explanation for why that is ok, why that won't be abused by coercive
authorities, and hence why it is not better to have something in between;
that gives providers what they claim to need, but not the coercers.

-- 
Colm

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Jul 2017 18:21:44 +0100

> claim the browsers support it today. Plainly, they do.

In what sense does a browser "support" a server leaking a private
key via some proprietary interface? That makes zero sense to me
and seems sheer hyperbole, as you said yourself. And not useful.

> We don't live in an abstract theoretical world in which this is not already

More hyperbole is less useful.

> happening, and is not already possible. 

When using crypto in a network protocol, it is impossible to know
or not know that a peer is implementing crypto well or badly.

> It will also continue to be
> explanation for why that is ok, 

I never said it was "ok." I said it wasn't part of the TLS RFCs.

The point here is to not specify mechanisms that enable wiretapping
to the extent that is feasible (you seem to assume that all uses
of crypto "support" wiretapping, since it's always possible for an
implementation to leak keys - that's gibberish IMO, but I'm using
the term in your sense in this paragraph).

> why that won't be abused by coercive
> authorities, 

It could be. It'd still be abuse IMO.

> and hence why it is not better to have something in between;

"something in between" is just nonsense sorry. Your strawman
proposition that we define all crypto as "supporting" wiretapping
being nonsense, means that so is that bogus pseudo-compromise.

But given that this aspect isn't really useful discussion, I
hope we can leave it there.

Cheers,
S.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 20 Jul 2017 11:39:49 -0700

On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell <[email-masked]

> and seems sheer hyperbole, as you said yourself. And not useful.

I think it's most useful to focus on the real world, and what works and
doesn't work in the real world, and the implications for user security,
again in the real world.  I don't think it's useful to engage in
disconnected arguments and debate that lack that focus.

In the real world, the kind of wiretapping you are talking about works
today, people are using it, so plainly it is supported. Let's stay grounded
in that reality.

> or not know that a peer is implementing crypto well or badly.

It absolutely is possible to know that a peer is implementing crypto badly;
for example if they use RC4, or have static DH parameters, those can be
detected. I can't fathom why those concerned with the problems of static-DH
are not advocating for dynamic-DH as a requirement. At a minimum that seems
like the most concrete real-world action that will prevent it. If nothing
is done, then static-DH remains possible.

> to the extent that is feasible

Two observations:

1. as static-DH  makes plain, TLS1.3 continues to enable this kind of
wiretapping. Are you proposing a modification? Do you then agree with my
suggestion that static-DH be actively forbidden and that clients can reject
duplicate DH params?

2. My concern is to specify things that will improve real-world security.
This should always be our goal.

(you seem to assume that all uses
> the term in your sense in this paragraph).

That's not gibberish and it's a really really important point. It *is*
always possible to leak keys, or plaintext. We can't ignore that. That's
part of the security model. Our task is then to make it as unlikely as
possible and to accommodate the needs of users in ways that discourage it.

> It could be. It'd still be abuse IMO.

I think it's a lot less likely that signaled, opt-in, infrastructure would
be used by coercive authorities. It works ok in the corporate cases, where
they control both ends, but  for the coercers, they couldn't just show up
and say "Use a static DH and give us the key" to anyone. Instead they'd
have to say "enable this option that browsers don't enable by default".
This doesn't seem realistic.

-- 
Colm

---

From: [email-masked] (Martin Rex)
Date: Thu, 20 Jul 2017 22:01:14 +0200 (CEST)

> passively. The only difference is DH vs RSA, and I know you'll agree that's

What I'm currently seeing in the installed base for getting at the plaintext
of TLS-protected traffic, are these two approaches:

(1) Server-side:  Reverse-proxy

(2) Client-side:  TLS-intercepting proxy

and neither of these needs to break TLS and neither needs to break forward
secrecy of the SSL/TLS-protected(!) communication.

While Server-side reverse proxies (1) _might_ be used to "inspect/monitor"
traffic, more often it seems to be used for scaling / load-balancing
to multiple backend servers of a server farm.  We ship such functionality
for the backend specifically for scaling/load-balancing, and for placing
the SSL termination point into a DMZ (firewalled backend servers).
We a proprietary scheme to forward SSL/TLS client certs from the
reverse proxy to the backend servers.

(2) is often used by so-called "AV-Software" of the "Internet Security"
kind, and studies have shown over and over again just how badly many of
that stuff breaks security (by botching the TLS server certificate
validation and/or server endpoint identification).

I also see (2) being used by some of our customers in the form of
TLS intercepting internet proxies, mostly in countries that lack
constitutional strong privacy protections (US, UK&CommonWealth, middle EAST).
It regularly breaks outgoing communication scenarios and confused
application admins, because the fake TLS server certificates will be
rejected by our app client unless the trust in explicitly configured.
Something which IT/networking departments occasionally fail to properly
explain to their colleague application admins.

Whenever outgoing communication requires the use of SSL/TLS client certs,
existing TLS intercepting proxies don't work (and I'm really glad that they
break).  A growing number of legal/governmental data exchange scenarios
use SSL/TLS client certs (something I really appreciate, because the use
of client certs fixes a number of problems).  :-)

Personally, I consider server-side reverse proxies primarily as an
implementation detail of the backend (how workload is distributed
within the backend).

The client-side TLS intercepting proxies, however, are a constant security
problem, and unless it is a ***TRUELY*** voluntary, consenting opt-in,
and running on the same machine as the user, and with the user in full
control on whether and how that intercepting proxy is used.

If presence & use of a TLS intercepting proxy is the result of anything
along the lines of "compliance", "policy" or "conformance", then it is
wire-tapping, with a probability near certainty.

-Martin

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 20 Jul 2017 20:15:03 +0000

Maybe we are better off just retrofitting RSA-key-transport back into TLS-1.3? In that case at least the peer could refuse this method of key establishment, and one could safely assume that if a peer insists on that key establishment mechanism, this session will be surveilled?

If I had to choose between the two evils, RSA-key-transport seems a lesser one (or at least a more obvious/visible one).
--
Regards,
Uri Blumenthal

On 7/20/17, 16:01, "TLS on behalf of Martin Rex" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    -Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 20 Jul 2017 23:32:38 +0300

On Thu, Jul 20, 2017 at 08:15:03PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Maybe we are better off just retrofitting RSA-key-transport back
> into TLS-1.3? In that case at least the peer could refuse this
> method of key establishment, and one could safely assume that if a
> peer insists on that key establishment mechanism, this session will
> be surveilled?
> 
> If I had to choose between the two evils, RSA-key-transport seems a
> lesser one (or at least a more obvious/visible one).

This has in fact been requested. Kenny Paterson said about the request:

-----------------------------------------------------------------------
My view concerning your request: no. 

Rationale: We're trying to build a more secure internet.
-----------------------------------------------------------------------

Furthermore, AFAICT, adding RSA key transport would cause major
problems with the way TLS 1.3 does its handshake: It assumes that
whatever the key exchange is, it is two-message client-goes-first,
where static RSA key exchange is two-message server-goes-first (three
messages as client-goes-first).

There is straightforward way to make a valid key exchange out of
RSA. However, the result is very slow for client, and is in fact
forward-secure.

-Ilari

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 20 Jul 2017 20:42:10 +0000

On 7/20/17, 16:32, "[email-masked] on behalf of Ilari Liusvaara" <[email-masked]> wrote:
    > into TLS-1.3? 

My rationale to resurrect it: others are trying to push TLS-1.3 into an invisibly-insecure state. If we must satisfy them (and I’m not at all sure we should), then this is the most obvious way to at least avoid the “insecurity” being silently pushed upon you. At the very least you’d have an option to continue under surveillance or abort connection.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 23 Jul 2017 10:02:40 +0300

On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> My rationale to resurrect it: others are trying to push TLS-1.3 into
> an invisibly-insecure state. If we must satisfy them (and I’m not at
> all sure we should), then this is the most obvious way to at least
> avoid the “insecurity” being silently pushed upon you. At the very
> least you’d have an option to continue under surveillance or abort
> connection. 

This isn't just matter of what is considered "secure enough" to
include. There are fundamential technical constraints that prevent
adding static RSA back.

Early on, there were all sorts of really fundamential decisions on how
TLS 1.3 works. The results of these decisions are baked deeply in the
protocol, and are extremely hard to change. These decisions were
already very apparent in draft-02, over 3 years ago, despite -02 being
unimplementable.

One implication of those assumptions is that any asymmetric key
exchange in TLS 1.3 is at least potentially forward secure[1] (the
actual constraints on asymmetric key exchanges are even stronger
than that, but this weaker version suffices here). Static RSA is not
even potentially forward-secure, so it can not be added.

If you try to add back RSA using the most straightforward method,
what you get is not an analog of static RSA from TLS 1.2. The result
would be closer to RSA_EXPORT from TLS 1.0.

On the other hand, there is no way to construct a key exchange that is
always forward-secure. Either endpoint can always act in a way that
destroys forward-security (even without leaking any per-connection
information), but can not be detected (DH share reuse is considered
detectable) by the other end.

[1] "potentially forward secure" means that there exists interoperating
client and server implementations, so that the key exchange is forward-
secure.

-Ilari

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 23 Jul 2017 12:43:34 +0000

Ilari,

I got your point.

But in view of the request this WG is discussing now, I see only two reasonable (IMHO) opinion: 
1. Tell those requestors to go away because TLS 1.3 has been designed to always be forward-secure; or 
2. Add a *detectable* non-PFS key exchange so those requestors would have something they can live with, and the rest of us could at least agree or disagree to a non-PFS session establishment on a per-session or a per-entity basis. 

I do not know what mechanism could do the latter, or off it even exists. But folding an RSA method in seems to do the job. I'd say it's fine if it borrows from 1.0, as it isn't going to be the most secure setting anyway.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 03:02, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jul 2017 10:33:26 -0400

I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning.   It's actually better for the server to secretly use a static key than to negotiate.   Stephen has already explained why: if this is a negotiation, then it's possible for a third party to simply block any negotiation that doesn't allow it.   We have no control over evil endpoints, and it's silly to pretend otherwise.   Pretending otherwise makes us less secure, not more secure.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 23 Jul 2017 16:05:52 +0000

I think there's no way the connection can be established if the third party in control of the network does not allow that. 

My only goal here is to leave fewer possibilities to set the eavesdropping silently.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 10:33, Ted Lemon <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Jul 2017 17:16:00 +0100

On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote:
> Ilari,
> 
> I got your point.
> 
> But in view of the request this WG is discussing now, I see only two
> reasonable (IMHO) opinion: 1. Tell those requestors to go away
> because TLS 1.3 has been designed to always be forward-secure; or 2.
> Add a *detectable* non-PFS key exchange so those requestors would
> have something they can live with, and the rest of us could at least
> agree or disagree to a non-PFS session establishment on a per-session
> or a per-entity basis.

In Prague some folks were considering another option:

3. Encourage folks who currently use static RSA keys for third
party decryption to put in place a migration plan that gets them
to FS without breaking TLS1.3. IOW, given they can continue to
use TLS1.2 for some years to come, there's no rush, and plenty
of time for transition plans to be put in place. (That'd I think
imply some work in the ops area of the IETF if there's any IETF
work needed at all, but nothing in the TLS wg.)

While I'd (probably entirely predictably:-) be against your
option 2 above, I'd also note that that'd entirely screw up any
ideas we might have of finishing TLS1.3 in the near term. Anyone
who'd argue for such changes needs to be clear that they're also
arguing for another year's delay.

Cheers,
S.

> 
> I do not know what mechanism could do the latter, or off it even
> exists. But folding an RSA method in seems to do the job. I'd say
> it's fine if it borrows from 1.0, as it isn't going to be the most
> secure setting anyway.
> 
> Regards, Uri
> 
> Sent from my iPhone
> 
>>>> On 7/20/17, 16:32, "[email-masked] on behalf of Ilari
>>>> Liusvaara" <[email-masked]> wrote: Maybe we are
>>>> better off just retrofitting RSA-key-transport back into
>>>> TLS-1.3?
>>> 
>>> My rationale to resurrect it: others are trying to push TLS-1.3
>>> into an invisibly-insecure state. If we must satisfy them (and
>>> I’m not at all sure we should), then this is the most obvious way
>>> to at least avoid the “insecurity” being silently pushed upon
>>> you. At the very least you’d have an option to continue under
>>> surveillance or abort connection.
>> 
>> Early on, there were all sorts of really fundamential decisions on
>> how TLS 1.3 works. The results of these decisions are baked deeply
>> in the protocol, and are extremely hard to change. These decisions
>> were already very apparent in draft-02, over 3 years ago, despite
>> -02 being unimplementable.
>> 
>> than that, but this weaker version suffices here). Static RSA is
>> not even potentially forward-secure, so it can not be added.
>> 
>> what you get is not an analog of static RSA from TLS 1.2. The
>> result would be closer to RSA_EXPORT from TLS 1.0.
>> 
>> 
>> On the other hand, there is no way to construct a key exchange that
>> is always forward-secure. Either endpoint can always act in a way
>> that destroys forward-security (even without leaking any
>> per-connection information), but can not be detected (DH share
>> reuse is considered detectable) by the other end.
>> 
>> 
>> [1] "potentially forward secure" means that there exists
>> interoperating client and server implementations, so that the key
>> exchange is forward- secure.
>> 
>> 
>> -Ilari
>> 
>> 
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 23 Jul 2017 16:23:31 +0000

I'd be perfectly happy with TLS 1.3 having nothing but PFS, and those in need of the plaintext getting it from the endpoint OOB.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 12:16, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jul 2017 15:37:11 -0400

> I think there's no way the connection can be established if the third party in control of the network does not allow that. 

This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong.   The attack that negotiating enables is not that a third party can block all connections. They can always block all connections.

What the attack enables is blocking only those connections that don’t negotiate a downgrade. So if you negotiate a downgrade, you get to look at your content, but if you don’t negotiate the downgrade, you don’t. This allows a MiTM to coerce end users into negotiating downgrades.

Of course the far end can just not downgrade, but it may have downgrading enabled either for debugging purposes, never intending that all connections be downgraded, or because the operator didn’t configure the server correctly.   If it’s not in the standard, it can still be enabled by operators who are violating the end user’s trust, but won’t happen by accident and won’t be possible to coerce with a MiTM attack.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 23 Jul 2017 14:37:46 -0700

On 7/23/2017 12:37 PM, Ted Lemon wrote:
> On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL
> <[email-masked] <mailto:[email-masked]>> wrote:
>> I think there's no way the connection can be established if the third
>> party in control of the network does not allow that. 
>
> This is why it’s hard to reason well about this stuff—we tend to get
> the threat models wrong.   The attack that negotiating enables is not
> that a third party can block all connections. They can always block
> /all/ connections.
>
> What the attack enables is blocking only those connections that don’t
> negotiate a downgrade. So if you negotiate a downgrade, you get to
> look at your content, but if you don’t negotiate the downgrade, you
> don’t. This allows a MiTM to coerce end users into negotiating downgrades.

Speaking of threat model, one of the main threats is the "Lavabit" case:
a server is asked to somehow implement a backdoor so existing clients.
In that case, it is very useful for clients to detect that something has
changed. They can move away and use another server.

We are also concerned with the "open library" case, in which the
backdoor ends up being implemented by default in popular libraries. If
that happens, the backdoor can be instantiated via a simple
configuration parameter, and coercion becomes that much easier.
Publishing an RFC describing the back door would of course increase the
risk that the corresponding code ends in the common libraries, and that
is reason enough to not publish such a text.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jul 2017 18:16:42 -0400

On Jul 23, 2017, at 5:37 PM, Christian Huitema <[email-masked]> wrote:
> Speaking of threat model, one of the main threats is the "Lavabit" case: a server is asked to somehow implement a backdoor so existing clients. In that case, it is very useful for clients to detect that something has changed. They can move away and use another server.

Clients cannot detect this backdoor.   They can be informed of it, but they can't detect it.

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 23 Jul 2017 18:28:47 -0400

On Sun, Jul 23, 2017 at 5:37 PM, Christian Huitema <[email-masked]> wrote:
> ...
> Speaking of threat model, one of the main threats is the "Lavabit" case: a
> server is asked to somehow implement a backdoor so existing clients. In that
> case, it is very useful for clients to detect that something has changed.
> They can move away and use another server.

That existed long before LavaBit. Hushmail FTW!

I was saddened to see a Canadian company cooperate with US law
enforcement by backdooring their applet. (Give credit where credit is
due).

Jeff

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 23 Jul 2017 21:01:37 -0400

On Jul 23, 2017, at 15:37, Ted Lemon <[email-masked]> wrote:
> On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked] <mailto:[email-masked]>> wrote:
> This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong.   The attack that negotiating enables is not that a third party can block all connections. They can always block all connections. What the attack enables is blocking only those connections that don’t negotiate a downgrade. So if you negotiate a downgrade, you get to look at your content, but if you don’t negotiate the downgrade, you don’t. This allows a MiTM to coerce end users into negotiating downgrades.

That is clear and AFAIK unavoidable. And not my (main) concern.

What I am trying to avoid is the ability to *surreptitiously* subvert a protocol that’s assumed to be secure. IMHO it is fine if one end-point is faced with a choice of either agreeing to an “eavesdropping” connection or aborting because of no (remaining) common cipher-suites. What I don’t want to see is one end negotiating a connection that “should” be secure based on the exchange parameters, but in fact leaking keys… What I want in such a case is a negotiation that clearly states what has been done. Then the end-point would make a conscious decision to either connect and access data despite being surveilled, or avoid both surveillance and service.

> Of course the far end can just not downgrade, but it may have downgrading enabled either for debugging purposes, never intending that all connections be downgraded, or because the operator didn’t configure the server correctly.  

My main concern is the “invisible” downgrade (that the operator has no say about), not an operator error.

> If it’s not in the standard, it can still be enabled by operators who are violating the end user’s trust, but won’t happen by accident and won’t be possible to coerce with a MiTM attack. 

I see your point. I don’t share your concern, but don’t object to it either.

---

From: Felix Wyss <[email-masked]>
Date: Sun, 23 Jul 2017 17:17:05 +0000

How about requiring a record of a fixed size that either contains the session key encrypted with a “leaking key” or the output of a stream cipher keyed with the session key.  A 3rd party observer would not be able to determine whether the session key is being leaked but the client can tell and act accordingly.

--Felix

From: TLS <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Date: Sunday, July 23, 2017 at 16:34
To: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jul 2017 05:28:52 -0400

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> What I am trying to avoid is the ability to *surreptitiously* subvert a protocol that’s assumed to be secure.

You don't seem to be hearing what I'm trying to say.   What you are proposing is physically impossible.   It is always possible to surreptitiously subvert the protocol.   This is not an achievable goal.   What you get if you implement what you are proposing is a protocol that's easier for an on-path attacker to subvert, not a protocol that is harder for an end-point attacker to subvert.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Jul 2017 10:41:17 +0100

It's fascinating that people cannot seem to stop picking at
the scab remaining after draft-green. I really think we'd be
wiser to just let the wound heal. (And get on with the work
that this WG has been chartered to do, which does not include
wiretapping.)

On 23/07/17 18:17, Felix Wyss wrote:
> How about requiring a record of a fixed size that either contains the
> session key encrypted with a “leaking key” or the output of a stream
> cipher keyed with the session key.  A 3rd party observer would not be
> able to determine whether the session key is being leaked but the
> client can tell and act accordingly.

The relevant signal is that a TLS deployment is able to be
wiretapped. It doesn't matter how that signal is sent, via
rfc1149 or in-band. Adding your putative field (which is
eerily reminiscent of a Clipper LEAF) is such a signal, and
it doesn't matter what content is in the field today, the
"local" authorities will see that and send you the key to
use for them.

See also the many earlier points about consent, naming etc
etc.

S.

> 
> --Felix
> 
> From: TLS <[email-masked]> on behalf of Ted Lemon
> <[email-masked]> Date: Sunday, July 23, 2017 at 16:34 To:
> "Blumenthal, Uri - 0553 - MITLL" <[email-masked]> Cc:
> "<[email-masked]>" <[email-masked]> Subject: Re: [TLS] datacenter TLS
> decryption as a three-party protocol
> 
> I did a little bit of rubber-duck debugging on this proposal with
> Andrea on the way back from Boston this morning.   It's actually
> better for the server to secretly use a static key than to negotiate.
> Stephen has already explained why: if this is a negotiation, then
> it's possible for a third party to simply block any negotiation that
> doesn't allow it.   We have no control over evil endpoints, and it's
> silly to pretend otherwise.   Pretending otherwise makes us less
> secure, not more secure.
> 
> 
>

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 24 Jul 2017 10:03:28 -0400

Ted Lemon <[email-masked]> writes:

> You don't seem to be hearing what I'm trying to say.   What you are
> proposing is physically impossible.

Is it?  I could imagine making the server ECDH share dependent on the
client ECDH share, plus a local random value.  At the end of the
session, the server discloses that random value, showing that it
properly constructed a fresh ECDH share.

Then the client has an opportunity to notice---this session didn't have
a (retrospective) proof of proper generation of the server ECDH share,
and so may involve key reuse in a dangerous way.

This doesn't stop the server from logging the session key, of course.

I *think* the shape I describe above fits into an extension, so (a) it
doesn't have to be done to ship TLS 1.3, and (b) it can be available for
use in general purpose browsers, and then disabled for the "enterprise"
case, and (c) I don't have to worry through the performance implications
of not being able to pre-generate a stack of ECDH shares.

-Brian

-- 
Brian Sniffen <[email-masked]>
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward

---

From: Kyle Rose <[email-masked]>
Date: Mon, 24 Jul 2017 10:19:09 -0400

> This doesn't stop the server from logging the session key, of course.

Of course, this is precisely the point. All your proposal does is
complicate the process of sharing sessions with a third-party: it doesn't
stop an endpoint from surreptitiously doing evil. (Your proposal is
interesting, but because it neatly solves the problem of DH share reuse
without requiring some kind of CT-like infrastructure, not because it
somehow addresses the evil endpoint problem. On the downside, it also may
have implications for amplification DoS.)

Kyle

---

From: Paul Turner <[email-masked]>
Date: Mon, 24 Jul 2017 14:27:44 +0000

It's fascinating that people cannot seem to stop picking at the scab remaining after draft-green. I really think we'd be wiser to just let the wound heal. (And get on with the work that this WG has been chartered to do, which does not include

wiretapping.)

Sorry to ask for this so late in the conversation but can you point me to the definition of the term “wiretapping” you’re using?

Paul

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 24 Jul 2017 10:29:17 -0400

Kyle Rose <[email-masked]> writes:

>> I could imagine making the server ECDH share dependent on the
> stop an endpoint from surreptitiously doing evil.

Yes, but it adds a storage requirement in proportion to the number of
evil acts taken.  For the same reason we find large-key cryptography
interesting---now the adversary has to smuggle out megabytes---we might
like this.

> (Your proposal is

Yes: I'd expect a large operator to drop support for this extension
under load, exactly when they switch to pre-generated ECDH keys.  When
they must further switch to re-used keys, that will be silent.

Conversation elsewhere raises a practical point: browsers don't want to
alert the user on every aborted connection.  But a bad server can
accept&send this extension, reuse a ECDH share, and then RST the
connection rather than properly terminate it.  All I can offer there is
the idea that the client *should* alert when *it* closes the connection
and doesn't get back a proof of proper key generation.

-Brian

---

From: "Paul Turner" <[email-masked]>
Date: Mon, 24 Jul 2017 10:33:14 -0400

Of course, this is precisely the point. All your proposal does is complicate the process of sharing sessions with a third-party: it doesn't stop an endpoint from surreptitiously doing evil.

Is the objective to have the protocol prevent an endpoint “surreptitiously doing evil”? Also, can you define what you mean by evil?

---

From: Kyle Rose <[email-masked]>
Date: Mon, 24 Jul 2017 10:46:06 -0400

On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner <[email-masked]> wrote:

> Is the objective to have the protocol prevent an endpoint “surreptitiously
> doing evil”?
>

To the extent it can, it should (within bounds of performance,
deployability, etc.). Many of us have been pointing out that there are
limits to what's possible, and tradeoffs involved in other facets.

Also, can you define what you mean by evil?

I am using it as shorthand in this conversation for the general notion of
actively enabling pervasive surveillance, which might be logging keys to a
government server or using a government-generated DH share, among other
possibilities. I am happy to use a different phrasing, but this one is
useful because it's pithy: it invokes intent, which separates it
conceptually from other classes of peer trust violations.

Kyle

---

From: Sean Turner <[email-masked]>
Date: Mon, 24 Jul 2017 17:04:14 +0200

> On Jul 24, 2017, at 16:27, Paul Turner <[email-masked]> wrote:
> 
>  

Paul,

Check out https://datatracker.ietf.org/doc/rfc2804/

spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Jul 2017 18:19:36 +0300

> properly constructed a fresh ECDH share.

I do not think this works. As a blatant example, have server generate
the ServerRandom and then the ECDH seed using Dual-EC-DRBG...

The ECDH share will then change every connection and there is a
seed to demonstrate, but the connections can still be decrypted by who
controls the Dua-EC-DRBG backdoor key.

Yes, Dual-EC-DRBG is quite crappy with sizable biases, but discovering
those would take way too many connections. And there are similar
methods that have much much smaller biases.

Basically, if implementation wants to be secretly evil, it can be
secretly evil, and there is nothing you can do to discover it remotely.

Bad implementations are a separate problem. E.g., repeating the same
DH share for a long time because there is no key rotation. That sort
of behavior is pretty blatant if one monitors the DH shares used.

-Ilari