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

[Simon Friedberger]

On 20/07/17 21:21, Carl Mehner wrote:
> On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
>  wrote:
> 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.
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.
> 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?
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.
> 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.
Yes!

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 20 Jul 2017, at 21:21, Carl Mehner wrote:

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.


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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carl Mehner]

On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
 wrote:
> 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:
>> 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.
>
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Simon Friedberger]

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:
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 19, 2017 11:38 AM, "Roland Dobbins"  wrote:

On 19 Jul 2017, at 20:29, Watson Ladd wrote:

Now it turns out that the requirements on solutions came from
> 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.

In many cases, the organizational issues do not exist, yet the technical
ones remain.


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.


I still don't see a response to how you determine unauthorized access
> 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.


Why can't the enforcing mechanism log its enforcement?



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.


We're talking one extra encryption+transmission. How is this not possible?



Let's standardize an extension that exports an encrypted EMS and be done
> with this debate.
>

That does not meet the technical requirements.


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?


There's some quite useful and constructive discussion of possible
approaches taking place - I'm observing it with interest.

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

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"  wrote:

> 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.
>
> ---
> Roland Dobbins 
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 19 Jul 2017, at 20:29, Watson Ladd wrote:


Now it turns out that the requirements on solutions came from
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.


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.


I still don't see a response to how you determine unauthorized access 
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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

> 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. 

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”).


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 19, 2017 10:54 AM, "Dobbins, Roland"  wrote:



On Jul 19, 2017, at 19:48, Watson Ladd  wrote:

Technical solutions to political problems are not the right approach.


---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


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.


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.


---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> 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. 

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL  
> 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. 

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

> 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.

There's some very constructive discussion taking place now about the 
relative merits of various approaches, & I'm following it quite keenly. 

So am I. ;>

---
Roland Dobbins 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> 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. 

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

On Jul 19, 2017, at 19:48, Watson Ladd 
> wrote:

Technical solutions to political problems are not the right approach.

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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.

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 19, 2017 10:43 AM, "Dobbins, Roland"  wrote:



> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL 
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.


Technical solutions to political problems are not the right approach.


---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL  
> 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.  

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

> On Jul 19, 2017, at 18:35, Colm MacCárthaigh  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. 

---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> 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.


> 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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).

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd  wrote:
>
> On Jul 17, 2017 12:29 PM, "Roland Dobbins"  wrote:
>
> On 17 Jul 2017, at 21:11, Watson Ladd wrote:
>
> How do you detect unauthorized access separate from knowing what
>> authorization is?
>>
>
> I think we're talking at cross purposes, here.  Can you clarify?
>
>
> 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.

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.
>
>
> 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.


> The tools that network engineers and security personnel need analyze
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 17, 2017 12:29 PM, "Roland Dobbins"  wrote:

On 17 Jul 2017, at 21:11, Watson Ladd wrote:

How do you detect unauthorized access separate from knowing what
> authorization is?
>

I think we're talking at cross purposes, here.  Can you clarify?


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?



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.


As the IRA pointed out to the Prime Minister, she needed to get lucky every
time.




And the endpoints taking logs won't be?
>

Logs are no substitute for seeing the packets on the wire.


Then log the raw plaintext stream.




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.


... something is wrong here.




No one is taking away the ability to log the PMS to a file. That's the
> capacity which exists now.
>

But the capacity in question here is to see the packets on the wire.


Wireshark can use that file to decrypt packets on the wire. Today. What is
the problem with that?



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.
>

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.

---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 17 Jul 2017, at 21:11, Watson Ladd wrote:


How do you detect unauthorized access separate from knowing what
authorization is?


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.



No one is taking away the ability to log the PMS to a file. That's the
capacity which exists now.


But the capacity in question here is to see the packets on the wire.

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.


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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 17, 2017 3:42 AM, "Roland Dobbins"  wrote:

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.


How do you detect unauthorized access separate from knowing what
authorization is?


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.


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?
>

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


And the endpoints taking logs won't be?


Which DDoS attacks specifically?
>

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


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?



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.

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.

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.


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.


---
Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

On 7/17/2017, 11:04, "Roland Dobbins"  wrote:
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.

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.

> 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.

“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?

> 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.

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.

And it's used to detect and prevent malware downloads by intranet user 
populations.

There are better tools for that.

> 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.

You must be lucky then. Criminals that we’re concerned with, aren’t that dumb.

> 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.

My point is that we should look at the trend – not just the status quo. And the 
trend shows the attackers become smarter.

> 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.

If the adversary allows you to infer it. It’s next to impossible with the 
large-scale traffic, when the adversary is crafty enough.

> 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.

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).

> 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.

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. 

> 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.

First, this ability depends on your adversary 

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

[Dobbins, Roland]

On Jul 17, 2017, at 17:08, Salz, Rich 
> wrote:

Let's not guess.

Agreed.

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

On 7/17/2017, 12:45, "TLS on behalf of Roland Dobbins"  wrote:

On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote:


> 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)

Yes, concur.

> 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).

I agree that the extension approach is something which is worthy of 
exploration.

Great. Then we all are in agreement.
 


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote:


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)


Yes, concur.


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).


I agree that the extension approach is something which is worthy of 
exploration.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On 07/17/2017 11:35 AM, Benjamin Kaduk wrote:
>
> 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).

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On 07/17/2017 10:18 AM, Yoav Nir wrote:
>> On 17 Jul 2017, at 17:06, Roland Dobbins  wrote:
>>
>> On 16 Jul 2017, at 11:19, Salz, Rich wrote:
>>
>>> The key point here is Within the enterprise.
>> +1
> 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 17:06, Roland Dobbins  wrote:
> 
> On 16 Jul 2017, at 11:19, Salz, Rich wrote:
> 
>> The key point here is Within the enterprise.
> 
> +1

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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> >  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).
> 
> Concur 100%.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

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

> The key point here is Within the enterprise.

+1

---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 16 Jul 2017, at 11:43, Kathleen Moriarty wrote:

>  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).

Concur 100%.

---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 16:20, Roland Dobbins  wrote:
> 
> On 17 Jul 2017, at 16:15, Yoav Nir wrote:
> 
>> Obligatory XKCD link:
> 
> This one is actually more relevant, IMHO:
> 
> 

ISTM that this is a great argument *against* allowing the administrators in the 
data center to be able to access the plaintext.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 17 Jul 2017, at 16:15, Yoav Nir wrote:

> Obligatory XKCD link:

This one is actually more relevant, IMHO:



---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 13:48, Salz, Rich  wrote:
> 
>>> DDoS mitigation can be done at endpoints
>> 
>> 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.

Obligatory XKCD link:

https://xkcd.com/1737/ 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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 



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

On Jul 17, 2017, at 14:21, Tom Ritter > 
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.

  ---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

Predicting the future is hard.

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.

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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

> 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.  

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?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

On Jul 17, 2017, at 13:50, Salz, Rich 
> wrote:

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

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.

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tom Ritter]

On Jul 17, 2017 6:06 AM, "Roland Dobbins"  wrote:

On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote:

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?
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> > DDoS mitigation can be done at endpoints
> 
> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote:


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?


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


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 16 Jul 2017, at 0:07, Watson Ladd wrote:


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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

On 15 Jul 2017, at 18:18, Kathleen Moriarty wrote:


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.


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.


;>

---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Dobbins]

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.


As for attack surface why is "Press here to get plaintex of 
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.

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.



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.


---
Roland Dobbins 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Melinda Shore]

On 7/17/17 1:23 AM, Daniel Kahn Gillmor wrote:
> Could you point me (and the list) to those requirements, please?  More
> specificity than "some countries" would be a useful contribution to this
> discussion.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Daniel Kahn Gillmor]

On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote:
> On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor 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.
>
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mark Nottingham]

>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  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
> 
> 
> 
> Am 15.07.2017 um 22:23 schrieb Salz, Rich:
>>> 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?
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:watsonbl...@gmail.com]
Sent: Saturday, July 15, 2017 7:08 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: Matthew Green <matthewdgr...@gmail.com>; Dobbins, Roland 
<rdobb...@arbor.net>; IETF TLS <tls@ietf.org>
Subject: RE: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017 12:39 PM, "Ackermann, Michael" 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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:watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>]
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>
Cc: Matthew Green <matthewdgr...@gmail.com<mailto:matthewdgr...@gmail.com>>; 
Dobbins, Roland <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>; IETF TLS 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017 11:16 AM, "Ackermann, Michael" 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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:rdobb...@arbor.net<mailto:rdobb...@arbor.net>]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>
Cc: Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>>; IETF TLS 
<tls@ietf.org<mailto:tls@ietf.org>>; Matthew Green 
<matthewdgr...@gmail.com<mailto:matthewdgr...@gmail.com>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017, at 22:36, Ackermann, Michael 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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.

---
Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>




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
TLS@ietf.o

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

[Wartan Hachaturow]

On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Sun, Jul 16, 2017 at 5:14 AM, Salz, Rich  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.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon  wrote:

> 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

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."

On Sun, Jul 16, 2017 at 11:04 AM, Colm MacCárthaigh 
wrote:

>
>
> On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich  wrote:
>
>> I would also like to understand why TLS 1.2 is not sufficient for, say,
>> the next five years.
>>
>
> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich  wrote:

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

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell  wrote:
>
> (*) 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.
>

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.

> 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."
>

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.

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 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?


> > 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.
>

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?


>
> > 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.)
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 15/07/17 20:49, Roland Zink wrote:
> 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?

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.


> 
> 
> 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
>> > wrote:
>>
>>  * 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!
>>
>>
>> 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
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 16/07/17 05:41, Colm MacCárthaigh wrote:
> On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell 
>  wrote:
> 
>> 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.
>> 
> 
> 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.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Melinda Shore]

On 7/16/17 7:55 AM, Salz, Rich wrote:
> I am not offended.  I am saying that if it terminates the connection it
> 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




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Sun, Jul 16, 2017 at 01:39:17AM +0100, Stephen Farrell wrote:
> 
> 
> 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.


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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Nick Sullivan  writes:

>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).

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 15, 2017 12:39 PM, "Ackermann, Michael" <mackerm...@bcbsm.com> 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:watsonbl...@gmail.com]
*Sent:* Saturday, July 15, 2017 3:26 PM
*To:* Ackermann, Michael <mackerm...@bcbsm.com>
*Cc:* Matthew Green <matthewdgr...@gmail.com>; Dobbins, Roland <
rdobb...@arbor.net>; IETF TLS <tls@ietf.org>
*Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01







On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <mackerm...@bcbsm.com> 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:rdobb...@arbor.net]
*Sent:* Saturday, July 15, 2017 2:03 PM
*To:* Ackermann, Michael <mackerm...@bcbsm.com>
*Cc:* Ted Lemon <mel...@fugue.com>; IETF TLS <tls@ietf.org>; Matthew Green <
matthewdgr...@gmail.com>
*Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01






On Jul 15, 2017, at 22:36, Ackermann, Michael <mackerm...@bcbsm.com> 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.



---
Roland Dobbins <rdobb...@arbor.net>







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
TLS@ietf.org
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Daniel Kahn Gillmor]

On Sat 2017-07-15 07:38:57 +, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor  
>> wrote:
>> 
>> * 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.
>
> 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


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich  wrote:

> > 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Zink]

Am 15.07.2017 um 23:14 schrieb Salz, Rich:

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


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

I believe it does.  Words matter.

So what is the definition of "middlebox"?

Roland

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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

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

I believe it does.  Words matter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Zink]

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



Am 15.07.2017 um 22:47 schrieb Salz, Rich:

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Sat, Jul 15, 2017 at 10:39:16PM +0200, Roland Zink 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.

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


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Zink]

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



Am 15.07.2017 um 22:23 schrieb Salz, Rich:

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?


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Zink]

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 
> wrote:


 * 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!


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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Roland Zink]

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



Am 15.07.2017 um 21:12 schrieb Salz, Rich:

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:watsonbl...@gmail.com]
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: Matthew Green <matthewdgr...@gmail.com>; Dobbins, Roland 
<rdobb...@arbor.net>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017 11:16 AM, "Ackermann, Michael" 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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:rdobb...@arbor.net<mailto:rdobb...@arbor.net>]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>
Cc: Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>>; IETF TLS 
<tls@ietf.org<mailto:tls@ietf.org>>; Matthew Green 
<matthewdgr...@gmail.com<mailto:matthewdgr...@gmail.com>>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017, at 22:36, Ackermann, Michael 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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.

---
Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>




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
TLS@ietf.org<mailto:TLS@ietf.org>
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <mackerm...@bcbsm.com> 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:rdobb...@arbor.net]
*Sent:* Saturday, July 15, 2017 2:03 PM
*To:* Ackermann, Michael <mackerm...@bcbsm.com>
*Cc:* Ted Lemon <mel...@fugue.com>; IETF TLS <tls@ietf.org>; Matthew Green <
matthewdgr...@gmail.com>
*Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01






On Jul 15, 2017, at 22:36, Ackermann, Michael <mackerm...@bcbsm.com> 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.



---
Roland Dobbins <rdobb...@arbor.net>





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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 15, 2017 11:03 AM, "Dobbins, Roland"  wrote:



On Jul 15, 2017, at 22:36, Ackermann, Michael  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.


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


---
Roland Dobbins 



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:rdobb...@arbor.net]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: Ted Lemon <mel...@fugue.com>; IETF TLS <tls@ietf.org>; Matthew Green 
<matthewdgr...@gmail.com>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01



On Jul 15, 2017, at 22:36, Ackermann, Michael 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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.

---
Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>




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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

On Jul 15, 2017, at 22:36, Ackermann, Michael 
> wrote:

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.

;>

---
Roland Dobbins >
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dobbins, Roland]

On Jul 15, 2017, at 22:36, Ackermann, Michael 
> 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.

---
Roland Dobbins >


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor  wrote:

>  * 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!
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:mel...@fugue.com]
Sent: Saturday, July 15, 2017 12:19 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: Dobbins, Roland <rdobb...@arbor.net>; IETF TLS <tls@ietf.org>; Matthew 
Green <matthewdgr...@gmail.com>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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 nai

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

[Kathleen Moriarty]

On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins  wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
>> 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.

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.
>
> I'm sure someone on the list can, however.
>
>
> ---
> Roland Dobbins 
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael 
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."
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins  wrote:
> On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:
>
>> 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.
>
>
> 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.

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.
>
> 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.
>
> ---
> Roland Dobbins 
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:tls-boun...@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Saturday, July 15, 2017 7:19 AM
To: Ilari Liusvaara <ilariliusva...@welho.com>; Dobbins, Roland 
<rdobb...@arbor.net>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote:
> 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.

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


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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Saturday, July 15, 2017 4:06 AM
To: Dobbins, Roland <rdobb...@arbor.net>
Cc: IETF TLS <tls@ietf.org>; Matthew Green <matthewdgr...@gmail.com>
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 
<rdobb...@arbor.net<mailto:rdobb...@arbor.net>> wrote:


> On Jul 15, 2017, at 14:48, Ted Lemon 
> <mel...@fugue.com<mailto:mel...@fugue.com>> 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.

---
Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>>



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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

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

Kyle

On Sat, Jul 15, 2017 at 9:08 AM, Kyle Rose  wrote:

> 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  wrote:
>
>> On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins 
>> wrote:
>>
>>> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>>>
>>> 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.
>>
>>
>> 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
>>
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

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  wrote:

> On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins 
> wrote:
>
>> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>>
>> 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.
>
>
> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins  wrote:

> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
> 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.


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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls