Subject: [TLS] TLS@IETF101 Agenda Posted

From: Sean Turner <[email-masked]>
Date: Thu, 8 Mar 2018 11:20:50 -0500

I’ve posted the draft agendas:

Monday:
  https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb

Wednesday:
  https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessa

spt

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 8 Mar 2018 17:21:40 +0000

Hi Sean, Joe,

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

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Thu, 8 Mar 2018 17:10:53 -0500

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: [email-masked]
| 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
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 8 Mar 2018 15:08:06 -0800

Hi Stephen,

In the meeting in Prague there was interest in this problem space, but
neither the consensus to accept or reject this work.  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.  I believe in this case this is the right thing to do even
if it appears there is some repetition of topic.   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.

Cheers,

Joe

---

From: Darin Pettis <[email-masked]>
Date: Thu, 08 Mar 2018 23:39:18 +0000

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

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Fri, 9 Mar 2018 08:52:15 +0300

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

On Fri, Mar 9, 2018 at 2:39 AM, Darin Pettis <[email-masked]> wrote:
> 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
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Mar 2018 21:24:21 +0000

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

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.

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Mar 2018 16:57:30 -0500

Hello, Stephen.

> "The main question: Is this subject something that the WG should

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

> whether that be draft-green or this latest iteration from Russ

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.

> [1] https://datatracker.ietf.org/meeting/99/materials/minutes-99-tls

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

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Mar 2018 22:07:25 +0000

Kathleen,

> The hummed answer to that question was very close to 50/50 in the

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?

> 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

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.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 9 Mar 2018 20:41:53 -0900

> The hummed answer to that question was very close to 50/50 in the

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.

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

Melinda

-- 
Software longa, hardware brevis

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

---

From: [email-masked]
Date: Sat, 10 Mar 2018 09:56:00 +0000

Hiya,

> but at any rate I think what matters here is a lack of

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Mar 2018 14:21:28 +0000

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

---

From: Jim Reid <[email-masked]>
Date: Tue, 13 Mar 2018 14:48:27 +0000

> On 13 Mar 2018, at 14:21, Stephen Farrell <[email-masked]> wrote:
> 

Stephen, the opposite PoV is equally valid. There was no consensus in Prague NOT to work on the topic. The mood of the room was evenly divided.

IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to drop that draft and come back with a new one which would hopefully be more likely to get WG consensus. That draft has now arrived. It’s unreasonable to deny the new I-D a fair hearing and even worse to reject it out of hand.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 13 Mar 2018 11:06:52 -0400

It's my fault for the ambiguous wording, but in this context the quote from
me reads as the opposite of my intent.  To be more clear: what I meant was
that while the proposals aren't making much progress, I don't mind that
it's being discussed.

