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 somewhere to go in orde

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 c

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 to hear an answer to t

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 the list and in the m

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 telling that this pool

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 Dobbin

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 separate

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 pract

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 ___ TLS mailing list TLS@iet

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

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 explained why endpoi

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 ent

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 redesign of said

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

On Jul 19, 2017, at 19:48, Watson Ladd mailto:watsonbl...@gmail.com>> wrote: Technical solutions to political problems are not the right approach. --- Roland Dobbins mailto:rdobb...@arbor.net>> ___ TLS mailing list TLS

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 from an operational perspective, which b

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 by the architectu

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

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

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 decrypt some > traf

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 ciphe

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 secondary

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 think we're talking at cross purposes, here

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 at packets to see un

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 to

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 boxes which are alrea

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 span of administrativ

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

On Jul 17, 2017, at 17:08, Salz, Rich mailto:rs...@akamai.com>> wrote: Let's not guess. Agreed. --- Roland Dobbins mailto:rdobb...@arbor.net>> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tl

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 entities, e.g., by national security letter, once > enable

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 to

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 w

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 > outside the enter

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

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 outside, and yet it’s all

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 guesses

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 in

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 in the data center to

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 https://www.ietf.org/mailman/lis

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, Horatio, then are dreamt

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 provi

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

On Jul 17, 2017, at 14:21, Tom Ritter mailto:t...@ritter.vg>> 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 thin

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 someeone

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

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

On Jul 17, 2017, at 13:50, Salz, Rich mailto:rs...@akamai.com>> 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 w

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

On Jul 17, 2017, at 13:48, Salz, Rich mailto:rs...@akamai.com>> wrote: Sometimes it is. Not at scale, in the vast majority of cases - as I'm sure you're aware, hence the 'sometimes'. Corner-cases are just that. Can we stop making definitive declarations like this? About factual matters, no,

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 implementation of the p

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 u

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

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 mandat

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 regulation

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 viewpoint they may

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

: Ackermann, Michael Cc: Matthew Green ; Dobbins, Roland ; IETF TLS Subject: RE: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 12:39 PM, "Ackermann, Michael" mailto:mackerm...@bcbsm.com>> wrote: I would be interested in how you initiate the traces at all the hundre

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

, Rich Cc: tls@ietf.org; Matthew Green Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On 15/07/17 23:55, Colm MacCárthaigh wrote: > So far responses on the mailing list have been saying "Don't use pcap, > instead run proxies". Sorry, but that is incorrect. Some 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 co

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 > infrastructure. They lose 0RTT

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 > doesn't seem like

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 reaso

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 alre

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 interpret the arguments aga

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 only find in the recovered clea

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 conside

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". >> Sorry, but that is incorrect.

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 d

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

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

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 h

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 sorta begs the question, why was i

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 othe

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

t;; IETF TLS *Subject:* 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 men

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 >> a datacenter under a s

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 take it as a criti

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 d

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

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 reverse

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 mid

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 proto

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

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

: Saturday, July 15, 2017 3:26 PM To: Ackermann, Michael Cc: Matthew Green ; Dobbins, Roland ; IETF TLS Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 11:16 AM, "Ackermann, Michael" mailto:mackerm...@bcbsm.com>> wrote: YES! I tried to say in my message

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

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 *Cc:* Ted Lemon ; IETF TLS ; Matthew Green < matthewdgr...@gmail.com> *Subject:* Re: [TLS] draft-green-tls-static-dh-in-t

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 & forward. It is always availible. How d

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

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

To: Ackermann, Michael Cc: Ted Lemon ; IETF TLS ; Matthew Green Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017, at 22:36, Ackermann, Michael mailto:mackerm...@bcbsm.com>> wrote: That being the unencrypted stream is available to the endpoints Even where

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

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

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

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

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 control. > > * Forward secrec

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

: Saturday, July 15, 2017 12:19 PM To: Ackermann, Michael Cc: Dobbins, Roland ; IETF TLS ; Matthew Green Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael mailto:mackerm...@bcbsm.com>> wrote: Your first sentence illustrates the disc

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, independent of any end

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 you run a packet trace at

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 decryption systems. > > > F

  1   2   >