Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Friday afternoon seems like a tolerable time to do something so questionably productive as mailing to this thread... On 10/25/2017 09:50 AM, David A. Cooper wrote: > This question is based on your that belief that this protocol will > "escape" onto the public Internet, that browsers and other

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 24, 2017, at 12:49, Joseph Salowey wrote: > > As is normal IETF practice, we will be giving this topic agenda time in > Singapore to see if a consensus emerges one way or the other. Just in case you’re following this thread and not the other administrivia emails,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25 Oct 2017, at 15:37, Richard Barnes wrote: Sorry, what? The current draft proposes an extension, literally the opposite of a standard, supported feature. I agree with Stephen on this (narrow) point. The draft is on Standards Track, which means is proposes a standard. The fact that it

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ options (quoted below) are wrong or do not work. The objection is that the IETF should not be publishing a RFC that documents them, is that right? Not at all. But maybe I’m mistaken; do you have links to messages that said that? The draft in the subject line is a different item

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 23:58, Peter Bowen wrote: > So, to be completely clear, no one is arguing that Nick's three > options (quoted below) are wrong or do not work. The objection is > that the IETF should not be publishing a RFC that documents them, is > that right? No, it's not that simple. For

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell wrote: > > > On 25/10/17 23:37, Richard Barnes wrote: >> Sorry, what? The current draft proposes an extension, literally the >> opposite of a standard, supported feature. It's explicitly optional. > > Optional is not

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 23:37, Richard Barnes wrote: > Sorry, what? The current draft proposes an extension, literally the > opposite of a standard, supported feature. It's explicitly optional. Optional is not the opposite of standard. See the intended status below. > I don't really have a dog in this

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 25, 2017 22:34, "Stephen Farrell" wrote: Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 17:11, Ackermann, Michael wrote: > And if this is not a feature that everyone wants, then so be it. > But at least it was an attempt by a small number of people to try to > find common ground and make any form of progress. I do not accept that there is an onus on IETF participants

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 25, 2017, at 3:34 PM, Nick Sullivan wrote: > Forward secrecy with respect to other keys, like the session ticket key or > other keys that can be generated centrally, are things that need to be looked > at more closely for TLS 1.4 (or whatever’s next). Unless

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I didn't want to stick my foot in this, but here we are. The goal for an inspection service to be able to take a recording of the network and a key (or corpus of keys) and be able to decrypt any TLS connection to a server within that network. There are multiple ways of getting these keys. 1) use

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink wrote: > It could but RFC 7469 section 2.6 > (https://tools.ietf.org/html/rfc7469#section-2.6) says: > > " It is acceptable to allow Pin >Validation to be disabled for some Hosts according to local policy. >For example, a UA

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

No, they would not prevent those other mechanisms. Where is your evidence that they would? If the "attacker" controls the software that the client is using, then it would set up the software to not check public-key pinning or CT, if necessary. As Richard

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

It could but RFC 7469 section 2.6 (https://tools.ietf.org/html/rfc7469#section-2.6) says: " It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich wrote: > > since those other means would be easier and more effective. You > have done nothing to suggest otherwise. > > Public-key pinning and CT seem like they would prevent those other > mechanisms. No? > Remember that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

f Of David A. Cooper Sent: Wednesday, October 25, 2017 10:50 AM To: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> since those other means would be easier and more effective. You have done nothing to suggest otherwise. Public-key pinning and CT seem like they would prevent those other mechanisms. No? ___ TLS mailing list TLS@ietf.org

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I've already responded to this! Why are you wasting everyone's time by asking the same questions over and over, even though I've already clearly answered them? An airplane/wifi provider might say "download our free browser," but it won't rely on draft-rhrd-tls-tls13-visibility to snoop on its

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

>This question is based on your that belief that this protocol will > "escape" onto the public Internet Yes. Are you saying that you don’t believe that the enterprise visibility will stop at their firewall? That they will allow ‘stock’ TLS 1.3 to work connecting to their sites? That the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ Similarly, the best that TLS can offer in terms of privacy is that the contents of the communication between the two endpoints is not seen by anyone else *unless* at least one of the two endpoints (client or server) chooses to provide the contents of the communication to some

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Everything I have stated is my personal opinion. Note that I never suggested that I like or am espousing a certain approach, I was simply stating a fact. In many cases today, a TLS connect that appears to a client to be terminating a one place (Company X) is actually terminating somewhere

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Before you leave, there are a number of questions still unanswered. 1 Can this draft enable an active attacker to modify traffic? If not, then then how is that prevented? 2 Can this draft be used to segregate traffic so that only those willing to be intercepted can be handled separately from

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

4, 2017 10:01 PM To: Ackermann, Michael <mackerm...@bcbsm.com>; David A. Cooper <david.coo...@nist.gov>; tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Michael, What, in your message below, has not been said a number of times in this thread? (A

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

David, I'll go back over your mails tomorrow but was struck by this... On 24/10/17 23:39, David A. Cooper wrote: > I haven't even gotten into the question of what does it mean for a connection > to > be MiTM'd. If Company X decides to have its web site operated by Hosting > Provider Y is the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

ber 24, 2017 6:39 PM > To: tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 > > On 10/24/2017 05:18 PM, Salz, Rich wrote: > > > * And, I don't buy the idea that if this extension is standardized that > it will be implemented

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> I'm not taking any risk. The ability for a server to allow a third party to > have access to data it is exchanging with a client already exists, and that > ability isn't going away whether this proposal (or something similar) is > standardized or not. As I've already pointed out, for the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

To: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On 10/24/2017 05:18 PM, Salz, Rich wrote: * And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers. And that is a risk you are willing

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/24/2017 05:18 PM, Salz, Rich wrote:   And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers.

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 4:40 PM, David A. Cooper wrote: > Also, in the data center case, there is no middlebox. Others, who know much > more than I do about operational constraints in data center environments, > have already argued that setting up a bunch of middleboxes would

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> Enterprise network operators say that deploying these devices to provide the > same visibility as the visibility extension would, at best, be highly > complicated and expensive, if not altogether impossible. Based on the contacts you’ve had, what’s their cost estimate for modifying the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers. And that is a risk you are willing for the entire public Internet to take? And what about the fact that it provides a cleartext signal as to whether or not a client

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

As difficult as what you describe below would be, using draft-rhrd-tls-tls13-visibility to snoop would be much more complicated. They would need to need to get their "special" browsers onto all of the students' devices, but then, unlike in the scenario below,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/24/2017 04:24 PM, Ted Lemon wrote: On Oct 24, 2017, at 4:21 PM, David A. Cooper wrote: I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 24 Oct 2017, at 22:54, David A. Cooper wrote: > > Why would these schools settle for a half measure that only allows them to > snoop on traffic between their students and servers provide the keys to their > Internet traffic to the schools? If a school wants to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 4:21 PM, David A. Cooper wrote: > I'm not suggesting that cash strapped schools would use one of these devices. > I'm simply saying that such a solution would be simpler and far more > effective than trying to use draft-rhrd-tls-tls13-visibility to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that such a solution would be simpler and far more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic. Those who

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> complicated-to-implement and largely ineffective solution such as subverting draft-rhrd-tls-tls13-visibility for improper purposes? The phrase “subverting for improper purposes” is inaccurate, and perhaps misleading. We would be providing another cleartext signal and we have to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 3:59 PM, Ted Lemon wrote: > On Oct 24, 2017, at 3:54 PM, David A. Cooper > wrote: >> There are already middleboxes on the market today that do this. They work >> for all outgoing connections and don't

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 3:54 PM, David A. Cooper wrote: > There are already middleboxes on the market today that do this. They work for > all outgoing connections and don't require any cooperation whatsoever from > the outside servers that the clients are trying to connect

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 24/10/17 20:31, Ted Lemon wrote: > But it's delaying other work, because people who could be doing > useful work in the IETF are engaging on this topic instead. I'm not sure of the extent to which my work in the IETF is useful or not, but it is certainly the case that these repeated proposals

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph, On 24/10/17 20:36, Yoav Nir wrote: > > >> On 24 Oct 2017, at 22:27, Ralph Droms wrote: >> >> >>> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >>> >>> I use an airplane as an example of a “captive” population, substitute any >>> similar group

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 3:24 PM, Ralph Droms wrote: > ...with the assumption that a client would automatically revert to trying the > connection with the visibility extension if it can't make a connection > without the extension. Why would that assumption be useful? How is

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 24 Oct 2017, at 22:27, Ralph Droms wrote: > > >> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >> >> I use an airplane as an example of a “captive” population, substitute any >> similar group you want. >> >> • Yes, any box that sits

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all? That is, I don't see why this scenario is specific to the visibility extension. Because you can’t do that with TLS right now. This adds that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 12:49 PM, Joseph Salowey wrote: > First, we would like to clarify that this discussion isn't delaying TLS 1.3. > We've been holding final publication to resolve some middlebox issues as > described in a recent message from ekr >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: > > I use an airplane as an example of a “captive” population, substitute any > similar group you want. > > • Yes, any box that sits between the client and the server can drop > traffic for whatever reason it wants.

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 24, 2017, at 3:17 PM, Ted Lemon wrote: > > On Oct 24, 2017, at 3:04 PM, David A. Cooper wrote: >> In order for a middlebox to be able to use this draft to intercept traffic >> that is TLS protected, it would need to: >> >> 1) get the server

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I use an airplane as an example of a “captive” population, substitute any similar group you want. * Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS. True, but

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 24, 2017, at 3:04 PM, David A. Cooper wrote: > In order for a middlebox to be able to use this draft to intercept traffic > that is TLS protected, it would need to: > > 1) get the server to agree to allow it to intercept the traffic; and > > 2) get the client to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

With this extension, any middlebox anywhere can drop traffic that is not tappable.  Regardless of who controls the clients and servers, we are now enabling entities to block traffic unless you acquiesce. For example, an inflight wifi could use this.  Maybe,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Joe, On 24/10/17 17:49, Joseph Salowey wrote: > As is normal > IETF practice, we will be giving this topic agenda time in Singapore to see > if a consensus emerges one way or the other. I would ask that you, as chairs, reconsider that. While I do have strong opinions, the list traffic seems to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Dear TLS WG, The chairs have been following the recent vigorous discussion on draft-rhrd-tls-tls13-visibility and we'd like to say a few words about process and how we intend to move forward. First, we would like to clarify that this discussion isn't delaying TLS 1.3. We've been holding final

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ Our proposals are for spanned/tapped, passive traffic.You seem to be talking about modifying the ➢ actual live data stream. Yes I am. ➢ And MitM is also outside of what we want to do but would seem to be more feasible in that scernario. I think that is a grudging admission

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

...@akamai.com] Sent: Tuesday, October 24, 2017 9:30 AM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 ➢ The objective is to be passively observe, out of band and not to be a MitM or modify/inject text.Just

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/24/17 2:38 AM, Stephen Farrell wrote: > So in addition to asking you as chairs to close down this > discussion, I would also ask that you contact the folks > being disruptive like that and try to educate them as to > how to behave in IETF discussions and also let them know > about the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ The objective is to be passively observe, out of band and not to be a MitM or modify/inject text.Just as we all do today. That might be the objective, but isn’t Ben correct? If a third-party has the session keys, what prevents them from doing that? Good behavior? Or is there

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

g to me. > > -Original Message- From: Benjamin Kaduk > [mailto:bka...@akamai.com] Sent: Monday, October 23, 2017 6:33 PM To: > Ackermann, Michael <mackerm...@bcbsm.com>; Tony Arcieri > <basc...@gmail.com>; Adam Caudill <a...@adamcaudill.com> Cc: > tls@ietf

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

udill <a...@adamcaudill.com> > CC: tls@ietf.org > Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 > > NO > The objective is to be passively observe, out of band and not to be a MitM or > modify/inject text.Just as we all do today. > >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael wrote: > NO > The objective is to be passively observe, out of band and not to be a MitM > or modify/inject text.Just as we all do today. You seem to be confused as to the difference between an active vs passive MitM.

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

<a...@adamcaudill.com> > Cc: tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 > >> On 10/23/2017 05:09 PM, Ackermann, Michael wrote: >> No one I am aware of is pushing for a MitM capability to address this. >> In fact it was

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

com>; Tony Arcieri <basc...@gmail.com>; Adam Caudill <a...@adamcaudill.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On 10/23/2017 05:09 PM, Ackermann, Michael wrote: > No one I am aware of is pushing for a MitM capability to addre

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk wrote: > There are no doubt folks here would claim that the writing has been on the > wall for > five years or more that static RSA was out and forward secrecy was on > the way in, and that now is the right time to draw the line

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 05:09 PM, Ackermann, Michael wrote: > No one I am aware of is pushing for a MitM capability to address > this.   In fact it was one of the alternative solutions for which many > implementation issues were cited at the Prague meeting and on this > list.    But I would like to ask, 

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 01:42 PM, Ackermann, Michael wrote: > But as stated in several previous Emails, the fact that TLS 1.2 is still > available, does not mean that we won't have applications, business units or > other entities that require TLS 1.3 and we will need to manage, monitor and > secure

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <a...@adamcaudill.com<mailto:a...@adamcaudill.com>> wrote: Those advocating for some standardized method of subverting the security properties of TL

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill wrote: > Those advocating for some standardized method of subverting the security > properties of TLS have been offered numerous options in good faith, and > continue to reject them all. I’m aware of extremely large enterprises

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

To be honest, I’m rather surprised that this group continues to spend time on this. I’m of the opinion that the chairs should step in and put this discussion on hold until the work on TLS 1.3 is complete. This, and any document of the same goal, are eating up time and energy that should be

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

- From: Salz, Rich [mailto:rs...@akamai.com] Sent: Friday, October 20, 2017 12:57 PM To: Ackermann, Michael <mackerm...@bcbsm.com>; Stephen Farrell <stephen.farr...@cs.tcd.ie>; Darin Pettis <dpp.e...@gmail.com>; tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-t

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 2:12 PM, Ackermann, Michael wrote: > To suggest that I or my industry does not take security seriously, is > inaccurate and immaterial to this discussion. I'm sure you take security seriously. What I'm saying is that you have tunnel vision about it,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

statements are not at all constructive, germane nor worthy of response. From: Ted Lemon [mailto:mel...@fugue.com] Sent: Monday, October 23, 2017 1:45 PM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: Salz, Rich <rs...@akamai.com>; tls@ietf.org Subject: Re: [TLS] Publication of dr

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 23/10/17 18:30, Ackermann, Michael wrote: > It is a huge proposition requiring change to virtually every platform > and application.Not to mention all the management, monitoring > and security platforms. It would be very expensive and time > consuming. And when they ask why this is

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* It is a huge proposition requiring change to virtually every platform and application.Not to mention all the management, monitoring and security platforms. Do you expect that this draft will require no changes to all your management, monitoring, and security platforms? * And

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 23, 2017, at 12:39 PM, Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: 1. If staying with TLS 1.2 indefinitely was considered acceptable, would we even be

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 12:39 PM, Ackermann, Michael wrote: 2. Modifying Server, application and logging infrastructure is a huge, expensive proposition, that executive management would not be receptive to at all. Not to mention the logistics to follow if they were. I'd just like to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

1. If staying with TLS 1.2 indefinitely was considered acceptable, would we even be having these discussions? DAMMIT. Stop saying indefinitely. What percentage of hosts within your enterprise use TLS 1.2 as the preferred protocol? 1. Modifying Server, application and logging

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael wrote: > If staying with TLS 1.2 indefinitely was considered acceptable, would we > even be having these discussions? This is a vacuous argument. Nobody has provided any evidence of any kind that "enterprise"

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Thursday, 19 October 2017 19:12:11 CEST Blumenthal, Uri - 0553 - MITLL wrote: > If those middleboxes already have sufficient alternative options, why do we > spend time discussing this draft? Why do we need to add yet another > alternative for them? so that they benefit from standardisation,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

...@akamai.com] Sent: Monday, October 23, 2017 12:27 PM To: Ackermann, Michael <mackerm...@bcbsm.com>; Ted Lemon <mel...@fugue.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 * I am merely trying to understand if there are any constructive suggest

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:25 PM, Ralph Droms wrote: > Is there running code that demonstrates the IPsec+IKE can be deployed and > operated at scale in the sort of environment the enterprise network tips have > described to us? Is there running code that demonstrates that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:22 PM, Ackermann, Michael wrote: > My question back to you was WHAT SIMPLIER PROTOCOL? This is what I actually wrote, in the message before the one Kathleen sent: > What they require is visibility into contents of the flow that they are using >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* Is there running code that demonstrates the IPsec+IKE can be deployed and operated at scale in the sort of environment the enterprise network tips have described to us? IBM has supported full-scale IPsec/IKE deployment on System/z for a very long time, and it also has an interesting way

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* I am merely trying to understand if there are any constructive suggestions amongst all these discussions, that we should consider. Yes. To repeat myself, here are two: 1. Continue to use your existing schemes. You won’t have to change to TLS 1.3 for years. 2. Modify your servers

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 22, 2017, at 2:40 PM, Ted Lemon wrote: > > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are places >> that require visibility into TLS. I

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ted Lemon [mailto:mel...@fugue.com] Sent: Monday, October 23, 2017 11:41 AM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: Steve Fenter <steven.fente...@gmail.com>; tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 23, 2017, at 10:35 AM, Ackerm

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/22/17 5:26 PM, Steve Fenter wrote: > I know of a number of large enterprises in verticals including financial, > health care, retail, and government, across multiple countries, who are using > packet payload inspection within their data centers. Most of these > enterprises are reluctant

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael wrote: > I was only asking what your opinion was, based on that statement in your > reply. With respect, Michael, I gave my opinion in the message to which Kathleen replied, so your assertion that you have been reading

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

ct: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 22, 2017, at 7:16 PM, Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: And out of curiosity, what is the simpler protocol you are recommending?I say out of curiosity because switch

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 22 Oct 2017, at 21:40, Ted Lemon wrote: > > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are places >> that require visibility into TLS. I will

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

➢ I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is trying to architect and engineer solutions without knowing the complete set of requirements, at

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hi Ted, On 23/10/17 00:35, Ted Lemon wrote: > On Oct 22, 2017, at 7:26 PM, Steve Fenter > wrote: >> I have been saying to anyone who will listen that the IETF needs a >> private forum for enterprises, to enable them to come forward and >> discuss their real

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 22, 2017, at 7:16 PM, Ackermann, Michael wrote: > And out of curiosity, what is the simpler protocol you are recommending? > I say out of curiosity because switching to a whole different protocol is not > likely to be feasible from any perspective for large

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 22, 2017, at 7:26 PM, Steve Fenter wrote: > I have been saying to anyone who will listen that the IETF needs a private > forum for enterprises, to enable them to come forward and discuss their real > requirements. Without this input the IETF is trying to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I know of a number of large enterprises in verticals including financial, health care, retail, and government, across multiple countries, who are using packet payload inspection within their data centers. Most of these enterprises are reluctant to step forward in a public forum and reveal

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

<steven.fente...@gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Oct 22, 2017, at 4:48 PM, Steve Fenter <steven.fente...@gmail.com<mailto:steven.fente...@gmail.com>> wrote: The main problem with not addressing the TLS vi

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 22/10/17 21:48, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is > that no one knows when a vulnerability will be discovered in TLS 1.2 > that forces enterprises to upgrade to TLS 1.3. We've had guarantees > that TLS 1.2 and the RSA key exchange are

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 22, 2017, at 4:48 PM, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is that no > one knows when a vulnerability will be discovered in TLS 1.2 that forces > enterprises to upgrade to TLS 1.3. We've had guarantees that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

First they have to go through this vulnerability search dance with TLS-1.1 and achieve a reasonably complete move to TLS-1.2. Regards, Uri Sent from my iPhone > On Oct 22, 2017, at 16:49, Steve Fenter wrote: > > The main problem with not addressing the TLS

  1   2   >