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

Sorry, My turn to disagree. I don't believe any points stated by David or myself had been stated previously nor "Countered". And if "Countered" means you disagree with the assertions, then you are saying that hosting providers are NOT doing MitM and that TLS is a multipoint protocol.

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

Michael, What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry. Thanks, S. On 25/10/17 01:41, Ackermann, Michael wrote: > Excellent

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

Excellent points/questions and I just wanted to add that your final example, regarding hosting providers actually being a MitM, is EXTREMELY prevalent in Enterprises today and is a management/ monitoring issue specifically pointed out by Steven Fenter in his presentation to the TLS WG in

Re: [TLS] sending full certificate chains in ClientCertificate

> On Oct 24, 2017, at 5:26 PM, Michael Richardson wrote: > > In the browser space there has been pushback against including the trust > anchors in the Server->Browser direction, including Google's Chrome browser > complaining about unnecessary certificates, and TLS

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] DTLS 1.3 ACKs

On Wed, Oct 25, 2017 at 12:59 AM, Ilari Liusvaara wrote: > On Mon, Oct 23, 2017 at 06:14:33PM -0700, Eric Rescorla wrote: >> We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > What is the _worst_ case memory usage (both sending and receving) for >

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

[TLS] sending full certificate chains in ClientCertificate

In ANIMA's BRSKI enrollment protocol we use TLS to communicate across realms. ( https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > We are connecting the (prospective) device owner's realm (the Registrar) to the manufacturer's realm (the MASA). The MASA's certificate is

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] editorial error in draft-ietf-tls-rfc4492bis-17

Thanks, Martin. This is correct. So there are two ways to fix this: As Martin suggests, make TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA one of the MTI instead of the current, or Add 0xC0,0x23 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256) to the list of ciphersuites. The first seems more consistent to

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

Our proposals are for spanned/tapped, passive traffic.You seem to be talking about modifying the actual live data stream. And MitM is also outside of what we want to do but would seem to be more feasible in that scernario. -Original Message- From: Salz, Rich

[TLS] TLS@IETF100: Agenda Requests

All, You will have seen that the chairs requested two sessions for IETF 100 TLS (on 20170929) and you will have also seen the that our request was granted (on 20171020). The sessions are currently scheduled as follows: tls Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room

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] DTLS 1.3 ACKs

On Mon, Oct 23, 2017 at 06:14:33PM -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. What is the _worst_ case memory usage (both sending and receving) for handling the acknowledgements and guaranteeing forward progress in all reasonable cases?

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

[TLS] editorial error in draft-ietf-tls-rfc4492bis-17

I just noticed a strange inconsistency in section 6 of draft-ietf-tls-rfc4492bis-17 https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6 The last of the "must implement 1 of these 4" list of cipher suites at the end of section 6 is not contained in the table at the beginning of

Re: [TLS] TLS 1.3 Record Boundaries

On Tue, Oct 24, 2017 at 12:42:01AM +, Andrei Popov wrote: > Draft-21 says: > "Handshake messages MUST NOT span key changes. Implementations > MUST verify that all messages immediately preceding a key change > align with a record boundary; if not, then they MUST terminate the >

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

Sean/Joe, this is addressed to you... On 24/10/17 00:31, 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. So from the above we see that some of the proponents of breaking TLS

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

Even if YOUR objective is to passively observe, you have to admit that this mechanism allows OTHER PEOPLE using it to modify the encrypted data, and we should always consider the worst-case scenario. In fact, my opinion a couple of weeks ago was that we had to find some way to provide