Subject: [TLS] draft-green-tls-static-dh-in-tls13-01

From: Matthew Green <[email-masked]>
Date: Fri, 7 Jul 2017 03:02:43 -0400

The need for enterprise datacenters to access TLS 1.3 plaintext for
security and operational requirements has been under discussion since
shortly before the Seoul IETF meeting. This draft provides current thinking
about the way to facilitate plain text access based on the use of static
(EC)DH keys on the servers. These keys have a lifetime; they get replaced
on a regular schedule. A key manager in the datacenter generates and
distributes these keys.  The Asymmetric Key Package [RFC5958] format is
used to transfer and load the keys wherever they are authorized for use.

We have asked for a few minutes to talk about this draft in the TLS WG
session at the upcoming Prague IETF. Please take a look so we can have a
productive discussion.  Of course, we're eager to start that discussion on
the mail list in advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 11:27:45 +0100

I don't believe the WG should adopt this as it goes
against rfc2804 and encourages bad behaviour. We
ought not be helping to normalise broken crypto. I'm
happy to repeat that at the mic in Prague but would
be even happier if this draft were not discussed
there - these attempts to weaken security have IMO
already taken up too much time and too many cycles.

S.

On 07/07/17 08:02, Matthew Green wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jul 2017 09:02:04 -0400

Without taking a position on whether this group should take on this work, a
couple of questions about alternative approaches (sorry if these have been
answered before):

1. It seems like the requirement here is that the DH private key be
*predictable* by the monitoring box based on some static configuration.
That is, it seems like you could have keys that are predictable to the
monitoring device, but still vary over time, something like setting the
private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom).
Without having done much analysis, this seems more conservative than making
things entirely static. Is there a reason to prefer the purely static
approach besides simplicity?

2. You could avoid changing how the DH works altogether by simply exporting
the DH private key, encrypted with a key shared with the monitoring device,
in a server extension.  (Not in EncryptedExtensions, obviously.)  This
would also have the benefit of explicitly signaling when such monitoring is
in use.  The only real challenge here is that the client would have to
offer the extension in order for the server to be able to send it, which I
expect things like browsers would be unlikely to do.  However, given that
the target of this draft seems to be intra-data-center TLS, perhaps this is
a workable requirement?

Thanks,
--Richard

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 7 Jul 2017 14:40:43 +0000

Matt
This document is extremely well written and describes the needs of enterprises well,  IMHO.    I believe and have heard,  there are similar needs beyond the enterprise realm,  but since we are the only ones formally expressing concerns, so be it.

The detail on the implementation,  as well as the details on why other alternative solutions are not viable/sufficient,  is very good and will help focus any related conversations.

I very much hope this can be on the agenda at IETF 99.
Thanks for your very productive efforts on this.
Mike

From: TLS [mailto:[email-masked]] On Behalf Of Matthew Green
Sent: Friday, July 7, 2017 3:03 AM
To: [email-masked]
Subject: [TLS] draft-green-tls-static-dh-in-tls13-01

The need for enterprise datacenters to access TLS 1.3 plaintext for security and operational requirements has been under discussion since shortly before the Seoul IETF meeting. This draft provides current thinking about the way to facilitate plain text access based on the use of static (EC)DH keys on the servers. These keys have a lifetime; they get replaced on a regular schedule. A key manager in the datacenter generates and distributes these keys.  The Asymmetric Key Package [RFC5958] format is used to transfer and load the keys wherever they are authorized for use.

We have asked for a few minutes to talk about this draft in the TLS WG session at the upcoming Prague IETF. Please take a look so we can have a productive discussion.  Of course, we're eager to start that discussion on the mail list in advance of the meeting.

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: Watson Ladd <[email-masked]>
Date: Fri, 7 Jul 2017 07:44:19 -0700

On Fri, Jul 7, 2017 at 7:40 AM, Ackermann, Michael <[email-masked]> wrote:
> Matt
>
> This document is extremely well written and describes the needs of
> enterprises well,  IMHO.    I believe and have heard,  there are similar
> needs beyond the enterprise realm,  but since we are the only ones formally
> expressing concerns, so be it.

Why does the IETF need to be involved, given this solution exists?

>
>
>
> The detail on the implementation,  as well as the details on why other
> alternative solutions are not viable/sufficient,  is very good and will help
> focus any related conversations.
>
>
>
> The need for enterprise datacenters to access TLS 1.3 plaintext for security
> and operational requirements has been under discussion since shortly before
> the Seoul IETF meeting. This draft provides current thinking about the way
> to facilitate plain text access based on the use of static (EC)DH keys on
> the servers. These keys have a lifetime; they get replaced on a regular
> schedule. A key manager in the datacenter generates and distributes these
> keys.  The Asymmetric Key Package [RFC5958] format is used to transfer and
> load the keys wherever they are authorized for use.
>
>
>
> 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.
>
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 12:35:18 -0400

Richard:

> Without taking a position on whether this group should take on this work, a couple of questions about alternative approaches (sorry if these have been answered before):
> 
> 1. It seems like the requirement here is that the DH private key be *predictable* by the monitoring box based on some static configuration.  That is, it seems like you could have keys that are predictable to the monitoring device, but still vary over time, something like setting the private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done much analysis, this seems more conservative than making things entirely static. Is there a reason to prefer the purely static approach besides simplicity?

Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a validity period.  The keys are expected to change over time.

> 2. You could avoid changing how the DH works altogether by simply exporting the DH private key, encrypted with a key shared with the monitoring device, in a server extension.  (Not in EncryptedExtensions, obviously.)  This would also have the benefit of explicitly signaling when such monitoring is in use.  The only real challenge here is that the client would have to offer the extension in order for the server to be able to send it, which I expect things like browsers would be unlikely to do.  However, given that the target of this draft seems to be intra-data-center TLS, perhaps this is a workable requirement?

In most common deployment case, the load balancer at the edge of the enterprise datacenter will terminate the TLS session and start a new one.  The TLS session that protects the traffic on the public Internet works exactly as described in draft-ietf-tls-tls13.  The non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter.  So, you are right, no browser will be at either end of any of these TLS sessions.  There is no change to the way that the protocol makes use of the DH key.  The drft-green, the server need to look in a table to choose a valid non-ephemeral DH key.  In your proposal, the server need to wrap the ephemeral DH private key in a key-enceyption key.  Both solutions require the distribution of some key (either the non-ephemenral DH key or the key-encryption key) to the parties that are authorized to see the traffic.

> already taken up too much time and too many cycles.

Repeating from above, the non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter.  In some industries, there are regulatory requirements that cannot be met without access to the plaintext.  Without some authorized access mechanism, the enterprise will be forced to use plaintext within the datacenter.  That seems like a worse alternative to me.

Russ

> On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green <[email-masked] <mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 <https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jul 2017 13:13:07 -0400

On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley <[email-masked]> wrote:

> Richard:
>
> Without taking a position on whether this group should take on this work,
> a couple of questions about alternative approaches (sorry if these have
> been answered before):
>
> Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a
> validity period.  The keys are expected to change over time.
>

OK, then why not have this happen automatically (e.g., by folding in
ServerRandom) rather than doing the provisioning process over and over?

>
> 2. You could avoid changing how the DH works altogether by simply
> exporting the DH private key, encrypted with a key shared with the
> monitoring device, in a server extension.  (Not in EncryptedExtensions,
> obviously.)  This would also have the benefit of explicitly signaling when
> such monitoring is in use.  The only real challenge here is that the client
> would have to offer the extension in order for the server to be able to
> send it, which I expect things like browsers would be unlikely to do.
> However, given that the target of this draft seems to be intra-data-center
> TLS, perhaps this is a workable requirement?
>
>
> In most common deployment case, the load balancer at the edge of the
> enterprise datacenter will terminate the TLS session and start a new one.
> The TLS session that protects the traffic on the public Internet works
> exactly as described in draft-ietf-tls-tls13.  The non-ephemeral DH keys
> are associated only with sessions that are inside the enterprise
> datacenter.  So, you are right, no browser will be at either end of any of
> these TLS sessions.  There is no change to the way that the protocol makes
> use of the DH key.  The drft-green, the server need to look in a table to
> choose a valid non-ephemeral DH key.  In your proposal, the server need to
> wrap the ephemeral DH private key in a key-enceyption key.  Both solutions
> require the distribution of some key (either the non-ephemenral DH key or
> the key-encryption key) to the parties that are authorized to see the
> traffic.
>

Yes, I understand that all of the solutions in this space will require some
static configuration.  What I'm trying to do is minimize the degree to
which that static-ness reduces the entropy in the TLS handshake.

In the "fold in ServerRandom" version, the static information gets tempered
with per-session random information.  In the "smuggle out the private key"
version, the static information doesn't even touch the base TLS handshake;
it's only used for wrapping the DH private key.

I agree that the "smuggle out the private key" still has a static component
that you would want to refresh.  However, it's minimal, in the sense that
you're going to need to authenticate the monitoring box to the TLS server
somehow anyway (even if just for provisioning).  And it seems like a
cleaner separation to have the static component as something off to the
side of the main handshake, rather than having to make invasive changes to
the handshake code.

--Richard

> Repeating from above, the non-ephemeral DH keys are associated only with
> sessions that are inside the enterprise datacenter.  In some industries,
> there are regulatory requirements that cannot be met without access to the
> plaintext.  Without some authorized access mechanism, the enterprise will
> be forced to use plaintext within the datacenter.  That seems like a worse
> alternative to me.
>
> Russ
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Jul 2017 17:16:56 +0000

I think there is little doubt that the draft is technically sound.

The question is, should the IETF “endorse” this by saying it is a product of the TLS working group?  That will certainly send a mixed message to some.  As we heard around around Seoul, not adopting might send a message to some industries that we are not interested in helping to solve their problems.

It is a fraught issue.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 7 Jul 2017 17:19:53 +0000

Would the Informational track be an acceptable compromise? This does not have to be a product of the TLS working group.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, July 7, 2017 10:17 AM
To: Russ Housley <[email-masked]>; Richard Barnes <[email-masked]>
Cc: IETF TLS <[email-masked]>; Matthew Green <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

The question is, should the IETF "endorse" this by saying it is a product of the TLS working group?  That will certainly send a mixed message to some.  As we heard around around Seoul, not adopting might send a message to some industries that we are not interested in helping to solve their problems.

It is a fraught issue.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 13:39:43 -0400

> Why does the IETF need to be involved, given this solution exists?

I would like there to be one way for the key manager to load the non-ephemeral key into the server and the authorized decrypt parties.  Without an RFC, I fear there will be many ways that this is handled, with varying levels of security.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 19:06:14 +0100

> Would the Informational track be an acceptable compromise? This does not have to be a product of the TLS working group.

IMO, no, and seeking compromise is not necessarily the
right approach anyway - if we did that here, then why
not "compromise" and say RC4 is better than nothing?
Or md5? Isn't a compromise due to this kind of broken
system far far more likely than one due to rc4 or md5?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 19:21:08 +0100

Hi Russ,

On 07/07/17 17:35, Russ Housley wrote:
> Repeating from above, the non-ephemeral DH keys are associated only
> with sessions that are inside the enterprise datacenter.

I find it really hard to believe anyone is convinced of that.

Yes, one could chose to use this proposed wiretapping scheme
like that but figure 3 in the draft makes if fully clear that
this colluding or coerced wiretapping device can be anywhere
on the Internet.

2804 says "no" here - are you proposing to obsolete that? If
so, being up-front about that is IMO a pre-requisite and talk
of "datacentres" avoided as the misdirection that it is.

Again, I hope the chairs do not devote/waste more time on this
until there is a demonstrated IETF consensus to obsolete 2804.
We cannot honestly have both this and that.

S.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 7 Jul 2017 14:40:36 -0400

On Fri, Jul 7, 2017 at 2:21 PM, Stephen Farrell <[email-masked]>
wrote:

> 2804 says "no" here - are you proposing to obsolete that?

I don't think 2804 says any such thing. In fact, it explicitly states that:

q( On the other hand, the IETF believes that mechanisms designed to
     facilitate or enable wiretapping, or methods of using other
     facilities for such purposes, should be openly described, so as to
     ensure the maximum review of the mechanisms and ensure that they
     adhere as closely as possible to their design constraints. The IETF
     believes that the publication of such mechanisms, and the
     publication of known weaknesses in such mechanisms, is a Good
     Thing. )

My reading of 2804 is that the IETF takes no moral position on wiretapping;
recommends against it on technical grounds; and encourages documentation of
proposed or in-use mechanisms for wiretapping for the express purpose of
publicizing the flaws inherent in any such approach.

IMO, an informational draft submitted via the ISE seems completely
appropriate for something like this. I'll add that we've already gotten
good input toward better alternatives on this very thread, which suggests
that having these discussions out in the open is likely to result in better
practical outcomes for user populations that are, one way or the other,
going to be subject to systems like this. Discussing something does not
presuppose or imply agreement on the objectives.

Kyle

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 19:44:22 +0100

On 07/07/17 19:40, Kyle Rose wrote:
> an informational draft submitted via the ISE

...has nothing to to with this WG and ought consume
no cycles on this list or in meetings.

Yes, the ISE is the route 2804 envisages for documenting
wiretapping schemes such as this.

The authors of this draft however chose to put "standards
track" in the header and some of those authors are very
very well aware of all the nuances here so that was not
a mistake is my conclusion. So I stand by my statement
that 2804 says no to this.

S.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 16:04:20 -0400

> that 2804 says no to this.

As Kyle quoted, RFC 2804 says that we should be talking about the design.  It seems to me the only way to make this proposal more secure is to talk about it.  And, the TLS WG has the people with the proper expertise for that discussion.

The enterprise wants forward secrecy on the public Internet. Terminating the TLS session at the load balancer preserves forward secrecy on the public Internet.

We already had a discussion on this list about requiring a fresh ephemeral DH key for every session.  The consensus was not to require it.  I understand that there are already servers that use the same "ephemeral" DH key for more than one session.  I gather that this is done for performance reasons.  

The conventions described in draft-green-tls-static-dh-in-tls13-01 for using non-ephemeral DH keys has no impact on interoperability.  Discussion of that topic could easily go in an Informational RFC.  Many Informational RFCs describe crypto algorithms.  On the other hand, the protocol between the key manager and the server for installing the non-ephemeral DH key has an impact on interoperability, so it could be in a standards-track document.

In your response, you ignored a fairly significant point in my previous post.

	In some industries, there are regulatory requirements that cannot be
	met without access to the plaintext.  Without some authorized access
	mechanism, the enterprise will be forced to use plaintext within the
	datacenter.  That seems like a worse alternative to me.

From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems like a much better way forward than plaintext throughout the datacenter.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 21:18:43 +0100

Russ,

You didn't refer to 2804 and the standards track. As an
author do you really think this can be on the standards
track and yet not obsolete 2804?

If you do, then I don't understand that. (And would argue
you are holding a counter-factual opinion.)

If you do not, then why does the draft say "standards
track"?

S.

PS: I disagree with other assertions below but the above
has to come first as we need to know if the authors are
or are not asking the IETF to change a major policy.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 17:12:38 -0400

> track and yet not obsolete 2804?

Yes.  Section 3 of RFC 2804 offers pretty clear definition of wiretapping, and that is not what is going on here.  In this situation, all of the parties are part of the same organization, under common key management.  The server must explicitly accept and use the centrally managed (EC)DH key, so that party is completely aware and, in fact, enabling the other parties to decrypt the traffic.

Russ

---

From: Eric Mill <[email-masked]>
Date: Fri, 7 Jul 2017 17:13:12 -0400

On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley <[email-masked]> wrote:
>
> The enterprise wants forward secrecy on the public Internet. Terminating
> the TLS session at the load balancer preserves forward secrecy on the
> public Internet.
>

> From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating
> outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same
> crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems
> like a much better way forward than plaintext throughout the datacenter.
>

Your response is also failing to address a very important point, by
presenting the choice as either static-key TLS or plaintext. That's clearly
not the case -- you can maintain traffic visibility at endpoints within
your data center, by forcing traffic through terminating trusted proxies
which log the same network traffic data you would get from passive
monitoring. You can do that with forward secret TLS today.

I'm sure it's not as easy to change your designs to incorporate proxies as
it is to just rely on the network monitoring infrastructure you already
have in place, but that's not a good enough reason to insist that the TLS
WG standardize an RFC which can plainly be used for wiretapping.

It's also passing up an opportunity to gain the benefits of forward secret
connections within your data center, which should really be a best practice
and requirement for any organization managing data that merits strict
regulatory oversight.

This comes across as asking the IETF to contort itself around its own
stated goals so that the enterprise doesn't have to do any heavy lifting to
keep up with security trends. As explained so far, this seems like
something the TLS WG should reject.

-- Eric

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 22:16:14 +0100

Hiya,

On 07/07/17 22:12, Russ Housley wrote:
> Stephen:
> 
>> You didn't refer to 2804 and the standards track. As an author do
>> you really think this can be on the standards track and yet not
>> obsolete 2804?
> 
> Yes. 

We disagree.

> Section 3 of RFC 2804 offers pretty clear definition of
> wiretapping, and that is not what is going on here.  In this
> situation, all of the parties are part of the same organization,
> under common key management.  

That is one possible deployment. There is nothing in this
proposal that limits it's use to that.

> The server must explicitly accept and
> use the centrally managed (EC)DH key, so that party is completely
> aware and, in fact, enabling the other parties to decrypt the
> traffic.

Yes, and the server could equally be compelled to do that,
in which case this technology would clearly be a standard
form of wiretapping.

Claiming that is not the case would be incredible so I have
no idea how you maintain that this isn't in conflict with
2804.

S.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 17:38:36 -0400

> no idea how you maintain that this isn't in conflict with

That does not follow the definition in Section 3 of RFC 2804.  If one of the parties is "compelled" to install the centrally managed (EC)DH key, then the server is aware.  If you consider the server to be the sending party, then this situation does not meet number 1 in the definition.  If you consider the server to be the receiving party, then this situation does not meet number 2 in the definition.

To save everyone from looking it up, RFC 2804 says:

   Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
      the third party

   3. When the normal expectation of the sender is that the transmitted
      information will only be seen by the recipient parties or parties
      obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
      of the first party, either because he is of interest, or because
      the second party's reception is of interest.

   The term "party", as used here, can refer to one person, a group of
   persons, or equipment acting on behalf of persons; the term "party"
   is used for brevity.

   Of course, many wiretaps will be bidirectional, monitoring traffic
   sent by two or more parties to each other.

   Thus, for instance, monitoring public newsgroups is not wiretapping
   (condition 3 violated), random monitoring of a large population is
   not wiretapping (condition 4 violated), a recipient passing on
   private email is not wiretapping (condition 2 violated).

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 22:40:58 +0100

On 07/07/17 22:38, Russ Housley wrote:
> Stephen:
> 
>>>> You didn't refer to 2804 and the standards track. As an author
>>>> do you really think this can be on the standards track and yet
>>>> not obsolete 2804?
>>> 
>>> Yes.
>> 
>> We disagree.
>> 
>> That is one possible deployment. There is nothing in this proposal
>> that limits it's use to that.
>> 
>>> The server must explicitly accept and use the centrally managed
>>> (EC)DH key, so that party is completely aware and, in fact,
>>> enabling the other parties to decrypt the traffic.
>> 
>> Yes, and the server could equally be compelled to do that, in which
>> case this technology would clearly be a standard form of
>> wiretapping.
>> 
>> Claiming that is not the case would be incredible so I have no idea
>> how you maintain that this isn't in conflict with 2804.
> 
> That does not follow the definition in Section 3 of RFC 2804.  If one
> of the parties is "compelled" to install the centrally managed (EC)DH
> key, then the server is aware. 

CDNs.

Cheers,
S.

? If you consider the server to be the
> sending party, then this situation does not meet number 1 in the
> definition.  If you consider the server to be the receiving party,
> then this situation does not meet number 2 in the definition.
> 
> 2. Without any of the recipient parties knowing about the delivery
> to the third party
> 
> of the first party, either because he is of interest, or because the
> second party's reception is of interest.
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 22:48:38 +0100

On 07/07/17 22:38, Russ Housley wrote:
> That does not follow the definition in Section 3 of RFC 2804.  

And also: I'm sorry to have to say it, but I consider that
attempted weasel wording around the clear intent of 2804. The
clear and real effect if your wiretapping proposal were standardised
by the IETF would be that we'd be standardising ways in which
TLS servers can be compelled into breaking TLS - it'd be a standard
wiretapping API that'd be insisted upon in many places and would
mean significantly degrading TLS (only *the* most important
security protocol we maintain) and the community's perception
of the IETF. It's all a shockingly bad idea.

S

PS: You might say that purely static DH can be detected by
the TLS client, but once we give in on this it'll be inevitable
that variants are derived that aren't detectable by the TLS
client.

> If one
> key, then the server is aware.  If you consider the server to be the

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 17:54:02 -0400

> of the IETF. It's all a shockingly bad idea.

I clearly disagree.  Otherwise, I would not have put any work into the draft.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Jul 2017 22:55:31 +0100

> I clearly disagree.  Otherwise, I would not have put any work into the draft.

I accept that.

But I think you and your co-authors are utterly wrong in this
case.

S.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 7 Jul 2017 18:10:33 -0700

On 7/7/2017 2:54 PM, Russ Housley wrote:
> ...
Russ,

What are the specific mechanisms that would allow this technique to be
used where you
intend it, i.e. within a data center, and not where Stephen fears it
would be, i.e., on
the broad Internet? For example, what mechanism could a client use to
guarantee
that this sort of "static DH" intercept could NOT be used against them?

-- 
Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Jul 2017 18:39:42 -0700

> that this sort of "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that
from happening. So I don't see why static DH is a) so essentially
necessary and b) so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit
from time to time.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 8 Jul 2017 02:06:31 +0000

Converting all session traffic to clear text is not a viable alternative for ANY enterprises or industries that I am aware of.  In particular those in financial sectors.  
Security policies, legislation and in many cases just good practice would not allow for this. 
We are compelled by these factors to encrypt all data in motion.    But we still need to manage our applications, networks, servers and clients.    Hence the need to decrypt traffic as outlined in this draft.   

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema <[email-masked]> wrote:
>>> And also: I'm sorry to have to say it, but I consider that attempted 
>>> weasel wording around the clear intent of 2804. The clear and real 
>>> effect if your wiretapping proposal were standardised by the IETF 
>>> would be that we'd be standardising ways in which TLS servers can be 
>>> compelled into breaking TLS - it'd be a standard wiretapping API 
>>> that'd be insisted upon in many places and would mean significantly 
>>> degrading TLS (only *the* most important security protocol we 
>>> maintain) and the community's perception of the IETF. It's all a 
>>> shockingly bad idea.
> used where you intend it, i.e. within a data center, and not where 
> Stephen fears it would be, i.e., on the broad Internet? For example, 
> what mechanism could a client use to guarantee that this sort of 
> "static DH" intercept could NOT be used against them?

This is the solution enterprises can use today. Nothing can stop that from happening. So I don't see why static DH is a) so essentially necessary and b) so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit from time to time.

---

From: Timothy Jackson <[email-masked]>
Date: Sat, 8 Jul 2017 03:18:45 +0000

As an earlier poster asked, what advantage does this approach have over TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am familiar is able to terminate at TLS connection, inspect/copy/filter, and then encrypt on a new TLS sessions.

For high performance customers, the SSL accelerators can be sandwiched around the filter so all the crypto is done in hardware.

The ways to prevent TLS inspection are cert pinning and client cert auth. If this is only within one's data center, then those features can be disabled if necessary, no?

What use case am I missing that can't be achieved better by other means than static keys?

Thanks,

Tim

Sent from Email+ secured by MobileIron

________________________________

From: "Ackermann, Michael" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 7, 2017 at 7:06:55 PM
To: "Watson Ladd" <[email-masked]<mailto:[email-masked]>>, "Christian Huitema" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 10:09:12 +0100

On 08/07/17 03:06, Ackermann, Michael wrote:
> Converting all session traffic to clear text is not a viable
> alternative for ANY enterprises or industries that I am aware of.  In
> particular those in financial sectors. Security policies, legislation
> and in many cases just good practice would not allow for this. We are
> compelled by these factors to encrypt all data in motion.    But we
> still need to manage our applications, networks, servers and clients.
> Hence the need to decrypt traffic as outlined in this draft.

That assertion of necessity is blatantly false.

It is entirely feasible to decrypt and re-encrypt in many
cases and for that to be efficient and to meet regulatory
needs.

If some systems are so badly designed that doing that while
updating to tls1.3 is a showstopper then that's down to bad
design or other bad practices. Fixing those is the place to
spend effort instead of spending effort on breaking TLS.

Other users of TLS ought not suffer on the basis of such
bad reasoning.

S.

> 
> -----Original Message----- From: TLS [mailto:[email-masked]] On
> Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To:
> Christian Huitema <[email-masked]> Cc: [email-masked] Subject: Re:
> [TLS] draft-green-tls-static-dh-in-tls13-01
> 
>>> Stephen: ...
>>>> clear and real effect if your wiretapping proposal were
>>>> standardised by the IETF would be that we'd be standardising
>>>> ways in which TLS servers can be compelled into breaking TLS -
>>>> it'd be a standard wiretapping API that'd be insisted upon in
>>>> many places and would mean significantly degrading TLS (only
>>>> *the* most important security protocol we maintain) and the
>>>> community's perception of the IETF. It's all a shockingly bad
>>>> idea.
>> What are the specific mechanisms that would allow this technique to
>> be used where you intend it, i.e. within a data center, and not
>> where Stephen fears it would be, i.e., on the broad Internet? For
>> example, what mechanism could a client use to guarantee that this
>> sort of "static DH" intercept could NOT be used against them?
> 
>> -- Christian Huitema
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> -- "Man is born free, but everywhere he is in chains". --Rousseau.
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 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.
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 8 Jul 2017 15:36:26 +0300

> On 8 Jul 2017, at 6:18, Timothy Jackson <[email-masked]> wrote:
> 

They would like to store traffic captures encrypted and be able to decrypt them a little later if that is necessary. Storing plaintext is something that auditors (rightfully!) don’t like.

They also don’t want to install TLS proxies all over the place.  That’s a large extra expense for them.

Yoav

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 8 Jul 2017 16:00:43 +0000

Regards to using proxies,  I believe this is covered in the draft.
But at a high level, most enterprises have tried this approach.   It can work in some  situations,  but in most cases there are utilization, performance and management issues that prevent this solution from being effective or affordable.   Not to mention the introduction of manifold new potential points of failure.

From: Timothy Jackson [mailto:[email-masked]]
Sent: Friday, July 7, 2017 11:19 PM
To: Ackermann, Michael <[email-masked]>; Watson Ladd <[email-masked]>; Christian Huitema <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Thanks,

Tim

Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> [email-masked]<mailto:[email-masked]>

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

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

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 8 Jul 2017 16:08:08 +0000

Not sure what you are saying in regards to systems being badly designed or bad reasoning or what our blatantly false assertions are?    
I suspect this is not a productive path to pursue, so I will not.   

But in an effort to keep this discourse on track with the issue at hand,  I will repeat my statement that converting everything to clear text is not viable in my world(s).   

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, July 8, 2017 5:09 AM
To: Ackermann, Michael <[email-masked]>; Watson Ladd <[email-masked]>; Christian Huitema <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

It is entirely feasible to decrypt and re-encrypt in many cases and for that to be efficient and to meet regulatory needs.

If some systems are so badly designed that doing that while updating to tls1.3 is a showstopper then that's down to bad design or other bad practices. Fixing those is the place to spend effort instead of spending effort on breaking TLS.

Other users of TLS ought not suffer on the basis of such bad reasoning.

S.

>>>> attempted weasel wording around the clear intent of 2804. The clear 
>>>> and real effect if your wiretapping proposal were standardised by 
>>>> the IETF would be that we'd be standardising ways in which TLS 
>>>> servers can be compelled into breaking TLS - it'd be a standard 
>>>> mean significantly degrading TLS (only
>>>> community's perception of the IETF. It's all a shockingly bad idea.
>> be used where you intend it, i.e. within a data center, and not where 
> 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.
> 
> are nonprofit corporations and independent licensees of the Blue Cross 
> and Blue Shield Association.
>

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 8 Jul 2017 09:11:26 -0700

On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <[email-masked]> wrote:

> You could avoid changing how the DH works altogether by simply exporting

I very much like the property that by using an extension, the client must
consent to being MitMed.

But in this case, why not just keywrap the session master secret with a
preshared KEK as opposed to exfiltrating the DH private key?

-- 
Tony Arcieri

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 8 Jul 2017 16:13:47 +0000

+1

From: Yoav Nir [mailto:[email-masked]]
Sent: Saturday, July 8, 2017 8:36 AM
To: Timothy Jackson <[email-masked]>
Cc: Ackermann, Michael <[email-masked]>; Watson Ladd <[email-masked]>; Christian Huitema <[email-masked]>; [email-masked]
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 8 Jul 2017, at 6:18, Timothy Jackson <[email-masked]<mailto:[email-masked]>> wrote:

They would like to store traffic captures encrypted and be able to decrypt them a little later if that is necessary. Storing plaintext is something that auditors (rightfully!) don't like.

They also don't want to install TLS proxies all over the place.  That's a large extra expense for them.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sat, 8 Jul 2017 09:27:32 -0700

On Sat, Jul 8, 2017 at 5:36 AM, Yoav Nir <[email-masked]> wrote:
> As an earlier poster asked, what advantage does this approach have over
> TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am
> familiar is able to terminate at TLS connection, inspect/copy/filter, and
> then encrypt on a new TLS sessions.
>
> For high performance customers, the SSL accelerators can be sandwiched
> around the filter so all the crypto is done in hardware.
>
> The ways to prevent TLS inspection are cert pinning and client cert auth. If
> this is only within one's data center, then those features can be disabled
> if necessary, no?
>
> They would like to store traffic captures encrypted and be able to decrypt
> them a little later if that is necessary. Storing plaintext is something
> that auditors (rightfully!) don’t like.

Then renencrypt the data on the storage device.
> large extra expense for them.

Nginx exists. What's the blocker?

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 8 Jul 2017 17:38:39 +0100

> They also don’t want to install TLS proxies all over the place.  That’s a large extra expense for them.

The predicated architecture - tappable inside, non-tappable outside the
enterprise - requires exactly that.
-- 
Jeremy

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 17:41:16 +0100

On 08/07/17 17:38, Jeremy Harris wrote:
> enterprise 

That's fiction.

S

---

From: Russ Housley <[email-masked]>
Date: Sat, 8 Jul 2017 13:05:03 -0400

> that this sort of "static DH" intercept could NOT be used against them?

Christian:

In draft-green-tls-static-dh-in-tls13, there is not one.  I have not thought about it in these terms.  The server, if acting in bad faith, can always release the client's traffic.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 18:17:21 +0100

On 08/07/17 18:05, Russ Housley wrote:
> In draft-green-tls-static-dh-in-tls13, there is not one.  I have not
> thought about it in these terms.  The server, if acting in bad faith,
> can always release the client's traffic.
Is it bad faith if the server is compelled to enable this
wiretap interface? For a wiretapper this is a great scheme,
as they only need to force it to be turned on and accept a
tiny bit of data and then they can pick up those packets
from anywhere without having to deal with problems at the
web server end. So no need to even re-imburse the web server
for the intercepted access anymore.

Honestly, doesn't that clearly mean a conflict with 2804?
And one that cannot afaics be avoided.

S.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 8 Jul 2017 13:30:35 -0400

> preshared KEK as opposed to exfiltrating the DH private key?

Actually, now that you mention it, something like that is probably
necessary -- I expect that there are unstated requirements here to support
for resumption (without having to find the previous session) and probably
0xRTT, and those modes use in a shared secret in addition to the DH
secret.  So you would need to exfiltrate the PSK as well.

Looking at the key schedule [1], it looks like it would not be sufficient
to send the master secret, since that wouldn't get you early data or
handshake messages, but it would be enough to exfiltrate the DH and PSK
secrets.

Nonetheless, I don't think this significantly changes the proposed design.
The interesting question is still whether opt-in is an acceptable
requirement for the folks looking for a mechanism here.

--Richard

[1]
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.7.1

---

From: Watson Ladd <[email-masked]>
Date: Sat, 8 Jul 2017 10:39:43 -0700

> for the intercepted access anymore.

The same applies to static RSA ciphersuites. I understand your desire
to move on with TLS 1.3, but we did burn what seemed to be a somewhat
important usecase to some people, and this draft demonstrates that TLS
1.3 can be deployed in datacenters without hurting that usecase. As
much as I think enterprise networks are suffering from bad design
decisions that solve problems with boxes and not endpoint changes,
this is a problem people are claiming to face, and there are some
security implications.

Servers already use static DH, in some cases by accident.
> And one that cannot afaics be avoided.

Why did static RSA not imply that?

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 18:42:02 +0100

> Why did static RSA not imply that?

We never defined a standards track API for handing over
the RSA private key.

This draft proposes to do exactly the equivalent, hence
the conflict with 2804.

S.

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 08 Jul 2017 21:16:00 +0000

Putting questions of whether or not this belongs as a working group
document, I think there are some necessary requirements for
intra-datacenter passive decryption schemes that are not met by this draft.

Specifically, any passive decryption scheme should the following two
properties:
1) Both server and client must explicitly opt-in
2) A third party should be able to tell whether or not this feature is
enabled by observing the stream

These two requirements protect services on the wider Internet from being
accidentally (or surreptitiously forced to be) subject to unauthorized
decryption. The static DH proposal satisfies neither of the above
requirements.

What you likely want is something similar to TLS 1.2 session tickets with
centrally managed session ticket keys. The client would advertise support
for "passive session decryption" in an extension and the server would
return an unencrypted extension containing the session keys encrypted by a
server "passive decryption key". The passive decryption key would be
managed in the same way as the static DH key in this draft: rotated
frequently and synchronized centrally.

A TLS 1.2 session ticket-like scheme provides the same semantics as this
static DH but provides more safeguards against accidental use outside the
datacenter. Both client and server need to opt in, it's visible from the
network, and limits the data visible to the inspection service to the
session (rather than exposing the master secret which can be used to
compute exporters and other things outside of the scope of session
inspection). Furthermore, in the session ticket-like scheme, a *public
key *could
be used to encrypt the session keys, removing the need for a secure
distribution scheme for the endpoints. The passive decryption private key
could me managed in a secure location and only the public key distributed
to the endpoints.

Session ticket-like scheme advantages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints

In summary, even if this was to be considered as a working group document,
I think this is the wrong solution to problem.

Nick

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 8 Jul 2017 15:08:09 -0700

With all respect to the authors for a well-written paper, this draft
should not be adopted by TLS WG, because it would weaken the security of
TLS as deployed in practice.

If the TLS WG were to adopt this draft, one of the likely outcomes would
be implementation in a variety of popular TLS libraries, like OpenSSL
and SChannel. Unfortunately, including interception capability in
off-the-shelf software is like keeping your plutonium next to your
potato chips; something is bound to go wrong. For instance, performance
advocates may suggest turning on the interception capability in order to
save cycles. If such advice is broadly adopted, we will effectively have
reintroduced non-forward secret sessions to TLS. In TLS 1.3 there are no
NULL cipher suites. Why should there be a commonly implemented mode that
breaks forward secrecy?

The "Weaknesses of Alternative Solutions" section nicely sums up the
tradeoffs of various techniques. Under "Export of ephemeral keys," it says:

> The complexity of the solution is a problem that adds risk.

This is absolutely true, but doesn't mention the bearer. The enterprise
that requires the interception bears the risk (or, more likely, the
vendors who sell interception software). I think when balancing the
monetary risk to the enterprise against the privacy risk to billions of
consumer Internet users, the consumers should win.

I would also point out that retrospectively decrypting pcaps asks TLS to
do double duty: as at-rest encryption in addition to transit encryption.
If, instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much
better security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much
more tightly. Instead of every TLS frontend having the keys for
retrospective decryption, those keys can be limited to auditors or
security team members.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 8 Jul 2017 18:11:41 -0400

> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

This document uses the terms:
"Ephemeral (EC)DHE" & "Static (EC)DHE"

The 'E' stands for ephemeral. Regardless of the technical, security, political, logistical, ethical, and whatever merits of this document, could you please make the terminology not hurt my brain? The former is the standard ATM machine silliness, and the later is contradictory and only vaguely viable by fiat of explicitly writing out the silliness:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01#section-1.1
>   This document introduces the term "static (elliptic curve) Diffie-
>   Hellman ephemeral", generally written as "static (EC)DHE", to refer
>   to long-lived finite field or elliptic curve Diffie-Hellman keys or
>   key pairs that will be used with the TLS 1.3 ephemeral ciphersuites
>   to negotiate traffic keys for multiple TLS sessions.
>
>   For clarity, this document also introduces the term "ephemeral
>   (elliptic curve) Diffie-Hellman ephemeral", generally written as
>   "ephemeral (EC)DHE", to denote finite field or elliptic curve Diffie-
>   Hellman keys or key pairs that will be used with the TLS 1.3
>   ephemeral ciphersuites to negotiate traffic keys for a single TLS
>   sessions.

It should be simply:
"Ephemeral (EC)DH" & "Static (EC)DH"

Or just:
"(EC)DHE" & "Static (EC)DH"
(or even "(EC)DHS" if you want to use a similar scheme for both)

My argument is that you've got to be able to come up with better terminology than "ephemeral (elliptic curve) Diffie-Hellman ephemeral". Using the same word twice in the same term with slightly different implications is... messy and confusing.

Dave

PS
Response on the merits of the spec to follow in another post.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 8 Jul 2017 18:14:46 -0400

On Sat, Jul 8, 2017 at 5:16 PM, Nick Sullivan <[email-masked]>
wrote:

> decryption.

I absolutely agree.

> frequently and synchronized centrally.

This is the best proposal I've seen so far.

What is the problem of publishing a scheme like this as an Informational
RFC? After all, we can cite many examples of protocols described in
Informational RFCs that are widely deployed by industry. If the proponents
of this draft think it critical that this needs formal IETF endorsement as
a standard, then I believe they ought to be also working on persuading the
IETF to withdraw or at least backtrack on some of our previous statements
(such as RFC 7258, which declared that IETF protocols need to have
technical countermeasures to prevent pervasive monitoring).

I doubt that we will be able to get consensus on IETF endorsement. Speaking
only for myself, I am against the IETF/TLS wg endorsing a protocol that
degrades the security of the TLS protocol. But I am perfectly fine with
publishing it as Informational document.

-- 
Shumon Huque

---

From: Dave Garrett <[email-masked]>
Date: Sat, 8 Jul 2017 18:16:50 -0400

This thread blew up rather quickly. Replying on a topic with quotes from various posts, below:

On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote:
> > alternative for ANY enterprises or industries that I am aware of.

Could we please drop the plaintext straw man here? The alternative is building a system that doesn't rely on outdated methods, rather than shoe-horning them into TLS 1.3, not ditching encryption.

> > In

+1

It is not the job of the TLS WG to make handling internal requirements of organizations easier with their existing systems in spite of the obvious risks that can be avoided.

A drop-in replacement for a theoretically legitimate usecase is also a drop-in replacement for very much illegitimate usecases. Making this a standard is not the way to go here. An argument could be made for informational RFC status rather than standards track, but even then, it's dangerous.

> this is a problem people are claiming to face, and there are some

The organizations that took the easy way at the time now are being told to take a harder way that is more secure. (and are consistently posting to this list with amnesia, acting like we told them to use plaintext) They don't like that; we shouldn't care. We should consider standardizing better solutions for this problem, without regard to how much old systems will have to adapt their design. This has come up on this list MANY times, and each time the end result of discussion was to not revert security decisions made to improve TLS. Releasing a standards track (or even informational) RFC on how to do exactly that using all the old methods, with some tweaks, defeats the purpose of making those security decisions.

I'm getting a bit of déjà vu from this thread, and think the same answer should come as from previous threads on the topic: no, please come up with something new. I don't see the proposed document being anywhere close to getting consensus for adoption by the TLS WG. For the stubborn, an (independent) informational RFC would get far less (but nontrivial) opposition.

Dave

PS
Please avoid the "but they'll do whatever they want anyway" comebacks. If the response to not accommodating static keys anymore is to stay with TLS 1.2 forever, then at least they'll be open in their desire to avoid change at all costs. We should not treat this like a hostage scenario.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 8 Jul 2017 22:21:10 +0000

> 1) Both server and client must explicitly opt-in

Why can't it be implicit such as when you click-through on the website's terms of service?

> 2) A third party should be able to tell whether or not this feature is enabled by observing the stream

Why?  Because we want to watch who's doing it?  Do we watch who is leaking plaintext?

---

From: Roland Zink <[email-masked]>
Date: Sun, 9 Jul 2017 00:53:22 +0200

Nice requirements. Will those be applied to all protocols around TLS? 
For example HTML/HTTP/QUIC tend to send data to third parties through 
additional connections and the HTTP referer header tells all those 3rd 
parties the URL used. This is a breach of the users privacy. For 
surveillance no wiretapping is necessary. A secret service just needs to 
infiltrate a few big companies and will get a pretty good overview who 
browse what. The user didn't explicitly opt-in into this although you 
may argue the client software (browser) does. A third party can't tell 
if this feature is enabled or not by observing the stream. So should the 
usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden? 
The referer header not allowed when TLS is used?

As a server (and client) can always silently forward the unencrypted 
data neither 1) nor 2) can be enforced so I guess those are only should 
requirements.

Roland

Am 08.07.2017 um 23:16 schrieb Nick Sullivan:
> These two requirements protect services on the wider Internet from 
> being accidentally (or surreptitiously forced to be) subject to 
> unauthorized decryption. The static DH proposal satisfies neither of 
> the above requirements.
>
> What you likely want is something similar to TLS 1.2 session tickets 
> with centrally managed session ticket keys. The client would advertise 
> support for "passive session decryption" in an extension and the 
> server would return an unencrypted extension containing the session 
> keys encrypted by a server "passive decryption key". The passive 
> decryption key would be managed in the same way as the static DH key 
> in this draft: rotated frequently and synchronized centrally.
>
> A TLS 1.2 session ticket-like scheme provides the same semantics as 
> this static DH but provides more safeguards against accidental use 
> outside the datacenter. Both client and server need to opt in, it's 
> visible from the network, and limits the data visible to the 
> inspection service to the session (rather than exposing the master 
> secret which can be used to compute exporters and other things outside 
> of the scope of session inspection). Furthermore, in the session 
> ticket-like scheme, a */public key /*could be used to encrypt the 
> session keys, removing the need for a secure distribution scheme for 
> the endpoints. The passive decryption private key could me managed in 
> a secure location and only the public key distributed to the endpoints.
>
> In summary, even if this was to be considered as a working group 
> document, I think this is the wrong solution to problem.
>
> Nick
>
> On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The need for enterprise datacenters to access TLS 1.3 plaintext
>     for security and operational requirements has been under
>     discussion since shortly before the Seoul IETF meeting. This draft
>     provides current thinking about the way to facilitate plain text
>     access based on the use of static (EC)DH keys on the servers.
>     These keys have a lifetime; they get replaced on a regular
>     schedule. A key manager in the datacenter generates and
>     distributes these keys.  The Asymmetric Key Package [RFC5958]
>     format is used to transfer and load the keys wherever they are
>     authorized for use.
>
>     We have asked for a few minutes to talk about this draft in the
>     TLS WG session at the upcoming Prague IETF. Please take a look so
>     we can have a productive discussion.  Of course, we're eager to
>     start that discussion on the mail list in advance of the meeting.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 8 Jul 2017 23:04:56 -0700

> Nginx exists. What's the blocker?

Here's how these networks work today:

* Key servers are configured to use RSA KX, no DH.
* In some cases, all outbound (e.g. internet) connectivity is also proxied
via such a server. Clients are made to trust a private CA for this purpose.
* All data is not necessarily logged or stored somewhere, and almost
certainly not in the plain, as that would increase over-all risk.
* Admins use port-mirrors and tools like tcpdump to investigate/scan
suspicious flows from time to time, or as part of a targeted investigation.
Occasionally it might also be used for debugging. The RSA keys can be used
to render the connections plain on demand.
* That doesn't mean that the RSA private keys are readily available, they
are often very tightly controlled.

Migrating to proxies would:

* Be a very big operational change. Gotta get nginx on all of the boxes, is
that even possible?
* Completely change the access mechanisms, invalidate almost all of the
operational controls.
* Probably more than double the basic compute costs associated with
encryption.
* Create more sensitive environments where plaintext is floating around.

That doesn't mean that these vendors/operators are owed a solution, or an
easy-to-insert more-or-less-compatible-with-today mechanism. But it does
help assess whether they are really likely to adopt TLS1.3 to begin with.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Sun, 9 Jul 2017 14:15:37 -0500

I don't understand this proposal at all.  You absolutely can build in
wiretapping capabilities into TLS server implementations without any
help from the TLS protocol.

(E.g., your servers could send a multicast UDP datagram for each
session/connection, bearing metadata and master keys encrypted to a
logging facility's public key, or in a logging session key.  If UDP be
insufficiently reliable for your needs, then use TCP.  Yes, there's
overhead in this, but it's minimal, and you already need fast logging
facilities anyways.)

Changing the TLS protocol to aid in wiretapping risks introducing
vulnerabilities in the protocol.

Nico
--

---

From: Eric Mill <[email-masked]>
Date: Sun, 9 Jul 2017 15:16:02 -0400

On Sun, Jul 9, 2017 at 2:04 AM, Colm MacCárthaigh <[email-masked]> wrote:

>> > They also don’t want to install TLS proxies all over the place.  That’s
>> a
>> > large extra expense for them.
>>
> * Be a very big operational change. Gotta get nginx on all of the boxes,
> is that even possible?
>

That's an oversimplification - proxying traffic should require addition of
points in the middle, but shouldn't (always) require modification of the
source and destination points.

But yes, it would be a big operational change. I don't think the folks
arguing that proxies can handle this are suggesting it's trivial to migrate
in this direction.

> * Completely change the access mechanisms, invalidate almost all of the

Why wouldn't these be improvements? (More below.)

> * Probably more than double the basic compute costs associated with

Perhaps, but also probably more than doubles the cost to attackers, by
granting forward secret properties to internal traffic and by removing the
number of places where keys exist that are capable of decrypting this data.

I don't see how that follows. In a previous message, Jacob Hoffman-Andrews
included a great description of why it should reduce the amount of access
to sensitive keys that can produce plaintext:

I would also point out that retrospectively decrypting pcaps asks TLS to do
double duty: as at-rest encryption in addition to transit encryption. If,
instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much better
security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much more
tightly. Instead of every TLS frontend having the keys for retrospective
decryption, those keys can be limited to auditors or security team members.

> help assess whether they are really likely to adopt TLS1.3 to begin with.

That's quite fair. However, what's so far been unstated is that it's
plausible for regulatory pressure to eventually build to push regulated
enterprises towards TLS 1.3 and away from 1.2.

It's also quite plausible that regulatory pressure could eventually build
to push agencies to use encrypted traffic with forward secret properties
within their data centers, for the same reasons that it's unacceptable
today to send plaintext around.

This WG is responsible for making the strongest protocol possible, and it's
up to the rest of the world how to use it. TLS 1.3 looks likely to be
extremely widely used on the public internet. If enterprises end up staying
behind on TLS 1.2 inside their networks, or making their own non-standard
alternative, because they can't summon the will to get away from
network-based monitoring, they're likely to face costs for doing that
eventually, whether regulatory or just in the ongoing overhead of creating
and maintaining non-standard tools.

-- Eric

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 13 Jul 2017 15:01:04 -0500

I don't think the WG should adopt this.

There are essentially two separate proposals in the I-D. Section 5 proposes a slight change to TLS that results in no changes on the wire and, as far as I can tell, is already allowed (but should probably be discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to do.

Sections 6 and 7 propose a new protocol for distributing key pairs. The use case is TLS, but it isn't specific to TLS and doesn't interact with TLS (outside of using TLS for HTTPS). As such, I believe it's outside the WG's charter.

-- 
Stephen Checkoway

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Jul 2017 15:27:22 -0500

+1

> There are essentially two separate proposals in the I-D. Section 5
> proposes a slight change to TLS that results in no changes on the wire
> and, as far as I can tell, is already allowed (but should probably be
> discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to
> do.
> 
> Sections 6 and 7 propose a new protocol for distributing key pairs.
> The use case is TLS, but it isn't specific to TLS and doesn't interact
> with TLS (outside of using TLS for HTTPS). As such, I believe it's
> outside the WG's charter.

Agreed.

Authors should make an ISE submission aiming for Informational, or just
let the I-D expire and never bring it up again -- that would work just
as well for me.  The IESG could always direct the ISE to not publish.

Given the lack of normative language in the proposed I-D, Informational
is the only track that makes sense.

What's to be gained by anyone in having this be a WG item anyways?
A patina of legitimacy is the only thing I can think of.

What's to be gained by anyone in having this be an RFC?  A patina of
legitimacy with which to flog it at implementors is the only thing I can
think of.

Legislatures elsewhere can always just legislate this sort of thing
(think CALEA).  But there's no reason the IETF should preemptively help
such things along.

I wouldn't be too annoyed if this gets published as an RFC because it's
all obvious and could always get published elsewhere anyways.  Refusing
to publish here won't keep this sort of thing from getting specified and
implemented.  But there is no need for the IETF's help in the matter.

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Jul 2017 20:36:34 +0000

> legitimacy with which to flog it at implementors is the only thing I can think
> of.

Folks who were at the last IETF might want to think of Prof Clark's talk about tilting the playing field; https://www.ietf.org/proceedings/98/slides/slides-98-ietf-sessc-david-clark-human-rights-in-the-balance-00.pdf

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 14 Jul 2017 15:35:26 +0000

Just want to +1 the notion that this should be opt-in for both sides and in
an extension!

On Sat, Jul 8, 2017 at 23:16 Nick Sullivan <[email-masked]>
wrote:

> key *could be used to encrypt the session keys, removing the need for a
> secure distribution scheme for the endpoints. The passive decryption
> private key could me managed in a secure location and only the public key
> distributed to the endpoints.
>
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Jul 2017 19:45:15 +0300

> On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> Just want to +1 the notion that this should be opt-in for both sides and in an extension!

It’s a good notion, but “we have to change one side” usually wins over “we have to change both sides”

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 14 Jul 2017 16:57:51 +0000

Except when it's the issue of mutual consent (rather than of a merely technical change).

Otherwise - "we have to change one side" might turn into "have you pay me $50,000 every month, your opt-in isn't necessary". :-)

Regards,
Uri

Sent from my iPhone

> On Jul 14, 2017, at 12:45, Yoav Nir <[email-masked]> wrote:
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 14 Jul 2017 20:01:53 +0200

> It’s a good notion, but “we have to change one side” usually wins over “we have to change both sides”

Something that demands a forklift upgrade of both/all sides at the
same time tends not to be deployed, ever (look at the history of
NAT/firewall traversal technologies in the IETF, as one example).

I'm basically in agreement with Stephen and Uri here but now that
I'm working for a company that's providing services I'm becoming
more aware of the real need for network monitoring.  It does need
to be discussed somewhere but I don't think that that discussion
needs to take place in the TLS working group in the context of this
one particular proposal.  There's more than one way to solve this
problem and while the fact that these folks want to keep solving
it basically the same way that they have in the past is interesting
but perhaps not as compelling as it could be.

It might make sense to kick it over to ops for a discussion with
people whose meat and potatoes is monitoring, management, and
measurement.  It needn't necessarily stay there but I think that
there are a bunch of options that need to be sorted through.  I
can't really see the static Diffie-Hellman proposal going anywhere
quickly, anyway, to be honest, so might as well use that time to
develop a fuller understanding of the potential solutions to the
problem.

Melinda

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 15 Jul 2017 01:41:57 +0700

On 15 Jul 2017, at 1:01, Melinda Shore wrote:

> measurement.

As someone who is ops-focused, I think this is an excellent suggestion!

There have been several assertions posted to the list recently regarding 
various aspects of security and their intersection with encryption.  It 
may be useful to take a moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted attack 
traffic, only a subset of attacks in a subset of situations can actually 
be adequately mitigated without full visibility into (and often the 
ability to interact with) the traffic within the cryptostream.  There 
are various ways to approach this issue, including full session 
termination and 'transparent' detection/classification, the latter of 
which isn't of course feasible in a PFS scenario.  Each of these general 
approaches has its advantages and drawbacks.

Very specifically, fingerprints of encrypted streams are not in fact 
adequate for DDoS defense; again, they're only useful for a subset of 
attack types in a subset of situations.

In the case of detecting and classifying hostile activity within a given 
network - which isn't limited to malware spreading, but includes data 
extraction, attempts at unauthorized access, attempts at subverting 
additional devices, et. al. - the same basic caveats apply.  It is not 
in fact possible to adequately detect and classify all, or even a large 
subset, of hostile network traffic without visibility into the 
cryptostream.  There are some gross behaviors which can be 
detected/classified whilst standing outside the tunnel, but assertions 
to the effect that all or most of what's required in this arena is 
possible without visibility (one way or another) into the relevant 
encrypted traffic are incorrect.

It's also important to understand that inserting proxies into multiple 
points of a network topology is not cost-free, nor an unalloyed good.  
It is impractical in many circumstances, and has highly unwelcome 
side-effects in many more, including a negative impact on reliability, 
performance, and availability, as well as broadening the potential 
attack surface.  Endpoint monitoring does not scale well, is often 
impossible to implement due to both technical and administrative 
challenges - and one can't really trust endpoints to self-report, 
anyways, as they can be subverted.

In many scenarios, one form or another of network-based visibility into 
encrypted traffic streams within the span of administrative control of a 
single organization is legitimate, vital and necessary.  It is not 
'wiretapping', any more than tools such as tcpdump or telemetry formats 
such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact 
is, the availability, confidentiality, and integrity of systems, 
applications, and networks that everyone on this list relies upon is 
highly dependent upon the ability of organizations to have visibility 
into encrypted traffic streams within their own networks, for purposes 
of security as well as testing and troubleshooting.

How this can be accomplished is a matter for further discussion.  But 
it's important that everyone focused on this topic understands that it 
is simply not possible to successfully defend against many forms of DDoS 
attacks nor to detect and classify hostile network traffic in the 
context of encrypted communications without visibility into the traffic 
in question, via some mechanism.  The same goes for troubleshooting 
complex problems.

Those with operational experience at scale will likely recognize and 
acknowledge the difficulties and challenges noted above; others may wish 
to consider these factors and their impact on the operational community 
and the networks, services, and applications for which they are 
responsible, and upon which we all depend, every day.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jul 2017 21:15:19 +0200

It seems to me that all the use cases you just described require the
*client* to have a static key, since the client is the thing that the
operator controls. If the client uses an unknown key, is malware or
unauthorized.

On Jul 14, 2017 20:42, "Roland Dobbins" <[email-masked]> wrote:

> It might make sense to kick it over to ops for a discussion with people
>> whose meat and potatoes is monitoring, management, and
>> measurement.
>>
>
> various aspects of security and their intersection with encryption.  It may
> be useful to take a moment and clarify a few of them.
>
> With regards to DDoS mitigation as it relates to encrypted attack traffic,
> only a subset of attacks in a subset of situations can actually be
> adequately mitigated without full visibility into (and often the ability to
> interact with) the traffic within the cryptostream.  There are various ways
> to approach this issue, including full session termination and
> 'transparent' detection/classification, the latter of which isn't of course
> feasible in a PFS scenario.  Each of these general approaches has its
> advantages and drawbacks.
>
> additional devices, et. al. - the same basic caveats apply.  It is not in
> fact possible to adequately detect and classify all, or even a large
> detected/classified whilst standing outside the tunnel, but assertions to
> the effect that all or most of what's required in this arena is possible
> without visibility (one way or another) into the relevant encrypted traffic
> are incorrect.
>
> points of a network topology is not cost-free, nor an unalloyed good.  It
> is impractical in many circumstances, and has highly unwelcome side-effects
> in many more, including a negative impact on reliability, performance, and
> availability, as well as broadening the potential attack surface.  Endpoint
> monitoring does not scale well, is often impossible to implement due to
> both technical and administrative challenges - and one can't really trust
> endpoints to self-report, anyways, as they can be subverted.
>
> such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is,
> the availability, confidentiality, and integrity of systems, applications,
> and networks that everyone on this list relies upon is highly dependent
> upon the ability of organizations to have visibility into encrypted traffic
> streams within their own networks, for purposes of security as well as
> testing and troubleshooting.
>
> How this can be accomplished is a matter for further discussion.  But it's
> important that everyone focused on this topic understands that it is simply
> not possible to successfully defend against many forms of DDoS attacks nor
> to detect and classify hostile network traffic in the context of encrypted
> communications without visibility into the traffic in question, via some
> mechanism.  The same goes for troubleshooting complex problems.
>
> acknowledge the difficulties and challenges noted above; others may wish to
> consider these factors and their impact on the operational community and
> the networks, services, and applications for which they are responsible,
> and upon which we all depend, every day.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 14 Jul 2017 23:01:26 +0200

Hi Roland,

It sounds like you misread my messages and should read them in context of TLS 1.3 and the draft using DH static keys proposed to help with monitoring.

Best regards,
Kathleen 

Sent from my iPhone

> On Jul 14, 2017, at 8:41 PM, Roland Dobbins <[email-masked]> wrote:
> 
>> It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is monitoring, management, and
>> measurement.
> 
> There have been several assertions posted to the list recently regarding various aspects of security and their intersection with encryption.  It may be useful to take a moment and clarify a few of them.
> 
> With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and often the ability to interact with) the traffic within the cryptostream.  There are various ways to approach this issue, including full session termination and 'transparent' detection/classification, the latter of which isn't of course feasible in a PFS scenario.  Each of these general approaches has its advantages and drawbacks.
> 
> Very specifically, fingerprints of encrypted streams are not in fact adequate for DDoS defense; again, they're only useful for a subset of attack types in a subset of situations.
> 
> In the case of detecting and classifying hostile activity within a given network - which isn't limited to malware spreading, but includes data extraction, attempts at unauthorized access, attempts at subverting additional devices, et. al. - the same basic caveats apply.  It is not in fact possible to adequately detect and classify all, or even a large subset, of hostile network traffic without visibility into the cryptostream.  There are some gross behaviors which can be detected/classified whilst standing outside the tunnel, but assertions to the effect that all or most of what's required in this arena is possible without visibility (one way or another) into the relevant encrypted traffic are incorrect.
> 
> It's also important to understand that inserting proxies into multiple points of a network topology is not cost-free, nor an unalloyed good.  It is impractical in many circumstances, and has highly unwelcome side-effects in many more, including a negative impact on reliability, performance, and availability, as well as broadening the potential attack surface.  Endpoint monitoring does not scale well, is often impossible to implement due to both technical and administrative challenges - and one can't really trust endpoints to self-report, anyways, as they can be subverted.
> 
> In many scenarios, one form or another of network-based visibility into encrypted traffic streams within the span of administrative control of a single organization is legitimate, vital and necessary.  It is not 'wiretapping', any more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is, the availability, confidentiality, and integrity of systems, applications, and networks that everyone on this list relies upon is highly dependent upon the ability of organizations to have visibility into encrypted traffic streams within their own networks, for purposes of security as well as testing and troubleshooting.
> 
> How this can be accomplished is a matter for further discussion.  But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against many forms of DDoS attacks nor to detect and classify hostile network traffic in the context of encrypted communications without visibility into the traffic in question, via some mechanism.  The same goes for troubleshooting complex problems.
> 
> Those with operational experience at scale will likely recognize and acknowledge the difficulties and challenges noted above; others may wish to consider these factors and their impact on the operational community and the networks, services, and applications for which they are responsible, and upon which we all depend, every day.
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Jul 2017 18:40:00 -0700

> With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and…

DDoS mitigation can be done at endpoints, and indeed has to be given
that other tools do not know which endpoints need to be rate-limited
or are expensive.  A lot of distinct things are being crammed together
into DDoS, and the fact is endpoints can deal with application layer
attacks via rate-limits, CAPTCHAs, and other techniques, while
not-application layer attacks don't require visibility to defeat. What
can a middlebox do that an endpoint cannot? Globbing a bunch of
distinct things together is not helping the debate.

> It's also important to understand that inserting proxies into multiple points of a network topology is not cost-free, nor an unalloyed good.  It is impractical in many circumstances, and has highly…

You are conflating different situations. If you want to detect
unauthorized access to a resource, having the resource which
determines access anyway log that is enough. Exfiltration detection
based on looking for sensitive identifiers doesn't work: real
attackers will encrypt the data and dribble it out slowly or pretend
to be videoconferencing. Did any exfiltration detector stop
heartbleed? Endpoint subversion is not an issue for access control: if
the endpoint is subverted, access has been gained. It isn't an issue
for DDoS protection.

Malware detection on the network does have to worry about subversion
of endpoints, and yes, being able to recognize anomalous traffic is
helpful here.

As for attack surface why is "Press here to get plaintex of
everything" not a major, major increase in attackability? Any honest
assessment of middlebox techniques would acknowledge they can also be
attacked and are inherently unsegmented.

Just because many large organizations have decided not to adopt the
smart-endpoint, dumb-network model of the Internet doesn't mean the
Internet needs to be redesigned to accommodate them. I am seeing
middlebox vendors and one vertical express need for this.
> How this can be accomplished is a matter for further discussion.  But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against ma…

Which DDoS attacks specifically? And if the traffic isn't hitting
endpoints, does it matter?
> Those with operational experience at scale will likely recognize and acknowledge the difficulties and challenges noted above; others may wish to consider these factors and their impact on the opera…

I'm currently working at place you notice when we go down. We do not
use these techniques on our production network. We use mutual TLS for
a large number of internal services, even within the datacenter and
the same machine. We debug many complex issues through logs and
specialized tools to examine troublesome state, as well as request
tracing. I've not personally had the pleasure of doing this, but I
know it is possible because it is done every day.

Finally, most software can export the secrets from TLS connections to
a file. The capacity being asked for already exists.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 15 Jul 2017 05:58:31 +0000

Unless I missed the reply, I did not see any answer to my question as to why it must be opt-in.  Do we think evildoers will tell the truth about what they are doing?

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 15 Jul 2017 02:10:32 -0400

On Sat, Jul 15, 2017 at 1:58 AM, Salz, Rich <[email-masked]> wrote:
> Unless I missed the reply, I did not see any answer to my question as to why
> it must be opt-in.  Do we think evildoers will tell the truth about what
> they are doing?

Opt-in is choice. Choice for a consumer is usually a good thing.
Sunlight is the best disinfectant.

The market can punish those who don't respect privacy concerns. I
can't speak for others, but I regularly avoid services that I find
unpalatable.

Some evildoers won't tell the truth. Eventually some will be caught.
The market can punish those who get caught.

EU regulators may be able to exert legal pressure on dishonest
evildoers. I doubt the US will take any action. The oligarchy is
strong on this side of the pond.

I speculate EU entities that were honest about their practices will
sidestep some regulatory actions.

Jeff

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 15 Jul 2017 08:12:42 +0200

On Sat 2017-07-15 05:58:31 +0000, Salz, Rich wrote:
> Unless I missed the reply, I did not see any answer to my question as
> to why it must be opt-in.  Do we think evildoers will tell the truth
> about what they are doing?

Because presumably the people who do *not* want to do evil want to avoid
specifying a mechanism that will be widely implemented that could leak
into use outside of the intended scenario.  right?

As far as i can tell, we're all in agreement here that:

 * This proposed TLS variant is *never* acceptable for use on the public
   Internet.  At most it's acceptable only between two endpoints within
   a datacenter under a single zone of administrative control.

 * Forward secrecy is in general a valuable property for encrypted
   communications in transit.

If there's anyone on the list who disagrees with the above two
statements, please speak up!

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 15 Jul 2017 08:26:35 +0200

On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote:

> met without access to the plaintext.

This is surely true, but it's not clear to me that any regulator
requires access to the plaintext *from direct network capture*.

Could you point to an example of any regulation that requires plaintext
from network capture specifically?

There are many non-network-based ways that plaintext can be produced as
required by the regulated endpoints, without introducing a standardized
mechanism that increases the attack surface of widespread
implementations on the public Internet.

Why should we privilege network capture (e.g. retrospectively
decryptable pcap dumps) as a means of meeting regulatory requirements
when:

 (a) other means of meeting regulatory requirements exist, and

 (b) we know that network capture is widely used adversarially by the
     kinds of attackers that TLS is explicitly intended to defend
     against?

       --dkg

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 07:38:57 +0000

> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

I would strongly attempt to dissuade anyone from using it across the public Internet. I agree that it is best-suited for use on networks within a single span of administrative control, & that's the use for which it is intended.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 07:42:58 +0000

> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

It often isn't feasible to obtain the plaintext any other way in a given circumstance. 

Not to mention the security & troubleshooting applications which require insight into the cryptostream on the wire.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 09:47:35 +0200

In the event that it is not feasible for an operator to obtain the
plaintext of a message without the key, isn't that because they don't
control either endpoint?   If so, why would it be their responsibility to
obtain the plaintext?   It should be the responsibility of the controller
of one of the endpoints.

If they do control one of the endpoints, then they don't need the key, or
rather, they have it.   So it is not our problem to provide them with a way
to change it less frequently, which is really what this proposal boils down
to.

Can you give an example of a use case for this proposal where what I just
said is not true, and explain why it is not true for that use case?   Sorry
if I am being dense, but I just don't understand why this is an issue.

On Sat, Jul 15, 2017 at 9:42 AM, Dobbins, Roland <[email-masked]> wrote:

> Not to mention the security & troubleshooting applications which require
> insight into the cryptostream on the wire.
>

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 07:48:25 +0000

>     kinds of attackers that TLS is explicitly intended to defend

Because we know that network capture is an absolute, unquestionable requirement in order to defeat adversaries who are both prevalent & who can actually be defeated. 

There's no talk of 'privileging' anything. The talk is about not arbitrarily depriving network administrators & security personnel of the tools & techniques they've been using for many years and with great success to troubleshoot & defend their networks, applications, services, & data.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 07:54:57 +0000

> On Jul 15, 2017, at 14:48, Ted Lemon <[email-masked]> wrote:
> 
> In the event that it is not feasible for an operator to obtain the plaintext of a message without the key, isn't that because they don't control either endpoint?

First of all, what goes on the wire is often contextually different  (and probatively so) from what's recorded in abstract log files. 

Secondly, administrative divisions within a single organization often impede cooperation between those tasked with securing & troubleshooting communications and those who 'own' the assets in question. 

Thirdly, for both security & troubleshooting applications, the hard requirement is for real-time visibility & possible intercession, not ex post facto analysis.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 10:06:28 +0200

I think that your first and third points are actually non-sequiturs: the
unencrypted stream is available to the entities controlling either
endpoint, not just the log.   There is no *technical *reason that in-flight
capture is required to address those two points.

Regarding your second point, this seems to be the real key that is
motivating you to make the first and third points.   If I may paraphrase,
the problem you are attempting to address is that in some situations two
sub-organizations both of which are in principle responsible to a larger
organization nonetheless are unable to cooperate due essentially to a
failure by one sub-organization to take seriously the responsibilities of
the other sub-organization, and the failure of the organization to which
they are both subordinate to successfully encourage cooperation on the part
of the intransigent sub-organization.   Did I paraphrase that correctly?

On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland <[email-masked]> wrote:

> control either endpoint?
> First of all, what goes on the wire is often contextually different  (and
> probatively so) from what's recorded in abstract log files.
>
> Secondly, administrative divisions within a single organization often
> impede cooperation between those tasked with securing & troubleshooting
> communications and those who 'own' the assets in question.
>
> Thirdly, for both security & troubleshooting applications, the hard
> requirement is for real-time visibility & possible intercession, not ex
> post facto analysis.
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 15 Jul 2017 11:14:50 +0300

> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

This TLS variant is only about using the same key share for a while. This is already done for optimization (as in “use the same key share for 1 minute before generating a new one”) although I guess for decryption a key would be used for longer than a minute.

The one difference between reusing a key share for optimization and reusing a key share for decryption is whether or not the server dumps this key share to disk. That is not a difference in TLS. In fact these two are indistinguishable. And that brings us back to Rich’s question: Do we expect evildoers to signal that they’re doing this?

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 08:22:50 +0000

On Jul 15, 2017, at 15:07, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log.

This assertion is both incorrect & incomplete in its scope.

There is no technical reason that in-flight capture is required to address those two points.

This assertion is factually incorrect.  There are quite frequently reasons to have both visibility & the ability to intercede into the traffic in question at one or more specific points in the network topology *between* endpoints.

This is network security & troubleshooting 101.

  Did I paraphrase that correctly?

No - the attempt to denigrate & dismiss real-world technical operational requirements is invalid, as is the dismissal of the administrative context of actual network operators in the real world.

The three points I made are independent of one another, & can be validated by anyone with a moderate degree of operational experience on production networks.

-----------------------------------
Roland Dobbins <[email-masked]<mailto:[email-masked]>>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 10:48:50 +0200

On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland <[email-masked]>
wrote:
> endpoint, not just the log.
>

Okay.   What did I miss?

> There is no *technical *reason that in-flight capture is required to
> address those two points.
>
> This assertion is factually incorrect.  There are quite frequently reasons
> to have both visibility & the ability to intercede into the traffic in
> question at one or more specific points in the network topology *between*
> endpoints.
>

For example?

> This is network security & troubleshooting 101.

Great!   Can you point me to the textbook for that class, because I must
have missed it!

> No - the attempt to denigrate & dismiss real-world technical operational
> requirements is invalid, as is the dismissal of the administrative context
> of actual network operators in the real world.
>

I believe that I merely described the situation.   If you think my
description was not accurate, then it would be great if you could explain
in what way it was not accurate.   I realize that institutional problems of
the sort that I described do exist, are real, and do cause real pain for
ops people--that's not my point.   My point is that what you are describing
sounds like it's a layer 9 problem.   If it's not, I'm genuinely not seeing
it.   Rather than being offended at what you say is my mischaracterization
of the situation, could you just point out where the mischaracterization
lies?

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Jul 2017 11:55:44 +0300

On Sat, Jul 15, 2017 at 07:48:25AM +0000, Dobbins, Roland wrote:
> Because we know that network capture is an absolute, unquestionable
> requirement in order to defeat adversaries who are both prevalent
> & who can actually be defeated. 

s/we know/I believe/

You seem to think that more data is better. Except collecting more data
will drive up background. And if you have high background, even common
events will just blend in and be missed completely, or are detected
with very poor efficiency.

Have big enough backgrounds, and one can have estimated over one
million events of certain interesting kind in one year, _while_ taking
data, but not able to be reasonbly sure that even a single event of the
kind occured. And that's while people specifically looking for events
of that kind.

OTOH, with small backgrounds, even very small amount of events will
really stand out. With really small backgrounds, even _one_ event
will stand out.

> There's no talk of 'privileging' anything. The talk is about not
> arbitrarily depriving network administrators & security personnel of
> the tools & techniques they've been using for many years and with
> great success to troubleshoot & defend their networks, applications,
> services, & data. 

You mean using security problems, that are exploited for bad ends too,
in past versions of TLS? E.g. using various problems in session tickets
and RSA key exchange?

Oh, and like any backdoor, this backdoor too has variety of security
problems. And your adversaries would absolutely love to be able to
exploit _you_ using these problems, as that would make their lives much
easier.

-Ilari

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 09:05:00 +0000

On Jul 15, 2017, at 15:49, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

Can you point me to the textbook for that class, because I must have missed it!

There is plenty of information on these topics available on the Internet today.  Search engines exist.  It isn't reasonable to expect a class to be held on the basics of network security & troubleshooting tools & techniques on this WG list.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 09:16:08 +0000

> On Jul 15, 2017, at 16:05, Dobbins, Roland <[email-masked]> wrote:
> 
> There is plenty of information on these topics available on the Internet today.

At the risk of self-replying, it should also be noted that highly informative discussions of these challenges, & detailed presentations thereof, have taken place in WG meetings at previous IETF meetings.  

There has also been ample time since those discussions & presentations to gain additional understanding & insight.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 11:29:53 +0200

On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland <[email-masked]>
wrote:

> There is plenty of information on these topics available on the Internet
> today.  Search engines exist.  It isn't reasonable to expect a class to be
> held on the basics of network security & troubleshooting tools & techniques
> on this WG list.
>

Roland, the reason that I made that particular comment was to try to show
you that the position you have taken here is untenable.   There is no such
textbook.   There is no consensus that what you have said is true.   I
understand that you believe it is true, and I'm sure it's frustrating that
not everybody believes it.   But if you want everybody to believe it, you
have to make your case, and not just hand-wave when I ask you for specifics.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 11:38:21 +0200

I was at at least one of those presentations recently, and while it
certainly convinced me that there was a problem in the short term, it did
not convince me that the points you are making are inherent problems with
the technology.   That is, the problem is not that there is no way to
achieve what you intend without static keys, but rather that it would be
difficult in the context of some existing deployed architectures to achieve
what you intend without static keys.  I agree that this is a problem.

On Sat, Jul 15, 2017 at 11:16 AM, Dobbins, Roland <[email-masked]>
wrote:

> today.
> At the risk of self-replying, it should also be noted that highly
> informative discussions of these challenges, & detailed presentations
> thereof, have taken place in WG meetings at previous IETF meetings.
>

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 10:00:36 +0000

> On Jul 15, 2017, at 16:30, Ted Lemon <[email-masked]> wrote:
> 
> Roland, the reason that I made that particular comment was to try to show you that the position you have taken here is untenable.

It is not untenable. It is operational really. 

>   There is no such textbook.

As you now, that was a euphemism for 'a moderate degree of operational experience on networks of at least moderate complexity and scope'.  One comes by this knowledge by doing the work. 

To deny the reality of the situation as described is equivalent to denying that the sun rises in the East. You can deny it all you want, but it doesn't change the objective facts of the situation. 

>   There is no consensus that what you have said is true.

There is amongst those with actual operational experience. 

>   I understand that you believe it is true,

I *know* it to be true.  It is objective, verifiable fact. 

> and I'm sure it's frustrating that not everybody believes it.

It's not frustrating. It's just indicative that the level of operational experience of many of those engaged on this topic is minimal. 

For myself, I would not presume to interpose myself in a discussion of topics of which I've little understanding, nor would I dismiss the arguments of specialists in the relevant fields without first having educated myself to attain a reasonable degree of understanding of those arguments. 

>   But if you want everybody to believe it, you have to make your case, and not just hand-wave when I ask you for specifics.

It has already been explained in detail. Beyond what I've already explained here, relevant  information is readily available both in the context of meetings of this WG and elsewhere on the Internet. 

Anyone who has genuine interest in understanding these topics has plenty of information available to be perused.  And it is obvious that if there weren't significant issues at stake, then they wouldn't have been raised in the first place.

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 15 Jul 2017 10:57:14 +0000

I'd like to raise another point.

Static Diffie-Hellman is a cryptographically problematic construction. Not
only was it found to be fragile to implement in the prime field variant
(LogJam), the Elliptic Curve variant has recently been identified as
troublesome as well (see recent JWE vulnerability
https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html
and CVE-2017-8932). Furthermore, many post-quantum key exchange mechanisms
cannot be secured with repeated key shares (SIDH is one example).

Encouraging (or worse, standardizing) the repeated use of a key share seems
risky and shortsighted.

For this reason, and the fact that there are alternative techniques to
achieve the same goals (put the symmetric key material in a serverhello
extension encrypted with an exfiltration key, for example), I don't think
this proposal should be considered. If alternative proposals come are
presented that don't require key shares to be reused, I am not against
discussing them.

Nick

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 15 Jul 2017 13:19:10 +0200

> exploit _you_ using these problems, as that would make their lives much

I'd like to hear from the people who are doing full-take network capture
within their datacenters about how they protect the security of the
internal decryption systems.  It certainly sounds like a tempting target
for any adversary interested in datacenter operations.

           --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 15 Jul 2017 13:23:35 +0200

On Sat 2017-07-15 07:42:58 +0000, Dobbins, Roland wrote:
> Not to mention the security & troubleshooting applications which
> require insight into the cryptostream on the wire.

I asked for examples of regulations that specifically require plaintext
from the network.

This e-mail contains no such example, just an assertion that it's
technically easier/simpler to do network capture for some deployments.
i believe this assertion, btw, so you don't need to argue it further.
Whether it justifies a loss of security is a separate question.

If anyone has a specific example of a regulation that mandates network
capture, i'd like to know about it.

If there are no such examples, and we plan to continue to discuss this
draft, i'd appreciate it if folks could take the "regulators require it"
argument off of the table, and we can focus on the actual technical
merits and risks of the proposal directly.

Regards,

    --dkg

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 15 Jul 2017 18:56:31 +0700

On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:

> internal decryption systems.

Firstly, they generally aren't storing everything, forever.  Most of the 
time, they feed into collection/analysis systems, and most if not all of 
the actual packets are discarded.

In many cases, they're only enabled on a situational basis - say, a 
security incident or a troubleshooting session.  Most if not all of the 
packets are discarded afterwards, in most cases.

In most cases, they're running on completely out-of-band management 
networks, using transparent taps or SPAN ports or equivalent.  In some 
cases, they can be used to intervene in the cryptostream - but even in 
that in-band case, all the management functions are still isolated on 
out-of-band management networks which are not interconnected with the 
production network, and are further isolated as necessary by 
implementing situationally-appropriate network access policies.

> It certainly sounds like a tempting target for any adversary 
> interested in datacenter operations.

I guarantee you that your bank, your hospital, your insurance provider, 
your credit card processor, your retailer, and/or your government 
welfare agency are doing this, and have been doing it for a long time.

It's quite common in the national security space, as well as other 
governmental bureaux.

I'm not saying everyone has implemented this perfectly, or optimally - 
but it is a common practice which has been going on for many years, and 
the loss of the ability to perform these functions would result in a net 
security loss for these organizations and for their customers and 
constituents - i.e., proles like you and me.

It isn't new, it isn't unique, it isn't a case of a small group engaging 
in special pleading.  What's amazing is that very few engaged in this 
discussion seems to understand all this.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 15 Jul 2017 18:59:37 +0700

> Whether it justifies a loss of security is a separate question.

It isn't a loss of security - it's actually a net gain for security.  
Network visibility, independent of any end-host, is a key requirement 
for network security.

As to the specific regulations, folks from the appropriate verticals 
will need to speak up.  I know vaguely that there are regulations in the 
financial sector and the defense contracting sector which apply, but 
can't cite chapter and verse.

I'm sure someone on the list can, however.

---

From: Kyle Rose <[email-masked]>
Date: Sat, 15 Jul 2017 08:18:45 -0400

> It isn't a loss of security - it's actually a net gain for security.

Security isn't a scalar quantity, so there's no way you can credibly assert
this. OTOH, it's easy to point to the individual security properties lost
by expanding the attack surface for a particular session key or by
mandating key-reuse.

Analyzing the impact of any particular mechanism for middlebox inspection
is a question of tradeoffs: what are you giving up, what are you gaining,
and is the trade worth it? The first two are questions of fact (though I'm
under no illusion that there would even be broad agreement on those). The
last is not: it's inherently subjective and among other things it depends
on the threats, the alternative mechanisms available, and the value placed
on the properties TLS provides to end users in its unadulterated form.

Every one of your emails seems to boil down to an argument of the form
"Organizations have infrastructure and operations set up to do inspection
this way, so we need some way to apply that to TLS 1.3." I am unpersuaded
by such arguments as a reason for standardizing a weakening of TLS. Given
that, I would like to understand the origins of this approach to
monitoring, as that may shed light on the hidden or unspecified constraints
other than those imposed by TLS. (For example, if this approach is deemed
to be less costly than doing endpoint monitoring, or if there are
insufficient access controls for entry to the privileged network, or if the
privileged network has systems that are too difficult to secure.)

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Sat, 15 Jul 2017 09:08:34 -0400

I've rebased from the kernel master HEAD (4.12.0+), tested, and
force-pushed the repository.

Conveniently, it looks like, since the last time I searched for one,
someone added an ECDH implementation to the kernel. That makes this a lot
easier.

Kyle

On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose <[email-masked]> wrote:

> Security isn't a scalar quantity, so there's no way you can credibly
> assert this. OTOH, it's easy to point to the individual security properties
> lost by expanding the attack surface for a particular session key or by
> mandating key-reuse.
>

---

From: Kyle Rose <[email-masked]>
Date: Sat, 15 Jul 2017 09:10:38 -0400

I might want to try responding to the right thread. Apologies for the
noise. ;-)

Kyle

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 15 Jul 2017 15:36:19 +0000

Ted
Your first sentence illustrates the disconnect between the Enterprise perspective and what many at IETF are saying.
That being the unencrypted stream is available to the endpoints.   IT IS NOT.     When you run a packet trace at the endpoint,  you will see encrypted payloads and will need the keys to decrypt.
So you can collect packet trace information at thousands or nodes,  or you can collect packet traces from network taps.   You still need the keys to derive meaningful diagnostic and monitoring information.

People than run and manage networks are PAINFULLY aware of this fact.     This is why we need what this draft proposes.

From: TLS [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Saturday, July 15, 2017 4:06 AM
To: Dobbins, Roland <[email-masked]>
Cc: IETF TLS <[email-masked]>; Matthew Green <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log.   There is no technical reason that in-flight capture is required to address those two points.

Regarding your second point, this seems to be the real key that is motivating you to make the first and third points.   If I may paraphrase, the problem you are attempting to address is that in some situations two sub-organizations both of which are in principle responsible to a larger organization nonetheless are unable to cooperate due essentially to a failure by one sub-organization to take seriously the responsibilities of the other sub-organization, and the failure of the organization to which they are both subordinate to successfully encourage cooperation on the part of the intransigent sub-organization.   Did I paraphrase that correctly?

On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland <[email-masked]<mailto:[email-masked]>> wrote:

> On Jul 15, 2017, at 14:48, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 15 Jul 2017 15:46:14 +0000

Most of us have Key Vaults and related management systems that are so (OVER in my opinion) secure, that this has never been a problem for us (in reality ---- NOT in theory or conversation).   

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Saturday, July 15, 2017 7:19 AM
To: Ilari Liusvaara <[email-masked]>; Dobbins, Roland <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote:
> exploit _you_ using these problems, as that would make their lives 
> much easier.

I'd like to hear from the people who are doing full-take network capture within their datacenters about how they protect the security of the internal decryption systems.  It certainly sounds like a tempting target for any adversary interested in datacenter operations.

           --dkg

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 15 Jul 2017 12:18:34 -0400

On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins <[email-masked]> wrote:
> time, they feed into collection/analysis systems, and most if not all of the
> actual packets are discarded.
>
> In many cases, they're only enabled on a situational basis - say, a security
> incident or a troubleshooting session.  Most if not all of the packets are
> discarded afterwards, in most cases.
>
> cases, they can be used to intervene in the cryptostream - but even in that
> in-band case, all the management functions are still isolated on out-of-band
> management networks which are not interconnected with the production
> network, and are further isolated as necessary by implementing
> situationally-appropriate network access policies.

When I have done this in the past in environments I've managed, I
always used a one way cable (receive only), set up the interface for
receive only, and then use the same protection mechanism offered by
the switch.

>
>> It certainly sounds like a tempting target for any adversary interested in
>> datacenter operations.
>
>
> I guarantee you that your bank, your hospital, your insurance provider, your
> credit card processor, your retailer, and/or your government welfare agency
> are doing this, and have been doing it for a long time.
>
> I'm not saying everyone has implemented this perfectly, or optimally - but
> it is a common practice which has been going on for many years, and the loss
> of the ability to perform these functions would result in a net security
> loss for these organizations and for their customers and constituents -
> i.e., proles like you and me.
>
> It isn't new, it isn't unique, it isn't a case of a small group engaging in
> special pleading.  What's amazing is that very few engaged in this

-- 

Best regards,
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 18:19:21 +0200

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <[email-masked]>
wrote:

> Your first sentence illustrates the disconnect between the Enterprise
> perspective and what many at IETF are saying.
>
> That being the unencrypted stream is available to the endpoints.   IT IS
> NOT.     When you run a packet trace at the endpoint,  you will see
> encrypted payloads and will need the keys to decrypt.
>
> So you can collect packet trace information at thousands or nodes,  or you
> can collect packet traces from network taps.   You still need the keys to
> derive meaningful diagnostic and monitoring information.
>

I agree that we have illustrated the disconnect here, in some sense.
However, from my perspective, what I see is that there is a problem: you
need to be able to look inside the stream.   I think we agree that this is
the problem.

There is a further problem: you have a set of tools that solves this
problem in a particular way, and for the moment, you are stuck with those
tools.   This is where I think the disconnect starts.   I am not
disagreeing with you that, for the moment, you are stuck with these tools.m
  But, I *am* disagreeing with you on the conclusion that this situation
leads to.

To me, it leads to the conclusion that you need two things.   First, you
need a plan for how to survive the situation you're stuck in right now.
Second, you need a plan for how you're going to approach this when next you
upgrade your infrastructure.  If I were in your position, my plan for the
first part would be to use TLS 1.2.   You already have what you want, and
you control the endpoints.   If it ain't broke, why fix it?

What I think is urgent, though, is that you be planning for how you're
going to handle this going forward.   There are a number of ways of doing
it.   One way would be to keep an appropriately-scaled log of keys.  If you
just need to look at active streams, it would be a rolling log, and your
snooping device would, when asked to snoop a stream, get the key.   This is
an improvement over TLS 1.2, because it increases accountability: you have
to ask for a key to decrypt a particular conversation, so it is known that
you decrypted that conversation.   Of course, if you are decrypting _every_
conversation, that's not so great.   Of course, key exfiltration is an
attack surface, but so is the static key.   Better get that right.

The other thing you can do is to do proper tooling on your servers, so that
you *can *access the raw stream.   This would require different tooling
than you have now, but there's no technical barrier to doing it.

Now, it's possible that either of these solutions would be less secure than
using a static key.   But I don't hear you arguing that.   You're still
back on tactics: how do I do what I need to do with the tools I have.   The
answer is, use TLS 1.2 until you upgrade.   Put the time in to shave off
all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves
off--disable the deprecated algorithms, for example.  It's your site, you
control the endpoints, this shouldn't be a problem.   But basically, just
keep doing what you are doing for now.

Maybe this is a naive suggestion on my part, but what I haven't been
hearing in this discussion is serious consideration of the tactical problem
and the strategic problem.   What I've been hearing is "forget about
strategy, we want tactics."

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 15 Jul 2017 12:22:22 -0400

On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins <[email-masked]> wrote:
> Network visibility, independent of any end-host, is a key requirement for
> network security.

Visibility, yes, but I don't agree that you can't protect the network
if traffic is encrypted.  Many incident response teams are able to use
indicators of compromise (IoCs) for encrypted streams.

>
> As to the specific regulations, folks from the appropriate verticals will
> need to speak up.  I know vaguely that there are regulations in the
> financial sector and the defense contracting sector which apply, but can't
> cite chapter and verse.
>

-- 

Best regards,
Kathleen

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 15 Jul 2017 16:39:04 +0000

Ted
Thank you for your response which appears to be an objective attempt to

  1.  Understand what some of our issues are.
  2.  Try to suggest optimal solutions.   Both long and short term.

This type of positive/constructive attitude has been missing from the majority of the List exchanges on this topic.    I have found that frustrating.

I think the Enterprises involved want to find the best solutions possible and doing this proactively through IETF,  in as much a Standards based fashion as possible,  seems much better to us than waiting several years and then reacting with custom solutions,  as has occurred in the past.     I believe this is why Enterprises are making an attempt to work with IETF.      I hope the IETF wants this as well.

I have several responses to your suggestions below.   But rather than take up more list time and attempt to describe in writing some of the issues, I believe there would be with a couple of your suggestions,    I think it might be swifter and clearer to have you speak live (and draw pictures, etc.   ☺),  with a couple of the EDCO people.    I would gladly be one of these.

Just so you know where I personally come from.   I am a SPLUNK admin,  so I am a big Endpoint advocate.    However,  I know from this experience that Endpoint will NOT get us all that we need.      Hence my interest in this very important topic.

Please let me know what you think.

Thanks again

Mike

From: Ted Lemon [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 12:19 PM
To: Ackermann, Michael <[email-masked]>
Cc: Dobbins, Roland <[email-masked]>; IETF TLS <[email-masked]>; Matthew Green <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:
Your first sentence illustrates the disconnect between the Enterprise perspective and what many at IETF are saying.
That being the unencrypted stream is available to the endpoints.   IT IS NOT.     When you run a packet trace at the endpoint,  you will see encrypted payloads and will need the keys to decrypt.
So you can collect packet trace information at thousands or nodes,  or you can collect packet traces from network taps.   You still need the keys to derive meaningful diagnostic and monitoring information.

I agree that we have illustrated the disconnect here, in some sense.   However, from my perspective, what I see is that there is a problem: you need to be able to look inside the stream.   I think we agree that this is the problem.

There is a further problem: you have a set of tools that solves this problem in a particular way, and for the moment, you are stuck with those tools.   This is where I think the disconnect starts.   I am not disagreeing with you that, for the moment, you are stuck with these tools.m   But, I am disagreeing with you on the conclusion that this situation leads to.

To me, it leads to the conclusion that you need two things.   First, you need a plan for how to survive the situation you're stuck in right now.   Second, you need a plan for how you're going to approach this when next you upgrade your infrastructure.  If I were in your position, my plan for the first part would be to use TLS 1.2.   You already have what you want, and you control the endpoints.   If it ain't broke, why fix it?

What I think is urgent, though, is that you be planning for how you're going to handle this going forward.   There are a number of ways of doing it.   One way would be to keep an appropriately-scaled log of keys.  If you just need to look at active streams, it would be a rolling log, and your snooping device would, when asked to snoop a stream, get the key.   This is an improvement over TLS 1.2, because it increases accountability: you have to ask for a key to decrypt a particular conversation, so it is known that you decrypted that conversation.   Of course, if you are decrypting _every_ conversation, that's not so great.   Of course, key exfiltration is an attack surface, but so is the static key.   Better get that right.

The other thing you can do is to do proper tooling on your servers, so that you can access the raw stream.   This would require different tooling than you have now, but there's no technical barrier to doing it.

Now, it's possible that either of these solutions would be less secure than using a static key.   But I don't hear you arguing that.   You're still back on tactics: how do I do what I need to do with the tools I have.   The answer is, use TLS 1.2 until you upgrade.   Put the time in to shave off all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves off--disable the deprecated algorithms, for example.  It's your site, you control the endpoints, this shouldn't be a problem.   But basically, just keep doing what you are doing for now.

Maybe this is a naive suggestion on my part, but what I haven't been hearing in this discussion is serious consideration of the tactical problem and the strategic problem.   What I've been hearing is "forget about strategy, we want tactics."

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 15 Jul 2017 10:34:01 -0700

On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor <[email-masked]

> statements, please speak up!

I agree with the second statement, but I don't really follow the logic of
the first. On the public internet, it's increasingly common for traffic to
be MITMd in the form of a CDN. Many commenters here have also responded
"Just use proxies". I don't get how that's better.

A proxy sees all of the plaintext, not just selected amounts. All of the
same coercion and compromise risks apply to a proxy too, but since it
undetectably sees everything,  that would seem objectively worse from a
security/privacy risk POV.

Or put another way: if these organizations need to occasionally inspect
plaintext, would I prefer that it's the kind of system where they have to
go pull a key from a store, and decrypt specific ciphertexts on demand
offline, or do I want them recording plaintext *all* of the time inline? It
seems utterly bizarre that we would collectively favor the latter. We end
up recommending the kinds of systems that are an attacker's dream.

Here's what I'd prefer:

 * Don't allow static DH. In fact, forbid it, and recommend that clients
check for changing DH params.
 * For the pcap-folks, define an extension that exports the session key or
PMS, encrypted under another key. Make this part of the post-handshake
transcript.
 * pcap-folks can do what they want, but clients will know and can issue
security warnings if they desire. Forbiding static DH enforces this
mechanism, and we can collectively land in a better place than we are
today.

-- 
Colm

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 18:03:01 +0000

On Jul 15, 2017, at 22:36, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:

That being the unencrypted stream is available to the endpoints

Even where it is eventually available, they don't have the horsepower to capture & forward.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 15 Jul 2017 18:05:15 +0000

So you can collect packet trace information at thousands or nodes

This is precisely what is being posited, which is obviously unworkable.

There's a real lack of understanding of the challenges of scale, here.

Which is rather ironic.

;>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 15 Jul 2017 18:16:10 +0000

YES!
I tried to say in my message that collecting traces on thousands,  or hundreds of thousands of hosts,  is just not practical or possible.   Not to mention the administrative domain barriers to this.

From: Dobbins, Roland [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <[email-masked]>
Cc: Ted Lemon <[email-masked]>; IETF TLS <[email-masked]>; Matthew Green <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 15 Jul 2017 19:12:22 +0000

> On the public internet, it's increasingly common for traffic to be MITMd in the form of a CDN.

A CDN is not a middlebox, it is not a MITM.  It is a site that the origin has hired to act as a "front" to it.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Jul 2017 12:24:14 -0700

On Jul 15, 2017 11:03 AM, "Dobbins, Roland" <[email-masked]> wrote:

On Jul 15, 2017, at 22:36, Ackermann, Michael <[email-masked]> wrote:

Even where it is eventually available, they don't have the horsepower to
capture & forward.

It is always availible. How do you process when it isn't? As for forwarding
that doubles bandwidth: no more.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Jul 2017 12:25:36 -0700

On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <[email-masked]> wrote:

YES!

I tried to say in my message that collecting traces on thousands,  or
hundreds of thousands of hosts,  is just not practical or possible.   Not
to mention the administrative domain barriers to this.

We do it every day at my current employer. Guess we do the impossible.

*From:* Dobbins, Roland [mailto:[email-masked]]
*Sent:* Saturday, July 15, 2017 2:03 PM
*To:* Ackermann, Michael <[email-masked]>
*Cc:* Ted Lemon <[email-masked]>; IETF TLS <[email-masked]>; Matthew Green <
[email-masked]>
*Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01

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.

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 21:33:31 +0200

see inline

Roland

> distinct things together is not helping the debate.
One thing which can be done is identifying the sources and notifying the 
owner of the devices so they can be cleaned.
> endpoints, does it matter?
Yes, DDoS cause damage to dumb networks in between as well.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 15 Jul 2017 19:39:27 +0000

I would be interested in how you initiate the traces at all the  hundreds of thousands of servers and clients and how you control the flow of pcap files back to where they need to be processed?     How are users and apps not impacted?

From: Watson Ladd [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <[email-masked]>
Cc: Matthew Green <[email-masked]>; Dobbins, Roland <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <[email-masked]<mailto:[email-masked]>> wrote:
YES!
I tried to say in my message that collecting traces on thousands,  or hundreds of thousands of hosts,  is just not practical or possible.   Not to mention the administrative domain barriers to this.

From: Dobbins, Roland [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <[email-masked]<mailto:[email-masked]>>
Cc: Ted Lemon <[email-masked]<mailto:[email-masked]>>; IETF TLS <[email-masked]<mailto:[email-masked]>>; Matthew Green <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 21:43:16 +0200

A cache may be hired by a user, origin or even a network operator to act 
as a "front" to the origin. Is it not a middlebox because of this? It is 
a question of definition if a CDN is in the middle or the endpoint :)

Roland

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 21:49:38 +0200

TLS is a two endpoint protocol. It looks like many of the use cases 
describe problems with more than two endpoints but are using TLS because 
it is commonly available. So should TLS be extended to be an n-party 
protocol (or is this always considered wiretapping?) or should be there 
another protocol or something else?

Regards,

Roland

Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh:
>
>
> On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> I agree with the second statement, but I don't really follow the logic 
> of the first. On the public internet, it's increasingly common for 
> traffic to be MITMd in the form of a CDN. Many commenters here have 
> also responded "Just use proxies". I don't get how that's better.
>
> A proxy sees all of the plaintext, not just selected amounts. All of 
> the same coercion and compromise risks apply to a proxy too, but since 
> it undetectably sees everything,  that would seem objectively worse 
> from a security/privacy risk POV.
> Or put another way: if these organizations need to occasionally 
> inspect plaintext, would I prefer that it's the kind of system where 
> they have to go pull a key from a store, and decrypt specific 
> ciphertexts on demand offline, or do I want them recording plaintext 
> *all* of the time inline? It seems utterly bizarre that we would 
> collectively favor the latter. We end up recommending the kinds of 
> systems that are an attacker's dream.
>
> Here's what I'd prefer:
>
>  * Don't allow static DH. In fact, forbid it, and recommend that 
> clients check for changing DH params.
>  * For the pcap-folks, define an extension that exports the session 
> key or PMS, encrypted under another key. Make this part of the 
> post-handshake transcript.
>  * pcap-folks can do what they want, but clients will know and can 
> issue security warnings if they desire. Forbiding static DH enforces 
> this mechanism, and we can collectively land in a better place than we 
> are today.
>
> -- 
> Colm
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 15 Jul 2017 20:23:21 +0000

> A cache may be hired by a user, origin or even a network operator to act as a
> "front" to the origin. Is it not a middlebox because of this? It is a question of
> definition if a CDN is in the middle or the endpoint :)

Yes.  And I am saying that the definition doesn't include a CDN as a middlepoint.

Do user-provided reverse proxies have official TLS certificates with a SAN field claiming to be the origin?

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 22:39:16 +0200

I think reverse proxies are middleboxes regardless if they have official 
origin TLS certificates. From the TLS viewpoint they may be the endpoint 
although from the HTTP viewpoint they are not.

Roland

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Jul 2017 23:47:07 +0300

> although from the HTTP viewpoint they are not.

CDNs go much farther than most reverse proxies, and seem more like
full-fledged origins than intermediates. For example, partially
processing POST requests.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 15 Jul 2017 20:47:48 +0000

> I think reverse proxies are middleboxes regardless if they have official origin
> TLS certificates. From the TLS viewpoint they may be the endpoint although
> from the HTTP viewpoint they are not.

This is wrong.

>From the HTTP viewpoint  -- of the origin! -- they are not middleboxes., not intermediaries.

It is no different from a load balancer sending you to a different data center.

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 23:03:57 +0200

RFC 3234 "Middleboxes: Taxonomy and Issues" says:

1.1. Terminology

    The phrase "middlebox" was coined by Lixia Zhang as a graphic
    description of a recent phenomenon in the Internet.  A middlebox is
    defined as any intermediary device performing functions other than
    the normal, standard functions of an IP router on the datagram path
    between a source host and destination host.

Even a load balancer may considered "middlebox", see section 2.8 of RFC 
3234.

Anyway it just depends on what you call middlebox and doesn't matter 
much regarding draft-green-tls-static-dh-in-tls13-01.

Roland

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 15 Jul 2017 21:14:18 +0000

The terminology in RFC 3234 has evolved; language has a way of doing that.

> much regarding draft-green-tls-static-dh-in-tls13-01.

I believe it does.  Words matter.

---

From: Roland Zink <[email-masked]>
Date: Sat, 15 Jul 2017 23:15:58 +0200

> I believe it does.  Words matter.
So what is the definition of "middlebox"?

Roland

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Jul 2017 15:07:48 -0700

On Jul 15, 2017 12:33 PM, "Roland Zink" <[email-masked]> wrote:

see inline

Roland

Am 15.07.2017 um 03:40 schrieb Watson Ladd:

>> traffic, only a subset of attacks in a subset of situations can actually be

How does an endpoint not know the source?

>> it's important that everyone focused on this topic understands that it is
>> simply not possible to successfully defend against many forms of DDoS
>> attacks nor to detect and classify hostile network traffic in the context
>> of encrypted communications without visibility into the traffic in
>> question, via some mechanism.  The same goes for troubleshooting complex
>> problems.
>>

I'm not talking DDoS. I'm talking attack traffic. You need to talk about
specifics you cannot solve other ways. DDOS isn't specific enough.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 15 Jul 2017 15:55:23 -0700

> has hired to act as a "front" to it.

Don't take it as a criticism; I've built two CDNs, and I think they are an
awesome and important part of the internet. But CDNs certainly are middle
boxes; they sit between the origin and the client. A box, in the middle.

What I'm trying to get it is the inconsistency of logic we are applying. So
far responses on the mailing list have been saying "Don't use pcap, instead
run proxies". For some reason we find proxies less distasteful, even though
they have unbounded capability to destroy forward secrecy, even though they
must be in-line and hence subject to exploit, even though it comes at
massive cost (in my opinion), even though it's much harder to use proxies
to examine plaintext in a forensic and selective way. Not only is this very
unlikely to be an answer that will work for the enterprise network folks,
if they did take our advice, it would actually be /worse/ security than
what they have today. That has to be a bizarre outcome to promote. For
what? moral purity?

With regard to CDNs, that's more illogic: why are we so against a key being
shared to decrypt session keys, but fine with a key being shared to
facilitate total impersonation? I can't make sense of it.

PS: I expect everyone who argues against facilitating PCAP decryption on
the ground of "Forward secrecy is a must have" to make identical demands of
0-RTT, which can do much more damage to FS.

-- 
Colm

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 16 Jul 2017 00:34:30 +0200

On Sat 2017-07-15 07:38:57 +0000, Dobbins, Roland wrote:
> I would strongly attempt to dissuade anyone from using it across the
> public Internet. I agree that it is best-suited for use on networks
> within a single span of administrative control, & that's the use for
> which it is intended.

How strongly would you attempt to dissuade its use across the public
Internet?

Strongly enough to support a proposal that would require this to be
opt-in from both sides, with an explicit and verifiable exfiltration
authority, so that no standard implementation of the proposed mechanism
could be accidentally turned on unilaterally without detection by the
unwitting peer?

Because the current proposal isn't nearly that strong at dissuading its
use on the public Internet.

      --dkg

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Jul 2017 16:07:58 -0700

On Jul 15, 2017 12:39 PM, "Ackermann, Michael" <[email-masked]> wrote:

I would be interested in how you initiate the traces at all the  hundreds
of thousands of servers and clients and how you control the flow of pcap
files back to where they need to be processed?     How are users and apps
not impacted?

Currently I work at Cloudflare, not in ops. It's possible some of what I
say is wrong.

We don't collect all traces if I understand what you mean by trace as a
packet capture. I misread your email. No technology I know of would make
that possible at our scale.

We do log a significant amount of information on requests and our responses
include headers that indicate the path taken through the system.(the cf-ray
you see when some sites fail behind us) We can quickly determine what went
wrong if something did through internal inspection tools starting from
those id's and problematic requests.

This works to identify, isolate, and fix problems in a complex system with
multiple internal services.

This architecture scales to what we estimate as x% of all HTTP requests.
Not x% of what we see, but of all of them. ( the x is sizeable)

The logging is done with open source log collection software. Because
packet capture and later decryption was not an option we created other
tools.

I don't know about internal app troubleshooting. Maybe we are talking at
cross purposes, because I don't see why apps cannot log to local disk/ have
a good idea of situations where pcap is really necessary and you can't log
the keys. If you can log pcaps, you can log to disk somewhere.

*From:* Watson Ladd [mailto:[email-masked]]
*Sent:* Saturday, July 15, 2017 3:26 PM
*To:* Ackermann, Michael <[email-masked]>
*Cc:* Matthew Green <[email-masked]>; Dobbins, Roland <
[email-masked]>; IETF TLS <[email-masked]>
*Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01

YES!

---

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

On 15/07/17 23:55, Colm MacCárthaigh wrote:
> So far responses on the mailing list have been saying "Don't use
> pcap, instead run proxies".
Sorry, but that is incorrect. Some list participants
have said "we need pcap" and others have said that
"no, we do not need to use packet capture." And others,
myself included, consider that there is dearth of
evidence.

The only reason to point that out is that it's one
amongst a pile of statements from the proponents of
drafgreen, that make assumptions that are pretty
clearly counter-factual.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 16 Jul 2017 04:03:56 +0000

Nick Sullivan <[email-masked]> writes:

>the Elliptic Curve variant has recently been identified as troublesome as
>well (see recent JWE vulnerability
>and CVE-2017-8932).

Which sorta begs the question, why was it put in the standard (or at least an
addendum to the standard) in the first place?  Misusing DH as if it was RSA
was a dumb idea [0] when it was made a part of S/MIME twenty years ago - the
entire S/MIME implementer community ignored the X9.42 MUST and kept on using
the RSA MAY as if it was the MUST, and PGP used it as Elgamal even if they
labelled it DH.  Given that JWE quite sensibly specifies RSA-OAEP, why was
ECDH-ES also given as an option, and why would anyone then actually use it
rather than just ignoring it like X9.42?

Peter.

[0] I was going to say "bad idea" but it was so obviously wrong to pretty much
    everyone involved that I've upgraded the epithet.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 15 Jul 2017 21:41:01 -0700

> myself included, consider that there is dearth of

Can you be more clear what is lacking in evidence? Are you skeptical that
existing network operators don't do this kind of decryption? There's
support for it in tools like Wireshark. Is that sufficient evidence?

Are you skeptical that there's no evidence that using proxies instead would
be a burdensome change? I'm not skeptical of that at all, but would be
interested in what acceptable evidence would look like. Though I'll point
out again: TLS 1.3 is the new thing that we want to gain adoption, so
really we should be looking for evidence that it's /not/ a burdensome
change.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 16 Jul 2017 08:48:10 +0300

> drafgreen, that make assumptions that are pretty

The architetures I have seen proposed, and some quick characteristics
of each (each has its good sides, bad sides and security impacts, minor
or major):

No visibility at all:

- Rely on IoC for malware (can be highly effective in low-background
  networks, high-background networks are a lost cause anyway).
- Debug network by TCP correlation (can be highly effective if issue is
  within networking).
- Application looging for debugging endpoint problems.
- No visibility infrastructure to exploit.

Packet captures with OoB key logging:

- Can have visibility at both sides.
- Can be high data amounts, but pcaps are much larger. Trigger jointly
  to reduce storage.
- Can asymmetrically encrypt the key data (and possibly also transport-
  encrypt for additional layer of security).
- Can give additional very-low-background channel w.r.t. malware.

Packet captures with in-band key logging:

- Can have visibility at both sides.
- Needs opt-in from both sides for server-side logging (client-only
  for client-side logging).
- Asymmetrically encrypts the key data.
- Can't easily use transport-encryption for additional protection.
- Automatically triggers jointly with packet captures.

Proxies:

- Can archive full visibility.
- Potentially heavy processing for lots of connections.
- Central point of attack in well-visible place.
- Required anyway in certain kinds of networks.

DH secret sharing (draft-green type):

- Visibilty on server side only.
- Needs proxies for external connections to avoid static or shared DHs
  from leaking.
- Pull leaves visible central point of attack visible.
- Push has self-vulernabilities.

And then there is major difference between _architecture_ (specify the
parts, requirements on them and analyze the results, without specifying
anything concretely implementable), _framework_ (specify places to
plug parts, but do not specify enough to make it interoperable) and
_protocol_ (specify something that is implementable and interoperable).
The difference between last two is especially large.

If draft-green had been about architecture and did the analysis well
(and had appropriate status for such draft, informational), it would
be much much less controversial than the current one, which is a
_protocol_ and labeled standards-track at that.

My opinion is that if the WG wants to work on "TLS 1.3 visibility", it
should be about various architectures, part requirements thereof and
analysis of results thereof. Good analysis of impacts is a goal
(something desriable to archive), interoperability is an anti-goal
(something _undesirable_ to archive). The WG sure as heck should not
work on interoprerable attack protocol (like one proposed in
draft-green). Of course, such "visibility architectures" document
would be quite a bit of work, especially considering that it would
actually requires analysis, which is much harder than just specifying
something interoperable.

However, I don't care too much if "visibility" architecture work is
done here or not. I do very much care that attack protocol work is
_NOT_ done here, nor anywhere else within IETF (can't do much about
various industry SDOs filled with industry hacks, I am sure there is
plenty of those to go around).

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 16 Jul 2017 05:55:11 +0000

I am not offended.  I am saying that if it terminates the connection it is an endpoint not a middlebox.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 16 Jul 2017 08:02:50 +0200

> is an endpoint not a middlebox.

Well, maybe.  That's certainly the general understanding of middleboxes
(i.e that they they are not directly addressed [well, NATs, but] and
that they don't terminate traffic) but even way back when we did the
original midcom work and produced 3234 (hard to believe it's been 15
years) there was some mushiness around transparency being a requirement
for being considered a middlebox.  For example, from 3234:

   Note that HTTP proxies do in fact terminate an IP packet flow and
   recreate another one, but they fall under the definition of
   "middlebox" given in Section 1.1 because the actual applications
   sessions traverse them.

However, that's not really a description of the behavior of CDNs -
HTTP sessions really do terminate on cache nodes.

That said, I'm not sure how this helps sort out the question of what
(if anything) needs to be done to satisfy monitoring requirements in
some deployments.

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Jul 2017 08:59:56 +0100

Hiya,

On 16/07/17 05:41, Colm MacCárthaigh wrote:
> On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell 
>> Sorry, but that is incorrect. Some list participants have said "we 
>> need pcap" and others have said that "no, we do not need to use 
>> packet capture." And others, myself included, consider that there 
>> is dearth of evidence.
>> 
> 
> Can you be more clear what is lacking in evidence?

Sure, sorry for the late-night terseness:-)

In this debate, there is a fairly complete lack of evidence
being offered as to:

- the (in)effectiveness of proxies or key-leaking vs. one
  another and vs. not doing either
- the precise scenarios in which pcap+key-leaking is the only
  possible (*) answer, and how commonly those scenarios occur

(*) I am not asking that people tell me that "pcap+key-leaking"
might work, but for them to describe when that works but nothing
else works. And that has to include the details of what it is
they can only find in the recovered cleartext that cannot be
detected without access to cleartext using this particular
method.

> Are you skeptical that existing network operators don't do this kind
> of decryption?

I believe that people do this kind of key-leak+pcap decryption.

People do all sorts of other unwise things too (myself included,
and fairly frequently;-), that is not a reason to encourage more
of "it" for any "it."

> There's support for it in tools like Wireshark. Is that sufficient 
> evidence?

Yes and no. That is sufficient in that yes it says that people
can use this tool. It is nowhere near sufficient evidence that the
IETF should standardise (an API for) such a tool. The existence
of a wireshrark dissector for a protocol is also fairly weak
evidence as to the importance of such a dissector - it seems to
be fairly common for folks to write those for lots of other
reasons, e.g. during protocol development, as student projects
that require no thought from the prof etc:-)

> Are you skeptical that there's no evidence that using proxies
> instead would be a burdensome change?

No. All changes are burdensome, and it's clear that that one
would be. (My own belief is that adding proxies solely to help
with possible network debugging would be dim anyway - I'd
argue there ought to be a functional reason for each proxy
added.)

I would also note that the "use a proxy" argument seems to me
to mostly be offered as a strawman counter-argument by folks
who would like to break TLS via static DH, and doesn't seem to
be a common argument offered by those against breaking TLS.
(Adding proxies is of course another way to break TLS, depending
on how and where it's done.)

> I'm not skeptical of that at all, but would be interested in what
> acceptable evidence would look like.

I'm not sure of the phrase "acceptable evidence" but regardless
of that:

TLS is an important protocol, extremely widely used. For any attempt
to weaken or break TLS, I think the onus is on the proponents of the
break-TLS proposal to produce convincing evidence that their scheme
will at least be a net positive, considering the entire ecosystem
that is dependent on TLS. And even if there is evidence that a scheme
would be a net positive, it may still be a bad idea, if the negative
aspects of the scheme have serious enough impacts in some use-cases
for TLS.

That's a pretty high bar, yes. And so it should be. I'm not at all
clear it can be cleared, ever.

> Though I'll point out again: TLS 1.3 is the new thing that we want
> to gain adoption, so really we should be looking for evidence that
> it's /not/ a burdensome change.

Sure, that is another fine thing to do. It'd be helped along if we
had evidence about the precise scenarios in which the pcap+key-leak
wiretapping is the only possible usable approach. That hasn't been
described on the list. (It has been asserted that such scenarios
exist, and it has been claimed that we should all know and accept
all this already, but those were TBBA non-arguments.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Jul 2017 09:20:39 +0100

Hiya,

> another protocol or something else?

Yes, if one wants different semantics than TLS and needs an
entirely different interface for applications, (which all N>2
party protocols do need) then one needs to define a different
protocol that is not TLS.

Of course, that's impractical, so people will continue to
ignore the fact that they're doing bad engineering and will
come along now and then and try convince us to break TLS.

Cheers,
S.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 16 Jul 2017 01:37:30 -0700

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell <[email-masked]
> detected without access to cleartext using this particular

Of course other techniques could work, every system involved from the
network devices to the endpoints is practically Turing complete. For me,
the more interesting question is really whether the providers/users are
likely to take on the costs of doing it differently, or wether they are
more likely to block TLS1.3 and stay on legacy crypto. Given everything
I've read, I think the latter is more likely.

> and fairly frequently;-), that is not a reason to encourage more

Well, they have the keys, and they have the desire, so I expect them to do
it by some means. The question then becomes not about promoting or
encouraging it, but how we may limit the damage and achieve the best
outcome. I don't understand how proxies are a better solution, as I've
outlined; they have drastically worse security properties.

> on how and where it's done.)

I can't make sense of this paragraph. A static-DH solution has no need for
proxies, so I'm unclear on why a static-DH proponent would suggest using
them. If proxies aren't the alternative, then what is? are you suggesting
none? That's the brinksmanship approach, which is valid of course, you can
risk TLS1.3 adoption. And the pcap operators may flinch first, or you may.
But is it really wise to ask your opponent for the evidence that they won't
flinch first?

> clear it can be cleared, ever.

Real world: They have the keys, so they can break FS by using proxies if
they want. If they do that, and they likely would, everyone is much /worse/
off because now there's less FS, more plaintext floating around, and more
exploitable software floating around. Is that really a sensible outcome?

> all this already, but those were TBBA non-arguments.)

Imagine you're blindfolded, with your finger on a button that fires a gun.
The gun might be pointed at you, it might be pointed at your opponent. Your
opponent has no blindfold. Your argument is "Tell me if the gun is pointed
at me or I'm going to push the button". Now if the gun is pointed at them,
can you really trust them? And if it's pointed at you, why should they care
to help you out?

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 16 Jul 2017 08:52:36 +0000

I would also like to understand why TLS 1.2 is not sufficient for, say, the next five years.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 16 Jul 2017 02:04:32 -0700

> I would also like to understand why TLS 1.2 is not sufficient for, say,

It probably is ... but isn't that the problem? If the answer is "Just let
them stay on TLS1.2", I find it very hard to interpret the arguments
against all of this as resulting in anything other than grand-standing.
Clearly the users would be no better off, and also end up denied the other
benefits of TLS1.3.

This seems self-defeating, when there is so easy a path that may improve
things for all cases (forbid static-DH, add an opt-in mechanism instead).

-- 
Colm

---

From: Ted Lemon <[email-masked]>
Date: Sun, 16 Jul 2017 11:08:23 +0200

What it means for users to be denied the benefits of TLS 1.3 is that they
don't get, for example, perfect forward secrecy.  Since the proposal was to
do away with that anyway, but for all users, not just some users, that
doesn't seem like it is better than just continuing to use TLS 1.2.  It's
already possible to configure both TLS 1.2 clients and servers to not use
obsolete encryption algorithms.  Most of the other improvements in TLS 1.3
probably don't apply to the use cases you are talking about.

So no, it's not self-defeating to say "continue using TLS 1.2 for now in
your use case while we study this issue and try to figure out if there's a
way forward that doesn't break TLS 1.3."

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 16 Jul 2017 09:14:53 +0000

Within an enterprise that believes they need this kind of packet-capture-decode thing, what are the other benefits of TLS 1.3?  They can already use good ciphers. They save the cost of not uplifting existing infrastructure. They lose 0RTT early-data, which when viewed globally seems like a reasonable trade-off.

I am much more cynical about the value of opt-in.  I mean, what are you expecting users to agree to?  And globally, what infinitesimal portion of the Web population can make an informed choice?  And often there is no choice – one of the advocates here is from a statewide insurance company.

So what is compelling about TLS 1.3 after you take away forward secrecy?  I really want to hear an answer to that question from folks who say they need TLS 1.3 but without it.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 16 Jul 2017 02:16:23 -0700

On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon <[email-masked]> wrote:

> doesn't seem like it is better than just continuing to use TLS 1.2.
>

DH by default is just one benefit of TLS1.3, there are many others or else
we wouldn't be shipping it with so many changes and improvements. Otherwise
there would be no TLS1.3, and only a deprecation of the non-PFS cipher
suites. But that plainly isn't the case.

The main one I'm concerned about is me having to support non-TLS1.3 clients
;-) 1RTT key exchange is worth it alone.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 16 Jul 2017 09:19:04 +0000

> The main one I'm concerned about is me having to support non-TLS1.3 clients ;-) 1RTT key exchange is worth it alone.

The key point here is Within the enterprise.

The amount of work one development team has to do, compared to the world, doesn't matter.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 16 Jul 2017 05:43:56 -0400

On Sun, Jul 16, 2017 at 5:14 AM, Salz, Rich <[email-masked]> wrote:
> Within an enterprise that believes they need this kind of
> packet-capture-decode thing, what are the other benefits of TLS 1.3?  They
> can already use good ciphers. They save the cost of not uplifting existing
> infrastructure. They lose 0RTT early-data, which when viewed globally seems
> like a reasonable trade-off.

 My guess is that industries interested in the DH key proposal would
want 0-RTT.  I think they would want to prevent replay attacks and
might even see configuration errors of this as a risk (allowing 0-RTT
inadvertently).

>
>
> I am much more cynical about the value of opt-in.  I mean, what are you
> expecting users to agree to?  And globally, what infinitesimal portion of
> the Web population can make an informed choice?  And often there is no
> choice – one of the advocates here is from a statewide insurance company.
>
>
>
> So what is compelling about TLS 1.3 after you take away forward secrecy?  I
> really want to hear an answer to that question from folks who say they need
> TLS 1.3 but without it.
>
>

-- 

Best regards,
Kathleen

---

From: Wartan Hachaturow <[email-masked]>
Date: Sun, 16 Jul 2017 12:44:04 +0300

> I asked for examples of regulations that specifically require plaintext

Some countries has got that kind of requirements in the lawful
interception context, in the sense that monitoring is explicitly
required to be fully passive. However, this mostly means "network
equipment that supports some kind of encryption on the link should
be able to pass the traffic in plaintext for monitoring purposes".

-- 
Regards, Wartan.

---

From: Roland Zink <[email-masked]>
Date: Sun, 16 Jul 2017 12:10:26 +0200

Am 16.07.2017 um 00:07 schrieb Watson Ladd:
>
>
> On Jul 15, 2017 12:33 PM, "Roland Zink" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     see inline
>
>     Roland
>
>
>         On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 It might make sense to kick it over to ops for a
>                 discussion with people whose meat and potatoes is
>                 monitoring, management, and
>                 measurement.
>
>
>             There have been several assertions posted to the list
>             recently regarding various aspects of security and their
>             intersection with encryption.  It may be useful to take a
>             moment and clarify a few of them.
>
>             With regards to DDoS mitigation as it relates to encrypted
>             attack traffic, only a subset of attacks in a subset of
>             situations can actually be adequately mitigated without
>             full visibility into (and often the ability to interact
>             with) the traffic within the cryptostream.  There are
>             various ways to approach this issue, including full
>             session termination and 'transparent'
>             detection/classification, the latter of which isn't of
>             course feasible in a PFS scenario.  Each of these general
>     One thing which can be done is identifying the sources and
>     notifying the owner of the devices so they can be cleaned.
>
>

An endpoint has information about the source IP address. It may not have 
an IP adress before NAT, email adress, postal adress or information 
about building / desk number. A middle box having more exact information 
about the source may notify the source owners which often are victims 
themselves.

>
>
>             In many scenarios, one form or another of network-based
>             visibility into encrypted traffic streams within the span
>             of administrative control of a single organization is
>             legitimate, vital and necessary.  It is not 'wiretapping',
>             any more than tools such as tcpdump or telemetry formats
>             such as IPFIX and PSAMP can be categorized as
>             'wiretapping'.  The fact is, the availability,
>             confidentiality, and integrity of systems, applications,
>             and networks that everyone on this list relies upon is
>             highly dependent upon the ability of organizations to have
>             visibility into encrypted traffic streams within their own
>             networks, for purposes of security as well as testing and
>             troubleshooting.
>
>
>             How this can be accomplished is a matter for further
>             discussion.  But it's important that everyone focused on
>             this topic understands that it is simply not possible to
>             successfully defend against many forms of DDoS attacks nor
>             to detect and classify hostile network traffic in the
>             context of encrypted communications without visibility
>             into the traffic in question, via some mechanism.  The
>             same goes for troubleshooting complex problems.
>
> I'm not talking DDoS. I'm talking attack traffic. You need to talk 
> about specifics you cannot solve other ways. DDOS isn't specific enough.
I was not talking about how it could be detected or prevented only that 
it matters before it is hitting the endpoint and if there is a way to 
avoid it then it should be avoided.

>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 16 Jul 2017 10:37:59 +0000

It seems that us Enterprise folks have not been clear.  
Every Enterprise I know has invested HEAVILY in infrastructures that tap, transport and process terabytes of packet trace or .pcap data every day.      
This is huge and omnipresent in all large Enterprise environments.  
AND IT WORKS!   For a number of critical functions.  

The above is why Enterprises are interested in this issue and this Draft.  

I hope this is clear? 

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Saturday, July 15, 2017 8:39 PM
To: Colm MacCárthaigh <[email-masked]>; Salz, Rich <[email-masked]>
Cc: [email-masked]; Matthew Green <[email-masked]>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 15/07/17 23:55, Colm MacCárthaigh wrote:
> So far responses on the mailing list have been saying "Don't use pcap, 
> instead run proxies".
Sorry, but that is incorrect. Some list participants have said "we need pcap" and others have said that "no, we do not need to use packet capture." And others, myself included, consider that there is dearth of evidence.

The only reason to point that out is that it's one amongst a pile of statements from the proponents of drafgreen, that make assumptions that are pretty clearly counter-factual.

S.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 16 Jul 2017 10:38:27 +0000

Thanks for the clarification Watson.
I am always looking to learn new tricks and was hoping you might had one for distributed, large scale, remote packet captures.    This is one area we have yet to fully conquer.

What you describe is something different,  but also valuable and useful.
But the best thing you illustrate,  IMHO,  is that none of these techniques or tools is a panacea.     We need many arrows in our quivers to do an effective job of managing todays networks.

Thanks again

Mike

From: Watson Ladd [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 7:08 PM
To: Ackermann, Michael <[email-masked]>
Cc: Matthew Green <[email-masked]>; Dobbins, Roland <[email-masked]>; IETF TLS <[email-masked]>
Subject: RE: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017 12:39 PM, "Ackermann, Michael" <[email-masked]<mailto:[email-masked]>> wrote:
I would be interested in how you initiate the traces at all the  hundreds of thousands of servers and clients and how you control the flow of pcap files back to where they need to be processed?     How are users and apps not impacted?
Currently I work at Cloudflare, not in ops. It's possible some of what I say is wrong.

We don't collect all traces if I understand what you mean by trace as a packet capture. I misread your email. No technology I know of would make that possible at our scale.

We do log a significant amount of information on requests and our responses include headers that indicate the path taken through the system.(the cf-ray you see when some sites fail behind us) We can quickly determine what went wrong if something did through internal inspection tools starting from those id's and problematic requests.

This works to identify, isolate, and fix problems in a complex system with multiple internal services.

This architecture scales to what we estimate as x% of all HTTP requests. Not x% of what we see, but of all of them. ( the x is sizeable)

The logging is done with open source log collection software. Because packet capture and later decryption was not an option we created other tools.

I don't know about internal app troubleshooting. Maybe we are talking at cross purposes, because I don't see why apps cannot log to local disk/ have a good idea of situations where pcap is really necessary and you can't log the keys. If you can log pcaps, you can log to disk somewhere.

From: Watson Ladd [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <[email-masked]<mailto:[email-masked]>>
Cc: Matthew Green <[email-masked]<mailto:[email-masked]>>; Dobbins, Roland <[email-masked]<mailto:[email-masked]>>; IETF TLS <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Jul 2017 14:51:16 +0200

From a HTTP standpoint, they are the origin (i.e., endpoint). They just happen to use HTTP "behind" them.

> On 15 Jul 2017, at 10:39 pm, Roland Zink <[email-masked]> wrote:
> 
> I think reverse proxies are middleboxes regardless if they have official origin TLS certificates. From the TLS viewpoint they may be the endpoint although from the HTTP viewpoint they are not.
> 
> 
> Roland
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 17 Jul 2017 01:23:11 +0200

On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote:
> required to be fully passive.

Could you point me (and the list) to those requirements, please?  More
specificity than "some countries" would be a useful contribution to this
discussion.

> However, this mostly means "network equipment that supports some kind
> of encryption on the link should be able to pass the traffic in
> plaintext for monitoring purposes".

Is this quote taken from a specific regulatory context?  or do the
quotation marks indicate paraphrasing or something else?

Regards,

      --dkg

---

From: Melinda Shore <[email-masked]>
Date: Mon, 17 Jul 2017 06:47:17 +0200

> specificity than "some countries" would be a useful contribution to this

At the time when I was working on VoIP there were a few countries,
such as South Africa, which required that any media streams collected
as a result of a wiretap order be handed over in the clear.  But this
was 20 years ago and things may or may not have changed.  That said,
I expect their requirements can be met by having operators in those
countries stick with TLS 1.2.

There are things that would surprise me more right now than having
proponents of weakening TLS 1.3 come back with a list of countries.
Such as, for example, having representatives from service providers
in those countries show up with requirements - that would surprise me,
given that they haven't yet and that getting TLS 1.3 done has been a
lengthy effort.

At this point the request to add the static D-H proposal to TLS 1.3
strikes me as unreasonable, even given what are frankly vague
references to countries requiring that data be decrypted before being
handed off to law enforcement or the government.

Melinda

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 12:42:17 +0200

On 15 Jul 2017, at 3:40, Watson Ladd wrote:

> DDoS mitigation can be done at endpoints

Not at scale.  That's why it isn't done that way.

I'm all in favor of things like mod_security.  But they can't do the 
heavy lifting on boxes which are already burdened by handling legitimate 
traffic.

> If you want to detect unauthorized access to a resource, having the 
> resource which
determines access anyway log that is enough.

This is incorrect.

> Exfiltration detection based on looking for sensitive identifiers 
> doesn't work:

Yes, it does.  I know, because I've done it.

> real attackers will encrypt the data and dribble it out slowly or 
> pretend to be videoconferencing.

Believe me, real attackers do all kinds of things - and the most common 
exfiltration mechanism is to try and get lost in the http/s crowd.

> everything" not a major, major increase in attackability?

Because these are intranet-only systems on isolated management networks 
with strong access controls.

> Which DDoS attacks specifically?

Among others, application-layer DDoS attacks within the cryptostream.

> And if the traffic isn't hitting endpoints, does it matter?

Of course it matters.

I've not personally had the pleasure of doing this, but I
know it is possible because it is done every day.

> a file.

Logs are context-free and in no wise have the same value as being able 
to see the interactive traffic on the network in real-time.

> The capacity being asked for already exists.

Yes - and now folks are talking about arbitrarily taking this capability 
away without understanding its criticality to network operations, 
troubleshooting, and security.

The fact that we're even having this discussion at this point in time is 
because of an astounding lack of due diligence on the part of those who 
are pushing to remove the capability to monitor standards-based 
encrypted traffic on intranets.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 12:49:40 +0200

> receive only, and then use the same protection mechanism offered by

Yes!  Back in the old days, when hubs were a thing, I used those for 
this purpose, with the appropriate connections diked out.

I still carry around a small GigE switch with SPAN capabilities, just in 
case.

;>

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 12:55:55 +0200

> How does an endpoint not know the source?

You do not seem to have a good grasp of Internet operations at scale and 
necessary division of functions.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 13:04:50 +0200

On 16 Jul 2017, at 11:14, Salz, Rich wrote:

> I really want to hear an answer to that question from folks who say 
> they need TLS 1.3 but without it.

Being able to continue to utilize vetted, well-understood, 
standards-based cryptography on intranets once regulatory bodies such as 
PCI/DSS mandate TLS 1.3 or above - which will happen, at some point in 
the not-too-distant future.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 13:05:57 +0200

> could be accidentally turned on unilaterally without detection by the

Quite possibly, yes - the devil will be in the details, but the concept 
is perfectly valid, IMHO.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Jul 2017 11:48:28 +0000

> Not at scale.  That's why it isn't done that way.

Sometimes it is.

Can we stop making definitive declarations like this?

There are more things in the world, Horatio, then are dreamt of in your philosophy.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Jul 2017 11:50:10 +0000

> Being able to continue to utilize vetted, well-understood, standards-based
> cryptography on intranets once regulatory bodies such as PCI/DSS mandate
> TLS 1.3 or above - which will happen, at some point in the not-too-distant
> future.

Which brings me to my second question (or first, depending on how you read email).  Will this be needed within five years?  Within three?

---

From: Tom Ritter <[email-masked]>
Date: Mon, 17 Jul 2017 07:21:39 -0500

On Jul 17, 2017 6:06 AM, "Roland Dobbins" <[email-masked]> wrote:

> could be accidentally turned on unilaterally without detection by the

Quite possibly, yes - the devil will be in the details, but the concept is
perfectly valid, IMHO.

I've read or skimmed much of these threads. I support an opt-in mechanism
like the one I think dkg is imagining.

It should be visible on the outside on the connection, so middle boxes that
don't break TLS can see that TLS is being broken. (Is that irony? After
Alanis I'm never sure anymore...)

I don't know enough minutia to have a well considered opinion about what
track such a doc should be, but not-Standards seems good.

-tom

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 17 Jul 2017 12:21:51 +0000

On Jul 17, 2017, at 13:48, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

Sometimes it is.

Not at scale, in the vast majority of cases - as I'm sure you're aware, hence the 'sometimes'. Corner-cases are just that.

About factual matters, no, 'we' can't.  I'm tired of seeing established objective facts about how & why intranet network open need visibility into  cryptostreams on their own networks being treated as theoretical & subjective.

Likewise.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 17 Jul 2017 12:24:07 +0000

On Jul 17, 2017, at 13:50, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

That's a very good question.

Unfortunately, we don't know, yet. But we do know it will happen at some point as a matter of course.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Jul 2017 12:32:17 +0000

> Unfortunately, we don't know, yet. But we do know it will happen at some point as a matter of course.  

Predicting the future is hard.

Does anyone have a crystal ball that says this MUST be done within, say, three years?  For example, are any vendors committing to do this?

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 17 Jul 2017 12:47:34 +0000

Does anyone have a crystal ball that says this MUST be done within, say, three years?

We can look at the PCI DSS timeline for previous revs - there's no guarantee it would be the same, of course. And there are other relevant regulators, as well.

Perhaps someeone from a regulated industry who's on this list can give us some insight?

For example, are any vendors committing to do this?

Vendors will do it if their customers/prospects  require it.  But many vendors insist on either Standards-track or WG-Informational (*not* Independent Stream) before they will commit.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 17 Jul 2017 12:57:01 +0000

On Jul 17, 2017, at 14:21, Tom Ritter <[email-masked]<mailto:[email-masked]>> wrote:

It should be visible on the outside on the connection, so middle boxes that don't break TLS can see that TLS is being broken.

With the caveat that the details of how it's actually implemented are key (pardon the pun), I think the feasibility of something along these lines should be considered.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 17 Jul 2017 14:04:34 +0000

A higher-level view on this issue.

TLS has been designed as a protocol that allows two entities to communicate securely over a network controlled by an adversary, including abusive authorities.

“But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS provides so we can catch criminals – and here is how we propose to break TLS-1.3”. 

Considering that unless at least one of the end-points chooses to comply with the “rules” it will not work – the claim that this measure is to help the good guys does not sound very candid.

Who is the intended target of this mechanism? What kind of criminals is it supposed to catch/detect? Surely not the malware that penetrated your infrastructure and tries to “call home”?

History shows that criminals violate laws, regulations, and even network protocols (:-) – that’s why they called criminals. Criminals also proved capable of creating quite sophisticated malware. The proponents of the “broken TLS” somehow expect that those criminals would use weakened crypto for the convenience of the network police. How much sense does this make? Experience shows that criminals use not just cutting edge – bleeding edge crypto. For example, consider Confiker. Plus, there are many ways to foil this proposed mechanism – for example, super-encrypting the data before transmission.

Then there’s an issue of the abuses. First, not all of the “legitimate” authorities are “good guys” (all the time :). Second, I’m not aware of any “network security” tool that hasn’t been subverted at some point in time. 

The likely result of the “static-dh-…” proposal is improved mass surveillance by authorities, and exploits of this mechanism by the organized crime.
 
To those who need that surveillance: stay with TLS-1.2. An important goal of TLS-1.3 is preventing the possibility of this surveillance.

To everybody: you can’t have your cake and eat it too. 
Either you have PFS and the bad guys will benefit from it too (so you need to detect and fight them using other methods), or only the bad guys have PFS and you might [0] detect them because their “protection quality” stands out amidst the ocean of the automatically-inspected & censored traffic.

[0] “Might” rather than “would”. Because there are well-known ways of hiding the presence of encryption, at the cost of increase of the ciphertext size. The hope that the encrypted traffic would stand out is unfounded. Considering how fast the attack sophistication is evolving, the likelihood that “they” would employ other countermeasures, but ignore this one is fairly low.
--
Regards,
Uri

---

From: Yoav Nir <[email-masked]>
Date: Mon, 17 Jul 2017 16:15:12 +0200

> On 17 Jul 2017, at 13:48, Salz, Rich <[email-masked]> wrote:
> 

Obligatory XKCD link:

https://xkcd.com/1737/ <https://xkcd.com/1737/>

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 16:20:22 +0200

> Obligatory XKCD link:

This one is actually more relevant, IMHO:

<https://xkcd.com/538/>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 17 Jul 2017 16:25:57 +0200

> On 17 Jul 2017, at 16:20, Roland Dobbins <[email-masked]> wrote:
> 

ISTM that this is a great argument *against* allowing the administrators in the data center to be able to access the plaintext.

Yoav

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 17:04:02 +0200

On 17 Jul 2017, at 16:04, Blumenthal, Uri - 0553 - MITLL wrote:

> “But we (the (network) authorities) are the good guys, and we need 
> to break the guarantees TLS provides so we can catch criminals – and 
> here is how we propose to break TLS-1.3”.

The actual concern of intranet operators is the inadvertent breakage of 
an important mechanism used for troubleshooting and security in the 
context of TLS-encrypted traffic on their own networks, within their own 
span of administrative control.

> Considering that unless at least one of the end-points chooses to 
> comply with the “rules” it will not work – the claim that this 
> measure is to help the good guys does not sound very candid.

To clarify, this technique is for use on intranets, within a single span 
of administrative control.

> Who is the intended target of this mechanism? What kind of criminals 
> is it supposed to catch/detect? Surely not the malware that penetrated 
> your infrastructure and tries to “call home”?

Actually, it's been used for this very purpose, quite successfully, for 
many years.  It's also used to detect and classify lateral movement and 
propagation of malware and attacks within an intranet.

And it's used to detect and prevent malware downloads by intranet user 
populations.

> The proponents of the “broken TLS” somehow expect that  those 
> criminals would use weakened crypto for the convenience of the ntwork 
> police. How much sense does this make?

In most cases, the attackers don't use any additional crypto at all.  
When they do, it's most often poor crypto.

> Experience shows that criminals use not just cutting edge – bleeding 
> edge crypto.

You're absolutely correct that a few do - as you note, Conficker is a 
good example of that.

> Plus, there are many ways to foil this proposed mechanism – for 
> example, super-encrypting the data before transmission.

Sure.  But the ability to infer the presence of superencryption is 
extremely valuable in and of itself.

> Then there’s an issue of the abuses. First, not all of the 
> “legitimate” authorities are “good guys” (all the time :). 
> Second, I’m not aware of any “network security” tool that 
> hasn’t been subverted at some point in time.

Again, to clarify, this mechanism for use on intranets within a single 
span of administrative control.  Like you, I would work to dissuade 
anyone from using it across the public Internet.

> The likely result of the “static-dh-…” proposal is improved mass 
> surveillance by authorities, and exploits of this mechanism by the 
> organized crime.

Let's remember that this technique is in use on intranets around the 
world, and that's the focus, here.

> To those who need that surveillance: stay with TLS-1.2.

Unfortunately, this isn't possible due to regulatory oversight and plain 
old bit-rot.

> Either you have PFS and the bad guys will benefit from it too (so you 
> need to detect and fight them using other methods), or only the bad 
> guys have PFS and you might [0] detect them because their 
> “protection quality” stands out amidst the ocean of the 
> automatically-inspected & censored traffic.

The ability to infer superencryption is quite important, per the above.

> Because there are well-known ways of hiding the presence of 
> encryption, at the cost of increase of the ciphertext size.

We should also keep in mind that are also ways to counter-detect these 
obfuscation techniques, too.

> The hope that the encrypted traffic would stand out is unfounded.

Actually, it does stand out, in many cases.

> Considering how fast the attack sophistication is evolving, the 
> likelihood that “they” would employ other countermeasures, but 
> ignore this one is fairly low.

This technique certainly isn't a universal panacea, as you rightly point 
out.  But it's an extremely valuable and important technique that's been 
in broad use for quite some time, so maintaining a mechanism for 
intranet operators to analyze TLS-encrypted traffic within their own 
spans of administrative control is important and worthwhile, IMHO.

We don't want to inadvertently drive them into using proprietary, 
non-auditable crypto.  That would be bad for everyone.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 17:04:53 +0200

> might even see configuration errors of this as a risk (allowing 0-RTT

Concur 100%.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 17:06:46 +0200

+1

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Jul 2017 15:08:26 +0000

> > might even see configuration errors of this as a risk (allowing 0-RTT

We should not design this based on guesses.

I think an Enterprise doesn't need 0RTT and early-data within its LAN.

Let's not guess.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 17 Jul 2017 17:18:17 +0200

> On 17 Jul 2017, at 17:06, Roland Dobbins <[email-masked]> wrote:
> 

It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for outside, and yet it’s all over the inside.

In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. Either it’s in SChannel or it’s not. Either F5 have it or they don’t.

If it’s not, it will be impossible to deploy in the enterprise network. They’re not all going to implement it themselves. And if it is, then it’s on the open Internet, and then at least some people will have it turned on. The border between the enterprise and the non-enterprise is pretty blurry.

Yoav

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 17:35:02 +0200

On 17 Jul 2017, at 16:25, Yoav Nir wrote:

> ISTM that this is a great argument *against* allowing the 
> administrators in the data center to be able to access the plaintext.

The joke is that obviating crypto by going around is something bad guys 
can and will do, sorry for being unclear!

Intranet administrators must have visibility into the traffic traversing 
their intranets in order to be able to maintain, troubleshoot, and 
secure those intranets.  This often includes TLS-encrypted traffic, too.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 17 Jul 2017 11:35:08 -0500

> If it’s not, it will be impossible to deploy in the enterprise network. They’re not all going to implement it themselves. And if it is, then it’s on the open Internet, and then at least some people…

Right, and that's the core motivation for a lot of the fierce resistance
this draft is experiencing.

Fundamentally, we are here talking about things at the Internet
Engineering Task Force.  We have an Internet threat model, partially
manifested in things like RFC 7624 but largely just latent institutional
knowledge, that includes a hostile network.  We know that Internet
protocols get used in Intranets as well, but that is not the main use
case for our work, and only a small portion of the scenarios that we
must consider when designing Internet protocols.  On at least many
Enterprise Intranets, the threat model is different from the one we
generally use for designing Internet protocols, so there is an impedance
mismatch between what features are desired or seen as problematic on the
Intranet and the Internet.

Because the risks/disadvantages of the current proposal, when applied to
the Internet as a whole, are so large, there is a lot of pushback, and a
desire to provide strong assurances that any proposal in this space does
not leak from the Intranet onto the Internet, both at a protocol level
and a implementation level.  If there was a scheme that
cryptographically required input from both TLS client and server in
order to enable the needed "key exfiltration" (or equivalent) for the
Intranet use case, that seems like it would resolve most of the concerns
being raised.  Unfortunately, it seems really hard to come up with
something like that, when there are so many options that are unilateral
for the server.

This is not just a question of "we promise we'll only use it on the
Intranet" because of the reasons Yoav states above -- even though I
assume that everyone participating in this thread is acting in good
faith, once the capability is in popular software packages, it could
easily be enabled accidentally on the Internet, or coercively required
of certain entities, e.g., by national security letter, once enablement
is just a configuration setting (as opposed to writing code).

So, in order to have something that is verifiably opt-in by both
parties, it seems like it would have to be a ClientHello/ServerHello
extension (included in the transcript for the generated traffic keys)
where both sides commit that they are willing to exfiltrate keys to a
given named entity(ies) (whether that's by raw public key, certificate
name, etc., is quite flexible).  Because of the key schedule (the
traffic keys are produced after that point in the handshake), it seems
like such a scheme would require encrypting DH private values to the
third party (and potentially a PSK as well).

I'm curious whether a non-handwavy writeup of such a scheme would get a
better reception than draft-green-tls-static-dh-in-tls13 is getting.  It
does lose forward secrecy for the traffic in question, but such traffic
is clearly marked, and rotating the third-party key sufficiently often
could regain some forward secrecy properties.  (Of course I'm also
interested in hearing if that is not feasible for the Enterprise case
since I don't understand those requirements very well.)  But it seems
that we're not really getting anywhere just arguing about the current
proposal (and repeating ourselves a lot), and proposing concrete
alternatives (that do not require rearchitecting the enterprise
networks) might be a way to make progress.

(It's still unclear whether such a scheme would be acceptable as a WG
item or Standards-Track, of course.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 17 Jul 2017 11:39:19 -0500

> third party (and potentially a PSK as well).

Whoops, a little too hand-wavy, since only one DH private value is
needed to generate the shared secret.  But it's "easy" to have some
crypto that requires both contributions, especially if you are willing
to modify the key schedule for the traffic keys.

-Ben

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 18:45:11 +0200

On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote:

> it could easily be enabled accidentally on the Internet, or coercively 
> required
> is just a configuration setting (as opposed to writing code)

Yes, concur.

> name, etc., is quite flexible).

I agree that the extension approach is something which is worthy of 
exploration.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 17 Jul 2017 17:37:20 +0000

On 7/17/2017, 12:45, "TLS on behalf of Roland Dobbins" <[email-masked] on behalf of [email-masked]> wrote:

    
    Yes, concur.

Great. Then we all are in agreement.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 17 Jul 2017 17:44:50 +0000

On Jul 17, 2017, at 17:08, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

Let's not guess.

Agreed.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 17 Jul 2017 18:30:09 +0000

On 7/17/2017, 11:04, "Roland Dobbins" <[email-masked]> wrote:

Something similar was brought up several decades ago, when some agencies expressed concerns that wide-spread availability of encryption would make national security and law enforcement jobs impossible. Thankfully, those fears proved unfounded then. They are likely to prove so now.

“Intranet” is an administrative term, and has no technical meaning. As such, it has no bearing on the protocols.

Not to mention the obvious lack of enforcement mechanisms – how are you going to enforce on the protocol level that “this technique” never crosses the administrative domain?

You can’t seriously expect this method of surveillance to stay available forever, as the criminals get smarter and their tool chest gets enriched by exploits from higher-level organizations? 

In any case, there are better mechanisms and tools to address this risk.    

There are better tools for that.

You must be lucky then. Criminals that we’re concerned with, aren’t that dumb.

My point is that we should look at the trend – not just the status quo. And the trend shows the attackers become smarter.

If the adversary allows you to infer it. It’s next to impossible with the large-scale traffic, when the adversary is crafty enough.

Again, technically there is no such thing as “intranet”. It’s an *administrative* domain, and there is no distinction protocol-wise.

The only “dissuade” I’d consider is when it’s enforced on the protocol level (on the wire), and there are unambiguous ways to detect it (and explicitly opt in, or opt out).

Let’s not forget that from the protocols point of view there is no “intranet”. There’s only “Internet” – a network of interconnected networks. Administrators can draw boundaries around hosts and routers they think they control – but it has no impact on the protocols themselves. 

First, this ability depends on your adversary letting you have it – it is not given. Second, I find it concerning that you seem to be OK with the second option of the choice I outlined.

    
For an individual connection – very likely so. For all the connections your subjects have within the company, and/or with the outside world? Not hardly. 

In fewer and fewer cases. As adversaries learn, they encode that learning into the tools that then become available to the lower-skills-level attackers. 

    out.  

:-)

    But it's an extremely valuable and important technique that's been 
    in broad use for quite some time, so maintaining a mechanism for 
    intranet operators to analyze TLS-encrypted traffic within their own 
    spans of administrative control is important and worthwhile, IMHO.

We disagree here. 

Not to mention that a country might consider the entire traffic within its borders as “intranet”. Some already do (and some don’t even stop there). I’d rather that these operators mature and realize that as the time goes, some new capabilities arrive, and some old capabilities wither and die. 

Publish that crypto, and it’s not proprietary any more. Subject it to an audit – and it’s now audited/auditable.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 17 Jul 2017 12:11:13 -0700

On Jul 17, 2017 3:42 AM, "Roland Dobbins" <[email-masked]> wrote:

I'm all in favor of things like mod_security.  But they can't do the heavy
lifting on boxes which are already burdened by handling legitimate traffic.

This is incorrect.

How do you detect unauthorized access separate from knowing what
authorization is?

Exfiltration detection based on looking for sensitive identifiers doesn't
> work:

real attackers will encrypt the data and dribble it out slowly or pretend
> to be videoconferencing.

Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?

As for attack surface why is "Press here to get plaintex of everything" not
> a major, major increase in attackability?
>

And the endpoints taking logs won't be?

Applications can rate-limited their own endpoints. You're telling me a
dedicated out of stream box can handle this but a beefy server cannot?

Of course it matters.

Finally, most software can export the secrets from TLS connections to a
> file.

Logs are context-free and in no wise have the same value as being able to
see the interactive traffic on the network in real-time.

No one is taking away the ability to log the PMS to a file. That's the
capacity which exists now.

The fact that we're even having this discussion at this point in time is
because of an astounding lack of due diligence on the part of those who are
pushing to remove the capability to monitor standards-based encrypted
traffic on intranets.

Alternatively it's because you've decided to run your networks in ways very
different from the public internet and used this as a way to avoid
organizational battles over giving operations the tools they need to work.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 17 Jul 2017 21:29:03 +0200

> How do you detect unauthorized access separate from knowing what

I think we're talking at cross purposes, here.  Can you clarify?

> Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?

Many don't.  And being able to see rot(x) in the cryptostream has value.

> And the endpoints taking logs won't be?

Logs are no substitute for seeing the packets on the wire.

> Applications can rate-limited their own endpoints.

There's a lot more to DDoS defense than rate-limiting.  Rate-limiting 
often leads to gross overblocking.

> You're telling me a dedicated out of stream box can handle this but a 
> beefy server cannot?

Sadly, in all too many cases, yes.

> capacity which exists now.

But the capacity in question here is to see the packets on the wire.

> organizational battles over giving operations the tools they need to 

I think that some perceptions of how these things are done even on the 
public Internet may be a bit circumscribed.

The tools that network engineers and security personnel need analyze 
network traffic.  Logs are insufficient.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Jul 2017 07:48:43 -0700

On Jul 17, 2017 12:29 PM, "Roland Dobbins" <[email-masked]> wrote:

You said you need to look at packets to see unauthorized access. How do you
that access is unauthorized unless the authorization system is doing the
monitoring?

As the IRA pointed out to the Prime Minister, she needed to get lucky every
time.

Then log the raw plaintext stream.

There's a lot more to DDoS defense than rate-limiting.  Rate-limiting often
leads to gross overblocking.

You're telling me a dedicated out of stream box can handle this but a beefy
> server cannot?

... something is wrong here.

Wireshark can use that file to decrypt packets on the wire. Today. What is
the problem with that?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 09:20:08 -0700

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd <[email-masked]> wrote:
> You said you need to look at packets to see unauthorized access. How do
> you that access is unauthorized unless the authorization system is doing
> the monitoring?
>

Over the years I've met with businesses who have these kinds of set ups.
The way it usually works is that the analysis is secondary and based on a
suspicion of some kind. For example: if an employee is suspected of insider
trading, or stealing proprietary data, then the administrators may take the
extreme measure of inspecting all of their traffic. This is why many
corporate environments have those "No expectation of privacy" disclaimers.

Another example is where traffic to a set of suspicious destinations is
subject to a higher level of scrutiny. For example, maybe traffic bound for
well known file sharing services.

I've never seen an environment with pervasive always-on monitoring;
creating a trove of plaintext would be a net security negative, and
organizations rarely have the resources it would take to keep or analyze
all of it anyway.

> As the IRA pointed out to the Prime Minister, she needed to get lucky
> every time.
>

Where I come from, if you're quoting the IRA to support an argument, nobody
takes you seriously.

> network traffic.  Logs are insufficient.

They are, though it's a big change. I think we can do better than logs; a
mechanism that's in TLS itself could be opt-in and user-aware, and so less
likely to be abused in other situations. There's also some basic security
model advantages to encrypting the PMS under a public-private key pair, and
one that isn't using the private key that the servers themselves hold.

-- 
Colm

---

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

You said you need to look at packets to see unauthorized access. How do you that access is unauthorized unless the authorization system is doing the monitoring?

Over the years I've met with businesses who have these kinds of set ups. The way it usually works is that the analysis is secondary and based on a suspicion of some kind. For example: if an employee is suspected of insider trading, or stealing proprietary data, then the administrators may take the extreme measure of inspecting all of their traffic. This is why many corporate environments have those "No expectation of privacy" disclaimers.

Another example is where traffic to a set of suspicious destinations is subject to a higher level of scrutiny. For example, maybe traffic bound for well known file sharing services. 

This all is fairly obvious. The question is when do you start recording (and therefore examining) the traffic.

I've never seen an environment with pervasive always-on monitoring; creating a trove of plaintext would be a net security negative, and organizations rarely have the resources it would take to keep or analyze all of it anyway.  

Same question. At some point in time you need to decide to start examining all the traffic. At that point you can start capturing its plaintext. The proposed alternative seems to be capturing the ciphertext and the key so the ciphertext can be decrypted later – which makes no sense to me.

They are, though it's a big change. I think we can do better than logs; a mechanism that's in TLS itself could be opt-in and user-aware, and so less likely to be abused in other situations. There's also some basic security model advantages to encrypting the PMS under a public-private key pair, and one that isn't using the private key that the servers themselves hold. 

To use the key you need to have the corresponding ciphertext stored. It is worse time- and space-wise than storing the plaintext (encrypted under the authorities’ key). You seem to have proved that capturing the plaintext from the originating (or receiving – whatever end you own) end-point and encrypting/storing it is much better option than sending ciphertext and leaking its keys (or reusing static keys for the same purpose).

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 19 Jul 2017 09:35:34 -0700

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:
>
> Same question. At some point in time you need to decide to start examining
> all the traffic. At that point you can start capturing its plaintext. The
> proposed alternative seems to be capturing the ciphertext and the key so
> the ciphertext can be decrypted later – which makes no sense to me.
>

That's not what I've seen. Instead, I see administrators creating port
mirrors on demand and then filtering the traffic they are interested in
using standard tcpdump rules, and I see MITM boxes that selectively decrypt
some traffic to look inside it and apply some kind of security filtering.
In the former case, DNS lookups and IP/port destinations are commonly used
to trigger some suspicions too.

> To use the key you need to have the corresponding ciphertext stored.
>

That's not how the tcpdump/wireshark approach usually works. You give it
the private key and decrypts the TLS connection as it's happening.

-- 
Colm

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 16:52:34 +0000

> On Jul 19, 2017, at 18:35, Colm MacCárthaigh <[email-masked]> wrote:
> 
> That's not what I've seen. Instead, I see administrators creating port mirrors on demand and then filtering the traffic they are interested in using standard tcpdump rules, and I see MITM boxes that selectively decrypt some traffic to look inside it and apply some kind of security filtering. In the former case, DNS lookups and IP/port destinations are commonly used to trigger some suspicions too. 

Correct.

> That's not how the tcpdump/wireshark approach usually works. You give it the private key and decrypts the TLS connection as it's happening.

Correct. 

Ex-post-facto is insufficient to purpose.  Real-time is the focus.  Archiving is rarely done, and is typically just snippets representative of the incident in question.

---

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

>> That's not what I've seen. Instead, I see administrators creating port mirrors on demand and then
>> filtering the traffic they are interested in using standard tcpdump rules, and I see MITM boxes
>> that selectively decrypt some traffic to look inside it and apply some kind of security filtering.
>> In the former case, DNS lookups and IP/port destinations are commonly used to trigger some suspicions too. 
>  Correct.

Yes I realize all that. That is the “traditional” way.

My point is that if you own/control the endpoint, then it doesn’t matter from the architecture point of view where you tap – and if TLS is not broken (i.e., does not allow you to “selectively decrypt”) you can tap the plaintext at the endpoint. You just need a different set of tools. But considering how today’s endpoints are loaded with tons and tons of “security software”, it seems rather straightforward. 

It’s not like you have an opaque endpoint, and the switch is the only place your visibility starts.
    
>> That's not how the tcpdump/wireshark approach usually works. You give it the private key and
>> decrypts the TLS connection as it's happening.
>
>  Correct. 
> Ex-post-facto is insufficient to purpose.  Real-time is the focus.  Archiving is rarely done,
> and is typically just snippets representative of the incident in question. 

Yes. The contention is between being able to decrypt already-encrypted traffic on-demand, and being able to tap the traffic before the encryption (or after the decryption) on-demand.

Your current tools to the first. Evolvement of the technology is pushing you towards the second. Arguing against it IMHO would have as much effect as arguing against exporting strong crypto had decades ago. Or are you simply trying to delay the inevitable?

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 17:43:41 +0000

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> My point is that if you own/control the endpoint, then it doesn’t matter from the architecture point of view

It absolutely matters from an operational perspective, which both informs and is informed by the architecture. 

And even though your overarching organization owns the endpoint, the 'you' who is responsible for troubleshooting and/or security analysis often does not.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Jul 2017 10:47:59 -0700

> My point is that if you own/control the endpoint, then it doesn’t matter
from the architecture point of view

It absolutely matters from an operational perspective, which both informs
and is informed by the architecture.

And even though your overarching organization owns the endpoint, the 'you'
who is responsible for troubleshooting and/or security analysis often does
not.

Technical solutions to political problems are not the right approach.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 17:54:34 +0000

On Jul 19, 2017, at 19:48, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:

Conversely, technical solutions which do not take into account operational reality don't benefit those who need them the most.

Sadly, we don't have the luxury of starting from a clean slate.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 18:01:36 +0000

> Or are you simply trying to delay the inevitable?

I'm open to any solution which meets the stated requirements & is deployable & usable on real-world production networks, without necessitating a total redesign of said networks & the complete social reorganization of the entities in question. 

;>

There's some very constructive discussion taking place now about the relative merits of various approaches, & I'm following it quite keenly.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 19 Jul 2017 18:06:09 +0000

> Or are you simply trying to delay the inevitable?
    
    I'm open to any solution which meets the stated requirements & is deployable & usable on real-world
    production networks, without necessitating a total redesign of said networks & the complete social
    reorganization of the entities in question. 
    
    ;>

It’s not the networks that need to be “totally redesigned”, but the mechanism to do surveillance. And only for some kinds of traffic (that uses TLS 1.3).
And we are not talking about “complete” “social reorganization” of the entities (if you mean endpoints) – most of them already carry all that’s necessary (and more) to perform surveillance from inside the endpoint.

So am I. ;>

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 18:14:47 +0000

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> most of them already carry all that’s necessary (and more) to perform surveillance from inside the endpoint.

Unfortunately, this is not the case.  Quite the opposite, actually. 

It's already been explained why endpoint-based measures are impractical.  If they were practical, they'd already be in widespread use, and this wouldn't be an issue in the first place.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 19 Jul 2017 18:18:23 +0000

> It’s not the networks that need to be “totally redesigned”, but the mechanism to do surveillance.

You underestimate the cascade effect of such measures.  It's neither operationally nor economically viable.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Jul 2017 11:29:35 -0700

On Jul 19, 2017 10:54 AM, "Dobbins, Roland" <[email-masked]> wrote:

On Jul 19, 2017, at 19:48, Watson Ladd <[email-masked]> wrote:

Conversely, technical solutions which do not take into account operational
reality don't benefit those who need them the most.

You started with a long list of requirements which had to be met by
interception. Now it turns out that the requirements on solutions came from
organizational issues you never told us about.

I still don't see a response to how you determine unauthorized access
happened without being the authority on what access is authorized.
Apparently exporting the PMS from clients and servers  isn't possible: I
find that hard to believe.

Let's standardize an extension that exports an encrypted EMS and be done
with this debate.

---

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

It's already been explained why endpoint-based measures are impractical. 
    If they were practical, they'd already be in widespread use, and this wouldn't be an issue in the first place. 

When there is a pool of data waiting for the operator to (figuratively speaking) push a button on a switch and start intercepting the traffic in plaintext – there’s no need to go through the extra inconvenience of using endpoints for that. No surprise.

I keep telling that this pool is drying up. It’s “go to endpoint for the plaintext” or “sorry, no plaintext at all” (or “stay with the old stuff – using old-rotten methods goes hand-in-hand with the bit-rot of the older protocols”).

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 19 Jul 2017 20:38:14 +0200

On 19 Jul 2017, at 20:29, Watson Ladd wrote:

> Now it turns out that the requirements on solutions came from

The organizational issues have been described previously, both on the 
list and in the meetings; and the technical issues are quite separate 
from the organizational ones.  The one isn't the cause of the other.

In many cases, the organizational issues do not exist, yet the technical 
ones remain.

There is a serious technical issue here; the only reason the 
organizational issues were even mentioned was to provide context.

> happened without being the authority on what access is authorized.

It's possible to have the relevant access policy information to hand 
without being the authority oneself.

> Apparently exporting the PMS from clients and servers  isn't possible: 
> I find that hard to believe.

It isn't practical from a performance nor a network architecture 
perspective.

> Let's standardize an extension that exports an encrypted EMS and be 
> done with this debate.

That does not meet the technical requirements.

There's some quite useful and constructive discussion of possible 
approaches taking place - I'm observing it with interest.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 19 Jul 2017 20:40:51 +0200

On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote:

> I keep telling that this pool is drying up.

The organizations who need this the most are already working in 
all-crypto environments.  Nothing about that pool is going to change.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 21:26:14 +0200

So is it an accurate assessment that the reason you aren't using ipsec fur
this use case is that the APIs suck and your engines don't support them?

On Jul 19, 2017 8:41 PM, "Roland Dobbins" <[email-masked]> wrote:

> The organizations who need this the most are already working in all-crypto
> environments.  Nothing about that pool is going to change.
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Jul 2017 12:29:46 -0700

On Jul 19, 2017 11:38 AM, "Roland Dobbins" <[email-masked]> wrote:

> organizational issues you never told us about.

The organizational issues have been described previously, both on the list
and in the meetings; and the technical issues are quite separate from the
organizational ones.  The one isn't the cause of the other.

What are the technical requirements?

There is a serious technical issue here; the only reason the organizational
issues were even mentioned was to provide context.

Why can't the enforcing mechanism log its enforcement?

We're talking one extra encryption+transmission. How is this not possible?

Why not? It enables interception if both ends opt in with the encrypted
packets. (I see I made a typo: I meant PMS) what does the green draft do
this does not?

---

From: Simon Friedberger <[email-masked]>
Date: Thu, 20 Jul 2017 17:38:24 +0200

I would like to point out that a lot of this discussion seems to hinge
on the following argument:

On 17/07/17 13:04, Roland Dobbins wrote:
> standards-based cryptography on intranets once regulatory bodies such
> as PCI/DSS mandate TLS 1.3 or above - which will happen, at some point
> in the not-too-distant future.

So the only reason not to use TLS 1.2 for these use cases is that it is
assumed that some regulator will in the future prohibit not using it.

(I don't think TLS 1.2 is going away any time soon so it will continue
to be vetted, well-understood and standards-based.)

I think it is up to those regulators to do their job properly and not
require TLS 1.3 for situations when it does not fullfil the requirements.
Or conversely if regulators still require TLS 1.3 although it does not
support the desired traffic inspection maybe they have made that
decision with good reason.

---

From: Carl Mehner <[email-masked]>
Date: Thu, 20 Jul 2017 14:21:12 -0500

> decision with good reason.

I think using TLS 1.2 and waiting will only work up to a point. When
the regulators do require TLS 1.3 (and that may be years and years
away), enterprises still need somewhere to go in order to use things
like IDS and IPS, to look into where application issues are happening,
and all the other reasons that are laid out for needing this draft.

What's unclear is: Are these organizations willing to take their
current networking and application designs and begin to slowly rework
it to support a TLS 1.3-only (real-ephemeral-keys-only) style
architecture by the time it is required?
I can say from my enterprise perspective, enterprises have been
working toward that goal since it was announced that RSA key exchange
was going away several years ago. We're working with software vendors
to get the logs that we need from endpoints, making sure that IDS/IPS
vendors that currently break open streams of TLS cipher text using RSA
keys are able to switch over to doing TLS termination (with good
configurations), or use load balancers that can terminate TLS and loop
it up into an IDS/IPS/WAF before sending the plaintext stream off into
a new encrypted direction.

It's not an overnight change, but it is a practical one, and one that
could end up making these complicated applications that "need"
static-key-style decryption work more effectively and efficiently.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 20 Jul 2017 21:51:15 +0200

> static-key-style decryption work more effectively and efficiently.

The problems of capex, opex, scale, additional complexity, and 
potentially broadening the attack surface via additional inline 
termination are also considerations - these tradeoffs may work for some 
organizations, but don't for many.

Whether or not one can obtain sufficient application/service 
instrumentation is also highly situationally-specific.

---

From: Simon Friedberger <[email-masked]>
Date: Fri, 21 Jul 2017 01:14:50 +0200

> and all the other reasons that are laid out for needing this draft.
I agree up to the last point. As you say later there are alternatives
and of course vendors of IDS solutions are not going to implement any of
the potentially more complicated solutions if they don't have to. But it
is entirely possible.
> architecture by the time it is required?
For business reasons they essentially must they that they wont but
should TLS 1.3 be accepted as-is they will either do it or be replaced
by more competitive businesses.
> static-key-style decryption work more effectively and efficiently.
Yes!