I'm happy to have mailing list threads on the topic and agenda time devoted
to it (I don't go in person, but I do watch the videos). Since it's an area
of such disagreement, I'd prefer to see /more/ discussion, not less.
There's always hope of movement and progress on either side, and I think
good discourse lessens the risk of dozens of fragmentary DIY solutions,
which I think will be the worst kind of outcome of non-engagement.

On Tue, Mar 13, 2018 at 10:21 AM, Stephen Farrell <[email-masked]

-- 
Colm

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 08:58:45 -0700

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.  So, the main thing
to acknowledge is that the enterprise use case is different than the
Internet use case.  As such, it needs its own solution.  Please note that
the endpoint is the intended recipient of the session and the owner and
responsible party for the security of the data.

The presentation in London is to present a use case solution – along with
TLS WG recommendations/updates from Prague where half of the room hummed
that an internal solution is needed.

This rift is not good for the TLS Working Group, it is not good for the
IETF, it is not good for the business community and it is not good for the
Internet.  We need to have some type of methodology so that we can continue
to protect ourselves.  Therefore, we are asking for WG help with a solution
to the enterprise use case.

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/

Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

On Tue, Mar 13, 2018 at 8:06 AM, Colm MacCárthaigh <[email-masked]>
wrote:

>
> It's my fault for the ambiguous wording, but in this context the quote
> from me reads as the opposite of my intent.  To be more clear: what I meant
> was that while the proposals aren't making much progress, I don't mind that
> it's being discussed.
>
> I'm happy to have mailing list threads on the topic and agenda time
> devoted to it (I don't go in person, but I do watch the videos). Since it's
> an area of such disagreement, I'd prefer to see /more/ discussion, not
> less. There's always hope of movement and progress on either side, and I
> think good discourse lessens the risk of dozens of fragmentary DIY
> solutions, which I think will be the worst kind of outcome of
> non-engagement.
>
> On Tue, Mar 13, 2018 at 10:21 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hiya,
>>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 16:05:48 +0000

*   Prague where half of the room hummed that an internal solution is needed.

No, this is not accurate.

Half the room hummed *to continue discussion.*  The discussion could still end with no action.

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 13 Mar 2018 09:09:03 -0700

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.

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 09:09:23 -0700

Thanks for the correction, Rich.

I agree that the room hummed to "continue the discussion".  I hope that we
can all work together to craft a solution.   We don't want fragmentation
and multiple DIY solutions.

Nalini

On Tue, Mar 13, 2018 at 9:05 AM, Salz, Rich <[email-masked]> wrote:

>
>    - Prague where half of the room hummed that an internal solution is
>    needed.
>
>
>
> Half the room hummed **to continue discussion.**  The discussion could
> still end with no action.
>
>
>

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 13 Mar 2018 09:09:20 -0700

The consensus (as judge by the chairs) was that there no clear consensus to
shut the discussion down.  It was not that work on internal solution is
needed.

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 09:12:15 -0700

As I wrote to Rich, thanks for the correction.

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

Nalini

On Tue, Mar 13, 2018 at 9:09 AM, Joseph Salowey <[email-masked]> wrote:

> The consensus (as judge by the chairs) was that there no clear consensus
> to shut the discussion down.  It was not that work on internal solution is
> needed.
>
>
>
>

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 13 Mar 2018 16:31:53 +0000

Hi Nalini,

вт, 13 мар. 2018 г., 11:59 nalini elkins <[email-masked]>:

> motivation to help the underdog and protect the political dissident.
>

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 16:32:07 +0000

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 Mar 2018 08:33:00 -0800

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

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 09:37:12 -0700

*>>* 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 <[email-masked]> 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”? ☺
>
>
>

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 09:51:01 -0700

Rich,

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 <[email-masked]>
wrote:

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

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 09:56:28 -0700

> This might be a good time to review RFC 7282

Thanks, Melinda!  Re-reading!

Nalini

On Tue, Mar 13, 2018 at 9:33 AM, Melinda Shore <[email-masked]

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 13 Mar 2018 16:58:56 +0000

+1 !
Well stated.

From: TLS [mailto:[email-masked]] On Behalf Of nalini elkins
Sent: Tuesday, March 13, 2018 11:59 AM
To: Colm MacCárthaigh <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

Stephen (and TLS group)

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.  So, the main thing to acknowledge is that the enterprise use case is different than the Internet use case.  As such, it needs its own solution.  Please note that the endpoint is the intended recipient of the session and the owner and responsible party for the security of the data.

The presentation in London is to present a use case solution – along with TLS WG recommendations/updates from Prague where half of the room hummed that an internal solution is needed.

This rift is not good for the TLS Working Group, it is not good for the IETF, it is not good for the business community and it is not good for the Internet.  We need to have some type of methodology so that we can continue to protect ourselves.  Therefore, we are asking for WG help with a solution to the enterprise use case.

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/

Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com<http://www.e-dco.com>

On Tue, Mar 13, 2018 at 8:06 AM, Colm MacCárthaigh <[email-masked]<mailto:[email-masked]>> wrote:

It's my fault for the ambiguous wording, but in this context the quote from me reads as the opposite of my intent.  To be more clear: what I meant was that while the proposals aren't making much progress, I don't mind that it's being discussed.

I'm happy to have mailing list threads on the topic and agenda time devoted to it (I don't go in person, but I do watch the videos). Since it's an area of such disagreement, I'd prefer to see /more/ discussion, not less. There's always hope of movement and progress on either side, and I think good discourse lessens the risk of dozens of fragmentary DIY solutions, which I think will be the worst kind of outcome of non-engagement.

On Tue, Mar 13, 2018 at 10:21 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hiya,

Thanks,
Stephen.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

--
Colm

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

--
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com<http://www.e-dco.com>

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 17:09:45 +0000

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

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 10:13:04 -0700

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

Sure.  I see your point.  From now on, I will stop using the pronoun "we"
and say "I".  Is that better?   And others can speak for themselves also.

Nalini

On Tue, Mar 13, 2018 at 10:09 AM, Salz, Rich <[email-masked]> 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.
>
>
>
> 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?
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Mar 2018 13:19:52 -0400

It would be far better if the concerned organizations could come forth
directly.  That helps the community see that there are real people who care
enough about this to engage, and will hopefully allow more direct
discussions of the problems and possible solutions.

Kudos to the US Bank guys for leading the way here.

On Tue, Mar 13, 2018 at 1:13 PM, nalini elkins <[email-masked]>
wrote:

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 Mar 2018 09:21:04 -0800

On 3/13/18 6:48 AM, Jim Reid wrote:
> Stephen, the opposite PoV is equally valid. There was no consensus in
> Prague NOT to work on the topic. The mood of the room was evenly
> divided.

To clarify, this isn't voting.  If there's no agreement in
either direction there's no agreement (and I hope the default
in the IETF is not that in the absence of agreement, work
goes forward).  The problem is how to come to agreement, and
what that typically involves is refining the proposal to
address objections.

> IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to
> drop that draft and come back with a new one which would hopefully be
> more likely to get WG consensus. That draft has now arrived. It’s
> unreasonable to deny the new I-D a fair hearing and even worse to
> reject it out of hand.

It's surprising that it got agenda time without mailing list
discussion.  Aside from the changes to the key
exchange there are some clear usability problems.  While
usability usually lies outside the purview of the IETF's
technical work, in this case the work is premised on the
ability of the user to consent (or not) to sharing keying
material with a third party, which in turn suggests that
they're presented with the question at the time the
session is initiated, so that the extension isn't sent in
the ClientHello.  Sounds like a click-through problem,
tbh, where the user has little practical control over whether
or not their data are shared with a third party.

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Mar 2018 10:23:21 -0700

On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins <[email-masked]>
wrote:

> 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

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 10:24:57 -0700

directly.  That helps the community see that there are real people who care
enough about this to engage, and will hopefully allow more direct
discussions of >the problems and possible solutions.

>Kudos to the US Bank guys for leading the way here.

There will be at least 10 other concerned organizations in London.   More
attending remotely.

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.

Nalini

---

From: George Palmer <[email-masked]>
Date: Tue, 13 Mar 2018 17:30:44 +0000

+1

> On 13 Mar 2018, at 17:23, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins <[email-masked]> wrote:
>> Stephen (and TLS group)
>> 
>> 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. 
>

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 13 Mar 2018 17:32:05 +0000

Hi Eric,

The author probably refers to a case where an infosec dept of an enterprise
will not just disable TLSv1.3 on the servers, but will also set up some
deep-juju DPI for filtering v1.3 in transit to make sure no one will enable
v1.3 accidentally somewhere.

As those DPI solutions are often of questionable reliability, that may
affect other transit users of that network.

вт, 13 мар. 2018 г., 13:24 Eric Rescorla <[email-masked]>:

>> The TLS working group has been concentrating on making the Internet
>> secure for the individual user.    We feel that there is also an underlying

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Mar 2018 17:39:33 +0000

> On Mar 13, 2018, at 16:31, Artyom Gavrichenkov <[email-masked]> wrote:
> 
> Hi Nalini,
> 
> 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.
> 
> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 17:39:53 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 13:52:44 -0400

On Mar 13, 2018, at 12:37 PM, nalini elkins <[email-masked]> 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.

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 13 Mar 2018 17:52:21 +0000

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 <[email-masked]>:

> > 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:
> 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"):

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 13 Mar 2018 14:15:51 -0400

On Tue, Mar 13, 2018 at 1:52 PM, Ted Lemon <[email-masked]> 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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 13 Mar 2018 18:27:52 +0000

*   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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 13 Mar 2018 14:44:23 -0400

> what that typically involves is refining the proposal to

And then there are other options too, like another WG.  Even from
Stephen's list of who is in agreement with him, I've received a few
messages saying their text wasn't what he thinks it was.  More
discussion here would be good to figure out a way forward.  The chairs
have not agreed to allow the work to go forward, but just the
discussions to determine next steps.

> or not their data are shared with a third party.

This should have had discussion time in Singapore, as the chairs
mentioned.  I'm mostly responding though because their use cases are
entirely server-to-server from what I understand.  The client
connection to the enterprise can terminate at the network edge, then
anything within the enterprise is from another encrypted session
(which could be TLS 1.2 or another protocol, or this proposal, or
something else including methods that eliminate the architectural
design for monitoring on the wire within the datacenter).  If there
were a way to limit this extension to server-to-server, that would
eliminate the click through problem you mention and the server admin
would be aware on either end of this usage.  I don't know if there is
a way to do this without using another protocol, but making the use
case clear may help with ideas.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 Mar 2018 11:08:30 -0800

> discussions to determine next steps.

Part of the problem here, I think, is that it's not clear
what's under discussion - the general problem or this
specific draft.  I tend to think that discussions of the
general problem will probably be unproductive and
polarizing, and that if there is a way forward on this
it's to have credible and specific technical proposals.
Remember that in terms of process we don't need to have
unanimity on a decision, but all serious technical
objections need to be addressed and resolved.  So,
if someone has a draft that can eventually clear that
bar, proponents of allowing third parties to decrypt
TLS sessions have a way forward.  (Unfortunately I
don't think this draft can make it through).  At any
rate I would regret (a lot) seeing discussion meander
on over to the broader should-we-or-shouldn't-we question.

Melinda

---

From: nalini elkins <[email-masked]>
Date: Tue, 13 Mar 2018 12:20:00 -0700

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 <[email-masked]> wrote:

>
>    - I am happy to set up an informal session where all can meet and talk
> 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.
>
>
>
>
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 13 Mar 2018 19:20:52 +0000

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:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, March 13, 2018 1:53 PM
To: nalini elkins <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 12:37 PM, nalini elkins <[email-masked]<mailto:[email-masked]>> 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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 13 Mar 2018 15:37:22 -0400

> on over to the broader should-we-or-shouldn't-we question.

I think the chairs made it clear that it is on the specific draft and
they just have 10 minutes to present.  I believe the slides are
already posted and include the use cases within them.  We've all spent
way more than 10 in this discussion ;-)

It's up to the WG to decide and it seems a few want to discuss it,
even from the list that Stephen says are not interested.  I think it's
better to let the discussion happen.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 16:27:39 -0400

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

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 13 Mar 2018 17:01:44 -0400

> 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

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 17:49:47 -0400

> what that typically involves is refining the proposal to

The Prague discussion was about draft-green-...  Nick Sullivan summarized four concerns with that approach.  See https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg <https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg>

draft-rhrd-... addresses all four of these concerns.  We had some discussion on the mail list, which lead to -01 being posted.

I do not know if the TLS WG will want to adopt this approach.  I would like to find out.

Russ

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 13 Mar 2018 21:55:25 +0000

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.

---

From: Darin Pettis <[email-masked]>
Date: Tue, 13 Mar 2018 22:07:47 +0000

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 <[email-masked]>
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.
>>
>>
>>

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 18:16:47 -0400

> 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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 13 Mar 2018 22:21:47 +0000

*   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 <[email-masked]> On Behalf Of Russ Housley
Sent: Tuesday, March 13, 2018 3:17 PM
To: Ted Lemon <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

Ted:

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Mar 2018 22:22:59 +0000

Joe,

On 13/03/18 16:09, Joseph Salowey wrote:
> 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

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 22:26:42 +0000

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 18:28:09 -0400

> On Mar 13, 2018, at 6:21 PM, Andrei Popov <[email-masked]> 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?

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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 13 Mar 2018 22:35:35 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 18:38:24 -0400

> putting meeting attendees and list participants through a bunch

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 22:38:45 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 18:40:45 -0400

On Mar 13, 2018, at 6:16 PM, Russ Housley <[email-masked]> 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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Mar 2018 22:48:41 +0000

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?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Mar 2018 22:53:54 +0000

Hi Russ,

On 13/03/18 21:49, Russ Housley wrote:
> The Prague discussion was about draft-green-...

Much more was discussed than just that one dead draft. In particular
see the minutes for the more general question posed by the chairs.

> Nick Sullivan summarized four concerns with that approach.  See 
> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>
> 
<https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg>
> 
> draft-rhrd-... addresses all four of these concerns.  We had some 
> discussion on the mail list, which lead to -01 being posted.

The problem you have however is that you're trying to square a
circle, so picking any set of N objections to try to address will
still leave you ending up with something unacceptable, for at
least one of a bunch of reasons. Partly, that's because you need
there to be a boundary between a data centre and the rest of the
Internet that's meaningful to TLS, and no such boundary exists.

(So the answer to Nalini's problems is: for applications causing
you this particular pain within a data centre don't use TLS,
find another way and while that might be painful for Nalini's
consortium, it's the right answer, given the overall costs of
anything else.)

> I do not know if the TLS WG will want to adopt this approach.  I 

Did you read the list traffic from Oct/Nov? I have no idea how
you can be in doubt if you did. It's readily apparent that your
draft has not caused a lot of people to change their minds. Do
you agree? If so, then the conclusion is obvious, isn't it?

S.

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 13 Mar 2018 23:45:14 +0000

13 Mar. 2018 г., 18:38 Ted Lemon <[email-masked]>:

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

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 13 Mar 2018 20:15:23 -0400

> On Mar 13, 2018, at 6:38 PM, Salz, Rich <[email-masked]> 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

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 22:55:56 -0400

Ted:

I do not follow.

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

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

> 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

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 23:03:41 -0400

> you agree? If so, then the conclusion is obvious, isn't it?

I see a handfull of very vocal people on this topic and many quiet ones.  I hum in the meeting is a meaningful way to find out what the quiet people are thinking.

Russ

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 13 Mar 2018 23:29:55 -0400

Clarifying question

On Tue, Mar 13, 2018 at 10:55 PM, Russ Housley <[email-masked]> wrote:
> 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.
>
>
> 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

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Mar 2018 23:49:21 -0400

> traffic may be intercepted if there were another party that might be

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

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 14 Mar 2018 00:47:45 -0400

Hi,

> On Mar 13, 2018, at 11:03 PM, Russ Housley <[email-masked]> wrote:
> 
> Stephen:
> 
> I see a handfull of very vocal people on this topic and many quiet ones.

I see at least seventeen people (This properly excludes the one recent clarification) who have articulated an opinion against what the draft proposes:

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

Thanks,
Stan

> I hum in the meeting is a meaningful way to find out what the quiet people are thinking.
> 
> Russ
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Mar 2018 09:01:29 +0000

Russ,

On 14/03/18 03:03, Russ Housley wrote:
>> Did you read the list traffic from Oct/Nov? I have no idea how you
>> can be in doubt if you did. It's readily apparent that your draft
>> has not caused a lot of people to change their minds. Do you agree?
>> If so, then the conclusion is obvious, isn't it?
> 

Handful? I don't think that's at all accurate.

But we know head-counting doesn't count of course.

My question to you, that you've not answered, was whether you agree
that your draft has not caused any significant shift in positions.

> quiet people are thinking.

And of course also any people who try pack out the room for any
reason;-(

S

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Mar 2018 08:24:08 -0400

> And of course also any people who try pack out the room for any

As long as the hum is treated as Pete describes in RFC 7282, this shouldn't be an issue.   However, I tend to agree with you that we won't learn anything new by doing this.  Do we really think that there are people who will hum in favor of this who haven't thus far been willing to say why?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Mar 2018 08:32:10 -0400

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

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?

---

From: Hubert Kario <[email-masked]>
Date: Wed, 14 Mar 2018 13:39:48 +0100

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!

if your vendor can't implement that feature, I can hardly call such software 
"maintained" in the first place

>  techniques that have been used in the past are thwarted.

sorry, but this is a complete non-sequitur; that client behaviour has nothing 
to do with TLS 1.3 existence or the way it works

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 Mar 2018 10:21:52 -0400

On Wed, Mar 14, 2018 at 8:32 AM, Ted Lemon <[email-masked]> 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?
>

I think you'd get further (not sure how far), if this were limited to
within the datacenter and without a need for browser implementations.
If it were specific to browsers for use within an enterprise, that
would be one option, but another would be to see if this could be
limited to server-to-server only connections with no need for a
browser.  If you're terminating at a load balancer and then starting a
new session with the extension, this could be done for internal and
external users.

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Mar 2018 14:53:21 -0400

> On Mar 14, 2018, at 8:39 AM, Hubert Kario <[email-masked]> wrote:
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Mar 2018 15:11:16 -0400

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" <[email-masked]> wrote:

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

---

From: Hubert Kario <[email-masked]>
Date: Wed, 14 Mar 2018 20:12:41 +0100

On Wednesday, 14 March 2018 19:53:21 CET Russ Housley wrote:
> >> This is a bogus argument.  First, staying with an old protocol version
> >> often leads to locking in unmaintained versions of old software.
> > 

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Mar 2018 19:15:14 +0000

Absolutely true!

---

From: Peter Bowen <[email-masked]>
Date: Wed, 14 Mar 2018 12:55:58 -0700

On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley <[email-masked]> 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

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 15:52:55 -0700

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 <[email-masked]>
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.
>
>
>
> Cheers,
>
>
>
> Andrei
>

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 16:00:07 -0700

>
> >>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 <[email-masked]>
wrote:

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 14 Mar 2018 19:07:38 -0400

On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins <[email-masked]>
wrote:

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

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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Mar 2018 23:16:30 +0000

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)

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 16:17:04 -0700

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

problem, since the claimed goal >is that Consortium-TLS would only be used

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 14 Mar 2018 19:30:47 -0400

On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins <[email-masked]>
wrote:

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

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?

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 16:32:25 -0700

Stephen,

>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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Mar 2018 23:33:47 +0000

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

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 16:43:30 -0700

- >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 <[email-masked]> wrote:

>
>    - The simple explanation is that people think they will have serious
> 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.
>
>
>

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 16:46:40 -0700

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.

> 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 <[email-masked]>
wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Mar 2018 23:49:47 +0000

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

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

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

---

From: nalini elkins <[email-masked]>
Date: Wed, 14 Mar 2018 17:05:52 -0700

Stephen,

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

>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

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Mar 2018 00:06:28 +0000

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2018 00:13:03 +0000

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

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Thu, 15 Mar 2018 00:14:22 +0000

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 <[email-masked]>:

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2018 00:58:09 +0000

> 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 waaaay more accurate than abusing the word
"visibility" to describe standardising a MitM capability.

S.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Mar 2018 22:32:28 -0400

> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov <[email-masked]> wrote:
> 
> 13 Mar. 2018 г., 18:38 Ted Lemon <[email-masked] <mailto:[email-masked]>>:
> 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

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Thu, 15 Mar 2018 02:52:17 +0000

14 Mar. 2018 г., 22:32 Ralph Droms <[email-masked]>:

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Mar 2018 23:09:37 -0400

> On Mar 14, 2018, at 10:52 PM, Artyom Gavrichenkov <[email-masked]> wrote:
> 
> 14 Mar. 2018 г., 22:32 Ralph Droms <[email-masked] <mailto:[email-masked]>>:
> 
>> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> I didn't! Ted has just pointed out that there's some strategy which is by the way effective under some circumstances, and I've just recalled it has a name. No labels attached!

Ah, OK, sorry for the incorrect inference!

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

- Ralph

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Mar 2018 03:15:00 +0000

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

---

From: nalini elkins <[email-masked]>
Date: Thu, 15 Mar 2018 01:47:11 -0700

>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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2018 06:21:03 -0400

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.

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

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

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 have agreed as to whether or not it is okay to weaken the security of the protocol, the discussion is non-terminal.   I've just quoted from three of the five long messages Ms. Elkins sent to the mailing list today, for example.

This is a serious problem: the working group cannot afford to debate this point indefinitely when the discussion is non-terminal.   It is not "ad hominem" (an argument about a person) to say that it would be better if the working group chairs were to declare this issue closed.   There is a clear benefit to doing so.

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 15 Mar 2018 11:04:43 -0400

[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 <[email-masked]> wrote:
> 
> 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
> 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
> 3.  I had no experience with such a situation so I was not sure what to do either.
> As I recall, I asked to have a discussion of the issues to see what we should do.
> 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 
> 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.
> 
> 4.  Then, I went back to these "enterprises".  They had to go all the way to the
> as help as I could be to them in writing drafts for TLS as that is not where 
> write the drafts for them.  But, this is TLS, so we have to get others to help.
> 5.  This issue with people being able to speak publicly is real.  It needs to
>> On Wed, Mar 14, 2018 at 5:13 PM, Stephen Farrell <[email-masked]> wrote:
>> 
>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Mar 2018 13:29:20 -0400

> 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

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Mar 2018 17:40:02 +0000

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 <[email-masked]> On Behalf Of Russ Housley
Sent: Thursday, March 15, 2018 10:29 AM
To: IETF TLS <[email-masked]>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

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

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Mar 2018 14:29:20 -0400

> And the bigger question, since the ask is essentially for a multi-party security protocol: Is TLS WG the right place to discuss this?

In my experience, technical review via the liaison process does not offer the same quality as an IETF WG.

I hope that your "bigger" question is clearly answered at the meeting next week.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2018 18:47:05 +0000

Russ,

On 15/03/18 17:29, Russ Housley wrote:
>> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>