Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Russ,

On 15/03/18 17:29, Russ Housley wrote:
>>> Nalini, why don't you (the consortium) define the standard,
>>> then?
> 
>> Indeed, if a “TLS13-visibility” standard has to be defined, it
>> would make sense for the consortium (rather than the TLS WG) to
>> define it.
> 
> In fact, my mistake that was caught by Martin is exactly the reason
> that we want the experts in the TLS WG to review the document.

Two things:-

1. I disagree with your assertion. Broad review to improve
security is well worthwhile and is a reason to bring work
to the IETF. Figuring out the how to controversially yet
diligently make TLS (or any IETF protocol) *weaker* is not
part of our process, and would IMO be extremely long-term
damaging to the argument that IETF security review is a
benefit of work being done via the IETF's processes.

2. Having had that fairly fundamental error pointed out,
and given the serious amount of analysis done for TLS1.3,
and *not done* for this MitM enabler, (e.g. the >1 snooper
issue has some showstoppers IMO no matter how any MitM
capability proposal tries to tackle or avoid it) - would you
not now agree that your draft is far too far from baked to
be worth the WG's f2f time in London, even if the WG had
consensus to consider the topic, which I think we've all
acknowledged is not the case? (*)

Thanks,
S.

(*) I considered not making this point - it could suit my
arguments better if the WG have a sequence of drafts like
this and draft-green to dismiss I guess but in fairness
and just in case you're now happy to withdraw your request
for a slot, I figured it worth asking, as I continue to
think that the way this topic is being mishandled is a bad
plan for all concerned.

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


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

Doesn’t IETF have a liaison process that is used to work with other standards 
bodies?
And the bigger question, since the ask is essentially for a multi-party 
security protocol: Is TLS WG the right place to discuss this?

Cheers,

Andrei

From: TLS <tls-boun...@ietf.org> On Behalf Of Russ Housley
Sent: Thursday, March 15, 2018 10:29 AM
To: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted


  *   >> Nalini, why don't you (the consortium) define the standard, then?

> Indeed, if a “TLS13-visibility” standard has to be defined, it would make 
> sense for the consortium (rather than the TLS WG) to define it.

In fact, my mistake that was caught by Martin is exactly the reason that we 
want the experts in the TLS WG to review the document.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stan Kalisch]

[top-posted because the bulk of the quoted material really is necessary for 
context]

Hi Nalini,

It seems to me your and Stephen's recollections of events have two essential 
points in common (well, in my view they do) that I'd like to highlight here:

1.  A number of your consortium's parties are, at minimum, reticent to come, or 
are restricted from coming, forward in this large public IETF forum.

2.  Your consortium is trying to prove a negative:  that some fundamental 
feature doesn't exist in the TLS 1.3 draft.  I say "some fundamental feature" 
because I'm not sure those for or opposed can say exactly what that technical 
feature is.  We know it allows the inspection of data, and we know there are 
theories on how that would securely work.

Here, I think, is a substantial part of the problem:  your consortium isn't 
pushing a specific technical feature, and the WG doesn't know specifically who 
they are.  I think this speaks to much of the difficulty the WG has in engaging 
with you regarding the TLS 1.3 and so-called "visibility" drafts.


Thanks,
Stan

> On Mar 15, 2018, at 4:47 AM, nalini elkins  wrote:
> 
> On 15/03/18 00:05, nalini elkins wrote:
> >> There is no question of a smokey back room.
> 
> >I'm sorry to disagree so bluntly, but while I was an
> >AD some of the people involved here requested that I
> >meet them in private to discuss this topic before it
> >had been raised on the list, and without telling me
> >ahead of time who, from what "enterprises," would be
> >in the room looking for what. As an AD I was always
> >happy to meet folks and have quiet discussions about
> >how to engage with the IETF or explore some detail of
> >how to get something done, I definitely did draw a
> >line well before private meetings aiming to overthrow
> >established WG consensus.
> 
> >While that all might be put down to a tactical error
> >in which advice to follow with whom when initially
> >engaging with the IETF, from my POV it was the epitome
> >of a request for a smokey-back room discussion.
> 
> >So yes, I do find that there are questions here about
> >smokey back rooms indeed. 
> 
> 1.  With respect, I contend that you are conflating what happened then with 
> what I am suggesting now.
> 
> 2.  Also, your description of what happened then does not match with my 
> memory.  We may
> have an honest disagreement or recollection of events.  I believe I have the 
> original
> email chain somewhere & can try to find it, if necessary.
> 
> My version of the events is:
> 
> 1.  A couple of years ago, I was involved with some "enterprises" who felt 
> they had an 
> issue with the upcoming TLS1.3 standard.  In particular, the deprecation of 
> RSA.   
> 
> 
> 2.   They were concerned about the reputational risk to their company of 
> speaking
> in a public forum.   (This is a huge issue for many companies.)  Also, they
> were not used to writing Internet Drafts or presenting at an IETF group.
> 
> 
> 3.  I had no experience with such a situation so I was not sure what to do 
> either.
> My own work is in IPPM (if anyone is interested, you can look at my work 
> in RFC8250), so I was not involved with the TLS group very much either. 
> (A situation which has since been corrected.  I now am happy to know 
> many of you quite well.) (Still no claims to being a crypto expert, though!)
> 
> I asked a former Chair of the IETF for advice.  He suggested asking for a 
> session with the leadership of the TLS group under Chatham House rules.
> 
> I did so.
> 
> As I recall, I asked to have a discussion of the issues to see what we should 
> do.
> I never asked for any consensus of the WG to be overturned.  I may be a dim
> bulb but I am not a complete idiot.   I do have some idea of how things work 
> as
> far as WG consensus.
> 
> Again, as I recall, you replied at some length about "subverting the process".
> After a few more somewhat emotional emails back and forth, where I was not 
> able to convey 
> my point adequately or to reach an understanding, I gave up on that route.
> 
> It is completely possible that I did not ask correctly or convey the right 
> information.
> It was a new situation to me & as I say, I was not sure what to do.  I did my 
> best.
> 
> If needed, I can look for the original email chain.
> 
> 
> 4.  Then, I went back to these "enterprises".  They had to go all the way to 
> the
> CEO of their company to get authority to speak publicly.   They did so at 
> the Chicago IETF.
> 
> And, you know what, I am going to do everything I can to help these guys.
> They have a point of view that deserves to be represented.  They have 
> put in a huge amount of time and effort to try to present what they feel
> will be a real problem for their company.  They are not doing it for any
> other reason.
> 
> Again, they are not used to writing Internet drafts.  And, I am not as much
> as help as I could be to them in writing drafts for TLS as that is not where 
> I live, so 

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

My responses for today are all in this message, including a response to Ralph.  
I'm going to try not to engage on this again until tomorrow.

On Mar 14, 2018, at 6:52 PM, nalini elkins  wrote:
> 1.  Multiple standards are likely to diverge.

We don't need multiple standards, so this isn't an issue.   What you need is to 
define the behavior that you need from your TLS implementation to give you the 
visibility that you want.

> 2.  The TLS WG of the IETF has many of the world's experts in defining such 
> protocols.  The years of collective expertise is remarkable.   We want to 
> work with the TLS group not try to recreate it.

Of course, it would be ideal for you if you could get the TLS working group to 
do this work for you.

> 3.   The reason I support the enterprises and their voice in TLS is because I 
> am naive enough to actually believe in the IETF.  I believe that technical 
> truth matters.  That it is not actually the Vendor Engineering Task Force.  
> That is a group of the vendors, by the vendors and for the vendors.   I could 
> see when this whole thing with taking away RSA was happening that correct 
> though it may be, it was going to cause enormous disruption for many, many 
> people in the commercial world.  You may not believe it, but I am actually 
> doing this because I really believe that we need one set of standards that 
> everyone can use.  I want it to be in the TLS WG.  I want the TLS WG to be 
> credible and succeed and I want the IETF to succeed.  I believe that the 
> Internet needs it.

The problem isn't that we don't believe that it will involve significant work 
for you to secure your customer's data.

> 4.  Again, believe it or not, the TLS WG needs the enterprises.  Of course, 
> this is all my opinion only.   These enterprises are a huge group of users of 
> the IETF protocols and TLS in particular.   The feedback of users is 
> irreplaceable.  Who are we building the protocols for if not the users?  
> Sure, there are multiple sets, but these are a very large group.  

This is the crux of the question: who are the users whose needs the TLS working 
group is serving?   Any discussion that doesn't begin by answering this 
question is going to be non-terminal.   I believe it's your position that the 
"user" is the large corporation; an alternate view, which appears to be shared 
by quite a few participants here, is that the user is the end user: the person 
who, if their data security is compromised, will wind up bearing the cost of 
that compromise.

> Enterprises value security and privacy.   They have a different job to do.  
> What they are trying to do is to protect against leakage of data, do fraud 
> monitoring, protect against malware and many other things.   When this gets 
> into the medical arena, it can even be lives.  I don't even see how you can 
> say what you are saying.

None of these applications require changes to TLS 1.3.   If you think they do, 
you need to walk us through your reasoning.  The reason we can say what we are 
saying is that we understand that none of what you have mentioned here requires 
that TLS 1.3 be weakened.

> But, it is a very difficult issue.   If I can use a different analogy, if the 
> City of Monterey built a new sewer system and told me that to connect to it, 
> I had to build a new house, I would scream!

That's a great analogy, but we are talking about software, not houses.   There 
is no technical reason why switching to TLS 1.3 requires you to build a new 
house.   It does require you to update your software, and there is no doubt a 
real cost to that.  There may even be software that you will have to stop 
using.  But any software that you would have to stop using is software you 
already should not be using, because it's not supported.

> I would not agree with that.  People understand that sometimes they have to 
> pay when there are protocol and other changes.  It is a question of if you 
> could do everything that you needed to do to protect your customers even if 
> you re-built your network from the ground up.

I don't think there's any question that if you rebuilt your network from the 
ground up, you could use TLS 1.3.   If you think this is not the case, it would 
help if you could say what precisely stands in the way.

On Mar 14, 2018, at 10:32 PM, Ralph Droms  wrote:
> And there is a name for this sort of labeling - it's called an "ad hominem 
> attack".  I don't believe anyone is employing "consensus by exhaustion".  
> Please don't attach unwarranted labels to honest attempts to explain 
> requirements and develop solutions.

Ralph, the problem is not that these attempts to explain requirements are not 
honest.  It is that until we agree on who we are protecting, talking about 
requirements doesn't really help: the requirements of people who are not our 
priority are interesting, but not important.

And because we are discussing requirements before we 

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

 On 15/03/18 00:05, nalini elkins wrote:
>> There is no question of a smokey back room.

>I'm sorry to disagree so bluntly, but while I was an
>AD some of the people involved here requested that I
>meet them in private to discuss this topic before it
>had been raised on the list, and without telling me
>ahead of time who, from what "enterprises," would be
>in the room looking for what. As an AD I was always
>happy to meet folks and have quiet discussions about
>how to engage with the IETF or explore some detail of
>how to get something done, I definitely did draw a
>line well before private meetings aiming to overthrow
>established WG consensus.

>While that all might be put down to a tactical error
>in which advice to follow with whom when initially
>engaging with the IETF, from my POV it was the epitome
>of a request for a smokey-back room discussion.

>So yes, I do find that there are questions here about
>smokey back rooms indeed.

1.  With respect, I contend that you are conflating what happened then with
what I am suggesting now.

2.  Also, your description of what happened then does not match with my
memory.  We may
have an honest disagreement or recollection of events.  I believe I have
the original
email chain somewhere & can try to find it, if necessary.

My version of the events is:

1.  A couple of years ago, I was involved with some "enterprises" who felt
they had an
issue with the upcoming TLS1.3 standard.  In particular, the deprecation of
RSA.


2.   They were concerned about the reputational risk to their company of
speaking
in a public forum.   (This is a huge issue for many companies.)  Also, they
were not used to writing Internet Drafts or presenting at an IETF group.


3.  I had no experience with such a situation so I was not sure what to do
either.
My own work is in IPPM (if anyone is interested, you can look at my work
in RFC8250), so I was not involved with the TLS group very much either.
(A situation which has since been corrected.  I now am happy to know
many of you quite well.) (Still no claims to being a crypto expert, though!)

I asked a former Chair of the IETF for advice.  He suggested asking for a
session with the leadership of the TLS group under Chatham House rules.

I did so.

As I recall, I asked to have a discussion of the issues to see what we
should do.
I never asked for any consensus of the WG to be overturned.  I may be a dim
bulb but I am not a complete idiot.   I do have some idea of how things
work as
far as WG consensus.

Again, as I recall, you replied at some length about "subverting the
process".
After a few more somewhat emotional emails back and forth, where I was not
able to convey
my point adequately or to reach an understanding, I gave up on that route.

It is completely possible that I did not ask correctly or convey the right
information.
It was a new situation to me & as I say, I was not sure what to do.  I did
my best.

If needed, I can look for the original email chain.


4.  Then, I went back to these "enterprises".  They had to go all the way
to the
CEO of their company to get authority to speak publicly.   They did so at
the Chicago IETF.

And, you know what, I am going to do everything I can to help these guys.
They have a point of view that deserves to be represented.  They have
put in a huge amount of time and effort to try to present what they feel
will be a real problem for their company.  They are not doing it for any
other reason.

Again, they are not used to writing Internet drafts.  And, I am not as much
as help as I could be to them in writing drafts for TLS as that is not
where
I live, so to speak.  If this was an issue in performance metrics, I could
write the drafts for them.  But, this is TLS, so we have to get others to
help.
We have tried as much as we can to follow the process.   We are all
imperfect, we are doing our best.


5.  This issue with people being able to speak publicly is real.  It needs
to
be recognized.  Not everyone works for an academic institution or
companies which support speaking openly about network architecture
issues.

Even some of the network product vendors who are starting to speak
openly on this issue have had to talk to their CEOs before commenting.
Not everyone will go to such lengths.  They will mostly just give up.
Which is unfortunate for everyone.  Including the IETF.

I completely understand why deliberations of something as important
as TLS need to be public and in the open.  I support that.  I am just
saying that there is an important constituency for whom speaking in
an open forum is a real issue.  Frankly, this is why we formed the
"consortium".

Nalini

On Wed, Mar 14, 2018 at 5:13 PM, Stephen Farrell 
wrote:

>
>
> On 15/03/18 00:05, nalini elkins wrote:
> > There is no question of a smokey back room.
>
> I'm sorry to disagree so bluntly, but while I was an
> AD some of the people involved here requested that I
> meet them in private to discuss this topic before 

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

  *   I think the core of the discussion is that no matter how many times I say 
that enterprises are trying to protect their customers, you do not consider 
that a valid use case.

Can you point to a section in the Fenter draft that shows how customers are 
being protected?  I could not find it.  I only found the following: “Ubiquitous 
packet capture and decryption are required for enterprise troubleshooting, and 
without this capability there will be high severity outages that cannot be 
solved in an acceptable time frame.” And throughout the rest of that document 
there is discussion about various types of operational debugging.  Can you tell 
show me where there is a “protect the customer” need, as opposed to “protecting 
the enterprise”?

In my experiences, virtually no enterprise will allow TLS connections from 
Internet to pass through their DMZ.  They terminate at an exterior firewall.  
Are you aware of organizations that would, for example, allow a user or partner 
in front of a browser to open a TLS connection all the way back to an internal 
service endpoint?


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

14 Mar. 2018 г., 22:32 Ralph Droms :

>
> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov 
> wrote:
>
> 13 Mar. 2018 г., 18:38 Ted Lemon :
>
>> One strategy that's very effective for overcoming resistance to bad ideas
>> is to keep pushing the idea until nobody who's resisting it can afford to
>> continue doing so.
>>
>
> There's a name for that tactics, it's called "consensus by exhaustion".
> (On the recent GNSO meeting this was briefly discussed as an issue within
> ICANN.)
>
> And there is a name for this sort of labeling - it's called an "ad hominem
> attack".  I don't believe anyone is employing "consensus by exhaustion".
> Please don't attach unwarranted labels to honest attempts to explain
> requirements and develop solutions.
>

I didn't! Ted has just pointed out that there's some strategy which is by
the way effective under some circumstances, and I've just recalled it has a
name. No labels attached!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ralph Droms]

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

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

- Ralph

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



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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:16, Stephen Farrell wrote:
> Of course some people who are used to MitMing connections will
> have problems and will have to change.

I got an offlist message correcting me about the above.

I do agree that it's odd to describe post-facto decryption
of a TLS session that used RSA key transport (via a copy of
the RSA private key) as a MitM. (The off list message didn't
say "odd" - it said "wrong":-)

It'd have been better if I'd said that all these approaches
*enable* MitM rather than *are* MitMing - even if the holder
of the copy of the RSA private key might never actually mount
an MitM, they always do have the capability to MitM whenever
they choose to do that. The same is true of Russ and Ralph's
draft as well, though of course the on-path nature of that
proposal makes an actual MitM attack more likely I'd guess,
given it requires both the cryptographic and the topological
capability to MitM whereas RSA based schemes only have to
provide the cryptographic capability.

So I accept the correction, it's a fair cop.

That said, I find using the term MitM as a shorthand for all
of the above to be wy more accurate than abusing the word
"visibility" to describe standardising a MitM capability.

S.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

a) Nalini, I haven't posted anything even slightly close to the examples of
offending messages you've just written.

b) Is this the only message of mine that deserves a response?

14 Mar. 2018 г., 19:00 nalini elkins :

> >>One strategy that's very effective for overcoming resistance to bad
>> ideas is to keep pushing the idea until nobody who's resisting it can
>> afford to continue doing so.
>>
>
> >There's a name for that tactics, it's called "consensus by exhaustion".
> (On the recent GNSO meeting this was briefly discussed as an issue within
> ICANN.)
>
>
> Guys, I know it is a lot of fun to talk about how others do not have the
> brains that God gave a termite and that maybe they are even the spawn of
> the devil.
>
> But, let's just use Occam's razor.   Or as I tell my daughter, "if you
> hear hoof beats, it is likely not a zebra, it is a horse".
>
> The simple explanation is that people think they will have serious issues
> with TLS1.3 and actually, TLS1.2 when it is DH only.
>
> Nalini
>
> On Tue, Mar 13, 2018 at 4:45 PM, Artyom Gavrichenkov 
> wrote:
>
>> 13 Mar. 2018 г., 18:38 Ted Lemon :
>>
>>> One strategy that's very effective for overcoming resistance to bad
>>> ideas is to keep pushing the idea until nobody who's resisting it can
>>> afford to continue doing so.
>>>
>>
>> There's a name for that tactics, it's called "consensus by exhaustion".
>> (On the recent GNSO meeting this was briefly discussed as an issue within
>> ICANN.)
>>
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 15/03/18 00:05, nalini elkins wrote:
> There is no question of a smokey back room.

I'm sorry to disagree so bluntly, but while I was an
AD some of the people involved here requested that I
meet them in private to discuss this topic before it
had been raised on the list, and without telling me
ahead of time who, from what "enterprises," would be
in the room looking for what. As an AD I was always
happy to meet folks and have quiet discussions about
how to engage with the IETF or explore some detail of
how to get something done, I definitely did draw a
line well before private meetings aiming to overthrow
established WG consensus.

While that all might be put down to a tactical error
in which advice to follow with whom when initially
engaging with the IETF, from my POV it was the epitome
of a request for a smokey-back room discussion.

So yes, I do find that there are questions here about
smokey back rooms indeed.

S.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

> If your consortium want a multi-party security protocol that does not affect 
> other folks' security as you seem to claim, then that is the obvious route to 
> explore.

+1. It seems that this is at the core of the request. In which case the proper 
solution is to define this multi-party protocol, not to modify TLS for this 
purpose.

Cheers,

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

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

Stephen,

More on other points later. I am getting pretty tired as am jet lagged.

>I am just fine with talking openly on the mailing list, as
>per IETF processes. I see no benefit in smokey back room
>discussions here at all, and only downsides to such.

You know, this issue of side or quiet conversations keeps coming up.   Let
me try to clarify what I feel is a misunderstanding.

In other WGs, we talk to each other sometimes in small groups, sometimes
one to one to try to clarify things.  The result ends up in the draft or
the public email list, as appropriate.

There is no question of a smokey back room.

I remember a while back when I had a lengthy disagreement with someone
which kept not getting resolved, someone (actually, Al Morton - dear sweet
guy!) took me by the scruff of the neck and made the two of us sit down
together with him.  In half an hour, we resolved the point and were able to
continue with the draft.  If we had kept throwing things at each other, as
it is easy to do via email, who knows how long the conflict would have
lasted.  I learned a valuable lesson that day.

So, I am not trying to subvert the process as some seem to imply.   Talking
to each other f2f actually seems to me to be one of the points of
journeying quite so far and spending so much money to come to an IETF
meeting.  (Having said that, the "journeying so far part" or plane trip is
catching up with me!   More tomorrow.)

Nalini









On Wed, Mar 14, 2018 at 4:49 PM, Stephen Farrell 
wrote:

>
>
> On 14/03/18 23:32, nalini elkins wrote:
> > But, it is a very difficult issue.   If I can use a different analogy, if
> > the City of Monterey built a new sewer system and told me that to connect
> > to it, I had to build a new house, I would scream!
>
> Analogies cannot be used to draw conclusions, merely to illustrate.
> That analogy doesn't help illustrate anything for me fwiw.
>
> > TLS is used in many, many places.  The Internet is critical to the
> > businesses of the world.
>
> Yes. Both fine reasons to not mess about with, weaken or
> try break the TLS protocol.
>
> BTW - while you and others may constantly over-claim and
> say your consortium represents "enterprises," I assume you
> do not claim to represent all "business." ;-)
>
> >  You can't just say use something other than
> > TLS.
>
> Yes. I can. Kerberos and IPsec are used within many enterprise
> networks. TLS is not the only tool in the toolbox.
>
> If your consortium want a multi-party security protocol that
> does not affect other folks' security as you seem to claim,
> then that is the obvious route to explore. And that protocol
> needs to be non-interoperable with TLS (maybe even non-confusable
> in some stronger sense) IMO in order to avoid the risks that
> breaking TLS would result in us all taking.
>
> > Or don't use the Internet.  It's not so easy.
>
> I never said that. Why invent something like that?
>
> > I wish we could actually talk to each other quietly and reasonably.  This
> > is a very, very difficult problem.
>
> I am just fine with talking openly on the mailing list, as
> per IETF processes. I see no benefit in smokey back room
> discussions here at all, and only downsides to such.
>
> S.
>
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:32, nalini elkins wrote:
> But, it is a very difficult issue.   If I can use a different analogy, if
> the City of Monterey built a new sewer system and told me that to connect
> to it, I had to build a new house, I would scream!

Analogies cannot be used to draw conclusions, merely to illustrate.
That analogy doesn't help illustrate anything for me fwiw.

> TLS is used in many, many places.  The Internet is critical to the
> businesses of the world. 

Yes. Both fine reasons to not mess about with, weaken or
try break the TLS protocol.

BTW - while you and others may constantly over-claim and
say your consortium represents "enterprises," I assume you
do not claim to represent all "business." ;-)

>  You can't just say use something other than
> TLS.   

Yes. I can. Kerberos and IPsec are used within many enterprise
networks. TLS is not the only tool in the toolbox.

If your consortium want a multi-party security protocol that
does not affect other folks' security as you seem to claim,
then that is the obvious route to explore. And that protocol
needs to be non-interoperable with TLS (maybe even non-confusable
in some stronger sense) IMO in order to avoid the risks that
breaking TLS would result in us all taking.

> Or don't use the Internet.  It's not so easy.

I never said that. Why invent something like that?

> I wish we could actually talk to each other quietly and reasonably.  This
> is a very, very difficult problem.

I am just fine with talking openly on the mailing list, as
per IETF processes. I see no benefit in smokey back room
discussions here at all, and only downsides to such.

S.




0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

 >>Enterprises value security and privacy.   They have a different job to
do.  What they are trying to do is to protect against leakage of data, do
fraud monitoring, protect against malware and many other things.   When
this gets into the medical arena, >>it can even be lives.  I don't even see
how you can say what you are saying.

>>Let me ask you then, what are the use cases you find to be valid?  Saying
that enterprises don't value security and privacy is really not terribly
useful to resolving any discussion.


> Isn't it the core of the discussion though?

I think the core of the discussion is that no matter how many times I say
that enterprises are trying to protect their customers, you do not consider
that a valid use case.

It is not possible to discuss something when the other person does not
think you have a valid point of view.

Nalini



On Wed, Mar 14, 2018 at 4:30 PM, Ryan Sleevi 
wrote:

>
>
> On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins 
> wrote:
>
>>
>>>- > Nalini, why don't you (the consortium) define the standard, then?
>>>
>>>
>>>
>>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
>>> make sense for the consortium (rather than the TLS WG) to define it.
>>>
>>>
>>>
>>> I completely disagree.   Here is why I would not prefer that route:
>>>
>>>
>>>
>>> 1.  Multiple standards are likely to diverge.
>>>
>>>
>>> Take the case of India, we have over 700 dialects.  Many of them started
>>> with the same root language.  It has gotten so villages 10 miles apart
>>> cannot talk to each other.  We use English (a clearly non-native language!)
>>> to communicate.
>>>
>>>
>>> I could see the same happening with TLS and Consortium-TLS.   Not a
>>> happy thought for interoperability.
>>>
>>
>> >Why is there any need for interoperability between TLS and
>> Consortium-TLS? TLS is designed to be secure and reliable, and it's clear
>> that Consortium-TLS finds such goals problematic. Yet I fail to see why
>> that's a problem, since the claimed goal >is that Consortium-TLS would only
>> be used within a single enterprise/datacenter, and thus would never need to
>> interoperate with a world that valued security and privacy.
>>
>>
>> Enterprises value security and privacy.   They have a different job to
>> do.  What they are trying to do is to protect against leakage of data, do
>> fraud monitoring, protect against malware and many other things.   When
>> this gets into the medical arena, it can even be lives.  I don't even see
>> how you can say what you are saying.
>>
>> Let me ask you then, what are the use cases you find to be valid?  Saying
>> that enterprises don't value security and privacy is really not terribly
>> useful to resolving any discussion.
>>
>
> Isn't it the core of the discussion though? Whether the enterprise case -
> which understandably and fundamentally weakens the security assurances,
> both to servers and to clients - is justified, given the ecosystem risk it
> poses? And the specific proposals, as demonstrated, have negative impacts
> both in the design and deployment of TLS.
>
> Given that, and given the ample discussion on-list motivating PFS, and
> given the stated reasoning, it doesn't seem that "inter-protocol
> interoperability" is necessary nor desirable. It's true that enterprises
> don't value the same security and privacy properties that have been
> discussed on the list - we wouldn't be having this discussion if that was
> not the case. This isn't unproductive or not useful - this is based on the
> statements from those advocating for the weakening of security of the
> protocol.
>
> As such, the need for interoperability is not a goal that's supported by
> the discussion to date, and thus the concerns - that TLS and consortium-TLS
> would diverge - does not seem supported by the arguments. So I do hope you
> can answer - why is interoperability between TLS and Consortium-TLS
> necessary, given that the use cases to date of Consortium-TLS state they'll
> be limited to the enterprise or datacenter, for which the only
> interoperability concerns that arise are between devices supporting
> Consortium-TLS, which by speccing in a Consortium as suggested, you could
> resolve?
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

   - >The simple explanation is that people think they will have serious
   issues with TLS1.3 and actually, TLS1.2 when it is DH only.





>They have a problem with a protocol that doesn’t use static-RSA key
exchange.  And they would rather not pay for a solution to that problem.



I would not agree with that.  People understand that sometimes they have to
pay when there are protocol and other changes.  It is a question of if you
could do everything that you needed to do to protect your customers even if
you re-built your network from the ground up.


Nalini


On Wed, Mar 14, 2018 at 4:33 PM, Salz, Rich  wrote:

>
>- The simple explanation is that people think they will have serious
>issues with TLS1.3 and actually, TLS1.2 when it is DH only.
>
>
>
>
>
> They have a problem with a protocol that doesn’t use static-RSA key
> exchange.  And they would rather not pay for a solution to that problem.
>
>
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

  *   The simple explanation is that people think they will have serious issues 
with TLS1.3 and actually, TLS1.2 when it is DH only.


They have a problem with a protocol that doesn’t use static-RSA key exchange.  
And they would rather not pay for a solution to that problem.


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

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

Stephen,

>So it doesn't really help the discussion to claim that
>such-and-such a (set of person(s) is/are good actors - we do
>assume that, but also that there are others who would like
>the same changes to happen who do not share the IETF's goals
>of making Internet security better as far as we can.

You know, I actually find myself in agreement with some of your points (not
all!)

I lived for a number of years in a country which was a military
dictatorship with no freedom of speech.  I am well aware of what some
people who want to hang on to power at all costs and place no value on
human life are prepared to do to others.  And, their power can be
multiplied and further weaponized with the Internet.

I know that you and many others in the TLS WG are saying what you are
saying because you are trying to protect others who cannot protect
themselves.   I know.  I respect that.  I spent two of the happiest years
of my life in sub-saharan Africa in the Peace Corps.  I totally get the
point of view of trying to help people and keep them safe.

But, it is a very difficult issue.   If I can use a different analogy, if
the City of Monterey built a new sewer system and told me that to connect
to it, I had to build a new house, I would scream!

TLS is used in many, many places.  The Internet is critical to the
businesses of the world.   You can't just say use something other than
TLS.   Or don't use the Internet.  It's not so easy.

I wish we could actually talk to each other quietly and reasonably.  This
is a very, very difficult problem.

Nalini






On Wed, Mar 14, 2018 at 4:16 PM, Stephen Farrell 
wrote:

>
>
> On 14/03/18 23:00, nalini elkins wrote:
> > The simple explanation is that people think they will have serious
> > issues with TLS1.3 and actually, TLS1.2 when it is DH only.
>
> Of course some people who are used to MitMing connections will
> have problems and will have to change.
>
> But that does not mean that their problems ought to be solved
> by any change to TLS.
>
> IMO the costs to the broader Internet of breaking TLS like that
> are far too high to optimse for these folks. It's understandable
> that they'd prefer otherwise.
>
> People with such problems should IMO look elsewhere for
> solutions and not be fixated on breaking TLS.
>
> Lastly, bear in mind that even if the people with whom you
> are dealing have the best intentions, there really are people
> who are paid large amounts of money to weaken Internet security
> (see [1] for scant detail of just one country's efforts in
> that regard) and that we have IETF consensus to oppose such
> efforts, as far as it's in the IETF's remit to do so.
>
> So it doesn't really help the discussion to claim that
> such-and-such a (set of person(s) is/are good actors - we do
> assume that, but also that there are others who would like
> the same changes to happen who do not share the IETF's goals
> of making Internet security better as far as we can.
>
> S.
>
> [1] https://en.wikipedia.org/wiki/Bullrun_(decryption_program)
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ryan Sleevi]

On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins 
wrote:

>
>>- > Nalini, why don't you (the consortium) define the standard, then?
>>
>>
>>
>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
>> make sense for the consortium (rather than the TLS WG) to define it.
>>
>>
>>
>> I completely disagree.   Here is why I would not prefer that route:
>>
>>
>>
>> 1.  Multiple standards are likely to diverge.
>>
>>
>> Take the case of India, we have over 700 dialects.  Many of them started
>> with the same root language.  It has gotten so villages 10 miles apart
>> cannot talk to each other.  We use English (a clearly non-native language!)
>> to communicate.
>>
>>
>> I could see the same happening with TLS and Consortium-TLS.   Not a happy
>> thought for interoperability.
>>
>
> >Why is there any need for interoperability between TLS and
> Consortium-TLS? TLS is designed to be secure and reliable, and it's clear
> that Consortium-TLS finds such goals problematic. Yet I fail to see why
> that's a problem, since the claimed goal >is that Consortium-TLS would only
> be used within a single enterprise/datacenter, and thus would never need to
> interoperate with a world that valued security and privacy.
>
>
> Enterprises value security and privacy.   They have a different job to
> do.  What they are trying to do is to protect against leakage of data, do
> fraud monitoring, protect against malware and many other things.   When
> this gets into the medical arena, it can even be lives.  I don't even see
> how you can say what you are saying.
>
> Let me ask you then, what are the use cases you find to be valid?  Saying
> that enterprises don't value security and privacy is really not terribly
> useful to resolving any discussion.
>

Isn't it the core of the discussion though? Whether the enterprise case -
which understandably and fundamentally weakens the security assurances,
both to servers and to clients - is justified, given the ecosystem risk it
poses? And the specific proposals, as demonstrated, have negative impacts
both in the design and deployment of TLS.

Given that, and given the ample discussion on-list motivating PFS, and
given the stated reasoning, it doesn't seem that "inter-protocol
interoperability" is necessary nor desirable. It's true that enterprises
don't value the same security and privacy properties that have been
discussed on the list - we wouldn't be having this discussion if that was
not the case. This isn't unproductive or not useful - this is based on the
statements from those advocating for the weakening of security of the
protocol.

As such, the need for interoperability is not a goal that's supported by
the discussion to date, and thus the concerns - that TLS and consortium-TLS
would diverge - does not seem supported by the arguments. So I do hope you
can answer - why is interoperability between TLS and Consortium-TLS
necessary, given that the use cases to date of Consortium-TLS state they'll
be limited to the enterprise or datacenter, for which the only
interoperability concerns that arise are between devices supporting
Consortium-TLS, which by speccing in a Consortium as suggested, you could
resolve?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

>
>
>- > Nalini, why don't you (the consortium) define the standard, then?
>
>
>
> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
> make sense for the consortium (rather than the TLS WG) to define it.
>
>
>
> I completely disagree.   Here is why I would not prefer that route:
>
>
>
> 1.  Multiple standards are likely to diverge.
>
>
> Take the case of India, we have over 700 dialects.  Many of them started
> with the same root language.  It has gotten so villages 10 miles apart
> cannot talk to each other.  We use English (a clearly non-native language!)
> to communicate.
>
>
> I could see the same happening with TLS and Consortium-TLS.   Not a happy
> thought for interoperability.
>

>Why is there any need for interoperability between TLS and Consortium-TLS?
TLS is designed to be secure and reliable, and it's clear that
Consortium-TLS finds such goals problematic. Yet I fail to see why that's a
problem, since the claimed goal >is that Consortium-TLS would only be used
within a single enterprise/datacenter, and thus would never need to
interoperate with a world that valued security and privacy.


Enterprises value security and privacy.   They have a different job to do.
What they are trying to do is to protect against leakage of data, do fraud
monitoring, protect against malware and many other things.   When this gets
into the medical arena, it can even be lives.  I don't even see how you can
say what you are saying.

Let me ask you then, what are the use cases you find to be valid?  Saying
that enterprises don't value security and privacy is really not terribly
useful to resolving any discussion.

Nalini







On Wed, Mar 14, 2018 at 4:07 PM, Ryan Sleevi 
wrote:

>
>
> On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins 
> wrote:
>
>>
>> All,
>>
>> In London now & back on email:
>>
>>
>>- >> Nalini, why don't you (the consortium) define the standard, then?
>>
>>
>>
>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
>> make sense for the consortium (rather than the TLS WG) to define it.
>>
>>
>>
>> I completely disagree.   Here is why I would not prefer that route:
>>
>>
>>
>> 1.  Multiple standards are likely to diverge.
>>
>>
>> Take the case of India, we have over 700 dialects.  Many of them started
>> with the same root language.  It has gotten so villages 10 miles apart
>> cannot talk to each other.  We use English (a clearly non-native language!)
>> to communicate.
>>
>>
>> I could see the same happening with TLS and Consortium-TLS.   Not a happy
>> thought for interoperability.
>>
>
> Why is there any need for interoperability between TLS and Consortium-TLS?
> TLS is designed to be secure and reliable, and it's clear that
> Consortium-TLS finds such goals problematic. Yet I fail to see why that's a
> problem, since the claimed goal is that Consortium-TLS would only be used
> within a single enterprise/datacenter, and thus would never need to
> interoperate with a world that valued security and privacy.
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:00, nalini elkins wrote:
> The simple explanation is that people think they will have serious
> issues with TLS1.3 and actually, TLS1.2 when it is DH only.

Of course some people who are used to MitMing connections will
have problems and will have to change.

But that does not mean that their problems ought to be solved
by any change to TLS.

IMO the costs to the broader Internet of breaking TLS like that
are far too high to optimse for these folks. It's understandable
that they'd prefer otherwise.

People with such problems should IMO look elsewhere for
solutions and not be fixated on breaking TLS.

Lastly, bear in mind that even if the people with whom you
are dealing have the best intentions, there really are people
who are paid large amounts of money to weaken Internet security
(see [1] for scant detail of just one country's efforts in
that regard) and that we have IETF consensus to oppose such
efforts, as far as it's in the IETF's remit to do so.

So it doesn't really help the discussion to claim that
such-and-such a (set of person(s) is/are good actors - we do
assume that, but also that there are others who would like
the same changes to happen who do not share the IETF's goals
of making Internet security better as far as we can.

S.

[1] https://en.wikipedia.org/wiki/Bullrun_(decryption_program)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ryan Sleevi]

On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins 
wrote:

>
> All,
>
> In London now & back on email:
>
>
>- >> Nalini, why don't you (the consortium) define the standard, then?
>
>
>
> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
> make sense for the consortium (rather than the TLS WG) to define it.
>
>
>
> I completely disagree.   Here is why I would not prefer that route:
>
>
>
> 1.  Multiple standards are likely to diverge.
>
>
> Take the case of India, we have over 700 dialects.  Many of them started
> with the same root language.  It has gotten so villages 10 miles apart
> cannot talk to each other.  We use English (a clearly non-native language!)
> to communicate.
>
>
> I could see the same happening with TLS and Consortium-TLS.   Not a happy
> thought for interoperability.
>

Why is there any need for interoperability between TLS and Consortium-TLS?
TLS is designed to be secure and reliable, and it's clear that
Consortium-TLS finds such goals problematic. Yet I fail to see why that's a
problem, since the claimed goal is that Consortium-TLS would only be used
within a single enterprise/datacenter, and thus would never need to
interoperate with a world that valued security and privacy.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

>
> >>One strategy that's very effective for overcoming resistance to bad
> ideas is to keep pushing the idea until nobody who's resisting it can
> afford to continue doing so.
>

>There's a name for that tactics, it's called "consensus by exhaustion".
(On the recent GNSO meeting this was briefly discussed as an issue within
ICANN.)


Guys, I know it is a lot of fun to talk about how others do not have the
brains that God gave a termite and that maybe they are even the spawn of
the devil.

But, let's just use Occam's razor.   Or as I tell my daughter, "if you hear
hoof beats, it is likely not a zebra, it is a horse".

The simple explanation is that people think they will have serious issues
with TLS1.3 and actually, TLS1.2 when it is DH only.

Nalini


On Tue, Mar 13, 2018 at 4:45 PM, Artyom Gavrichenkov 
wrote:

> 13 Mar. 2018 г., 18:38 Ted Lemon :
>
>> One strategy that's very effective for overcoming resistance to bad ideas
>> is to keep pushing the idea until nobody who's resisting it can afford to
>> continue doing so.
>>
>
> There's a name for that tactics, it's called "consensus by exhaustion".
> (On the recent GNSO meeting this was briefly discussed as an issue within
> ICANN.)
>
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

All,

In London now & back on email:


   - >> Nalini, why don't you (the consortium) define the standard, then?



> Indeed, if a “TLS13-visibility” standard has to be defined, it would make
sense for the consortium (rather than the TLS WG) to define it.



I completely disagree.   Here is why I would not prefer that route:



1.  Multiple standards are likely to diverge.


Take the case of India, we have over 700 dialects.  Many of them started
with the same root language.  It has gotten so villages 10 miles apart
cannot talk to each other.  We use English (a clearly non-native language!)
to communicate.


I could see the same happening with TLS and Consortium-TLS.   Not a happy
thought for interoperability.



2.  The TLS WG of the IETF has many of the world's experts in defining such
protocols.  The years of collective expertise is remarkable.   We want to
work with the TLS group not try to recreate it.



3.   The reason I support the enterprises and their voice in TLS is because
I am naive enough to actually believe in the IETF.  I believe that
technical truth matters.  That it is not actually the Vendor Engineering
Task Force.  That is a group of the vendors, by the vendors and for the
vendors.   I could see when this whole thing with taking away RSA was
happening that correct though it may be, it was going to cause enormous
disruption for many, many people in the commercial world.  You may not
believe it, but I am actually doing this because I really believe that we
need one set of standards that everyone can use.  I want it to be in the
TLS WG.  I want the TLS WG to be credible and succeed and I want the IETF
to succeed.  I believe that the Internet needs it.



4.  Again, believe it or not, the TLS WG needs the enterprises.  Of course,
this is all my opinion only.   These enterprises are a huge group of users
of the IETF protocols and TLS in particular.   The feedback of users is
irreplaceable.  Who are we building the protocols for if not the users?
Sure, there are multiple sets, but these are a very large group.


And, OK, maybe they don't state every need properly, let's try to help
them.   When I was designing products, I didn't expect the customer to come
up with the design for the screen or the code.  They don't have the skills
to do that.  They provide feedback and come up with requirements.  I do the
code design.


Any organism which does not take feedback is not likely to thrive in the
long term.


Again, I am asking everyone to be open to working together.


Nalini





On Tue, Mar 13, 2018 at 11:27 AM, Andrei Popov 
wrote:

>
>- "We" is a consortium of organizations.   I would say over 50 so
>far.  They operate large data centers.   They are in manufacturing,
>insurance, finance, and others.
>
>
>
>- Nalini, why don't you (the consortium) define the standard, then?
>
>
>
> Indeed, if a “TLS13-visibility” standard has to be defined, it would make
> sense for the consortium (rather than the TLS WG) to define it.
>
>
>
> Cheers,
>
>
>
> Andrei
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Peter Bowen]

On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley  wrote:
> Second, using
> TLS1.2 does not technically address the issue.  If the client were to
> exclusively offer DHE-based ciphersuites, then the visibility techniques
> that have been used in the past are thwarted.

I expect this configuration to become more common in the future.  In
November 2017, US NIST published draft SP 800-52 r2
(https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft )
which explicitly disallows all non-DH cipher suites.  The comment
period closed on 1 Feb 2018, and none of the published comments pushed
back on this.  Given that PCI DSS and many other standards refer to
the NIST Special Publications for implementation requirements, I would
not be surprised to see DH-only (including ECDH/ECDHE/DHE) become
prevalent.

Based on the comments from the proponents of the various drafts, it
would seem that this should be a bigger concern than any changes in
TLS 1.3, as it is implementable today.  I highly suspect that the
currently deployed systems will not handle handshakes that only offer
DH suites, right?

Thanks,
Peter

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

>while sure, both TLS 1.0 and TLS 1.2 likely will be removed from those 
> afore-
mentioned libraries at _some_ point, it is disingenuous to suggest it will 
happen in a matter of just few years, especially for the latter of the two 
protocols
  
Absolutely true!

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Hubert Kario]

On Wednesday, 14 March 2018 19:53:21 CET Russ Housley wrote:
> > On Mar 14, 2018, at 8:39 AM, Hubert Kario  wrote:
> > 
> > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote:
> >> Ted:
> >>> There's an easy way to do this, although as a sometime bank security
> >>> geek
> >>> I would strongly advise you to not do it: keep using TLS 1.2.
> >> 
> >> This is a bogus argument.  First, staying with an old protocol version
> >> often leads to locking in unmaintained versions of old software.
> > 
> > this is simply not true, the newest versions of OpenSSL, NSS, GnuTLS and
> > schannel allow you to disable TLS 1.2 and TLS 1.1 protocol support to
> > effectively only support TLS 1.0!
> 
> After TLS 1.3 is approved, I have heard a desire from software maintainers
> to drop support for some of the older versions over time. Support for SSL
> 3.0 has been dropped in some cases, and for good reasons.

there's a long road from "desire to drop support for TLS 1.0", through 
"marking the TLS 1.0 support as deprecated", "making the TLS 1.0 support a 
compile only option" to "removing TLS 1.0 code completely"

while sure, both TLS 1.0 and TLS 1.2 likely will be removed from those afore-
mentioned libraries at _some_ point, it is disingenuous to suggest it will 
happen in a matter of just few years, especially for the latter of the two 
protocols
-- 
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] TLS@IETF101 Agenda Posted

[Ted Lemon]

Perhaps this would be a good time to put in a plug for additional funding
for openssl et al...

On Mar 14, 2018 14:53, "Russ Housley"  wrote:

>
> > On Mar 14, 2018, at 8:39 AM, Hubert Kario  wrote:
> >
> > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote:
> >> Ted:
> >>> There's an easy way to do this, although as a sometime bank security
> geek
> >>> I would strongly advise you to not do it: keep using TLS 1.2.
> >> This is a bogus argument.  First, staying with an old protocol version
> often
> >> leads to locking in unmaintained versions of old software.
> >
> > this is simply not true, the newest versions of OpenSSL, NSS, GnuTLS and
> > schannel allow you to disable TLS 1.2 and TLS 1.1 protocol support to
> > effectively only support TLS 1.0!
>
> After TLS 1.3 is approved, I have heard a desire from software maintainers
> to drop support for some of the older versions over time. Support for SSL
> 3.0 has been dropped in some cases, and for good reasons.
>
> Russ
>
> ___
> 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] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 11:49 PM, Russ Housley  wrote:
> I was trying to separate these two cases.  If the TLS session is terminated 
> at a load balancer, then the client within the load balancer is (as Ted says) 
> under control of the operator.  The operator can include any extensions that 
> it wishes.  If the TLS session is not terminated at a load balancer, then the 
> client needs to opt-in for decryption points in the enterprise data center to 
> get the needed keying material.

I had thought that we had agreement in Prague that this proposal did not 
require special browsers to be widely available in the wild.   If it does, that 
seems like a mildly stronger argument against it, since if the requirement for 
this behavior successfully infects browsers in the wild, the damage done will 
be to connections in addition to the ones that you are trying to wiretap.

Is there still confusion on the question of whether click-through warnings can 
ever be part of an effective user interface design?

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Russ Housley]

 Second, using TLS1.2 does not technically address the issue.  If the client
 were to exclusively offer DHE-based ciphersuites, then the visibility
 techniques that have been used in the past are thwarted.
>>> 
>>> The client in this case is under the control of the operator, so this is a
>>> non-issue.
>> 
>> In some cases, the client in the load balancer is under the control of the
>> enterprise.  In other cases, the client is in the customer browser, and
>> opt-in is very significant.
> 
> When you say customer browser, do you mean the users on the enterprise
> network behind the firewall, all within the control of the enterprise
> that owns the data?  I think this is what is meant since the Internet
> sessions from customers could be terminated at a load balancer on the
> enterprise edge and then this extension may be used between servers
> internal to the enterprise and from what you are saying, browsers as
> well.  Or is the plan for this to be opt-in from the customer external
> to the enterprise (I didn't think that was the case and it would be
> good to clarify).  This distinction would be helpful to know where
> traffic may be intercepted if there were another party that might be
> malicious.

I was trying to separate these two cases.  If the TLS session is terminated at 
a load balancer, then the client within the load balancer is (as Ted says) 
under control of the operator.  The operator can include any extensions that it 
wishes.  If the TLS session is not terminated at a load balancer, then the 
client needs to opt-in for decryption points in the enterprise data center to 
get the needed keying material.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Kathleen Moriarty]

Clarifying question

On Tue, Mar 13, 2018 at 10:55 PM, Russ Housley  wrote:
> Ted:
>
> I do not follow.
>
> This is a bogus argument.
>
>
> I'm pretty sure there's a Monty Python skit about this, so I won't belabor
> the point.
>
>
> I'll avoid asking how many sparrows are needed ;-)
>
> First, staying with an old protocol version often leads to locking in
> unmaintained versions of old software.
>
>
> Right, that's one of the stated goals of this work: to be able to continue
> to use software that the operator can't upgrade.
>
>
> No, the enterprise wants to use maintained server implementations.
>
> Second, using TLS1.2 does not technically address the issue.  If the client
> were to exclusively offer DHE-based ciphersuites, then the visibility
> techniques that have been used in the past are thwarted.
>
>
> The client in this case is under the control of the operator, so this is a
> non-issue.
>
>
> In some cases, the client in the load balancer is under the control of the
> enterprise.  In other cases, the client is in the customer browser, and
> opt-in is very significant.

When you say customer browser, do you mean the users on the enterprise
network behind the firewall, all within the control of the enterprise
that owns the data?  I think this is what is meant since the Internet
sessions from customers could be terminated at a load balancer on the
enterprise edge and then this extension may be used between servers
internal to the enterprise and from what you are saying, browsers as
well.  Or is the plan for this to be opt-in from the customer external
to the enterprise (I didn't think that was the case and it would be
good to clarify).  This distinction would be helpful to know where
traffic may be intercepted if there were another party that might be
malicious.

Thanks,
Kathleen

>
> Russ
>
>
> ___
> 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] TLS@IETF101 Agenda Posted

[Russ Housley]

Ted:

I do not follow.

>> This is a bogus argument.
> 
> I'm pretty sure there's a Monty Python skit about this, so I won't belabor 
> the point.

I'll avoid asking how many sparrows are needed ;-)

>> First, staying with an old protocol version often leads to locking in 
>> unmaintained versions of old software.
> 
> Right, that's one of the stated goals of this work: to be able to continue to 
> use software that the operator can't upgrade.

No, the enterprise wants to use maintained server implementations.

>> Second, using TLS1.2 does not technically address the issue.  If the client 
>> were to exclusively offer DHE-based ciphersuites, then the visibility 
>> techniques that have been used in the past are thwarted.
> 
> The client in this case is under the control of the operator, so this is a 
> non-issue.

In some cases, the client in the load balancer is under the control of the 
enterprise.  In other cases, the client is in the customer browser, and opt-in 
is very significant.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stan Kalisch]

> On Mar 13, 2018, at 6:38 PM, Salz, Rich  wrote:
> 
> The second paragraph talks about how quickly PCI DSS moved. As a 
> counterpoint, how quickly did they move to delay TLS 1.0 when organizations 
> pushed back?   SSL3 was "safe" to remove.  So far they can't even follow 
> industry best practices and remove TLS 1.0!  The last part of the paragraph 
> repeats the previous concern and adds nothing new.

+1.  That paragraph is bizarre and defies explanation.


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

13 Mar. 2018 г., 18:38 Ted Lemon :

> One strategy that's very effective for overcoming resistance to bad ideas
> is to keep pushing the idea until nobody who's resisting it can afford to
> continue doing so.
>

There's a name for that tactics, it's called "consensus by exhaustion". (On
the recent GNSO meeting this was briefly discussed as an issue within
ICANN.)

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

Have any of the folks in the “visibility” camp had discussions with browser 
vendors?  And if so, have any of them said they would support this?

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 6:16 PM, Russ Housley  wrote:
> This is a bogus argument.

I'm pretty sure there's a Monty Python skit about this, so I won't belabor the 
point.

> First, staying with an old protocol version often leads to locking in 
> unmaintained versions of old software.

Right, that's one of the stated goals of this work: to be able to continue to 
use software that the operator can't upgrade.

> Second, using TLS1.2 does not technically address the issue.  If the client 
> were to exclusively offer DHE-based ciphersuites, then the visibility 
> techniques that have been used in the past are thwarted.

The client in this case is under the control of the operator, so this is a 
non-issue.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

So I re-read Steve's document.

>To keep using TLS1.2 has been proposed and discussed many times over the 
> past year or so and is not acceptable for many reasons outlined in Steve 
> Fenters draft.  So I will refer to that, rather than add repetition to the 
> list.  But suffice to say it is well beyond PCI for most Enterprises.  
   
So I re-read Steve's document.  This is what it says about TLS 1.2

   TLS 1.2 [RFC5246] is not a long term option for enterprises.  The RSA
   key exchange is gradually being removed by vendors as a TLS 1.2
   option. For example, mobile devices have been seen to send TLS 1.2
   Client Hello's with no RSA key exchange options.  There is also the
   risk that new vulnerabilities and weaknesses will be discovered with
   TLS 1.2 and/or RSA that will accelerate its removal by other vendors.

   When significant vulnerabilities were found in SSL and early TLS in
   late 2014 (including POODLE), it took the PCI Security Standards
   Council less than a year to require a migration plan away from these
   SSL/TLS versions (PCI Information Supplement: Migrating from SSL and
   Early TLS).  Enterprises are at risk that vulnerabilities could be
   found in TLS 1.2 or in the RSA key exchange, and that PCI will
   require upgrade to TLS 1.3.  There is no guarantee that TLS 1.2 will
   be available many years into the future.

We have an assertion. A general claim that it's being removed, supported by an 
observation that one or more mobile devices only do PFS.  Worries about a 
possible risk being discovered in TLS 1.2 and static-RSA.  That first paragraph 
contains very few facts, doesn't it?

The second paragraph talks about how quickly PCI DSS moved. As a counterpoint, 
how quickly did they move to delay TLS 1.0 when organizations pushed back?   
SSL3 was "safe" to remove.  So far they can't even follow industry best 
practices and remove TLS 1.0!  The last part of the paragraph repeats the 
previous concern and adds nothing new. (To be fair, they are three pages apart.)

So yes, let's discuss in detail why TLS 1.2 isn't acceptable because, from what 
I see, you haven't made the case.


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 6:22 PM, Stephen Farrell  wrote:
> I mean, do you *really* think there's any chance of reaching rough
> consensus on the list for this draft? If not, then ISTM you're
> putting meeting attendees and list participants through a bunch
> of pain for no gain.

It's actually worse than that—it costs us time to do this, and those of us who 
are not given free money to work on stuff like this have to choose between 
billing for work our employers want us to do, or participating in conversations 
like this.  Today this has cost me several billable hours.   When the working 
group is allowed to continue discussing issues like this that are never going 
to get consensus, ad infinitum, we have to choose between participating in the 
discussion, which is just a rehash of the previous discussion, or doing work we 
can get paid for.

One strategy that's very effective for overcoming resistance to bad ideas is to 
keep pushing the idea until nobody who's resisting it can afford to continue 
doing so.   So whether or not to allow this conversation to continue is not 
simply a question of propriety or of protecting the working group's real work, 
although those are important considerations as well.  It really is a violation 
of the spirit of the consensus process to allow conversations like this to just 
go on and on and on and on.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   Second, using TLS1.2 does not technically address the issue.  If the 
client were to exclusively offer DHE-based ciphersuites, then the visibility 
techniques that have been used in the past are thwarted.
  *   Yes, the server cannot use the "tls_visibility" extension unless the 
client offers it.  This is to enable client opt-in.

It looks like both the TLS1.2 solution and “TLS1.3-visibility” depend on the 
client to support certain options…

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Russ Housley]

> On Mar 13, 2018, at 6:21 PM, Andrei Popov  wrote:
> 
> If the client were to exclusively offer DHE-based ciphersuites, then the 
> visibility techniques that have been used in the past are thwarted.
> TLS1.3-visibility will be equally thwarted if the client does not send the 
> empty “tls_visibility” extension, right?
> (Assuming the server chooses to play by the rules, of course.)

Two points:

1) Yes, the server cannot use the "tls_visibility" extension unless the client 
offers it.  This is to enable client opt-in.

2) If the server sends the "tls_visibility" extension without the client first 
offering it, by the normal TLS extension processing rules, the client MUST 
close the connection.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

  *   This is a bogus argument.  First, staying with an old protocol version 
