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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

On Jul 19, 2017, at 19:48, Watson Ladd > wrote: Technical solutions to political problems are not the right approach. --- Roland Dobbins >

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Jul 17, 2017, at 17:08, Salz, Rich > wrote: Let's not guess. Agreed. --- Roland Dobbins > ___ TLS mailing list TLS@ietf.org

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

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

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

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

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

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

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

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

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

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!

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

> 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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

> 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

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

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

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

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

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

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

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

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,

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

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

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

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,

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

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

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

>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

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

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" &l

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

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

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

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 >

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 m

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

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

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

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

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

rg>; 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 availa

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

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.

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] draft-green-tls-static-dh-in-tls13-01

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

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

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,

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

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

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

  1   2   >