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

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

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

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

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

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

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

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

On Jul 15, 2017 12:39 PM, "Ackermann, Michael" 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

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

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

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

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

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

On Jul 15, 2017 12:33 PM, "Roland Zink" wrote: see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: > On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins > wrote: > >> On 15 Jul 2017, at 1:01, Melinda Shore wrote: >> >> It might make sense to kick

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

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

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

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

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

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,

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

> 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

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

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

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

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

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

> 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

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

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

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

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,

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

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:

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

see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins wrote: On 15 Jul 2017, at 1:01, Melinda Shore wrote: It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is

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

On Jul 15, 2017 11:16 AM, "Ackermann, Michael" 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

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

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

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

> 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

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

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

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

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

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

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.

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

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

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

On 7/15/17 4:01 PM, Sean Turner wrote: > draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday > because that’s the only time Melinda can make. No, I'm afraid that I *cannot* make it Monday, and need to have our slot stay on Wednesday. Melinda signature.asc Description:

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

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

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

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,

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

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

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

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

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

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

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

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

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

> On Jul 15, 2017, at 09:46, Salz, Rich wrote: > > encrypting-SNI and DANE/DNSSEC draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday because that’s the only time Melinda can make. In Yokohama, I said encrypted SNI has occupied about 27 hours of WG time

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

Travel plans were made based on the published agenda, an Matt Green will not be on Prague on Monday. We should not discuss draft-green- without him. Russ > On Jul 15, 2017, at 9:46 AM, Salz, Rich wrote: > > I would *VERY VERY STRONGLY* like to see the static-dh draft be on

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

I would *VERY VERY STRONGLY* like to see the static-dh draft be on Monday, and all the Monday topics moved to the main scheduled slot on Wednesday, even if it means taking 5 minutes of each of encrypting-SNI and DANE/DNSSEC Those are technical topics, far more suited to the main event then the

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

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

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

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

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

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

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

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. As to the

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

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

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

On Sat 2017-07-15 07:42:58 +, Dobbins, Roland wrote: >> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor >> wrote: >> >> Could you point to an example of any regulation that requires plaintext >> from network capture specifically? > > It often isn't feasible to obtain

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

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

I'd like to raise another point. Static Diffie-Hellman is a cryptographically problematic construction. Not only was it found to be fragile to implement in the prime field variant (LogJam), the Elliptic Curve variant has recently been identified as troublesome as well (see recent JWE

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

> On Jul 15, 2017, at 16:30, Ted Lemon wrote: > > Roland, the reason that I made that particular comment was to try to show you > that the position you have taken here is untenable. It is not untenable. It is operational really. > There is no such textbook. As you now,

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

I was at at least one of those presentations recently, and while it certainly convinced me that there was a problem in the short term, it did not convince me that the points you are making are inherent problems with the technology. That is, the problem is not that there is no way to achieve what

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

On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland wrote: > There is plenty of information on these topics available on the Internet > today. Search engines exist. It isn't reasonable to expect a class to be > held on the basics of network security & troubleshooting tools &

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

> On Jul 15, 2017, at 16:05, Dobbins, Roland wrote: > > There is plenty of information on these topics available on the Internet > today. At the risk of self-replying, it should also be noted that highly informative discussions of these challenges, & detailed

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

On Jul 15, 2017, at 15:49, Ted Lemon > wrote: Can you point me to the textbook for that class, because I must have missed it! There is plenty of information on these topics available on the Internet today. Search engines exist. It isn't reasonable

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

On Sat, Jul 15, 2017 at 07:48:25AM +, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor > > wrote: > > > > (b) we know that network capture is widely used adversarially by the > > kinds of attackers that TLS is explicitly intended to

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

On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland wrote: > > I think that your first and third points are actually non-sequiturs: the > unencrypted stream is available to the entities controlling either > endpoint, not just the log. > > This assertion is both incorrect &

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

On Jul 15, 2017, at 15:07, Ted Lemon > wrote: I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log. This assertion is both incorrect &

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

> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor wrote: > > On Sat 2017-07-15 05:58:31 +, Salz, Rich wrote: >> Unless I missed the reply, I did not see any answer to my question as >> to why it must be opt-in. Do we think evildoers will tell the truth >> about what

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,

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

> On Jul 15, 2017, at 14:48, Ted Lemon 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

[TLS] tls - Update to a Meeting Session Request for IETF 99

An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the tls working group. - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Stephanie McCammon

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

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

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

> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote: > > Could you point to an example of any regulation that requires plaintext > from network capture specifically? It often isn't feasible to obtain the plaintext any other way in a given circumstance. Not to

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

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

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

On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote: > In some industries, there are regulatory requirements that cannot be > met without access to the plaintext. This is surely true, but it's not clear to me that any regulator requires access to the plaintext *from direct network capture*.

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

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

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

On Sat, Jul 15, 2017 at 1:58 AM, Salz, Rich wrote: > Unless I missed the reply, I did not see any answer to my question as to why > it must be opt-in. Do we think evildoers will tell the truth about what > they are doing? Opt-in is choice. Choice for a consumer is usually a