Re: [TLS] TLS@IETF101 Agenda Posted

[Ralph Droms]

> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov  wrote:
> 
> 13 Mar. 2018 г., 18:38 Ted Lemon mailto:mel...@fugue.com>>:
> One strategy that's very effective for overcoming resistance to bad ideas is 
> to keep pushing the idea until nobody who's resisting it can afford to 
> continue doing so.
> 
> There's a name for that tactics, it's called "consensus by exhaustion". (On 
> the recent GNSO meeting this was briefly discussed as an issue within ICANN.)

And there is a name for this sort of labeling - it's called an "ad hominem 
attack".  I don't believe anyone is employing "consensus by exhaustion".  
Please don't attach unwarranted labels to honest attempts to explain 
requirements and develop solutions.

- Ralph

> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ralph Droms]

> On Mar 14, 2018, at 10:52 PM, Artyom Gavrichenkov  wrote:
> 
> 14 Mar. 2018 г., 22:32 Ralph Droms  <mailto:rdroms.i...@gmail.com>>:
> 
>> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov > <mailto:xima...@gmail.com>> wrote:
>> 
>> 13 Mar. 2018 г., 18:38 Ted Lemon > <mailto:mel...@fugue.com>>:
>> One strategy that's very effective for overcoming resistance to bad ideas is 
>> to keep pushing the idea until nobody who's resisting it can afford to 
>> continue doing so.
>> 
>> There's a name for that tactics, it's called "consensus by exhaustion". (On 
>> the recent GNSO meeting this was briefly discussed as an issue within ICANN.)
> 
> And there is a name for this sort of labeling - it's called an "ad hominem 
> attack".  I don't believe anyone is employing "consensus by exhaustion".  
> Please don't attach unwarranted labels to honest attempts to explain 
> requirements and develop solutions.
> 
> I didn't! Ted has just pointed out that there's some strategy which is by the 
> way effective under some circumstances, and I've just recalled it has a name. 
> No labels attached!

Ah, OK, sorry for the incorrect inference!

In my opinion some people may be misreading a good faith effort to explain the 
problem, listen to feedback and develop a solution as pushing an idea until the 
opponents can't afford to keep participating.  Please accept that good faith 
effort at face value...

- Ralph



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ralph Droms]

We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension 
defined in this I-D takes into account what we heard from the discussion 
regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. 
Specifically, it provides an opt-in capability for both the TLS client and 
server and makes it clear on the wire that visibility will be enabled for the 
session.  The new mechanism does not depend on static handshake or session 
keys.  

- Ralph and Russ


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ralph Droms]

> 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 will let one of the people that works 
>> in a regulated industry offer pointers to the documents.
> 
> What they require is visibility into contents of the flow that they are using 
> encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
> TLS 1.2.   The right thing for them to do if they continue to need this 
> visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,

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?

> or some protocol that is designed for this use case, not to take a protocol 
> designed specifically for securing flows from on-path eavesdropping and 
> create a mode where it is easier to wiretap.

...assuming the necessary lead time and support from vendors to implement 
another protocol.

> There is no reason other than momentum for them to switch to TLS 1.3 when it 
> doesn't address their use case.

But TLS 1.3 addresses *part* of the use case, as it does provide better 
security and it represents an incremental change to the current deployment and 
operation practices.  

- Ralph

> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ralph Droms]

> 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 to agree to allow it to intercept the traffic; and
>> 
>> 2) get the client to include the new extension in its ClientHello.
>> 
>> How would the middlebox get the client to include the extension.
> 
> Block all TLS connections that don't use it.

...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 this situation 
different than the current practice of using HTTP if HTTPS fails?

> 
>>> I believe I know why people want this now. They are worried that if TLS 1.3 
>>> goes out without something like this, then the market (standard widely 
>>> available browsers) will not implement it. Let me assure you that this 
>>> isn’t an issue. The extension would *never ever* make it to the MUST state, 
>>> and the browsers would be unlikely to ever implement it anyway.
>> 
>> I partially agree with this and partially disagree. I agree that browsers 
>> (and other similar clients) would be unlikely to ever implement it. I 
>> disagree with the suggestion that proponents of this draft want for browsers 
>> to implement this or want it to be a MUST. Proponents of this draft are 
>> interested in visibility within the data center, and have no interest in 
>> using this capability in any scenario in which a browser would be the client.

> 
> Let's be clear.   While I may have made some statements about the balance of 
> concern over who pays for this, nobody is saying that the proponents of this 
> draft intend a nefarious use of this extension.   The concern is not that 
> BCBS is going to invade my privacy.   It is that if BCBS gets its way, 
> someone _else_ will use this technology to invade my privacy, or to trojan 
> horse some malware onto my computer, or some other attack.

Can you demonstrate how such an attack would work without the assumption that a 
client (e.g., browser) would, as policy, downgrade to using the extension if it 
can't connect without the extension.  I understand the general concern.

> 
>> So, given your agreement that browsers would be unlikely to ever implement 
>> this extension, how would the in-flight WiFi (or other middlebox) be able to 
>> get clients to include the extension if the software they are using doesn't 
>> support it? It seems that the only way would be to coerce the clients into 
>> using a browser (or other client) provided by the attacker (i.e., in order 
>> to use the Internet while in flight you must install Evil Airline's 
>> browser/app). But then, if the attacker is able to get the client to install 
>> and use its own software, then it would easily be able to intercept all 
>> traffic from the client, not just traffic to cooperating servers, so why 
>> would it bother using this draft at all in this case?
> 
> You've inverted the chain of causality here.   The chain is (to the best of 
> my ability to explain it, anyway):
> 
> 1. Standardize this extension
> 2. Someone with a service people want to use starts blocking connections that 
> don't enable it.
> 3. Browser vendors are forced to implement it, or end users are forced to 
> download special browser software.
> 4. Now an attack surface exists on the user's machine that hadn't previously 
> existed.
> 5. The user's machine is now subject to attack by a larger set of attackers 
> than it had been previously, using a larger set of attacks than were 
> available previously.

I still don't see how step 2 is different than forcing a connection without 
using TLS at all?  Why is the visibility extension more dangerous than only 
allowing connections with no TLS?

> 
> None of this is a smoking gun.   If everybody keeps all the plates spinning, 
> we won't have a problem.   The problem is that everybody keeping the plates 
> spinning is something that pretty much doesn't happen in the real world, as 
> we've seen if we follow the news.   And some of the everybodies in this 
> equation are operating infrastructure that we really, really need to be well 
> protected.   And others are being stalked.   And still others are trying to 
> do secure transactions online.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ralph Droms]

> 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. Such a box could today drop any traffic 
> that is protected using TLS.
> 
> True, but that’s not the point.  The point is by adding this extension into 
> the clientHello, we are providing middleboxes with another knob to control 
> traffic.  I think we want to avoid that. And keep in mind it’s not just HTTP, 
> but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily 
> enable spying, but it could be used to guarantee that all traffic is amenable 
> to spying.
>  
> As for how would such clients get promulgated?  Some simple scenarious 
> include “surf for free on your flight, but use our Chromium-based browser to 
> do so, available for free here.”How many people on the plane would click 
> and download?

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.

>  
> > Proponents of this draft are interested in visibility within the data 
> > center, and have no interest in using this capability in any scenario in 
> > which a browser would be the client.
> 
> How do you propose to guarantee that?  As Stephen pointed out, we have no way 
> to prevent this from “escaping” on to the public Internet, and no way to 
> prevent captive audiences from being forced to comply.
>  
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ralph Droms]

> On Oct 24, 2017, at 4: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 such a solution would be simpler and far 
>> more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop 
>> on outgoing traffic.
> 
> Again, if that were true, then it would also be true that these devices would 
> nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

I think your suggestion is addressed as one of the alternative solutions in 
draft-rhrd-tls-tls13-visibility.  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.

- Ralph

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls