subject:"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 altogether.

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

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 myself, I disagree with some aspect's of Nick's analysis, which
we can go into as needed. I don't think that's needed in this mail.

On your second point...

The IETF has a range of policies (BCPs etc) that call for use of
strong and not-weakened cryptography in protocols. Some of that
is mentioned in places at [1] but I'm sure a more complete job
could be done. There are sound technical reasons why the IETF has
consensus on a bunch of those positions. For some of those, it
is also true that the consensus has always been rough, e.g. I
think it's true there have always been IETFers who would actually
like to MitM security protocols for what they consider good
reasons. (That doesn't make those people either bad or correct.)

One particular relevant RFC (2804) does explicitly envisage that
people who want to do snooping might document their ways of doing
that in independent stream RFCs (which are not IETF RFCs despite
almost no RFC-readers grokking any difference there;-). But in
this case the authors say they want standards-track. And in the
previous case, from talking with Russ, he didn't see any benefit
in the independent stream route (which I didn't understand at the
time tbh).

So the situation is actually sort-of clear, but not simple. It's
true that appreciating the clarity requires quite a bit of IETF
lore ;-)

S.

[1] https://github.com/sftcd/tinfoil

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

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

2017-10-25 Thread Peter Bowen

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 the opposite of standard.
>
> See the intended status below.
>
>> I don't really have a dog in this fight, but let's please be accurate.
>
> Accuracy level is just fine I think.

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?

Nick Sullivan wrote:
> 1) use TLS 1.2 with RSA -> one single key
> 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to 
> draft-green)
> 3) use any version of TLS and export the session keys -> corpus of keys equal 
> to number of connections

Thanks,
Peter

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

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 fight, but let's please be accurate.

Accuracy level is just fine I think.

S.

Network Working Group R. Housley
Internet-DraftVigil Security
Intended status: Standards TrackR. Droms
Expires: April 2, 2018  Interisle Consulting
  September 29, 2017

 TLS 1.3 Option for Negotiation of Visibility in the Datacenter
   draft-rhrd-tls-tls13-visibility-00

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

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

2017-10-25 Thread Richard Barnes

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 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
> other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.

Sorry, what?  The current draft proposes an extension, literally the
opposite of a standard, supported feature.  It's explicitly optional.

I don't really have a dog in this fight, but let's please be accurate.

--Richard

> But, I'm tired of the abusive
> and false suggestions that draft-rhrd-tls-tls13-visibility is a
> "wiretapping" draft or that it is defining a "please-screw-me
> extension."

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.

___
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

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
to acquiesce to bad ideas in the name of finding common ground.
The IETF is not that kind of SDO (at least I hope not).

When a thing is a sufficiently bad idea, then it is not a good
plan to try meet it half-way. That is the case with the basic
idea here.

So, sorry, no - compromise is not a goal.

OTOH, investigating non-damaging means of meeting data centre
requirements that do not involve TLS is an entirely fine thing
to do IMO. (Though maybe not the oft-quoted but *never* so far
substantiated claims related to PCI;-).

I would encourage you and others to go do that. If that calls
for the development of a new multi-party security protocol
that can be used in such environments, that is also just fine
and could have other interesting uses.

One could also do work to try make it easier for sites to
evolve towards use of (closer to, but not, perfect) forward
secrecy.

But breaking TLS is very different to both and is not fine.

S.

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

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
> server) chooses to provide the contents of the communication to some
> other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.

> But, I'm tired of the abusive
> and false suggestions that draft-rhrd-tls-tls13-visibility is a
> "wiretapping" draft or that it is defining a "please-screw-me
> extension." 

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.

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

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

Thank you Nick.

On 25/10/17 20:34, Nick Sullivan wrote:
> On that note, so what if some browsers opt in? Servers need to also opt-in
> to setting visibility keys.

It is good to see the discussion move on from the proponents'
seeming inability to envisage that anything bad could possibly
happen here;-)

I believe you are right that if we standardise this, it is
reasonably likely to end up in some browser. (I've no idea
how to estimate that probability, so we're all guessing
really.)

As you might expect, I disagree with your analysis as to the
consequences if browsers did support this.

Just as one example, I read today of reports that some people
have been arrested/accused partly on the basis that they downloaded
some software [1] so it is sadly far too easy to imagine that
some regime somewhere would arrest people for having a browser
that does not support this "standard" feature. Note, I'm not
saying I accept all details of the story in [1] as such things
are often badly reported, but I do assert that such issues are
ones we ought be seriously considering.

For me, us defining a feature like this that could be mandated,
for wiretapping, or the absence of which could get folks into
that kind of trouble, is just not something we ought be risking,
regardless of our inability to estimate the probabilities
involved.

[1]
https://www.theguardian.com/world/2017/oct/25/amnesty-turkish-chair-taner-kilic-on-trial-over-failed-coup

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

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

2017-10-25 Thread Ted Lemon

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 I am very much mistaken, it is literally impossible to prevent a server 
from escrowing a key so that the contents of the communication can be decrypted.

> - having such a system on the internet is a bad idea because it reduces the 
> security of multiple connections down to a single piece of data
> - on the other hand using draft-rhrd is safer than allowing organizations to 
> hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with 
> non-forward-secret cipher suites

There's no question of allowing or not allowing—that's outside of IETF's sphere 
of influence.   But the case has been (to me convincingly) made that making it 
possible for an eavesdropper on the conversation to easily tell whether a 
client is willing to accept key escrow makes things worse, from a security 
perspective.

The main sense in which it makes things worse is that such a feature might be 
added to standard libraries, and thus be available at low cost, and thus might 
become easy to impose as a regulatory requirement.

This is why I have been advocating for simply not using TLS for this use case.  
 There exist solutions to this problem that do not require breaking TLS 1.3, 
that are standard, and that are already allowed for PCI compliance.   It's 
better for everyone if these two domains are kept separate, and I haven't yet 
heard a good argument for not doing so.

> The fundamental assumption of this draft is that that 3) is not feasible for 
> all enterprises because rearchitecting their systems for a multi-key escrow 
> is either too costly or that the requirement for TLS 1.3 will come too soon. 
> Ted Lemon had some convincing arguments earlier about why enterprises should 
> see this coming and invest in migrating to a model closer to 3),

To be clear, I actually don't think that per-session key escrow is feasible in 
the use case that we are talking about here.   From a security perspective I 
think it's a pretty good idea, because it allows for things like rate-limiting 
the number of connections that can be monitored, but from a practical 
perspective, arranging to have the keys available in a timely manner during 
debugging seems to me not to be tractable, since the number of keys involved 
would be substantial, and the timing would be quite exact; indeed, if the 
debugging process requires debugging all active streams in order to find an ID 
in the stream that is actually sought, I think it would be almost impossible, 
and certainly ludicrously expensive.

What I've been arguing for is to switch away from TLS for this use case.

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

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

2017-10-25 Thread Nick Sullivan

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 TLS 1.2 with RSA -> one single key
2) use TLS 1.3 with DH key derived from seed -> one single key (similar to
draft-green)
3) use any version of TLS and export the session keys -> corpus of keys
equal to number of connections

The fundamental assumption of this draft is that that 3) is not feasible
for all enterprises because rearchitecting their systems for a multi-key
escrow is either too costly or that the requirement for TLS 1.3 will come
too soon. Ted Lemon had some convincing arguments earlier about why
enterprises should see this coming and invest in migrating to a model
closer to 3), which will always be possible in a system that uses symmetric
cryptography for encryption. Newer companies like the one mentioned by Tony
Arcieri have managed to architect their systems this way, so it’s not
impossible. Still, it’s usually cheaper to adapt an existing system rather
than re-architect your network (and buy more gear). As long as 2) is
possible, the moving to a model based on 3) is going to be a hard sell.

Given that enterprises would rather be standards-compliant, this draft is a
way to prevent enterprises from just going ahead and implementing 2), and
instead implement something that has similar benefits (a single master key
that can decrypt multiple connections), but with additional safeguards for
the user:
-the ability to opt out
-visibility into the fact that their connection is part of a pool of
connections protected by a single key

You can do neither with 2). This is a win. To Rich’s argument that network
domains will force browsers to implement this by blocking connections that
don’t advertise this support, I disagree. There are no passive firewalls
that I know of that drop TLS connections that don’t support escrow (in the
sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow).
Shouldn’t these be blocked by the GFW if someone is forcing RSA escrow?

On that note, so what if some browsers opt in? Servers need to also opt-in
to setting visibility keys. These will be visible by the browser, and
visible by network watchdogs. Visibility is good in the situation where
both parties want to be honest, and a dishonest escrow mechanism is
possible. Furthermore, large services that are internet-facing that see
this extension existence can simply disconnect when it's presented,
applying back-pressure in the event of this "escaping" the datacenter.

Until TLS is redesigned so that a single key escrow is not possible,
datacenter operators will choose to do 2). For the next version of TLS, we
should strive to eliminate a the ability for a server to escrow a single
key. I posit that this should be a fundamental design principle for TLS
going forward: *cross-connection secrecy*. Forward secrecy with respect to
the long term certificate key is something that has been addressed in TLS
1.3. 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).

This draft is an optional extension that allows a client and server to
agree that a single key held by the server should be able to decrypt the
data of multiple connections. I don’t think it’s something that belongs on
the Internet as a whole, but understood it as a lesser of two evils with
respect to the options people have.

To summarize:
- TLS 1.3 allows single-key escrow with no client opt-in by design (because
of ephemeral DH)
- This is something that requires fundamental changes to TLS to fix, but
should be looked into
- Enterprises should look into moving to a model where session keys are
exported to prepare for this eventuality
- draft-rhrd allows clients to opt-in to an extension-based escrow system
that doesn’t abuse the core protocol and it enables network watchdogs to
observe
- having such a system on the internet is a bad idea because it reduces the
security of multiple connections down to a single piece of data
- on the other hand using draft-rhrd is safer than allowing organizations
to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
non-forward-secret cipher suites

Nick

On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich  wrote:

>
> > I didn’t say easy, I said ‘easier’
> >
> Can you explain how it is easier?
>
> There’s no way to limit it to the use-case it was putatively intended
> for.  We now have a signaling mechanism that says “allow interception.”
> Firewalls can drop connections where the client doesn’t send that
> extension. Therefore they can force only tappable TLS traffic. This makes
> the job easier.
>
> I take it you want to see this draft adopted?
>
>
> _

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

2017-10-25 Thread Jeffrey Walton

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 may disable Pin Validation for Pinned Hosts whose
>validated certificate chain terminates at a user-defined trust
>anchor, rather than a trust anchor built-in to the UA (or underlying
>platform)."
>
> and most browsers seem to follow this mitm exception.

The browsers are also complicit in the coverup. Reporting the broken
pinset to the user or site is a  "should not", even though
organizational policies and regulations may require it.

Jeff

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

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 noted, this may not even require
  developing custom software. It may be as simple as distributing a
  standard browser with its own CA added as a "user-installed" root
  certificate.
  
  In the case that the "attacker" has the cooperation of the server,
  and the client is using unmodified software, then the data sent
  between the client and server (including the server's certificate)
  would be no different than if the server wasn't allowing the
  "attacker" to have access to the data. There would be no
  information available to the client at all that would distinguish
  between scenarios in which the server either is or isn't allowing
  another party to have access to the data being transmitted over
  the TLS session.
  
  If public-key pinning and CT would prevent other mechanisms from
  working, please explain in detail how they would do so. Or better
  yet, let's end this line of discussion and work on finding
  mutually agreeable solutions to the underlying problem.
  
  On 10/25/2017 12:12 PM, Richard Barnes wrote:


  
  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 non-default, user-installed root
  certificates are exempted from those mechanisms in all
  current browsers.


--Richard



 

  

  ___
  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

2017-10-25 Thread Roland Zink

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 chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform)."


and most browsers seem to follow this mitm exception.

Regards,
Roland


Am 25.10.2017 um 18:06 schrieb Salz, Rich:

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

2017-10-25 Thread Richard Barnes

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 non-default, user-installed root certificates are exempted
from those mechanisms in all current browsers.

--Richard

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

2017-10-25 Thread Ackermann, Michael

" idea of a client extension was added based on feedback at the Prague meeting 
in order to help prevent the protocol from being used over the public Internet, 
by preventing the protocol from being used without the client's knowledge."

Responding ONLY to the above sentence,  as I agree with Stephen that this has  
gotten too NOISY.  

But at the end of the WG meeting in Prague,  the Chairs asked for the two sides 
to work together to find common ground.   We tried very hard to set up as many 
meetings as we could.  Very few would meet with us.   Ted Lemon was one.   As 
is evident,  Ted and I don't always agree,  but he went out of his way to meet 
with us and exchange views,  which was greatly appreciated and the type of 
effort it will take for two sides that do not agree, to find some form of 
compromise.
The only person that gave us constructive ideas in the common ground, was 
Martin Thompson,  who we all greatly appreciate meeting with us as well.   Out 
of that meeting came the idea that having the client be aware,  could address 
some of the issues brought up in the WG meeting.  
My point here is that we are trying hard to find ANY common ground and want to 
work towards this.   The client aware feature being added is NOT something that 
Enterprises want or need,  but was an effort to compromise and attempt to gain 
mutual consensus.  
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.  
If we could do more of this and less of the negative, duplicative and sometimes 
insulting rhetoric on this list,  perhaps we can make progress.   

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf 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 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 would filter 
traffic based on whether or not the extension is present in the ClientHello. 
I've already explained why I believe that scenario will never happen, and so no 
I do not agree that it is a "fundamental change."

The idea of a client extension was added based on feedback at the Prague 
meeting in order to help prevent the protocol from being used over the public 
Internet, by preventing the protocol from being used without the client's 
knowledge. Obviously you believe that the method being proposed to address one 
concern introduces another concern. I do not share those concerns for the 
reasons that I've already stated.

I don't plan to comment on this issue any further, and doing so would just be 
repeating myself, thus just adding to the noise.

On 10/25/2017 10:28 AM, Salz, Rich 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
>  server) chooses to provide the contents of the communication to some
>  other entity. draft-rhrd-tls-tls13-visibility doesn't change that.
>  
> Yes it does.  It signals on the wire to any observer that the client and 
> server agree to this.  TLS never attempted to control what the client or 
> server could do. But it never put any such signal on the wire. This is an 
> important and fundamental change, and it allows traffic to be categorized and 
> handled differently.
>
> Do you agree with that?
>

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

The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

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 customers. 
If the airplane/wifi provider controls the software on its customers' 
computers, it doesn't need the cooperation of the servers that the 
customers are connecting to in order to snoop, so it wouldn't go through 
the effort of trying to get that cooperation. And, if the airplane/wifi 
provider has the cooperation of the servers that the customers are 
connecting to it doesn't need to convince its customers to download any 
software or in any other way get the customers to cooperate in allowing 
the snooping, so it won't bother.. If you believe otherwise, then you 
are the one who is being very naïve.


I can't guarantee that enterprise visibility will stop at the enterprise 
firewall. My argument is simply that use of the protocol in this draft 
will stop at the enterprise firewall since outside the firewall, when 
communicating with clients outside of the enterprise's control, the 
enterprises that want to enable "visibility" into such traffic will use 
other means that don't require the the cooperation or knowledge of the 
clients, since those other means would be easier and more effective. You 
have done nothing to suggest otherwise.


On 10/25/2017 10:56 AM, Salz, Rich wrote:

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 airplane/wifi provider won’t say ‘download 
our free browser’?

I think you’re being very naïve to think otherwise.




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

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 airplane/wifi provider won’t say ‘download 
our free browser’?

I think you’re being very naïve to think otherwise.


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

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 would filter traffic based on whether or not the 
extension is present in the ClientHello. I've already explained why I 
believe that scenario will never happen, and so no I do not agree that 
it is a "fundamental change."


The idea of a client extension was added based on feedback at the Prague 
meeting in order to help prevent the protocol from being used over the 
public Internet, by preventing the protocol from being used without the 
client's knowledge. Obviously you believe that the method being proposed 
to address one concern introduces another concern. I do not share those 
concerns for the reasons that I've already stated.


I don't plan to comment on this issue any further, and doing so would 
just be repeating myself, thus just adding to the noise.


On 10/25/2017 10:28 AM, Salz, Rich 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
 server) chooses to provide the contents of the communication to some
 other entity. draft-rhrd-tls-tls13-visibility doesn't change that.
 
Yes it does.  It signals on the wire to any observer that the client and server agree to this.  TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently.


Do you agree with that?



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

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 
other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

Yes it does.  It signals on the wire to any observer that the client and server 
agree to this.  TLS never attempted to control what the client or server could 
do. But it never put any such signal on the wire. This is an important and 
fundamental change, and it allows traffic to be categorized and handled 
differently.

Do you agree with that?

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

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 else (Hosting Provider Y) without 
any clear indication to the client that the connection is terminating at 
Hosting Provider Y. Nobody has suggested that this is unacceptable or 
that TLS is broken if it can't prevent that.


TLS is not an end-to-end protocol, it is a point-to-point protocol, and 
as noted in hosting company example, which you claim to find so 
troubling, it isn't always clear to either party what's at the other end 
of the connection. It might be the entity the client thinks its 
connecting to (Company X), it might be a hosting provider acting on 
behalf of Company X, or it might be something else. The best the client 
can hope for with things like TLS, PKIX, TRANS, etc., is that the server 
end of the connection is either Company X or some entity authorized by 
Company X to act as Company X for the purpose of being the connection 
endpoint (and, yes, Company X may have been coerced into authorizing 
some other entity to covertly act as the server endpoint). I am not 
saying that I like this or am "espousing" it, I am simply pointing out a 
fact.


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 
other entity. draft-rhrd-tls-tls13-visibility doesn't change that.


It is also a fact that once a client provides data to a server, there 
are no technical mechanisms that would allow the client to limit what 
the server does with that data. As has been show over and over again, 
including by you, it is very frequently the case that the server that 
initially receives the data passes it on to others. The others may be 
back-end database servers or anti-virus scanners, but the client has no 
control over what happens to the data once the server receives it.


I have not tried to argue that draft-rhrd-tls-tls13-visibility is the 
best solution for addressing the need for visibility within the data 
center. Perhaps it is, perhaps it isn't. But, I'm tired of the abusive 
and false suggestions that draft-rhrd-tls-tls13-visibility is a 
"wiretapping" draft or that it is defining a "please-screw-me 
extension." These suggestions have been repeated over and over again, 
even though they have already been countered effectively - "repeating 
points already countered is just disruptive noise."


On 10/24/2017 10:13 PM, Stephen Farrell wrote:

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 connection between the client and Company X being MiTM'd? The
client might think it has a secure end-to-end connection with Company X, but in
reality its data is being intercepted and read by Hosting Provider Y, without
the client's permission (and most likely without the client's knowledge). How
does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be
standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.



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

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 those unwilling?

3 Do you think that this draft will require zero changes to your 
infrastructure?  How does that cost estimate compare with, say, the server just 
sending the PFS session key to the infrastructure?

4 What percentage of traffic in your enterprise is TLS 1.2 now?  (Yes, that’s a 
new question I admit)

5 When do you think you will “have” to move to TLS 1.3, round it to, say five 
years.

6 What is the justification for this approach, other than you think it will be 
a “hard sell” to convince executives to do the work needed?  I’ve seen no other 
reasons discussed and am curious to see how this response and #3 align.



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

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

2017-10-24 Thread Ackermann, Michael

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.And once again I disagree.  
But since I too deplore "Noise",  I will comment no further on these aspects of 
the conversation and we can agree to disagree.  


-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Tuesday, October 24, 2017 10:01 PM
To: Ackermann, Michael ; David A. Cooper 
; 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? (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 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 Prague.
> Without the ability to decrypt these sessions our ability to 
> manage/monitor/secure is severely reduced.
> And TLS, being a point to point protocol,  cannot help in its current form.
> 
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper
> Sent: Tuesday, October 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 in commonly-used browsers.
> 
> And that is a risk you are willing for the entire public Internet to take?
> 
> 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 scenarios people 
> are concerned about, the "attacks" being described would be much more easily 
> carried out by some means other than draft-rhrd-tls-tls13-visibility.
> 
> So, no I am not worried about the "risk" of creating a complicated way for 
> servers and middleboxes to collude to do something that they can already do 
> now in a simpler way.
> 
> 
> And what about the fact that it provides a cleartext signal as to whether or 
> not a client is willing to let itself be MiTM'd, does that bother you?
> 
> No. As I noted before, servers can already allow middleboxes to MiTM 
> connections with clients with asking the client's permission. Public facing 
> servers that want to allow this (even if as a result of coercion) won't use 
> this extension. They'll just enable it without informing the clients.
> 
> There are also other ways a server could allow a middlebox to MiTM the 
> connections that it has with clients that don't require the client's 
> cooperation (or knowledge) and that wouldn't require any changes on the 
> client side; ways that would be easier than trying to use 
> draft-rhrd-tls-tls13-visibility.
> 
> If the only way (or the easiest way) these connections could be MiTM'd 
> required getting clients' permission, then this might be a concern, I don't 
> see servers that want to (or are coerced into) allowing connections to be 
> MiTM'd asking clients whether they are willing. Given this, we aren't going 
> to see browsers that are configurable to signal that the client is willing to 
> "allow" the connection to be MiTM'd.
> 
> 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 connection between the client and Company X being MiTM'd? 
> The client might think it has a secure end-to-end connection with Company X, 
> but in reality its data is being intercepted and read by Hosting Provider Y, 
> without the client's permission (and most likely without the client's 
> knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding 
> that TLS cannot be standardized until it can be proven that such a scenario 
> is impossible?
> 
> 
> 
> 
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the in

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 connection between the client and Company X being MiTM'd? 
> The 
> client might think it has a secure end-to-end connection with Company X, but 
> in 
> reality its data is being intercepted and read by Hosting Provider Y, without 
> the client's permission (and most likely without the client's knowledge). How 
> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot 
> be 
> standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.

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

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 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 Prague.
> Without the ability to decrypt these sessions our ability to 
> manage/monitor/secure is severely reduced.
> And TLS, being a point to point protocol,  cannot help in its current form.
> 
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper
> Sent: Tuesday, October 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 in commonly-used browsers.
> 
> And that is a risk you are willing for the entire public Internet to take?
> 
> 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 scenarios people 
> are concerned about, the "attacks" being described would be much more easily 
> carried out by some means other than draft-rhrd-tls-tls13-visibility.
> 
> So, no I am not worried about the "risk" of creating a complicated way for 
> servers and middleboxes to collude to do something that they can already do 
> now in a simpler way.
> 
> 
> And what about the fact that it provides a cleartext signal as to whether or 
> not a client is willing to let itself be MiTM’d, does that bother you?
> 
> No. As I noted before, servers can already allow middleboxes to MiTM 
> connections with clients with asking the client's permission. Public facing 
> servers that want to allow this (even if as a result of coercion) won't use 
> this extension. They'll just enable it without informing the clients.
> 
> There are also other ways a server could allow a middlebox to MiTM the 
> connections that it has with clients that don't require the client's 
> cooperation (or knowledge) and that wouldn't require any changes on the 
> client side; ways that would be easier than trying to use 
> draft-rhrd-tls-tls13-visibility.
> 
> If the only way (or the easiest way) these connections could be MiTM'd 
> required getting clients' permission, then this might be a concern, I don't 
> see servers that want to (or are coerced into) allowing connections to be 
> MiTM'd asking clients whether they are willing. Given this, we aren't going 
> to see browsers that are configurable to signal that the client is willing to 
> "allow" the connection to be MiTM'd.
> 
> 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 connection between the client and Company X being MiTM'd? 
> The client might think it has a secure end-to-end connection with Company X, 
> but in reality its data is being intercepted and read by Hosting Provider Y, 
> without the client's permission (and most likely without the client's 
> knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding 
> that TLS cannot be standardized until it can be proven that such a scenario 
> is impossible?
> 
> 
> 
> 
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the individual(s) to whom this communication 
> is directed. If you are not the intended recipient, you are hereby notified 
> that any viewing, copying, disclosure or distribution of this information is 
> prohibited. Please notify the sender, by electronic mail or telephone, of any 
> unintended receipt and delete the original message without making any copies.
>  
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
> nonprofit corporations and independent licensees of the Blue Cross and Blue 
> Shield Association.
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



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

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 scenarios people 
> are concerned about, the "attacks" being described would be much more easily 
> carried out by some means other than draft-rhrd-tls-tls13-visibility.

Yes, you are taking a risk.  Or, rather, you are providing a way for any 
middlebox to force clients to acquiesce.  You might think it’s complicated, but 
it’s not.  There’s a perl script in the OpenSSL distribution that does 
something very similar (look for the TLS Proxy).

Servers have always had the ability to share whatever information they want 
with other entities.  We are not trying to change that.  What this draft does 
is force clients to become parties in that interaction and signal in the clear 
that they are doing so.  This is a really fundamental change to TLS.

> So, no I am not worried about the "risk" of creating a complicated way for 
> servers and middleboxes to collude to do something that they can already do 
> now in a simpler way.

I think you’re not getting it.  Sorry, probably my fault for not being a very 
good explainer.





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

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

2017-10-24 Thread Ackermann, Michael

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 Prague.
Without the ability to decrypt these sessions our ability to 
manage/monitor/secure is severely reduced.
And TLS, being a point to point protocol,  cannot help in its current form.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper
Sent: Tuesday, October 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 in commonly-used browsers.

And that is a risk you are willing for the entire public Internet to take?

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 scenarios people are 
concerned about, the "attacks" being described would be much more easily 
carried out by some means other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated way for 
servers and middleboxes to collude to do something that they can already do now 
in a simpler way.


And what about the fact that it provides a cleartext signal as to whether or 
not a client is willing to let itself be MiTM’d, does that bother you?

No. As I noted before, servers can already allow middleboxes to MiTM 
connections with clients with asking the client's permission. Public facing 
servers that want to allow this (even if as a result of coercion) won't use 
this extension. They'll just enable it without informing the clients.

There are also other ways a server could allow a middlebox to MiTM the 
connections that it has with clients that don't require the client's 
cooperation (or knowledge) and that wouldn't require any changes on the client 
side; ways that would be easier than trying to use 
draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be MiTM'd required 
getting clients' permission, then this might be a concern, I don't see servers 
that want to (or are coerced into) allowing connections to be MiTM'd asking 
clients whether they are willing. Given this, we aren't going to see browsers 
that are configurable to signal that the client is willing to "allow" the 
connection to be MiTM'd.

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 connection between the client and Company X being MiTM'd? The 
client might think it has a secure end-to-end connection with Company X, but in 
reality its data is being intercepted and read by Hosting Provider Y, without 
the client's permission (and most likely without the client's knowledge). How 
does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot 
be standardized until it can be proven that such a scenario is impossible?




The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/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.

 
And that is a risk you are willing for the
  entire public Internet to take?
  


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 scenarios people are concerned about, the "attacks"
being described would be much more easily carried out by some means
other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated
way for servers and middleboxes to collude to do something that they
can already do now in a simpler way.


  
And what about the fact that it provides a
  cleartext signal as to whether or not a client is willing to
  let itself be MiTM’d, does that bother you?
  


No. As I noted before, servers can already allow middleboxes to MiTM
connections with clients with asking the client's permission. Public
facing servers that want to allow this (even if as a result of
coercion) won't use this extension. They'll just enable it without
informing the clients.

There are also other ways a server could allow a middlebox to MiTM
the connections that it has with clients that don't require the
client's cooperation (or knowledge) and that wouldn't require any
changes on the client side; ways that would be easier than trying to
use draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be
MiTM'd required getting clients' permission, then this might be a
concern, I don't see servers that want to (or are coerced into)
allowing connections to be MiTM'd asking clients whether they are
willing. Given this, we aren't going to see browsers that are
configurable to signal that the client is willing to "allow" the
connection to be MiTM'd.

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 connection between the client
and Company X being MiTM'd? The client might think it has a secure
end-to-end connection with Company X, but in reality its data is
being intercepted and read by Hosting Provider Y, without the
client's permission (and most likely without the client's
knowledge). How does TLS, currently, prevent this? Why isn't anyone
demanding that TLS cannot be standardized until it can be proven
that such a scenario is impossible?



  


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

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 not be a 
> viable solution.

I was not actually suggesting this as a solution.   Rather, I was pointing out 
that it's a lousy solution for both use cases.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 
servers and monitoring infrastructure?  Zero?  Thousands per device?  Based on  
the contacts you’ve had, how does the cost of modifications to support *this* 
draft, compare to the cost of modifying the server and monitoring 
infrastructure to report and use negotiation PFS session keys?

And hey, you’re an author.  Does your draft allow an intermediate such as a 
firewall to modify the traffic that passes through?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 is willing to let itself be MiTM’d, does that bother you?

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

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, that would only be the beginning of
what they need to do. They would need to active cooperation of
every TLS-protected server that the students could connect to and
they would need an infrastructure for obtaining and managing all
of the keys that they would be getting from all of these servers.
[In practice, of course, there wouldn't be that many keys since
practically no servers would cooperate in this scheme.]

So, yes, setting up a scheme to snoop on all outgoing
TLS-protected traffic would not be easy. However,
draft-rhrd-tls-tls13-visibility would not make it easier than it
currently is, as implementing something based on
draft-rhrd-tls-tls13-visibility would be far more difficult than
using currently available methods.

And, I don't buy the idea that if this extension is standardized
that it will be implemented in commonly-used browsers. We don't
have to "keep all the plates spinning" in order to prevent this
extension from "escaping" on to the public Internet. This isn't
something that could "accidentally" be implemented in browsers if
browser vendors don't take extreme precautions to prevent it from
happening. Browser vendors would have to pro-actively decide to
implement this, and I don't see that happening. The idea that
someone would set up a service that would only work if browsers
implemented this extension, and then browsers would be "forced" to
implement the extension so that this service would work isn't
realistic.

A server that wanted to allow third party interception of traffic
between itself and its clients wouldn't require this extension and
then wait for browsers to implement the extension. It would just
use TLSv1.2 with RSA key exchange (or something like
draft-green-tls-static-dh-in-tls13), and then set up the
interception capability without the client's knowledge.

On 10/24/2017 04:38 PM, Yoav Nir wrote:

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 snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.

This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others). It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students” and “MustangBrowser for Mountain Crest High School students"

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 to, and only expert users would notice the presence of the MiTM.

Unless they had to configure their browser themselves. The support costs of these is tremendous.

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

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

2017-10-24 Thread Kathleen Moriarty

On Tue, 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.

These are two different problems and although you could use a proxy
solution inside a datacenter, it doesn't scale or make sense.  IMO,
David countered Yoav's clever scenario very well.

Now, the proponents are asking for alternatives to consider and a
serious look at their proposal.  Can we look at this request
constructively and provide a cohesive set of alternate solutions?

IPsec [1] might be possible, but requires a change in tooling for
intercepting traffic.  In hosted environments, it also could change
who is managing the encryption (TCP/application vs. IP layer).
I also received a comment that you could also tie in use of IPv6 and
label sessions with the IPsec approach and that makes sense.

What about the experimental drafts in TCPInc?  [2]
This provides opportunistically encrypted TCP, so you could MiTM it.

Are there other alternate solutions that have been discussed or should
be?  Maybe it would be helpful to list them out for comparison and
evaluation by those interested - not on list as that's off-topic.

[1] 
https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward
[2] https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/?include_text=1

Thanks,
Kathleen

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

-- 

Best regards,
Kathleen

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

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

2017-10-24 Thread 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

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


Not at all. Visibility in the data center is a totally different
problem than inspecting outgoing traffic. In the data center case
the same organization controls the clients, servers, and the
authorized listeners. That is very different from a scenario in
which the organization that wants to listen in is different from the
organizations that control the servers, and in which the
organizations that control the servers are unlikely to want to grant
this intermediary the ability to listen in on the traffic between it
and its clients.

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 not be a viable solution.

  


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

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

2017-10-24 Thread Yoav Nir

> 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 snoop on its students' 
> traffic, it would do so in a much easier way than using 
> draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today 
> use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all 
but the most orderly of enterprises. You need to have all clients trust the 
middlebox CA. Fine, so the Windows computers get that installed through SMS or 
GPO or whatever the central configuration feature is called these days. The 
people with Macs have to figure it out for themselves, and the same goes for 
people with phones. Oh, and also for people who use Firefox, because that 
browser comes with its own trust store. The people on this list can probably 
figure it out with a little web search. A school with a thousand students all 
bringing their own devices? Good luck.

> This browser that students would be required to use would be one that has a 
> CA controlled by the middlebox installed as a trust anchor. Whenever one of 
> the students' clients tries to connect to an external secure site, the 
> middlebox-controlled CA issues a certificate for that site so that the 
> connection can be terminated at the middlebox. The middlebox then establishes 
> a secure connection with the end server, thus setting up the middlebox as a 
> MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app 
stores of all phone and computer OS-es) works in this school (and all the 
others).  It’s a totally different thing to fill the app stores with 
“GrizzlyBrowser for Logan High School students” and “MustangBrowser for 
Mountain Crest High School students"

> 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 to, and only 
> expert users would notice the presence of the MiTM.

Unless they had to configure their browser themselves.  The support costs of 
these is tremendous.

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

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

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

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 are suggesting draft-rhrd-tls-tls13-visibility could be
  used to snoop on outgoing traffic are imagining a scenario in
  which the school (or other snooper) would make arrangements with
  each TLS-protected server that they would allow their clients to
  connect to receive copies of the keys that would be needed to
  decrypt the traffic. How effective would that be? How expensive
  would that be?
  
  Besides, the scenario I described previously is just one
  possibility (although perhaps the easiest to implement). The
  software that the middlebox requires clients to use could just
  send the traffic in plaintext to the middlebox while falsely
  indicating to the client that the connection is secure. Plainly,
  if the attacker developed the software that the client is running,
  then there is no protection from the attacker.
  
  On 10/24/2017 04:01 PM, Ted Lemon wrote:


  
  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 require
any cooperation whatsoever from the outside servers
that the clients are trying to connect to, and only
expert users would notice the presence of the MiTM.
  


They are also quite
  expensive because they have to generate certs on the fly.
    If you look at environments where these are in use, they
  tend to be either high-margin, or else low-use.   So e.g.
  you only redirect TLS connections that you absolutely need
  to intercept through the box; other connections are
  terminated normally.   Practically speaking, I don't see
  any cash-strapped school spending money on one of these
  devices.
  

  
  
  BTW, if you find this argument unconvincing,
consider why these boxes aren't being proposed for use as an
alternative to draft-rhrd-tls-tls13-visibility-00.   :)
  
  



  


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

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 
expect that someone will use it; anything else would be naïve. All the 
discussions about “ossification” in the past two years should make that 
painfully obvious.

As for “improper purposes,” it’s something enabled by the protocol, even if 
it’s not what the proposers intended it for.  But isn’t the whole story of the 
Internet? If the purposes are really improper, define things in a way that it 
can only be used properly, for whatever that definition is.

So far, we’ve seen that it can be used to segregate clients, open them up to 
stream modification, and the only justification has been that this is perceived 
easier to keep visibility as currently built by sharing static RSA keys.

Do I have that right?

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

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 require any cooperation whatsoever 
>> from the outside servers that the clients are trying to connect to, and only 
>> expert users would notice the presence of the MiTM.
> 
> They are also quite expensive because they have to generate certs on the fly. 
>   If you look at environments where these are in use, they tend to be either 
> high-margin, or else low-use.   So e.g. you only redirect TLS connections 
> that you absolutely need to intercept through the box; other connections are 
> terminated normally.   Practically speaking, I don't see any cash-strapped 
> school spending money on one of these devices.

BTW, if you find this argument unconvincing, consider why these boxes aren't 
being proposed for use as an alternative to draft-rhrd-tls-tls13-visibility-00. 
  :)

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

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 to, and only 
> expert users would notice the presence of the MiTM.

They are also quite expensive because they have to generate certs on the fly.   
If you look at environments where these are in use, they tend to be either 
high-margin, or else low-use.   So e.g. you only redirect TLS connections that 
you absolutely need to intercept through the box; other connections are 
terminated normally.   Practically speaking, I don't see any cash-strapped 
school spending money on one of these devices.

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

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 have consumed the cycles I have for that
work. As both Ted and Ben have said this I know I'm not
alone in that, and the volume of mail on the topic alone
shows that others are spending valuable time rebutting the
ongoing break-TLS show.

Whether or not any of us would have contributed to TLS1.3 or
DTLS1.3 being done sooner or better instead is another question,
but the real linkage to TLS1.3 here is that if any of these
bad ideas did achieve more that forcing us to oppose them, and
the WG went mad and adopted any of it, then that would surely
and fully muck up TLS1.3 and DTLS1.3, both in terms of timing
and I believe in terms of utility. (Who'd want a new TLS version
that's designed as broken?)

S.

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

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 
draft-rhrd-tls-tls13-visibility, in the same way that some enterprises 
today use middleboxes to inspect all outgoing traffic.


This browser that students would be required to use would be one that 
has a CA controlled by the middlebox installed as a trust anchor. 
Whenever one of the students' clients tries to connect to an external 
secure site, the middlebox-controlled CA issues a certificate for that 
site so that the connection can be terminated at the middlebox. The 
middlebox then establishes a secure connection with the end server, thus 
setting up the middlebox as a MiTM.


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 to, and only expert users would notice the presence of the MiTM.


Given that such an effective and simple-to-implement solution is already 
available today, why would these schools be so anxious to use a 
complicated-to-implement and largely ineffective solution such as 
subverting draft-rhrd-tls-tls13-visibility for improper purposes?


On 10/24/2017 03:36 PM, 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 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.

Think of the children.

We can’t just let them loose on the Internet, there’s predators out there. So 
we will snoop on their traffic.  To do that, we block all traffic that isn’t 
snoopable, and we do it at the edge router in schools.  All schools in our 
state are required by law to install a firewall that does this. And we get the 
mobile operators to do so as well (only for handsets in schools).

Now either the mobile OS vendors make a browser that works in schools (at least 
with a setting), or the school recommends a third party browser that works in 
school. And best of all, this is *more secure* than regular TLS 1.3, because it 
also protects your children from Internet predators. Think of the children.

You can’t make a claim like that for an HTTP-only browser, and worse still, it 
won’t work on much of today’s Internet.

Yoav



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

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 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.
> 
> Think of the children.
> 
> We can’t just let them loose on the Internet, there’s predators out there. So 
> we will snoop on their traffic.  To do that, we block all traffic that isn’t 
> snoopable, and we do it at the edge router in schools.  All schools in our 
> state are required by law to install a firewall that does this. And we get 
> the mobile operators to do so as well (only for handsets in schools).
> 
> Now either the mobile OS vendors make a browser that works in schools (at 
> least with a setting), or the school recommends a third party browser that 
> works in school. And best of all, this is *more secure* than regular TLS 1.3, 
> because it also protects your children from Internet predators. Think of the 
> children.
> 
> You can’t make a claim like that for an HTTP-only browser, and worse still, 
> it won’t work on much of today’s Internet.

Just to note that the only substantive difference between
draft-green and this is the please-screw-me extension in
the ClientHello and Yoav's argument above (with or without
all the obvious corollaries/variations) destroys that as
a defence for your latest effort to square this circle. (This
has been stated at least a couple of times/ways already.)

If you Ralph or Russ have some new arguments for your draft
that have not been countered already or wrt draft-green
then I wish you would raise those, because I've not seen any
that have survived. And if you have no such arguments then
I think it'd be a fine thing to admit that truth openly.

The underlying idea remains as bad as ever, for all the
reasons I tried to summarise at [1] (to which I'll add Yoav's
description above when I get a chance as it's a nice
illustration).

S.

[1] https://github.com/sftcd/tinfoil

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



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

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

More likely the client would be failed with one that just automatically 
negotiates the visibility extension, because that's easier and quicker.

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

I don't think it's necessary to demonstrate that, because the browser that 
implements this extension will just automatically negotiate it.

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

There's no fig leaf of security if you allow connections with no TLS.

The problem with these proposals generally is that they push us in the 
direction of picking and choosing who we will allow to eavesdrop on us, and 
make it non-negotiable in order to access services we want.   You and I are 
smart enough to say "no" when presented with this choice; unfortunately, at 
least at present, many people are not, and see things like browser security 
warnings as annoyances.   This is why UAC failed in Windows Vista, and why 
Vista was widely reviled for its poor usability.

It is demonstrably the case that users will say yes to things that are not in 
their self interest to get to the resources they want.   Every time I visit my 
mom, she has new malware installed on her Chromebook that I removed on my 
previous visit.

So if we do not say no to this, it's likely that ultimately not enough people 
will, and a lot of end users will suffer as a result, some of them operating 
things we'd like to remain secure.   That is the discussion we should be having 
right now.

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

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

2017-10-24 Thread Yoav Nir

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

Think of the children.

We can’t just let them loose on the Internet, there’s predators out there. So 
we will snoop on their traffic.  To do that, we block all traffic that isn’t 
snoopable, and we do it at the edge router in schools.  All schools in our 
state are required by law to install a firewall that does this. And we get the 
mobile operators to do so as well (only for handsets in schools).

Now either the mobile OS vendors make a browser that works in schools (at least 
with a setting), or the school recommends a third party browser that works in 
school. And best of all, this is *more secure* than regular TLS 1.3, because it 
also protects your children from Internet predators. Think of the children.

You can’t make a claim like that for an HTTP-only browser, and worse still, it 
won’t work on much of today’s Internet.

Yoav

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

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 ability.   The 
idea of having a plaintext signal that allows intermediaries to force users 
into weakening their security seems to go against the very grain of what TLS 
tries to do.


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

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
> https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 
>  and 
> expect to discuss this in Singapore. No one and we mean no one should delay 
> submitting a PR related to TLS1.3 or any other WG draft because of this 
> discussion. You’ll note that others have recently, you should follow suit.

Perhaps not.   I don't feel qualified to judge.   But it's delaying other work, 
because people who could be doing useful work in the IETF are engaging on this 
topic instead.   No discussion is without cost, so there is value in cutting 
off useless discussion, and it is very much your job to do so.   E.g., this was 
about a half hour of my time, and I have a bunch of other things to do before 
the draft submission cutoff that I didn't do so that I could respond to this.

> In Prague, we had a discussion of draft-green and there was neither consensus 
> to work in this area nor to decline to work in this area.  In addition to the 
> comments that we should simply decline all such work, the authors received 
> technical comments about their approach and draft-rhrd seems to be an attempt 
> to address some of those comments.  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.

The problem with this is that technical comments about a bad idea just improve 
the bad idea.   The discussion we have been trying to have with the proponents 
of this idea is the question of whether or not it is a bad idea, not about the 
technical details.   I say this as someone who has proposed lots of bad ideas 
in the past.   When I propose a bad idea, and for example Dave Oran points out 
something obvious that I missed (true story), my response to this is to 
reconsider what I've proposed to do and to see if there is a better way to 
solve the problem, not to continue pushing for the idea that has been shown to 
be a bad idea.

Our objection here, which I third or fourth, is that this discussion has not 
progressed that way.   This is clearly a bad idea.   Maybe you don't agree.   
But we've said why it's clearly a bad idea, and that is something that could 
have been discussed.   But none of the proponents of this idea have made any 
attempt to address the substantive objections that have been raised about the 
idea itself.

So it's not really fair to say that progress is being made.   Progress is being 
made on refining the bad idea, but no progress has been made in discussing ways 
to solve the problem that aren't a bad idea.   To be clear, I and several 
others have proposed ways of solving this problem that are not bad ideas.   
These have been rejected on non-technical grounds.

> Absolutely no decisions will be made about adoption prior to that time, nor 
> prior to a formal call for adoption. In particular, decisions will not be 
> made based on the volume of messages to the mailing list.  It is unnecessary 
> and unproductive to repeat points you have already made just because someone 
> responds to you. You will not be missing out on the chance to make your 
> argument.

This feels like the Overton window shifting due to a false equivalence.   The 
issue here is not that we feel that we will miss out on the chance to make our 
arguments.   It's that we've been making them, and they've been explicitly 
ignored.

> Finally, we would like to remind WG members to keep their messages 
> professional and civil. We have noted a number of recent messages that do not 
> conform to those standards and we will be reaching out to people personally 
> to address those instances.

I believe that I have been personally chastized by another participant for 
responding in a way that was held by that participant to be 
uncivil/unprofessional.   If you agree with that assessment, please communicate 
with me to that effect privately (or publicly, if you prefer, but this 
conversation has really gone on for too long).

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

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

2017-10-24 Thread 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

2017-10-24 Thread 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

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?

> 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

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

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

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

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

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, ultimately, many/most of the servers that the
  passengers connect to will not support it, but some might.


Rich,

You've brought up this example of in-flight WiFi and other
middleboxes on the Internet uses this extension as a means of
coercing individuals into allowing their TLS traffic with servers to
be intercepted, but I fail to see how the scenario is at all
realistic.

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.

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. You
previously said:
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.

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?



  


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

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 me to
have been extremely clear on this draft and on this overall
topic. Personally, given recent traffic, and the clear lack
of consensus to even discuss the basic proposition of snooping,
I can't see agenda time for this as being other that a waste
of time. (Again.)

S.

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

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

2017-10-24 Thread Joseph Salowey

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 publication to resolve some middlebox issues
as described in a recent message from ekr

https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 and
expect to discuss this in Singapore. No one and we mean no one should delay
submitting a PR related to TLS1.3 or any other WG draft because of this
discussion. You’ll note that others have recently, you should follow suit.

In Prague, we had a discussion of draft-green and there was neither
consensus to work in this area nor to decline to work in this area.  In
addition to the comments that we should simply decline all such work, the
authors received technical comments about their approach and draft-rhrd
seems to be an attempt to address some of those comments.  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.

Absolutely no decisions will be made about adoption prior to that time, nor
prior to a formal call for adoption. In particular, decisions will not be
made based on the volume of messages to the mailing list.  It is
unnecessary and unproductive to repeat points you have already made just
because someone responds to you. You will not be missing out on the chance
to make your argument.

Finally, we would like to remind WG members to keep their messages
professional and civil. We have noted a number of recent messages that do
not conform to those standards and we will be reaching out to people
personally to address those instances.

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

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 that it does, but please be explicit.  
Does your proposal enable an attacker (such as a gateway on an airplane or any 
other middlebox between the endpoints) to modify the stream?  Ideally your 
answer – or, better yet, from one of the I-D authors – is yes, no, or I don’t 
know.


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

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

2017-10-24 Thread Ackermann, Michael

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 [mailto:rs...@akamai.com] 
Sent: Tuesday, October 24, 2017 9:30 AM
To: Ackermann, Michael 
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 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 
some technical means (unclear to me) to actually prevent it?

As I used to read in the comics of my youth, 
https://www.urbandictionary.com/define.php?term=good%20lord%21%20choke  I am 
glad that this conversation thread kept going, like a zombie it keeps rising.  
We know have enough knowledge to definitively put a stake through its heart, 
forever.

The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-24 Thread Peter Saint-Andre

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 IETF's processes for dealing with disruptive
> postings.
> 
> Thanks,
> S.
> 
> PS: Your (chairs') silence on the repeated requests to
> close down this discussion is quite puzzling to me.

Section 2 of RFC 7282 is relevant here: "rough consensus is achieved
when all issues are addressed, but not necessarily accommodated". Issues
have been raised (albeit some of them seemingly not well informed about
best industry practices, technical alternatives, practical implications,
or IETF processes), and those issues have been considered, weighed,
addressed, and (IMHO) found to be "in the rough".

+1 to Stephen's request.

Peter

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

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 
some technical means (unclear to me) to actually prevent it?

As I used to read in the comics of my youth, 
https://www.urbandictionary.com/define.php?term=good%20lord%21%20choke  I am 
glad that this conversation thread kept going, like a zombie it keeps rising.  
We know have enough knowledge to definitively put a stake through its heart, 
forever.



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

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

2017-10-24 Thread Hubert Kario

On Tuesday, 24 October 2017 00:40:44 CEST Colm MacCárthaigh wrote:
> 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 and drop the
> > backwards compatibility.In fact, there is already presumed WG
> > consensus for that position, so a strong argument indeed would be needed
> > to shift the boundary from now.  I won't say that no such argument can
> > exist, but I don't think we've seen it yet.
> 
> I don't have too strong an interest in this thread, it's not going
> anywhere, and I don't mind that. But I do want to chime in and point
> out that forward secrecy is not completely on the way in. With STEK
> based 0-RTT, it sounds like many implementors are happy to see user's
> requests, cookies, passwords and other secret tokens protected only by
> symmetric keys that are widely shared across many machines and
> geographic boundaries, with no defined key schedule, usage
> requirements or forward secrecy. Clearly, the consensus has been
> willing to accept that trade-off, and there is definite wiggle room.

which part of the HTTP 0-RTT usage policy does say that that is acceptable?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 demonstrate a breathtaking ignorance of what
they are espousing. After 18 months of this WG dealing
with the "I want my static RSA" pony, I personally think
we are justified in demanding more from those who've been
actively engaged for some time in trying to break TLS and
therefore we ought consider postings such as the above,
or ones containing blatantly false/exaggerated statements
(e.g. about "guarantees" or "using TLS1.2 forever") as
being merely disruptive.

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 IETF's processes for dealing with disruptive
postings.

Thanks,
S.

PS: Your (chairs') silence on the repeated requests to
close down this discussion is quite puzzling to me.

> 
> -Original Message- From: Benjamin Kaduk
> [mailto:bka...@akamai.com] Sent: Monday, October 23, 2017 6:33 PM To:
> Ackermann, Michael ; Tony Arcieri
> ; Adam Caudill  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 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,  what is the solution that
>> your company and others that you reference,  have solved this
>> problem by implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of
> the SSWrapDH1 private key has the cryptographic capability to inject
> traffic and modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any unintended
> receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue
> Cross and Blue Shield Association. 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 

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

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

2017-10-24 Thread Ion Larranaga Azcue

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 visibility for TLS 1.3, but after reading other people's comments on 
this thread, I think there are lots of solutions to provide visibility of the 
encrypted data within internal networks. And if the transition requires work 
and money... Well, security always does.

I side with the people that think we should close this topic and move on (I am 
even wondering if it was a good idea to send this mail and thus fuel the 
discussion). I'm eager to see a final specification of TLS 1.3 and I'm 
currently frustrated with being unable to see the light at the end of the 
tunnel while we are just going round and round the same discussion...

> -Mensaje original-
> De: TLS [mailto:tls-boun...@ietf.org] En nombre de Ackermann, Michael
> Enviado el: martes, 24 de octubre de 2017 1:31
> Para: Benjamin Kaduk ; Tony Arcieri
> ; Adam Caudill 
> 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.
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:bka...@akamai.com]
> Sent: Monday, October 23, 2017 6:33 PM
> To: Ackermann, Michael ; Tony Arcieri
> ; Adam Caudill 
> 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 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,  what is the solution that your
> > company and others that you reference,  have solved this problem by
> > implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
> SSWrapDH1 private key has the cryptographic capability to inject traffic and
> modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly confidential and is
> intended solely for the use of the individual(s) to whom this communication
> is directed. If you are not the intended recipient, you are hereby notified
> that any viewing, copying, disclosure or distribution of this information is
> prohibited. Please notify the sender, by electronic mail or telephone, of any
> unintended receipt and delete the original message without making any
> copies.
> 
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
> ___
> 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

2017-10-23 Thread Tony Arcieri

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. Using the term “MitM” for a passive network observer, particularly
one which can decrypt traffic, is perfectly apt.

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

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

2017-10-23 Thread Blumenthal, Uri - 0553 - MITLL

Who cares about the objective? People are asking about the result.

Regards,
Uri

Sent from my iPhone

> On Oct 23, 2017, at 19:32, 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.  
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:bka...@akamai.com] 
> Sent: Monday, October 23, 2017 6:33 PM
> To: Ackermann, Michael ; Tony Arcieri 
> ; Adam Caudill 
> 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 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,  what is the solution that your 
>> company and others that you reference,  have solved this problem by 
>> implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
> SSWrapDH1 private key has the cryptographic capability to inject traffic and 
> modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the individual(s) to whom this communication 
> is directed. If you are not the intended recipient, you are hereby notified 
> that any viewing, copying, disclosure or distribution of this information is 
> prohibited. Please notify the sender, by electronic mail or telephone, of any 
> unintended receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
> nonprofit corporations and independent licensees of the Blue Cross and Blue 
> Shield Association.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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.  

-Original Message-
From: Benjamin Kaduk [mailto:bka...@akamai.com] 
Sent: Monday, October 23, 2017 6:33 PM
To: Ackermann, Michael ; Tony Arcieri 
; Adam Caudill 
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 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,  what is the solution that your 
> company and others that you reference,  have solved this problem by 
> implementing?

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic and 
modify plaintext for the affected connections?

-Ben

The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Colm MacCárthaigh

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 and drop the
> backwards compatibility.In fact, there is already presumed WG
> consensus for that position, so a strong argument indeed would be needed
> to shift the boundary from now.  I won't say that no such argument can
> exist, but I don't think we've seen it yet.

I don't have too strong an interest in this thread, it's not going
anywhere, and I don't mind that. But I do want to chime in and point
out that forward secrecy is not completely on the way in. With STEK
based 0-RTT, it sounds like many implementors are happy to see user's
requests, cookies, passwords and other secret tokens protected only by
symmetric keys that are widely shared across many machines and
geographic boundaries, with no defined key schedule, usage
requirements or forward secrecy. Clearly, the consensus has been
willing to accept that trade-off, and there is definite wiggle room.

-- 
Colm

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

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

2017-10-23 Thread Benjamin Kaduk

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,  what is the solution that your
> company and others that you reference,  have solved this problem by
> implementing?   

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic
and modify plaintext for the affected connections?

-Ben

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

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

2017-10-23 Thread Benjamin Kaduk

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 these, as well as older versions.

This seems sufficiently hypothetical so as to be non-actionable.

That is, I assume that any sufficiently large enterprise must have some
sort of architecture review process before a new system is deployed (and
if one does not, it seems highly unlikely to be secure).  There would
need to be some resolution of the conflict between those parties
"requiring" monitorability and those parties "requiring" TLS 1.3 before
such a system could get approved and approach deployment, so I feel
obligated to insert "require" into scare quotes and attribute no real
meaning to the statement.

As was stated previously, this is a case of being stuck between a rock
and a hard place.  While it is reasonable to investigate changing both
of the rock and the hard place, it seems unwise to presume that it is
one or the other specifically that must change.  You assert in a
different message that it would be very expensive and time consuming to
change "virtually every platform and application, not to mention all the
management, monitoring, and security platforms" (e.g., the "hard
place"), and I do not disagree.  It would also be expensive and time
consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the
way(s) being proposed; unfortunately, the error bars on this cost
estimate are necessarily quite large so as to take into account the risk
of catastrophic breakdown of the security of the Internet.   It seems
pretty clear that various parties involved in this conversation are
applying different metric functions to weight these various costs, which
makes it hard to see a path that would appease everyone.

In that same "different message" you also mention that you have come to
expect backwards compatibility, but can you really expect backwards
compatibility without limit?  Does Windows 10 run MS-DOS executables? 
Can a Kerberos principal who last set their password using Kerberos 4
expect to interoperate in a modern Kerberos 5 deployment?  Can you still
log into a shell server via telnet?  There are many arguments in support
of backwards compatibility, but they are not universal, and history
provides plenty of precedent for security eventually overriding
backwards compatibility.  So where would you put the boundary on the
backwards compatibility for static RSA in TLS or equivalent
non-forward-secrecy mechanisms?  Would you propose infinite
compatibility in this space with no bound?  Ten years from now?  When a
quantum computer can quickly factor 2048-bit RSA keys?  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 and drop the
backwards compatibility.    In fact, there is already presumed WG
consensus for that position, so a strong argument indeed would be needed
to shift the boundary from now.  I won't say that no such argument can
exist, but I don't think we've seen it yet.

-Ben

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

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

This can be solved without changes to the protocol or a standardized “backdoor” 
- and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, 
in the payments business no less, I would like to restate that it's incredibly 
disingenuous to cite the need for self-MitM capability as an "industry" concern.

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,  what is the solution that your company and others that you reference,  
have solved this problem by implementing?




From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tony Arcieri
Sent: Monday, October 23, 2017 5:43 PM
To: Adam Caudill 
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 
mailto:a...@adamcaudill.com>> 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 that in 
fact require TLS 1.2 with PFS, as they made the investment in addressing this 
issue early on, and do so effectively. This can be solved without changes to 
the protocol or a standardized “backdoor” - and is being done today by at least 
some enterprises.

Having worked (and presently working) for more than one company of this nature, 
in the payments business no less, I would like to restate that it's incredibly 
disingenuous to cite the need for self-MitM capability as an "industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find the 
field divided between those who have invested in a real observability story, 
and those who think passive network traffic collection is the only way to debug 
their systems. I think if you were to even take a straw poll of the best 
approaches monitoring/observability among actual industry practitioners, 
passive network traffic collection would rank close to the bottom of the list.

I would go as far as to say that if you are among those requesting this 
misfeature, you are doing a terrible job securing your infrastructure, and 
should look into modern observability techniques as an alternative to debugging 
by concentrating network traffic dumps into a single point of compromise which 
represents a huge security liability. Yes, switching to a new approach to 
observability is a huge investment that will take time, but so is upgrading to 
a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM 
misfeature and could be actively harmed by it, and while a self-MitM capability 
may be standard operating practice for some, it is not true for all, and 
identifying those who want the self-MitM capability as "industry" is a 
composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not 
listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the 
rest of us less secure at the request of those who are running insecure 
infrastructures and apparently intend on keeping things that way.


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Tony Arcieri

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 that
> in fact require TLS 1.2 with PFS, as they made the investment in addressing
> this issue early on, and do so effectively. This can be solved without
> changes to the protocol or a standardized “backdoor” - and is being done
> today by at least some enterprises.
>

Having worked (and presently working) for more than one company of this
nature, in the payments business no less, I would like to restate that it's
incredibly disingenuous to cite the need for self-MitM capability as an
"industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find
the field divided between those who have invested in a real observability
story, and those who think passive network traffic collection is the only
way to debug their systems. I think if you were to even take a straw poll
of the best approaches monitoring/observability among actual industry
practitioners, passive network traffic collection would rank close to the
bottom of the list.

I would go as far as to say that if you are among those requesting this
misfeature, you are doing a terrible job securing your infrastructure, and
should look into modern observability techniques as an alternative to
debugging by concentrating network traffic dumps into a single point of
compromise which represents a huge security liability. Yes, switching to a
new approach to observability is a huge investment that will take time, but
so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM
misfeature and could be actively harmed by it, and while a self-MitM
capability may be standard operating practice for some, it is not true for
all, and identifying those who want the self-MitM capability as "industry"
is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF
is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the
rest of us less secure at the request of those who are running insecure
infrastructures and apparently intend on keeping things that way.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Adam Caudill

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
directed to completing the work this group was chartered to do. There’s no
indication that there will be any consensus on moving forward with any such
document in this group, and I don’t think that will change any time soon.

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 that
in fact require TLS 1.2 with PFS, as they made the investment in addressing
this issue early on, and do so effectively. This can be solved without
changes to the protocol or a standardized “backdoor” - and is being done
today by at least some enterprises.

I understand that this complicates the work that some do, and will mean
additional engineering or spending to deal with it, when they eventually
move to TLS 1.3; that said, I don’t think their decision to take the easy
route in traffic inspection and ignore the evolution of 1.3 till the last
moment should lead to adding new risk to every other TLS user, especially
those that invested in long term solutions that deal with these changes.

I’m of the opinion that this discussion is no longer productive; there’s no
indication that there will be consensus on this or similar documents, good
faith efforts have been made to offer alternatives - in multiple
discussions, it’s distracting from the work of completing 1.3. To me, the
most logical thing to do is move on, finish the work on 1.3, and then
reevaluate (not that I expect consensus to emerge then either).


-- 

--*Adam Caudill*
http://adamcaudill.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

 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 these, as well as older versions.  

-Original Message-
From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Friday, October 20, 2017 12:57 PM
To: Ackermann, Michael ; Stephen Farrell 
; Darin Pettis ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

So it sounds like we are in agreement that continuing to use TLS 1.2 is not 
a viable long term  alternative.  

Long-term is a subjective term, and using it can lead to misunderstandings.

Based on current and previous actions around SSL and TLS versions, you can use 
TLS 1.2 for at least five, likely at least 10, years.

The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

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

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, because you are caught between a rock (the IETF) and a hard 
place (management that won't listen).

> I would put the comment  that anyone or any industry is attempting to lay 
> costs for anything off on IETF,  in the same unfortunate bucket. 

By "we" I mean users of the Internet, not the IETF.  The IETF doesn't have deep 
pockets.

> These types of subjectively negative statements are not at all constructive, 
> germane nor worthy of response.

That's fine.   We would all like for this conversation to end.   My 
"subjectively negative statements" were just explaining to you why you aren't 
making any headway in the working group in trying to get the outcome you seek.

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

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

  *   I would put the comment  that anyone or any industry is attempting to lay 
costs for anything off on IETF,  in the same unfortunate bucket.

Do I misunderstand what you meant by this comment?
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.

Or this one?
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.

Or this one?
I believe his point was that because we do not move quickly,  
we need to prepare as much in advance as possible, and assure that the base 
protocols we know we will be using in the future,  do not put us in the 
position of having to do things that are generally not possible,  such as make 
significant application or protocol changes.


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

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

To suggest that I or my industry does not take security seriously, is 
inaccurate and immaterial to this discussion.

I would put the comment  that anyone or any industry is attempting to lay costs 
for anything off on IETF,  in the same unfortunate bucket.

These types of subjectively negative 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 
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael 
mailto:mackerm...@bcbsm.com>> wrote:
The WHY you ask is in the answer.
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 necessary,  it is because the new version of the 
existing protocol is not backwards compatible,  which is something we have come 
to expect.

I really tried to have sympathy for you about this in Prague.   I know what 
it's like to get unreasonable pushes from management (not based on recent 
experience, fortunately).   But this exact form of reasoning is why we're 
suffering from attacks on the internet like the Mirai botnet and the Reaper 
botnet, the Equifax hack, et cetera.

You have come to a group of people who take these issues extremely seriously 
and asked them to bless you in going forward to create another problem of the 
same magnitude.   I know you don't think that's what you're asking, but that 
really is what you are asking.   It might not be on your network—maybe you will 
operate this technology securely.   But you are asking us to create an attack 
surface, and it will be used.

When you make requests like this, what you are really doing is pushing off 
costs your management doesn't want to pay on the users of the Internet as a 
whole.   130 million Americans are now doomed for life to suffer from attacks 
on their credit because of this kind of thinking.

Stop asking us to take security less seriously, and start taking it more 
seriously.   You work for BCBS: you are responsible for protecting the privacy 
of a similar number of Americans.   I know this is hard, but it's time to stop 
imagining that you can lay costs off on us and start planning how you are going 
to migrate to a more secure architecture.



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Blumenthal, Uri - 0553 - MITLL

For the chairs: I second Stephen’s request. Enough is enough.
--
Regards,
Uri Blumenthal

On 10/23/17, 13:54, "TLS on behalf of Stephen Farrell"  wrote:

 On 23/10/17 18:30, Ackermann, Michael wrote: …

The arguments did not convince before, and will not convince now.

They did not garner rough consensus before and I'm pretty happy
from list discussion that they don't seem to be doing so now.

For the chairs:
- *Various people have asked you to call a halt here*.
- *I do so again*.
- Pretty-please even :-)

It seems clear this latest version of the same old bad idea
is going nowhere but /dev/null, as is proper. Please do declare
the discussion done.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Stephen Farrell

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 necessary,  it is because
> the new version of the existing protocol is not backwards compatible,
> which is something we have come to expect.
All of these cost (*) arguments were raised in the draft-green
iteration of this nonsense. None of them are any different when
draft-green is replaced with draft-rehired.

The arguments did not convince before, and will not convince now.

They did not garner rough consensus before and I'm pretty happy
from list discussion that they don't seem to be doing so now.

Why do you insist on wasting the time of the WG? That seems
disruptive to me.

For the chairs:
- Various people have asked you to call a halt here.
- I do so again.
- Pretty-please even :-)

It seems clear this latest version of the same old bad idea
is going nowhere but /dev/null, as is proper. Please do declare
the discussion done.

S.

(*) The arguments here are of course all about moving the
cost to someone else, they are not about reducing costs. The
proponents of moving the cost elsewhere of course never seem
to admit that.

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

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

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael  wrote:
> The WHY you ask is in the answer.  
> 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 necessary,  it is because the new version of 
> the existing protocol is not backwards compatible,  which is something we 
> have come to expect. 

I really tried to have sympathy for you about this in Prague.   I know what 
it's like to get unreasonable pushes from management (not based on recent 
experience, fortunately).   But this exact form of reasoning is why we're 
suffering from attacks on the internet like the Mirai botnet and the Reaper 
botnet, the Equifax hack, et cetera.

You have come to a group of people who take these issues extremely seriously 
and asked them to bless you in going forward to create another problem of the 
same magnitude.   I know you don't think that's what you're asking, but that 
really is what you are asking.   It might not be on your network—maybe you will 
operate this technology securely.   But you are asking us to create an attack 
surface, and it will be used.

When you make requests like this, what you are really doing is pushing off 
costs your management doesn't want to pay on the users of the Internet as a 
whole.   130 million Americans are now doomed for life to suffer from attacks 
on their credit because of this kind of thinking.

Stop asking us to take security less seriously, and start taking it more 
seriously.   You work for BCBS: you are responsible for protecting the privacy 
of a similar number of Americans.   I know this is hard, but it's time to stop 
imagining that you can lay costs off on us and start planning how you are going 
to migrate to a more secure architecture.

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

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 when they ask why this is necessary,  it is because the new version 
of the existing protocol is not backwards compatible,  which is something we 
have come to expect.

You have years to set the right expectation.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

The WHY you ask is in the answer.
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 necessary,  it is because the new version of the 
existing protocol is not backwards compatible,  which is something we have come 
to expect.

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 12:44 PM
To: Ackermann, Michael 
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael 
mailto:mackerm...@bcbsm.com>> wrote:

  1.  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" installations relying on TLS 1.2 would ever switch to TLS 1.3, 
much less that they would do so in any kind of hurry.   You demonstrate why 
with your very next bullet point:

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

If indeed that unmovable mountain, executive management, must be moved in the 
case of switching to TLS 1.3 or in the case of switching to something else, it 
seems obvious to me that it is better to switch to something else.

Can you give me a clear technical reason why that is not preferable?



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Dave Garrett


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 have everyone stop and focus on this, right here. This 
is the crux of everything. It takes effort and resources to upgrade your 
systems, and you don't want to do it. Tough; this is not the TLS WG's 
problem. The job here is to design the most secure protocol possible, 
and weakening things significantly to accommodate legacy methods is not 
a realistic option. Organizations will *always* have to expend effort 
and resources to upgrade to better systems. If that can be reduced 
without affecting security, great, but if not, then you're just going to 
have to accept it. People should not be here arguing against technical 
improvements; they should be with their managers explaining the simple 
reality of the situation. Yeah, I know it's hard to explain to executive 
management that they are not in control here, but they aren't.


I count at least 400+ messages on this list on this one topic. The 
answer is still "no". You're not getting a cheap drop-in replacement for 
your existing insecure use of static RSA keys out of this WG. Fixing 
devil's advocate qualms like whether or not clients have to send an 
extension is not enough to get even a rough consensus. Nontrivial, but 
very much viable, effort and resources will be required to upgrade.


https://en.wikipedia.org/wiki/Technical_debt


Dave

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

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

And this is probably the main point behind all this.  Folks want to make the 
entire Internet less secure (I’ve explained why) so that they can save time and 
money.

But even if that were not the issue, do you think this draft won’t require 
custom work?

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

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" installations relying on TLS 1.2 would ever switch to TLS 1.3, 
much less that they would do so in any kind of hurry.   You demonstrate why 
with your very next bullet point:
> 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.  

If indeed that unmovable mountain, executive management, must be moved in the 
case of switching to TLS 1.3 or in the case of switching to something else, it 
seems obvious to me that it is better to switch to something else.

Can you give me a clear technical reason why that is not preferable?

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

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

2017-10-23 Thread Hubert Kario

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, network effects and be fiscally 
responsible!


 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
> 
> > On Oct 19, 2017, at 13:08, Paul Turner  wrote:
> > 
> > 
> > 
> > 
> >> 
> >> Subverting one CA cuts across a large scale of Internet traffic and might
> >> be
 noticed or can be routed around.
> > 
> > 
> > With respect to "be noticed", forcing clients to opt-in seems like it
> > would clearly be noticed. My understanding was that you were saying that
> > the middlebox could block traffic. That seems in conflict with your
> > statement that they can be "routed around". 
 
> > 
> >> Certificate transparency helps prevent a
> >> single CA from being coerced into misissuance.  
> > 
> > 
> > It seems like a middlebox that is able to deny traffic (has that level of
> > power, would simply use their own CA and force trust of that)
 
> > 
> >> With this extension, someone
> >> doesn’t have to coerce a CA or force victims to trust a new CA.  Instead
> >> they have to gain the cooperation of the origin(s) they are interested
> >> in.>
> > 
> > Gaining the cooperation of the servers (origins) seems relevant. If they
> > get the cooperation of the servers, they can simply get the data directly
> > from them. But, again, they also have to get the cooperation of the
> > clients. 
 
> > If a middlebox has sufficient power to block traffic, force clients into
> > opting in, and coerce servers into opting in, it seems like they have
> > sufficient alternative options that are of equivalent effort ("ease").
 
> > 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

Thanks Rich
I have seen these suggestions previously.
But as numerous messages on this chain, from various people have discussed, 
neither  of those suggestions are viable from an Enterprise Architecture 
planning perspective.


  1.  If staying with TLS 1.2 indefinitely was considered acceptable,  would we 
even be having these discussions?
  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.


From: Salz, Rich [mailto:rs...@akamai.com]
Sent: Monday, October 23, 2017 12:27 PM
To: Ackermann, Michael ; Ted Lemon 
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 
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 and logging infrastructure to report-out the PFS keys 
and use them

Do you need me to post links to my messages?



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 draft-rhrd-tls-tls13-visibility-00 
can be deployed and operated at scale?   :)

In fact, when I went looking at the state of the art for IKE/IPsec after our 
conversation in Prague, I was pleasantly surprised at how usable it is.   I 
don't know if it currently scales up as you suggest, but it certainly can in 
principle.   This is why I'm suggesting that resources be spent doing that, 
rather than in limiting the ability of TLS 1.3 to address its use case, which 
is a different use case.

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

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


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

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 of sharing/escrowing TLS session keys 
with Cisco boxes.

So if we can assume that many of these large enterprises have a mainframe, then 
they have the proofpoints behind their own firewall.

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

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 and logging infrastructure to report-out the PFS keys 
and use them

Do you need me to post links to my messages?

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

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

2017-10-23 Thread 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

I am merely trying to understand if there are any constructive suggestions 
amongst all these discussions, that we should consider.

Your comment was
"It would be better to use a simpler protocol,"

My question back to you was WHAT SIMPLIER PROTOCOL?

If  your answer to my question,  is to refer to Kathleen's document,  then she 
discusses a few things.   If I have to guess which one of those you may be 
referring to,  I will guess IPSEC?
Is this correct?   Are you suggesting we should convert to IPSEC?

If that was stated in any previous correspondence,  I did not see it.

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 11:41 AM
To: Ackermann, Michael 
Cc: Steve Fenter ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael 
mailto:mackerm...@bcbsm.com>> 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 these messages doesn't 
seem to be reflected in the dialog we are having.


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-10-23 Thread Peter Saint-Andre

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 to step forward in a public forum and reveal their 
> internal network structure and their internal security and monitoring 
> practices. This gives the false impression that out of band decryption of TLS 
> is not a big deal. It is in fact mission critical to a significant number of 
> large enterprises.
> 
> 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 least on the 
> enterprise side.  This results in sub-optimal design decisions (from an 
> enterprise perspective), which in this case will break mission critical 
> enterprise monitoring and troubleshooting systems.

The IETF doesn't run private forums behind closed doors. You'd need to
do that kind of work elsewhere (these large enterprises could, of
course, start their own industry forum, where they could work in ways
that the IETF doesn't).

> We've already experienced what a rollout of TLS 1.3 will be like, at more 
> than one enterprise, when certain vendors decided to move Diffie Hellman 
> ciphers to the top of their priority list on a code upgrade. This caused 
> severity one outages of critical monitoring systems. 

It sounds as if different internal teams might not have been
communicating well about the rollout of those new cipher suites.
Operational issues in large enterprises are not a problem that requires
protocol work.

>  This means that critical applications depend on these monitoring systems, 
> and if the monitoring system is down the application is completely down. This 
> is not the outcome we want when TLS 1.3 is rolled out, but it is what we are 
> headed for. Enterprise monitoring should be tested as part of the operational 
> TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should 
> not be approved if enterprise monitoring breaks.

Operational testing is always good, but very strong arguments need to be
made for the latter claim. Among other things, you're adding a new
requirement to the Internet Standards Process, which would necessitate
IETF consensus on changes to RFC 2026!

> The only other option being presented to enterprises is that we continue to 
> run on a TLS spec that is nine years old, and then continue running it until 
> it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 
> standard, but say that enterprises cannot upgrade to it.

There are many options, some of which Kathleen outlined in her blog
post. It's not helpful to say there is just one option when we haven't
fully explored either the problem space or the solution space. And by
"we" I mean especially those who are claiming the need for TLS visibility.

Peter




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

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 these messages doesn't 
seem to be reflected in the dialog we are having.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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