often leads to locking in unmaintained versions of old software.  Second, using 
TLS1.2 does not technically address the issue.  If the client were to 
exclusively offer DHE-based ciphersuites, then the visibility techniques that 
have been used in the past are thwarted.

Yes, exactly, it’s possible with TLS 1.2 now.  Why has that not been a concern?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Joe,

On 13/03/18 16:09, Joseph Salowey wrote:
> Hi Stephen,
> 
> It is not accurate to say that there was consensus to stop discussion of
> this topic in Prague.  

I did not say that.

I said numerous times that there was a clear lack of consensus
in Prague.

Based on the question *you* asked, which was much more general
than one about draft-green, that means that work in this space
is not being undertaken by the WG. I hope we agree on that.

> There are vocal contingents both for an against this
> topic. 
I could quibble there too - Nalini calls her folks a consortium,
and it certainly seems that there were a bunch of them in the room.
AFAIK, there's no well-organised other set of folks, just a bunch
of people who have significant overlapping technical concerns with
proposals to break TLS. But that's an aside.

> We did not have discussion of this draft in Singapore because the
> authors could not make the meeting due to several issues and we did not not
> think it would be appropriate to have a discussion without them present.
> We are going to continue forward and have discussion on this topic in the
> Monday TLS meeting in London.

My problem is that we *did* have significant discussion on the
list (of Russ and Ralph's -00 draft). I can see no way in which
anyone could read that mega-thread and conclude that this draft
is likely to garner rough consensus on the list.

And since the list is the place where we do real work, and we're
not in any case working on this topic as a WG (see above), allocating
a presentation slot for the -01 version of Russ and Ralph's draft
seems to me to be ignoring the WG participants' postings to the list,
and hence violating our processes.

I think you and Sean, as chairs, should have read the thread on
Russ and Ralph's -00 and said whether or not you think it could
achieve rough consensus. That requires no presentation from Russ.

I mean, do you *really* think there's any chance of reaching rough
consensus on the list for this draft? If not, then ISTM you're
putting meeting attendees and list participants through a bunch
of pain for no gain.

Lastly, to be clear: if Nalini's consortium's next set of authors
turn up with yet another attempt, then I would not ask you to
immediately shut down that *list* discussion, but just as in this
case, I would expect you to *not* schedule WG session time for such
a proposal, if significant list discussion has demonstrated that
folks' sets of opinions have not really changed. (Which is pretty
likely, isn't it?) Similarly, if such a proposal hasn't had any
list discussion then I also think it ought not get WG session
time. ISTM, that if you (chairs) don't start to impose that kind
of (normal actually) discipline on these efforts, we risk an
endless round of iterations of this overall discussion.

S.


> 
> 
> On Tue, Mar 13, 2018 at 7:21 AM, Stephen Farrell 
> wrote:
> 
>>
>> Hiya,
>>
>> Just to be clear: I'm still waiting for the chairs and/or
>> AD to explain how the proposed discussion of this draft
>> is consistent with IETF processes, given the results of
>> the discussion in Prague (a very clear lack of consensus
>> to even work on this topic), and the discussion of the
>> -00 version of this late last year. IOW, I don't consider
>> my objection has been answered.
>>
>> In case people haven't got all the mails from last year
>> at the front of their minds, I went through them for you
>> and have provided links and selected quotes below. Yes,
>> the quotes are selected but I think do indicate that the
>> opposition to these ideas is as before. And there were
>> also the usual voices in support of weakening TLS in this
>> manner as well - a read of the thread clearly indicates
>> to me that discussion of this draft in London will, as
>> before, be a divisive waste of time and energy.
>>
>> Chairs: Please drop the agenda item, or explain how any
>> of this fits our process, because I'm just not getting
>> it.
>>
>> Thanks,
>> Stephen.
>>
>>
>> me, "IMO the WG shouldn't touch this terrible proposal with a
>> bargepole."
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24493.html
>>
>> Randy Bush: "there are a lot of us lurkers out here a bit horrified
>> watching this wg go off the rails." (Different thread, but same topic)
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24539.html
>>
>> Uri Blumenthal: "+1 to Stephen"
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24542.html
>>
>> Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24544.html
>>
>> Ion Larranaga Azcue, "I really don't feel confortable with the approach
>> taken in this draft."
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24562.html
>>
>> Hubert Kario: "to be clear: me too" (replying about hating the idea)
>>
>> 

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   If the client were to exclusively offer DHE-based ciphersuites, then the 
visibility techniques that have been used in the past are thwarted.
TLS1.3-visibility will be equally thwarted if the client does not send the 
empty "tls_visibility" extension, right?
(Assuming the server chooses to play by the rules, of course.)

Cheers,

Andrei

From: TLS <tls-boun...@ietf.org> On Behalf Of Russ Housley
Sent: Tuesday, March 13, 2018 3:17 PM
To: Ted Lemon <mel...@fugue.com>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

Ted:

There's an easy way to do this, although as a sometime bank security geek I 
would strongly advise you to not do it: keep using TLS 1.2.

This is a bogus argument.  First, staying with an old protocol version often 
leads to locking in unmaintained versions of old software.  Second, using 
TLS1.2 does not technically address the issue.  If the client were to 
exclusively offer DHE-based ciphersuites, then the visibility techniques that 
have been used in the past are thwarted.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Russ Housley]

Ted:

> There's an easy way to do this, although as a sometime bank security geek I 
> would strongly advise you to not do it: keep using TLS 1.2.

This is a bogus argument.  First, staying with an old protocol version often 
leads to locking in unmaintained versions of old software.  Second, using 
TLS1.2 does not technically address the issue.  If the client were to 
exclusively offer DHE-based ciphersuites, then the visibility techniques that 
have been used in the past are thwarted.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Darin Pettis]

Richard Barnes and Rich Salz,
Thank you for the kind words.   They are much appreciated!  Best of luck to
Rich with the health concerns too.

It’s been an interesting journey with a lot of great folks.  Will reply to
the issues later as I need to head out at the moment.

-Darin


On Tue, Mar 13, 2018 at 2:20 PM nalini elkins 
wrote:

> All,
>
> The time has gotten away from me.   I have to leave for the airport. I am
> taking my daughter to London & need to get us all packed & out of the house.
>
> I will write respond to all at length either from the airport or in London.
>
> Rich, so sorry about your health issues.  My best wishes for a full and
> complete recovery.
>
> Nalini
>
> On Tue, Mar 13, 2018 at 10:39 AM, Salz, Rich  wrote:
>
>>
>>- I am happy to set up an informal session where all can meet and
>>talk quietly.   Not everyone will be there on Sunday but maybe Monday
>>breakfast or during a break?  Just let me know if you are interested & we
>>can make intros.
>>
>>
>>
>> I won’t be there (health issues), but I’ve already turned down such
>> private invites before.
>>
>>
>>
>> Standing up in front of a WG and talking about unpopular topics is hard.
>> As Richard said, kudo’s to USBank (and a BCBS org) for doing so.  But if
>> you’re not willing to do the hard work, then you don’t get to have the IETF
>> address your concerns.
>>
>>
>>
>> I remember saying before that I firmly believe that the main, and
>> unstated, reason for wanting an IETF RFC on this is so that would-be
>> customers can point to vendors and ask for a common solution at a lower
>> price because the ability is now commoditized.  With all due respect to the
>> people involved, I believe that is still the case.
>>
>>
>>
>> I have heard concerns that it is necessary to have a “speedy” solution.
>> Again, I strongly disagree with this. The standard organizations haven’t
>> even made TLS 1.0 illegal yet, as I said last time.  What makes you think
>> that something is needed in under five years?  I asked that question
>> before, too.
>>
>>
>>
>>
>>
>
>
>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
> ___
> 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] TLS@IETF101 Agenda Posted

[Ackermann, Michael]

I will pretty much repeat what I said below.   Significant fundamental 
infrastructure changes,  are very difficult for very large organizations to 
assimilate.   Because of time and resource issues,  large organizations would 
seek to avoid major, overhaul type changes,  wherever possible.The larger 
the organization,  the more ominous such challenges become.   I am sure I am 
not telling you anything you do not already know.  
But,"Not making any changes" does not fall into this category.  
The fact that Enterprises are finally coming to the IETF table,  should be 
sufficient to show the willingness to be involved,  flexible,  compromise and 
yes. change as necessary.  
From the beginning,  many Enterprises have waned nothing more than to have 
their use cases accepted as valid,  by the IETF,  and to collaborate with the 
IETF SMEs,  on crafting optimal solutions.  
I guess I am personally  still naïve enough to believe this can occur.  

To keep using TLS1.2 has been proposed and discussed many times over the past 
year or so and is not acceptable for many reasons outlined in Steve Fenters 
draft.  So I will refer to that, rather than add repetition to the list.  But 
suffice to say it is well beyond PCI for most Enterprises.  



-Original Message-
From: Ted Lemon [mailto:mel...@fugue.com] 
Sent: Tuesday, March 13, 2018 4:28 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: nalini elkins <nalini.elk...@e-dco.com>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 3:20 PM, Ackermann, Michael <mackerm...@bcbsm.com> wrote:
> I think that most Enterprises are not espousing any conversations "how can we 
> avoid making any changes?"

With respect, Michael, when I have conversed with you about this in the past, 
that is precisely what you have asked for.   You do not want to have to change 
your operational methodology, and any change to TLS that forces you to change 
your operational methodology is unacceptable to you.  I understand why that is, 
and I sympathize, but let's please be clear that this is your precise goal.

> But we would seek to avoid unnecessary,  wholesale, infrastructure 
> architectural changes.

There's an easy way to do this, although as a sometime bank security geek I 
would strongly advise you to not do it: keep using TLS 1.2.

Of course, you've also explained why that isn't acceptable to you—you are 
afraid that the payment card industry will eventually force you to use TLS 1.3, 
just as they have, rather ineffectively, tried to insist that you use TLS 1.2.

Now why would they do that?



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] TLS@IETF101 Agenda Posted

[Stan Kalisch]

> On Mar 13, 2018, at 3:20 PM, Ackermann, Michael  wrote:
> 
> I think that most Enterprises are not espousing any conversations "how can we 
> avoid making any changes?"   
> But we would seek to avoid unnecessary,  wholesale, infrastructure 
> architectural changes. 
> We want to stay with standards wherever/whenever possible and keep the number 
> of standards to the lowest common denominator.

*Common* being the pivotal word.


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 3:20 PM, Ackermann, Michael  wrote:
> I think that most Enterprises are not espousing any conversations "how can we 
> avoid making any changes?"

With respect, Michael, when I have conversed with you about this in the past, 
that is precisely what you have asked for.   You do not want to have to change 
your operational methodology, and any change to TLS that forces you to change 
your operational methodology is unacceptable to you.  I understand why that is, 
and I sympathize, but let's please be clear that this is your precise goal.

> But we would seek to avoid unnecessary,  wholesale, infrastructure 
> architectural changes.

There's an easy way to do this, although as a sometime bank security geek I 
would strongly advise you to not do it: keep using TLS 1.2.

Of course, you've also explained why that isn't acceptable to you—you are 
afraid that the payment card industry will eventually force you to use TLS 1.3, 
just as they have, rather ineffectively, tried to insist that you use TLS 1.2.

Now why would they do that?

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ackermann, Michael]

I think that most Enterprises are not espousing any conversations "how can we 
avoid making any changes?"
But we would seek to avoid unnecessary,  wholesale, infrastructure 
architectural changes.
We want to stay with standards wherever/whenever possible and keep the number 
of standards to the lowest common denominator.
That is why Enterprises are finally coming to the IETF.   Hopeful of some 
common ground and collaborative solutions.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, March 13, 2018 1:53 PM
To: nalini elkins <nalini.elk...@e-dco.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 12:37 PM, nalini elkins 
<nalini.elk...@e-dco.com<mailto:nalini.elk...@e-dco.com>> wrote:
"We" is a consortium of organizations.   I would say over 50 so far.  They 
operate large data centers.   They are in manufacturing, insurance, finance, 
and others.

Nalini, why don't you (the consortium) define the standard, then?

The reason I ask is that you are essentially asking us (the security folks) to 
bless something that is pretty obviously a bad idea, and of course we're 
resisting, and we're going to continue to resist.   I don't think you are ever 
going to get consensus on a document in the IETF that says what you want it to 
say.   And this is perfectly fine.   Your consortium can publish its own 
document that says what you want it to say.

Then when this goes badly wrong, it will be your consortium that is 
responsible, not the IETF.   Or if it doesn't go badly wrong, you can claim the 
credit.   But either way, you aren't going to have to keep arguing with us 
about this.   I don't think there's any reason for you to think that the 
argument is going to end in consensus; this is the reason that some of us are 
asking for it to stop.

Also, if what you produce isn't an IETF standard, then a browser can identify 
whether it implements IETF tls 1.3, or business-consortium-wtls-1.0.   We would 
hope that browsers that implement the latter would not exist, and that this 
would be okay for you because you don't actually need this hack in the browser. 
  That's the value of not doing this work in the IETF.

Also, I just wanted to mention a problem with something you said earlier:

We feel that there is also an underlying motivation to help the underdog and 
protect the political dissident.

This is not a correct description of the situation.   TLS security is needed by 
whose information is communiced information over the network when revealing 
that information to an adversary would put them at risk.   When you make TLS 
security weaker, the set of people who is at risk is everyone, and the risks go 
from "twitter account compromised" all the way up to "teen with 'shameful 
secret' commits suicide when outed" or "my aging mom loses her retirement 
savings."

In addition, you are reducing compartmentalization with your keying strategy—in 
order to make communications easily decryptable, you have to have 
broadly-shared keys, and that reduces the amount of compartmentalization that 
TLS can provide between disparate elements in your networks.

We have seen the result of poor compartmentalization on network security—the 
most recent really egregious example being the Equifax, which would have been a 
lot less bad if Equifax had employed the sort of basic compartmentalization 
precautions that the NIST recommends.   Reducing compartmentalization 
inevitably makes it easier for an adversary to infiltrate your network and 
exfiltrate private user data.   Maybe it will never happen if you are careful 
enough.

The point is that your characterization of our objections as being about a 
certain special corner case is simply not an accurate characterization.   What 
you are proposing to do will weaken your network security too, and this 
weakening is quite likely to result in my personal data being compromised.

It would be really great if we could start talking seriously about ways to 
solve your problem, but that conversation can't take the form "how can we avoid 
making any changes?"   When I've tried to have serious conversations with you 
and others in your consortium about how to solve this problem in the past, any 
solution that requires you to implement new technology is always off the table. 
  That's no good.



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 Michiga

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

All,

The time has gotten away from me.   I have to leave for the airport. I am
taking my daughter to London & need to get us all packed & out of the house.

I will write respond to all at length either from the airport or in London.

Rich, so sorry about your health issues.  My best wishes for a full and
complete recovery.

Nalini

On Tue, Mar 13, 2018 at 10:39 AM, Salz, Rich  wrote:

>
>- I am happy to set up an informal session where all can meet and talk
>quietly.   Not everyone will be there on Sunday but maybe Monday breakfast
>or during a break?  Just let me know if you are interested & we can make
>intros.
>
>
>
> I won’t be there (health issues), but I’ve already turned down such
> private invites before.
>
>
>
> Standing up in front of a WG and talking about unpopular topics is hard.
> As Richard said, kudo’s to USBank (and a BCBS org) for doing so.  But if
> you’re not willing to do the hard work, then you don’t get to have the IETF
> address your concerns.
>
>
>
> I remember saying before that I firmly believe that the main, and
> unstated, reason for wanting an IETF RFC on this is so that would-be
> customers can point to vendors and ask for a common solution at a lower
> price because the ability is now commoditized.  With all due respect to the
> people involved, I believe that is still the case.
>
>
>
> I have heard concerns that it is necessary to have a “speedy” solution.
> Again, I strongly disagree with this. The standard organizations haven’t
> even made TLS 1.0 illegal yet, as I said last time.  What makes you think
> that something is needed in under five years?  I asked that question
> before, too.
>
>
>
>
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   "We" is a consortium of organizations.   I would say over 50 so far.  
They operate large data centers.   They are in manufacturing, insurance, 
finance, and others.


  *   Nalini, why don't you (the consortium) define the standard, then?

Indeed, if a “TLS13-visibility” standard has to be defined, it would make sense 
for the consortium (rather than the TLS WG) to define it.

Cheers,

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

On Tue, Mar 13, 2018 at 1:52 PM, Ted Lemon  wrote:
> In addition, you are reducing compartmentalization with your keying
> strategy—in order to make communications easily decryptable, you have to
> have broadly-shared keys, and that reduces the amount of
> compartmentalization that TLS can provide between disparate elements in your
> networks.
>
> We have seen the result of poor compartmentalization on network security—the
> most recent really egregious example being the Equifax, which would have
> been a lot less bad if Equifax had employed the sort of basic
> compartmentalization precautions that the NIST recommends.   Reducing
> compartmentalization inevitably makes it easier for an adversary to
> infiltrate your network and exfiltrate private user data.

+1
And I wonder how come that after all hundreds of discussions the
compartmentalization issue is not addressed properly in draft-fenter.
Because simply stating that "typically, only select groups within an
organization [are able to see decrypted traffic]" doesn't seem enough.

(this is just a single example of an issue with that draft)

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

Yes, I've read all that through, and I've been in Prague, and I still feel
that the problem statement lacks some clarification.

This is, by the way, the reason draft-fenter is published; who would need
that if the reasons all this visibility thing is proposed would have been
transparent for anyone?

вт, 13 мар. 2018 г., 13:39 Sean Turner :

>
>
> > On Mar 13, 2018, at 16:31, Artyom Gavrichenkov 
> wrote:
> >
> > Hi Nalini,
> >
> > вт, 13 мар. 2018 г., 11:59 nalini elkins :
> > The TLS working group has been concentrating on making the Internet
> secure for the individual user.We feel that there is also an underlying
> motivation to help the underdog and protect the political dissident.
> >
> > This isn't about dissidents, this is all about the proper design.
> >
> > This ID helps explain the situation and subsequent need.  If you haven’t
> had a chance to read it yet, please try to do it before the London meeting.
> > https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/
> >
> > I've read this document and have already proposed spawning a separate
> thread discussing that before we'll land in London. Probably even before
> the agenda will be confirmed. Or even better, discussing draft-fenter there
> instead of draft-rhrd.
> >
> > IMO draft-fenter is much more important, because it is a problem
> statement, and it's better to settle on a problem statement before
> discussing solution which is "tls visibility". And, for me, personally, the
> problem statement in draft-fenter is not convincing.
>
> I meant to answer your question: draft-fenter is referred to in Russ’s
> slides it’s not specifically on the agenda.  The chairs have seen the
> slides you haven’t yet (Russ gets a gold start for submitting slides early).
>
> This is not the first time the topic (both the motivations and solutions)
> has been discussed.  This time tracks back to IETF 97.  You can find the
> presentation somewhere on the TLS row:
> https://datatracker.ietf.org/meeting/97/agenda.html
> There was also some discussion in Prague, which can found somewhere near
> the TLS row at:
> https://datatracker.ietf.org/meeting/99/proceedings
>
> There have also been hundreds of message related to this topic that you
> can search for on the list to get a sense (use the search tool with
> something like “datacenter" OR "Data Center" OR draft-green OR RHRD OR
> draft-rhrd OR "Industry Concerns"):
> https://mailarchive.ietf.org/arch/search/?email_list=tls
>
> I hope that folks who come to the session will take the time to review the
> previous discussion.
>
> spt
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 12:37 PM, nalini elkins  wrote:
> "We" is a consortium of organizations.   I would say over 50 so far.  They 
> operate large data centers.   They are in manufacturing, insurance, finance, 
> and others.  

Nalini, why don't you (the consortium) define the standard, then?

The reason I ask is that you are essentially asking us (the security folks) to 
bless something that is pretty obviously a bad idea, and of course we're 
resisting, and we're going to continue to resist.   I don't think you are ever 
going to get consensus on a document in the IETF that says what you want it to 
say.   And this is perfectly fine.   Your consortium can publish its own 
document that says what you want it to say.

Then when this goes badly wrong, it will be your consortium that is 
responsible, not the IETF.   Or if it doesn't go badly wrong, you can claim the 
credit.   But either way, you aren't going to have to keep arguing with us 
about this.   I don't think there's any reason for you to think that the 
argument is going to end in consensus; this is the reason that some of us are 
asking for it to stop.

Also, if what you produce isn't an IETF standard, then a browser can identify 
whether it implements IETF tls 1.3, or business-consortium-wtls-1.0.   We would 
hope that browsers that implement the latter would not exist, and that this 
would be okay for you because you don't actually need this hack in the browser. 
  That's the value of not doing this work in the IETF.

Also, I just wanted to mention a problem with something you said earlier:

> We feel that there is also an underlying motivation to help the underdog and 
> protect the political dissident. 

This is not a correct description of the situation.   TLS security is needed by 
whose information is communiced information over the network when revealing 
that information to an adversary would put them at risk.   When you make TLS 
security weaker, the set of people who is at risk is everyone, and the risks go 
from "twitter account compromised" all the way up to "teen with 'shameful 
secret' commits suicide when outed" or "my aging mom loses her retirement 
savings."

In addition, you are reducing compartmentalization with your keying strategy—in 
order to make communications easily decryptable, you have to have 
broadly-shared keys, and that reduces the amount of compartmentalization that 
TLS can provide between disparate elements in your networks.

We have seen the result of poor compartmentalization on network security—the 
most recent really egregious example being the Equifax, which would have been a 
lot less bad if Equifax had employed the sort of basic compartmentalization 
precautions that the NIST recommends.   Reducing compartmentalization 
inevitably makes it easier for an adversary to infiltrate your network and 
exfiltrate private user data.   Maybe it will never happen if you are careful 
enough.

The point is that your characterization of our objections as being about a 
certain special corner case is simply not an accurate characterization.   What 
you are proposing to do will weaken your network security too, and this 
weakening is quite likely to result in my personal data being compromised.

It would be really great if we could start talking seriously about ways to 
solve your problem, but that conversation can't take the form "how can we avoid 
making any changes?"   When I've tried to have serious conversations with you 
and others in your consortium about how to solve this problem in the past, any 
solution that requires you to implement new technology is always off the table. 
  That's no good.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

  *   I am happy to set up an informal session where all can meet and talk 
quietly.   Not everyone will be there on Sunday but maybe Monday breakfast or 
during a break?  Just let me know if you are interested & we can make intros.

I won’t be there (health issues), but I’ve already turned down such private 
invites before.

Standing up in front of a WG and talking about unpopular topics is hard.  As 
Richard said, kudo’s to USBank (and a BCBS org) for doing so.  But if you’re 
not willing to do the hard work, then you don’t get to have the IETF address 
your concerns.

I remember saying before that I firmly believe that the main, and unstated, 
reason for wanting an IETF RFC on this is so that would-be customers can point 
to vendors and ask for a common solution at a lower price because the ability 
is now commoditized.  With all due respect to the people involved, I believe 
that is still the case.

I have heard concerns that it is necessary to have a “speedy” solution. Again, 
I strongly disagree with this. The standard organizations haven’t even made TLS 
1.0 illegal yet, as I said last time.  What makes you think that something is 
needed in under five years?  I asked that question before, too.


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Sean Turner]

> On Mar 13, 2018, at 16:31, Artyom Gavrichenkov  wrote:
> 
> Hi Nalini,
> 
> вт, 13 мар. 2018 г., 11:59 nalini elkins :
> The TLS working group has been concentrating on making the Internet secure 
> for the individual user.We feel that there is also an underlying 
> motivation to help the underdog and protect the political dissident.
> 
> This isn't about dissidents, this is all about the proper design.
> 
> This ID helps explain the situation and subsequent need.  If you haven’t had 
> a chance to read it yet, please try to do it before the London meeting. 
> https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/
> 
> I've read this document and have already proposed spawning a separate thread 
> discussing that before we'll land in London. Probably even before the agenda 
> will be confirmed. Or even better, discussing draft-fenter there instead of 
> draft-rhrd.
> 
> IMO draft-fenter is much more important, because it is a problem statement, 
> and it's better to settle on a problem statement before discussing solution 
> which is "tls visibility". And, for me, personally, the problem statement in 
> draft-fenter is not convincing.

I meant to answer your question: draft-fenter is referred to in Russ’s slides 
it’s not specifically on the agenda.  The chairs have seen the slides you 
haven’t yet (Russ gets a gold start for submitting slides early).

This is not the first time the topic (both the motivations and solutions) has 
been discussed.  This time tracks back to IETF 97.  You can find the 
presentation somewhere on the TLS row:
https://datatracker.ietf.org/meeting/97/agenda.html
There was also some discussion in Prague, which can found somewhere near the 
TLS row at:
https://datatracker.ietf.org/meeting/99/proceedings

There have also been hundreds of message related to this topic that you can 
search for on the list to get a sense (use the search tool with something like 
“datacenter" OR "Data Center" OR draft-green OR RHRD OR draft-rhrd OR "Industry 
Concerns"):
https://mailarchive.ietf.org/arch/search/?email_list=tls

I hope that folks who come to the session will take the time to review the 
previous discussion. 

spt

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

Re: [TLS] TLS@IETF101 Agenda Posted

[George Palmer]

+1

> On 13 Mar 2018, at 17:23, Eric Rescorla  wrote:
> 
> 
> 
>> On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins  
>> wrote:
>> Stephen (and TLS group)
>> 
>> We need to look at the bigger picture.
>> 
>> The TLS working group has been concentrating on making the Internet secure 
>> for the individual user.We feel that there is also an underlying 
>> motivation to help the underdog and protect the political dissident.  These 
>> are all laudable goals.  
>> 
>> But, the Internet is much more than that.  The Internet is the underpinnings 
>> of much of the business community which is utilized by consumers (end 
>> users).   Making a change which makes businesses less secure because crucial 
>> functions cannot be done will lead to enormous chaos and disruption.   Many 
>> businesses are likely to not want to adopt TLS1.3 or seek unique DIY type 
>> alternatives.  In fact, we have already heard of some planning to block TLS 
>> 1.3 traffic just for this reason. 
> 
> As a break from the meta-discussion about whether this topic should be
> on the agenda, I'd like to make a technical point. There are two
> separate settings where TLS 1.3 makes inspection more difficult:
> 
> 1. Cases where the inspecting entity controls the server and does
>passive inspection: TLS 1.3 mandates PFS and so designs
>which involve having a copy of the server's RSA key won't work
>
> 2. Cases where the inspecting entity controls the client and does
>MITM: TLS 1.3 encrypts the certificate and so conditional
>inspection based on the server cert doesn't work (though see [0]
>for some of the reasons this is problematic.)
> 
> The two drafts under discussion here only apply to case #1 and not to
> case #2. However, for case #1, because you control the server, there's
> no need to look at blocking TLS 1.3, you merely need to not enable it
> on your server, so this framing is a bit confusing.
> 
> 
> -Ekr
> 
> [0] https://www.imperialviolet.org/2018/03/10/tls13.html 
> 
> 
> 
> ___
> 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] TLS@IETF101 Agenda Posted

[Eric Rescorla]

On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins 
wrote:

> Stephen (and TLS group)
>
> We need to look at the bigger picture.
>
> The TLS working group has been concentrating on making the Internet secure
> for the individual user.We feel that there is also an underlying
> motivation to help the underdog and protect the political dissident.  These
> are all laudable goals.
>
> But, the Internet is much more than that.  The Internet is the
> underpinnings of much of the business community which is utilized by
> consumers (end users).   Making a change which makes businesses less secure
> because crucial functions cannot be done will lead to enormous chaos and
> disruption.   Many businesses are likely to not want to adopt TLS1.3 or
> seek unique DIY type alternatives.  In fact, we have already heard of some
> planning to block TLS 1.3 traffic just for this reason.
>

As a break from the meta-discussion about whether this topic should be
on the agenda, I'd like to make a technical point. There are two
separate settings where TLS 1.3 makes inspection more difficult:

1. Cases where the inspecting entity controls the server and does
   passive inspection: TLS 1.3 mandates PFS and so designs
   which involve having a copy of the server's RSA key won't work

2. Cases where the inspecting entity controls the client and does
   MITM: TLS 1.3 encrypts the certificate and so conditional
   inspection based on the server cert doesn't work (though see [0]
   for some of the reasons this is problematic.)

The two drafts under discussion here only apply to case #1 and not to
case #2. However, for case #1, because you control the server, there's
no need to look at blocking TLS 1.3, you merely need to not enable it
on your server, so this framing is a bit confusing.


-Ekr

[0] https://www.imperialviolet.org/2018/03/10/tls13.html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Salz, Rich]

  *   "We" is a consortium of organizations.   I would say over 50 so far.  
They operate large data centers.   They are in manufacturing, insurance, 
finance, and others.

See, I have a bit of a problem with that.  As you should know (since you are a 
Mentor coordinator), participation is on the basis of individuals, not 
corporations or consortia.  Right?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

Rich,


A clarification:


> Well, I’d be fine with a bunch of point solutions that were only sold and
deployed in an enterprise because, as I said last time, this is too risky
for the public Internet.


What I meant about being fine with is a solution INSIDE the enterprise.
But, we need a STANDARD because we need to have multiple vendors implement
it.  And, if there is a problem, then the vendors will point first to that
non-standard solution as being the possible problem - which it certainly
could be!


We need to be able to solve problems for end users rapidly.  Some of our
members provide services to hundreds of thousands or millions of end users,
so uptime is critical.


Nalini


On Tue, Mar 13, 2018 at 9:37 AM, nalini elkins 
wrote:

> *>>* I hope that we can all work together to craft a solution.   We don't
> want fragmentation and multiple DIY solutions.
>
>
>
> > Well, I’d be fine with a bunch of point solutions that were only sold
> and deployed in an enterprise because, as I said last time, this is too
> risky for the public Internet.
>
>
> We would be fine with that also.  We are looking for something only INSIDE
> the enterprise.
>
>
>
> > So then, who is “we”?
>
>
> "We" is a consortium of organizations.   I would say over 50 so far.  They
> operate large data centers.   They are in manufacturing, insurance,
> finance, and others.
>
>
> Nalini
>
>
> On Tue, Mar 13, 2018 at 9:32 AM, Salz, Rich  wrote:
>
>> *>* I hope that we can all work together to craft a solution.   We don't
>> want fragmentation and multiple DIY solutions.
>>
>>
>>
>> Well, I’d be fine with a bunch of point solutions that were only sold and
>> deployed in an enterprise because, as I said last time, this is too risky
>> for the public Internet.
>>
>>
>>
>> So then, who is “we”? ☺
>>
>>
>>
>
>
>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

*>>* I hope that we can all work together to craft a solution.   We don't
want fragmentation and multiple DIY solutions.



> Well, I’d be fine with a bunch of point solutions that were only sold and
deployed in an enterprise because, as I said last time, this is too risky
for the public Internet.


We would be fine with that also.  We are looking for something only INSIDE
the enterprise.



> So then, who is “we”?


"We" is a consortium of organizations.   I would say over 50 so far.  They
operate large data centers.   They are in manufacturing, insurance,
finance, and others.


Nalini


On Tue, Mar 13, 2018 at 9:32 AM, Salz, Rich  wrote:

> *>* I hope that we can all work together to craft a solution.   We don't
> want fragmentation and multiple DIY solutions.
>
>
>
> Well, I’d be fine with a bunch of point solutions that were only sold and
> deployed in an enterprise because, as I said last time, this is too risky
> for the public Internet.
>
>
>
> So then, who is “we”? ☺
>
>
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Melinda Shore]

On 3/13/18 8:09 AM, nalini elkins wrote:
> I agree that the room hummed to "continue the discussion".

This might be a good time to review RFC 7282 ("On Consensus
and Humming in the IETF") so that everybody is more-or-less
on the same page with respect to what a roughly 50/50 split
hum means.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

Hi Nalini,

вт, 13 мар. 2018 г., 11:59 nalini elkins :

> The TLS working group has been concentrating on making the Internet secure
> for the individual user.We feel that there is also an underlying
> motivation to help the underdog and protect the political dissident.
>

This isn't about dissidents, this is all about the proper design.

This ID helps explain the situation and subsequent need.  If you haven’t
> had a chance to read it yet, please try to do it before the London meeting.
> https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/
>

I've read this document and have already proposed spawning a separate
thread discussing that before we'll land in London. Probably even before
the agenda will be confirmed. Or even better, discussing draft-fenter there
instead of draft-rhrd.

IMO draft-fenter is much more important, because it is a problem statement,
and it's better to settle on a problem statement before discussing solution
which is "tls visibility". And, for me, personally, the problem statement
in draft-fenter is not convincing.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Joseph Salowey]

Hi Stephen,

It is not accurate to say that there was consensus to stop discussion of
this topic in Prague.  There are vocal contingents both for an against this
topic.  We did not have discussion of this draft in Singapore because the
authors could not make the meeting due to several issues and we did not not
think it would be appropriate to have a discussion without them present.
We are going to continue forward and have discussion on this topic in the
Monday TLS meeting in London.


On Tue, Mar 13, 2018 at 7:21 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> Just to be clear: I'm still waiting for the chairs and/or
> AD to explain how the proposed discussion of this draft
> is consistent with IETF processes, given the results of
> the discussion in Prague (a very clear lack of consensus
> to even work on this topic), and the discussion of the
> -00 version of this late last year. IOW, I don't consider
> my objection has been answered.
>
> In case people haven't got all the mails from last year
> at the front of their minds, I went through them for you
> and have provided links and selected quotes below. Yes,
> the quotes are selected but I think do indicate that the
> opposition to these ideas is as before. And there were
> also the usual voices in support of weakening TLS in this
> manner as well - a read of the thread clearly indicates
> to me that discussion of this draft in London will, as
> before, be a divisive waste of time and energy.
>
> Chairs: Please drop the agenda item, or explain how any
> of this fits our process, because I'm just not getting
> it.
>
> Thanks,
> Stephen.
>
>
> me, "IMO the WG shouldn't touch this terrible proposal with a
> bargepole."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24493.html
>
> Randy Bush: "there are a lot of us lurkers out here a bit horrified
> watching this wg go off the rails." (Different thread, but same topic)
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24539.html
>
> Uri Blumenthal: "+1 to Stephen"
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24542.html
>
> Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24544.html
>
> Ion Larranaga Azcue, "I really don't feel confortable with the approach
> taken in this draft."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24562.html
>
> Hubert Kario: "to be clear: me too" (replying about hating the idea)
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24578.html
>
> Rich Salz: "I am opposed to the basic concept of injecting a third-party
> into the E2E TLS process."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24585.html
>
> Florian Weimer: "I don't understand why this complicated approach is
> needed."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24607.html
>
> Ben Kaduk: "I do not see any potential for a workable solution."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24620.html
>
> Uri Blumenthal: "why do we spend time discussing this draft?"
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24639.html
>
> Christian Huitema: "Maybe they have found ways to manage their
> applications and servers without breaking TLS..."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24643.html
>
> Ted Lemon: "I think we should stop."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24649.html
>
> Andrei Popov: "deploying a weakened configuration of TLS 1.3 (without
> PFS) would not meet the intent of those future mandates/requirements."
> (On "industry need")
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24656.html
>
> Ben Kaduk: "The time I am spending on this thread is time that I am not
> able to spend improving the TLS 1.3 document."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24660.html
>
> Dave Garrett: "Please, let's just let this mess die. "
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24667.html
>
> Uri Blumenthal "I'm against weakening the protocol, since there are
> other ways to accomplish the perlustrator's mission"
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24670.html
> Yeah, I had to look it up too:-)
> https://en.oxforddictionaries.com/definition/us/perlustrator
>
> Adam Caudill: "To be honest, I’m rather surprised that this group
> continues to spend time on this."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24712.html
>
> Tony Arcieri, "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."
>
> https://www.ietf.org/mail-archive/web/tls/current/msg24715.html
>
> Colm MacCárthaigh: "I 

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Hiya,

Just to be clear: I'm still waiting for the chairs and/or
AD to explain how the proposed discussion of this draft
is consistent with IETF processes, given the results of
the discussion in Prague (a very clear lack of consensus
to even work on this topic), and the discussion of the
-00 version of this late last year. IOW, I don't consider
my objection has been answered.

In case people haven't got all the mails from last year
at the front of their minds, I went through them for you
and have provided links and selected quotes below. Yes,
the quotes are selected but I think do indicate that the
opposition to these ideas is as before. And there were
also the usual voices in support of weakening TLS in this
manner as well - a read of the thread clearly indicates
to me that discussion of this draft in London will, as
before, be a divisive waste of time and energy.

Chairs: Please drop the agenda item, or explain how any
of this fits our process, because I'm just not getting
it.

Thanks,
Stephen.


me, "IMO the WG shouldn't touch this terrible proposal with a
bargepole."

https://www.ietf.org/mail-archive/web/tls/current/msg24493.html

Randy Bush: "there are a lot of us lurkers out here a bit horrified
watching this wg go off the rails." (Different thread, but same topic)

https://www.ietf.org/mail-archive/web/tls/current/msg24539.html

Uri Blumenthal: "+1 to Stephen"

https://www.ietf.org/mail-archive/web/tls/current/msg24542.html

Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"

https://www.ietf.org/mail-archive/web/tls/current/msg24544.html

Ion Larranaga Azcue, "I really don't feel confortable with the approach
taken in this draft."

https://www.ietf.org/mail-archive/web/tls/current/msg24562.html

Hubert Kario: "to be clear: me too" (replying about hating the idea)

https://www.ietf.org/mail-archive/web/tls/current/msg24578.html

Rich Salz: "I am opposed to the basic concept of injecting a third-party
into the E2E TLS process."

https://www.ietf.org/mail-archive/web/tls/current/msg24585.html

Florian Weimer: "I don't understand why this complicated approach is
needed."

https://www.ietf.org/mail-archive/web/tls/current/msg24607.html

Ben Kaduk: "I do not see any potential for a workable solution."

https://www.ietf.org/mail-archive/web/tls/current/msg24620.html

Uri Blumenthal: "why do we spend time discussing this draft?"

https://www.ietf.org/mail-archive/web/tls/current/msg24639.html

Christian Huitema: "Maybe they have found ways to manage their
applications and servers without breaking TLS..."

https://www.ietf.org/mail-archive/web/tls/current/msg24643.html

Ted Lemon: "I think we should stop."

https://www.ietf.org/mail-archive/web/tls/current/msg24649.html

Andrei Popov: "deploying a weakened configuration of TLS 1.3 (without
PFS) would not meet the intent of those future mandates/requirements."
(On "industry need")

https://www.ietf.org/mail-archive/web/tls/current/msg24656.html

Ben Kaduk: "The time I am spending on this thread is time that I am not
able to spend improving the TLS 1.3 document."

https://www.ietf.org/mail-archive/web/tls/current/msg24660.html

Dave Garrett: "Please, let's just let this mess die. "

https://www.ietf.org/mail-archive/web/tls/current/msg24667.html

Uri Blumenthal "I'm against weakening the protocol, since there are
other ways to accomplish the perlustrator's mission"

https://www.ietf.org/mail-archive/web/tls/current/msg24670.html
Yeah, I had to look it up too:-)
https://en.oxforddictionaries.com/definition/us/perlustrator

Adam Caudill: "To be honest, I’m rather surprised that this group
continues to spend time on this."

https://www.ietf.org/mail-archive/web/tls/current/msg24712.html

Tony Arcieri, "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."

https://www.ietf.org/mail-archive/web/tls/current/msg24715.html

Colm MacCárthaigh: "I don't have too strong an interest in this thread,
it's not going anywhere, and I don't mind that."

https://www.ietf.org/mail-archive/web/tls/current/msg24720.html

Peter Saint-Andre: "+1 to Stephen's request." (for chairs to close down
the discussion)

https://www.ietf.org/mail-archive/web/tls/current/msg24734.html

Cas Cremers: " I think such a mechanism should not be part of the TLS
1.3 standard."

https://www.ietf.org/mail-archive/web/tls/current/msg24885.html

Karthikeyan Bhargavan: "I really don’t recommend any change to the TLS
1.3 design to accomplish any of this"

https://www.ietf.org/mail-archive/web/tls/current/msg24903.html



0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital 

Re: [TLS] TLS@IETF101 Agenda Posted

[stephen . farrell]

Hiya,

On Saturday, 10 March 2018, Melinda Shore wrote:
> On 3/9/18 12:57 PM, Kathleen Moriarty wrote:
> > The hummed answer to that question was very close to 50/50 in the
> > room, inconclusive.
> 
> From the perspective of consensus decision-making that's
> actually very clear - there's no consensus.  What that
> means in practice depends on the question that was asked,
> but at any rate I think what matters here is a lack of
> consensus.

Agreed. My earlier mail pointed at the minutes as to the question.  

> 
> Also, there's been basically no discussion of the draft
> on the mailing list, and I'm not sure why.
>

There was lots of discussion about -00, late last year.  -01 isn't 
significantly different afaics. From my pov that discussion was entirely 
predictable indicating no significant changes in position. 

Cheers 
S
 
> Melinda
> 
> -- 
> Software longa, hardware brevis
> 
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
> 
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Kathleen,

On 09/03/18 21:57, Kathleen Moriarty wrote:
> Hello, Stephen.
> 
> On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
>  wrote:
>>
>> Hi Joe,
>>
>> I'm sorry, but I gotta say that answer seems to me both unresponsive
>> to the questions asked and unconvincing.
>>
>> On 08/03/18 23:08, Joseph Salowey wrote:
>>> Hi Stephen,
>>>
>>> In the meeting in Prague there was interest in this problem space, but
>>> neither the consensus to accept or reject this work.
>>
>> Without rough consensus to adopt, the work is not adopted.
>>
>> But your statement above isn't accurate - it wasn't "this work"
>> (as in this draft) that was discussed in Prague, but rather the
>> entire idea of weakening TLS in these ways - quoting from the
>> Prague minutes [1]:
>>
>> "The main question: Is this subject something that the WG should
>> consider?"
> 
> The hummed answer to that question was very close to 50/50 in the
> room, inconclusive.

I'm sorry to disagree but it was entirely clear there was a
lack of consensus. That's the significant thing here. And
there is zero evidence that anyone's changing their position.

That ought be enough for the chairs to say no to all proposals
in this space unless someone turns up with something unexpected.

That's not the case here - in discussion of this draft, various
folks asked on the list that we stop the constant debate about
making TLS worse, so there is zero evidence that this draft is
going to change people's minds.

Where am I wrong?

> 
>>
>> There is clearly no consensus to adopt *any* work in this space,
>> whether that be draft-green or this latest iteration from Russ
>> and Ralph.
> 
> It was clear that there was no consensus to adopt draft-green and that
> is considered dead in the water, we agree there. 

The question asked in Prague was not specific to draft-green.
I would have preferred if it had been and Lucy Lynch suggested
that in fact (so say the minutes) but the chairs conferred and
asked a much more general question. The consequence is that
Russ and Ralph's draft, having been discussed on the list, with
no evidence that it's changed minds, ought not be taken further
in the WG and ought not get agenda time.

Where am I wrong?

> Since there was
> interest (50% of the room) to consider work in this space, I agree
> with the chairs assessment to allow this presentation.  I am confident
> they will work on any hums to carefully assess next steps and if any
> future proposals belong in this WG or elsewhere.

Again, I'm sorry but that's just not logical. There's abundant
evidence that people's opinions have not changed from the earlier
discussion of Russ and Ralph's draft so it makes no sense at all
to repeatedly impose this divisive topic on the WG.

S.


> 
>>
>> I see nothing whatsoever to indicate any significant change in
>> sets of opinions since Prague.
>>
>> What makes you think iterating on yet more proposals like this
>> will ever conclude? If there's no evidence of that we ought not
>> waste the time and energy. Can you point at any change that
>> could possibly indicate that this bun-fight is worth doing yet
>> again?
>>
>>>  The authors have
>>> revised their proposal to address some of the concerns raised by working
>>> group members and are asking to bring the new approach in front of the
>>> working group.
>>
>> What significant change has there been since -00 of Russ and Ralph's
>> draft? I see nothing major there. that -00 was debated on the list
>> which is the primary place for  discussion. My read of that set of
>> threads it that it pretty clearly showed that the same folks have
>> the same opinions with no significant movement. Can you point at
>> some evidence to the contrary? If not, we shouldn't bother to waste
>> more time on this.
>>
>> If instead you mean Russ and Ralph's draft differs from draft-green,
>> then see above - it wasn't only draft-green that was rejected in
>> Prague, but the entire idea of adopting work in this space, which
>> includes Russ and Ralph's -00 and -01.
>>
>> That the authors have asked for time counts for nothing, when the
>> WG have no consensus to work in this space. If just asking for time
>> does matter, then I'll now publicly repeat my request for time
>> to refure the assertions that'll be made for breaking TLS. You said
>> no to my request, so what's different about one that relates to a
>> draft that has been debated on the list and attracted significant
>> negative comment?
>>
>>> I believe in this case this is the right thing to do even
>>> if it appears there is some repetition of topic.
>>
>> It is not "some repetition" - this topic has been debated f2f and
>> on this draft on the list and there's zero evidence of significant
>> changes in opinion, in fact the opposite. Can you point at any
>> such evidence? If not, your position as chairs seems illogical.
>>
>>> However, if the new
>>> approach fails to achieve significantly more support I believe the authors
>>> will 

Re: [TLS] TLS@IETF101 Agenda Posted

[Kathleen Moriarty]

Hello, Stephen.

On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
 wrote:
>
> Hi Joe,
>
> I'm sorry, but I gotta say that answer seems to me both unresponsive
> to the questions asked and unconvincing.
>
> On 08/03/18 23:08, Joseph Salowey wrote:
>> Hi Stephen,
>>
>> In the meeting in Prague there was interest in this problem space, but
>> neither the consensus to accept or reject this work.
>
> Without rough consensus to adopt, the work is not adopted.
>
> But your statement above isn't accurate - it wasn't "this work"
> (as in this draft) that was discussed in Prague, but rather the
> entire idea of weakening TLS in these ways - quoting from the
> Prague minutes [1]:
>
> "The main question: Is this subject something that the WG should
> consider?"

The hummed answer to that question was very close to 50/50 in the
room, inconclusive.

>
> There is clearly no consensus to adopt *any* work in this space,
> whether that be draft-green or this latest iteration from Russ
> and Ralph.

It was clear that there was no consensus to adopt draft-green and that
is considered dead in the water, we agree there.  Since there was
interest (50% of the room) to consider work in this space, I agree
with the chairs assessment to allow this presentation.  I am confident
they will work on any hums to carefully assess next steps and if any
future proposals belong in this WG or elsewhere.

>
> I see nothing whatsoever to indicate any significant change in
> sets of opinions since Prague.
>
> What makes you think iterating on yet more proposals like this
> will ever conclude? If there's no evidence of that we ought not
> waste the time and energy. Can you point at any change that
> could possibly indicate that this bun-fight is worth doing yet
> again?
>
>>  The authors have
>> revised their proposal to address some of the concerns raised by working
>> group members and are asking to bring the new approach in front of the
>> working group.
>
> What significant change has there been since -00 of Russ and Ralph's
> draft? I see nothing major there. that -00 was debated on the list
> which is the primary place for  discussion. My read of that set of
> threads it that it pretty clearly showed that the same folks have
> the same opinions with no significant movement. Can you point at
> some evidence to the contrary? If not, we shouldn't bother to waste
> more time on this.
>
> If instead you mean Russ and Ralph's draft differs from draft-green,
> then see above - it wasn't only draft-green that was rejected in
> Prague, but the entire idea of adopting work in this space, which
> includes Russ and Ralph's -00 and -01.
>
> That the authors have asked for time counts for nothing, when the
> WG have no consensus to work in this space. If just asking for time
> does matter, then I'll now publicly repeat my request for time
> to refure the assertions that'll be made for breaking TLS. You said
> no to my request, so what's different about one that relates to a
> draft that has been debated on the list and attracted significant
> negative comment?
>
>> I believe in this case this is the right thing to do even
>> if it appears there is some repetition of topic.
>
> It is not "some repetition" - this topic has been debated f2f and
> on this draft on the list and there's zero evidence of significant
> changes in opinion, in fact the opposite. Can you point at any
> such evidence? If not, your position as chairs seems illogical.
>
>> However, if the new
>> approach fails to achieve significantly more support I believe the authors
>> will need to find another path for their work that does not go through the
>> TLS working group.
>
> But the WG has already demonstrated a lack of consensus to even
> consider "work in this space" (your choice of words I believe.)
> That should be enough. What does or doesn't happen outside the
> TLS WG is not at issue here.
>
> To reiterate, in Prague you asked "The main question: Is this subject
> something that the WG should consider?" The result was a clear lack of
> any consensus to work in this space, which means not working in this
> space. Yet here we are again giving agenda time to highly controversial
> proposals in this space.
>
> Please: just take this off the agenda and let the WG do it's real work.
>
> Thanks,
> S.
>
> [1] https://datatracker.ietf.org/meeting/99/materials/minutes-99-tls

Relevant comment from minutes:
Hums: No clarity whatsoever. Seemed pretty even.

Best,
Kathleen

>
>>
>> Cheers,
>>
>> Joe
>>
>> On Thu, Mar 8, 2018 at 9:21 AM, Stephen Farrell 
>> wrote:
>>
>>>
>>> Hi Sean, Joe,
>>>
>>> On 08/03/18 16:20, Sean Turner wrote:
 I’ve posted the draft agendas:

 Monday:
   https://datatracker.ietf.org/meeting/101/materials/agenda-
>>> 101-tls-sessb
>>>
>>> That includes:
>>> "
>>> TLS Vizability - Russ & Chairs - 30min
>>>  - 10min draft - Russ
>>>   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>>>  - 

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

Hi Darin,

I just asked for clarification whether it's on a TLS WG agenda for London.
I'm not quite sure this is a right thread to discuss the contents of that draft.
(In fact, I'm pretty sire it isn't.)

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58


On Fri, Mar 9, 2018 at 2:39 AM, Darin Pettis  wrote:
> Artyom,
> Thanks for mentioning the ID and you are right that draft Fenter is the
> supporting problem description.
>
> The reason it was written was to help folks understand why legitimate
> internal out-of-band decryption is still needed on data once it reaches its
> destination and that there isn’t a viable alternative that we are aware of.
> Especially not in-line MitM decryption.  It just doesn’t scale.  The draft
> lists the legitimate internal requirements and speaks to the facts around
> some of the suggestions that have been offered.
>
>  It’s a good read and we are happy to answer questions in advance as needed.
>
> Darin
>
> On Thu, Mar 8, 2018 at 4:11 PM Artyom Gavrichenkov 
> wrote:
>>
>> Hi Sean, Joe,
>>
>> WG also has this at its disposal:
>> https://tools.ietf.org/html/draft-fenter-tls-decryption-00
>> Will that be discussed along with draft-rhrd-tls-tls13-visibility?
>> Those two seem to be rather connected/dependant on each other.
>>
>> | Artyom Gavrichenkov
>> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
>> | mailto: xima...@gmail.com
>> | fb: ximaera
>> | telegram: xima_era
>> | skype: xima_era
>> | tel. no: +7 916 515 49 58
>>
>>
>> On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
>>  wrote:
>> >
>> > Hi Sean, Joe,
>> >
>> > On 08/03/18 16:20, Sean Turner wrote:
>> >> I’ve posted the draft agendas:
>> >>
>> >> Monday:
>> >>
>> >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
>> >
>> > That includes:
>> > "
>> > TLS Vizability - Russ & Chairs - 30min
>> >  - 10min draft - Russ
>> >   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>> >  - 10min discussion - Chairs
>> >  - 10min wrap-up - Chairs
>> > "
>> >
>> > Consider this as an objection to that agenda item
>> > being given any time. I also have some questions
>> > below.
>> >
>> > This topic was discussed at length in Prague with a
>> > very clear lack of consensus to consider any work in
>> > that space, despite there being quite a few fans of
>> > doing such work in the room that day. I don't see
>> > that anything has changed in the meantime.
>> >
>> > Russ' draft was discussed on the list last year, also
>> > with (ISTM) no consensus at all to do any work in
>> > that space. (While you didn't make a consensus call,
>> > am I wrong?) The -01 version is not significantly
>> > different from what was discussed on the list so I
>> > see no need for any presentation nor discussion time.
>> >
>> > Given the above, on what basis are meeting attendees
>> > being asked to waste yet more f2f time on this topic?
>> >
>> > And why is another want-it/hate-it exercise useful?
>> >
>> > As chairs, are you going to continually allow the same
>> > topic to be raised, in the face of a very clear lack
>> > of consensus to do anything in this space? If not,
>> > then what's the plan for ending this?
>> >
>> > Thanks,
>> > S.
>> >
>> > PS: I also strongly object to the "visibility" euphemism,
>> > and while that's partly a comment on the draft, it would
>> > also IMO be a significant error to pose any questions to
>> > the WG based on that euphemism.
>> >
>> >
>> > ___
>> > 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

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Darin Pettis]

Artyom,
Thanks for mentioning the ID and you are right that draft Fenter is the
supporting problem description.

The reason it was written was to help folks understand why legitimate
internal out-of-band decryption is still needed on data once it reaches its
destination and that there isn’t a viable alternative that we are aware of.
   Especially not in-line MitM decryption.  It just doesn’t scale.  The
draft lists the legitimate internal requirements and speaks to the facts
around some of the suggestions that have been offered.

 It’s a good read and we are happy to answer questions in advance as
needed.

Darin

On Thu, Mar 8, 2018 at 4:11 PM Artyom Gavrichenkov 
wrote:

> Hi Sean, Joe,
>
> WG also has this at its disposal:
> https://tools.ietf.org/html/draft-fenter-tls-decryption-00
> Will that be discussed along with draft-rhrd-tls-tls13-visibility?
> Those two seem to be rather connected/dependant on each other.
>
> | Artyom Gavrichenkov
> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> | mailto: xima...@gmail.com
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> | tel. no: +7 916 515 49 58
>
>
> On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
>  wrote:
> >
> > Hi Sean, Joe,
> >
> > On 08/03/18 16:20, Sean Turner wrote:
> >> I’ve posted the draft agendas:
> >>
> >> Monday:
> >>
> https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
> >
> > That includes:
> > "
> > TLS Vizability - Russ & Chairs - 30min
> >  - 10min draft - Russ
> >   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
> >  - 10min discussion - Chairs
> >  - 10min wrap-up - Chairs
> > "
> >
> > Consider this as an objection to that agenda item
> > being given any time. I also have some questions
> > below.
> >
> > This topic was discussed at length in Prague with a
> > very clear lack of consensus to consider any work in
> > that space, despite there being quite a few fans of
> > doing such work in the room that day. I don't see
> > that anything has changed in the meantime.
> >
> > Russ' draft was discussed on the list last year, also
> > with (ISTM) no consensus at all to do any work in
> > that space. (While you didn't make a consensus call,
> > am I wrong?) The -01 version is not significantly
> > different from what was discussed on the list so I
> > see no need for any presentation nor discussion time.
> >
> > Given the above, on what basis are meeting attendees
> > being asked to waste yet more f2f time on this topic?
> >
> > And why is another want-it/hate-it exercise useful?
> >
> > As chairs, are you going to continually allow the same
> > topic to be raised, in the face of a very clear lack
> > of consensus to do anything in this space? If not,
> > then what's the plan for ending this?
> >
> > Thanks,
> > S.
> >
> > PS: I also strongly object to the "visibility" euphemism,
> > and while that's partly a comment on the draft, it would
> > also IMO be a significant error to pose any questions to
> > the WG based on that euphemism.
> >
> >
> > ___
> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls