Subject: [hrpc] "We try to avoid"

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Nov 2018 13:50:16 +0100

https://www.ietf.org/about/participate/get-started/

"We try to avoid policy and business questions, as much as possible."

This seems at odds with several RFC (including of course RFC
8280). An old text which was never revised?

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 14 Nov 2018 13:56:39 +0100

Good catch, I forwarded it to the website team.

On 11/14/18 1:50 PM, Stephane Bortzmeyer wrote:
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: Corinne Cath <[email-masked]>
Date: Wed, 14 Nov 2018 16:24:03 +0000

which other RFCs is it at odds with?

-- 
Corinne Cath - Speth
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: [email-masked] & [email-masked]
Twitter: @C_Cath

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Nov 2018 17:34:04 +0100

On Wed, Nov 14, 2018 at 04:24:03PM +0000,
 Corinne Cath <[email-masked]> wrote 

> which other RFCs is it at odds with?

1984, 2804, 6973, 7258, 8404 and certainly others.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2018 16:56:00 +0000

Hiya,

> 1984, 2804, 6973, 7258, 8404 and certainly others.

Personally, I have no problem with "avoid... as much as
possible" and don't think it actually conflicts with any
of those RFCs. (Noting also that 8280 is an IRTF and not
an IETF RFC.) So FWIW, I'm fine with the web page staying
as-is.

(And also: I wonder is this a change that's really worth
much effort?)

Cheers,
S.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 14 Nov 2018 08:43:50 -0900

> "We try to avoid policy and business questions, as much as possible."

I like to think of that as aspirational, although clearly it's
not really accurate.  I'm not sure the consequences of leaving it
in there are particularly problematic and would be fine with
leaving it as-is.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 15 Nov 2018 10:50:14 +0300

> (And also: I wonder is this a change that's really worth

I appreciate Stephen and Melinda weighing in that perhaps this is not an
important statement to correct and that we can carry on.

But just wondering, what is the original purpose of that statement?

-Mallory

-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 10:19:15 -0500

> But just wondering, what is the original purpose of that statement?

Preventing unmanageable scope creep.   When you add business and policy to
the mix, it makes it a lot harder to get work done, because they are
matters of opinion, not fact, and competing interests will not be able to
reach consensus.

I think this is actually a useful thing for HRPC participants to be bearing
in mind:  to the extent that what we come with actually has clear policy
implications, it's going to be difficult to get consensus on it.

Look at the discussion we had over TLS 1.3 back in Prague.   There was a
clear technical goal: make connections as secure as reasonably possible
(I'm sure the TLS folks will heckle me for grossly
oversimplifying—sorry!).   And there was a competing business goal: allow
me to debug my network without retooling completely.   The business goal
lost not because it wasn't a real problem, but because it was a business
problem, not a technical problem.   Of course for the person dealing with
the problem, it *feels* like a technical problem, but ultimately it's a
problem because of the practices of the business being affected by the
added security of TLS 1.3, *not* because there's actually a technical
problem with TLS 1.3.

So when we think about how the wording of this text implicates the work
being done in HRPC, it would be good to be very careful not to jump to
conclusions about what the wording implies.   In this case, it's pretty
clear (to me, of course!) that letting the right technical solution win was
better for human rights.   I think it's possible that this generalizes to
some extent—my complaining about SMTP in the meeting is because although
SMTP was a good enough technical solution, there were some very serious
technical problems with it that weren't considered, and these problems came
back to haunt us in a big way.   You could say the same thing about BGP.

And having had a week and a half to digest the BGP talk, the conclusion
I've come to is that there's a clear net win for RPKI here.   Yes, RPKI
makes it possible for governments to openly blockade peers they don't
like.   But when they do so, it will be public, and not something that
happened quietly in a room somewhere as a result of a failed trust
relationship that couldn't be enforced.   RPKI creates *problems* for human
rights, but they are problems that we can figure out how to deal with.
 Not using RPKI creates problems we *can't* deal with.

---

From: Bill Jouris <[email-masked]>
Date: Thu, 15 Nov 2018 20:25:43 +0000 (UTC)

Look at the discussion we had over TLS 1.3 back in Prague.   There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly oversimplifying—sorry!).   And there was a competing business goal: allow me to debug my network without retooling completely.   The business goal lost not because it wasn't a real problem, but because it was a business problem, not a technical problem.   Of course for the person dealing with the problem, it feels like a technical problem, but ultimately it's a problem because of the practices of the business being affected by the added security of TLS 1.3, not because there's actually a technical problem with TLS 1.3
The purpose of the IETF is to address technical issues in order to make the Internet work better for Internet users.  And businesses are Internet users every bit as much as individuals are.  

That doesn't mean that business's issues should override individual concerns.  But neither does it justify ignoring them -- which seems to be what you are advocating.  If a technical change creates a "business problem", that doesn't mean we can just sit back and say "Oh, it's not a technical problem so tough on them."  Unless we can say "Here is a solution using available technology which would allow you to address your business problem," it seems like an abdication of responsibility to try to wash our hands of the whole thing. 

Bill Jouris

      From: Ted Lemon <[email-masked]>
 To: Mallory Knodel <[email-masked]> 
Cc: Hrpc <[email-masked]>
 Sent: Thursday, November 15, 2018 7:20 AM
 Subject: Re: [hrpc] "We try to avoid"
   
On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <[email-masked]> wrote:

Preventing unmanageable scope creep.   When you add business and policy to the mix, it makes it a lot harder to get work done, because they are matters of opinion, not fact, and competing interests will not be able to reach consensus.
I think this is actually a useful thing for HRPC participants to be bearing in mind:  to the extent that what we come with actually has clear policy implications, it's going to be difficult to get consensus on it.
Look at the discussion we had over TLS 1.3 back in Prague.   There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly oversimplifying—sorry!).   And there was a competing business goal: allow me to debug my network without retooling completely.   The business goal lost not because it wasn't a real problem, but because it was a business problem, not a technical problem.   Of course for the person dealing with the problem, it feels like a technical problem, but ultimately it's a problem because of the practices of the business being affected by the added security of TLS 1.3, not because there's actually a technical problem with TLS 1.3.
So when we think about how the wording of this text implicates the work being done in HRPC, it would be good to be very careful not to jump to conclusions about what the wording implies.   In this case, it's pretty clear (to me, of course!) that letting the right technical solution win was better for human rights.   I think it's possible that this generalizes to some extent—my complaining about SMTP in the meeting is because although SMTP was a good enough technical solution, there were some very serious technical problems with it that weren't considered, and these problems came back to haunt us in a big way.   You could say the same thing about BGP.
And having had a week and a half to digest the BGP talk, the conclusion I've come to is that there's a clear net win for RPKI here.   Yes, RPKI makes it possible for governments to openly blockade peers they don't like.   But when they do so, it will be public, and not something that happened quietly in a room somewhere as a result of a failed trust relationship that couldn't be enforced..   RPKI creates problems for human rights, but they are problems that we can figure out how to deal with.   Not using RPKI creates problems we can't deal with.
_______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: Nalini J Elkins <[email-masked]>
Date: Thu, 15 Nov 2018 20:59:03 +0000 (UTC)

Ted,

>Look at the discussion we had over TLS 1.3 back in Prague.   There was a clear technical goal: make connections as secure as reasonably >possible (I'm sure the TLS folks will heckle me for grossly oversimplifying—sorry!).   And there was a competing business goal: allow me to >debug my network without retooling completely.   The business goal lost not because it wasn't a real problem, but because it was a business >problem, not a technical problem.   Of course for the person dealing with the problem, it feels like a technical problem, but ultimately >it's a problem because of the practices of the business being affected by the added security of TLS 1.3, not because there's actually a >technical problem with TLS 1.3.

Business problems are realities.  No one has unlimited funds.  I know my daughter thinks that money grows on trees, but I would beg to differ.

In another example, quite a few of our villages in India have only 2g.  This is due to economic realities.  We are trying to work with this in protocol design. It is a reality of life where resources are not infinite.

I do not know if you have seen protocol changes / RFCs in certain working groups which are intended to advantage certain businesses or vendor products.  I know I certainly have.  This is certainly business.

Some companies also send 50 or 100 people to the IETF.  This could be because they are generous contributors to the common good.  I suspect it is more likely because they find there is an economic advantage to be gained by doing so.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 16:10:27 -0500

Yes, I hear your point.   However, if the IETF were to take that on as a
policy, the result would be that we would fail as a standards body, because
no one protocol can reasonably account for every possible use case.   The
problem we had in this case is that TLS is a screwdriver, and the
proponents of the "break TLS" use case needed a hammer.   The solution to
that is for them to use a hammer, not for the IETF to make a hamdriver.

The appropriate IETF response to the statement "TLS 1.3 doesn't work for my
use case" is "hm, what is your use case, and how can we best address it."
 We did that.   The problem is that the answer wasn't to the liking of the
folks who wanted to instead break TLS.

This is *precisely* why we say that the IETF's purpose is not to get
involved in that calculus.   It's simply out of our possible scope.   Of
course there's no point in us building something that nobody will use, but
when we build something, we need to build it to fit a particular use case;
if there are two incompatible use cases, that means that we need to build
two things.

On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris <[email-masked]> wrote:

> *Look at the discussion we had over TLS 1.3 back in Prague.   There was a
> the problem, it feels like a technical problem, but ultimately it's a
> added security of TLS 1.3, not because there's actually a technical problem
> with TLS 1.3*
>
> The purpose of the IETF is to address technical issues *in order to make
> the Internet work better for Internet users*.  And businesses are
> Internet users every bit as much as individuals are.
>
> That doesn't mean that business's issues should override individual
> concerns.  But neither does it justify ignoring them -- which seems to be
> what you are advocating.  If a technical change creates a "business
> problem", that doesn't mean we can just sit back and say "Oh, it's not a
> technical problem so tough on them."  Unless we can say "Here is a solution
> using available technology which would allow you to address your business
> problem," it seems like an abdication of responsibility to try to wash our
> hands of the whole thing.
>
> Bill Jouris
>
>
> ------------------------------
> *From:* Ted Lemon <[email-masked]>
> *To:* Mallory Knodel <[email-masked]>
> *Cc:* Hrpc <[email-masked]>
> *Sent:* Thursday, November 15, 2018 7:20 AM
> *Subject:* Re: [hrpc] "We try to avoid"
>
> I think this is actually a useful thing for HRPC participants to be
> bearing in mind:  to the extent that what we come with actually has clear
> policy implications, it's going to be difficult to get consensus on it.
>
> relationship that couldn't be enforced..   RPKI creates *problems* for
> human rights, but they are problems that we can figure out how to deal
> with.   Not using RPKI creates problems we *can't* deal with.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 16:16:33 -0500

I'm pretty sure that the motivation for keeping TLS secure is that it
benefits end users by preventing criminals (and businesses) from
eavesdropping on their connections.   That was certainly my motivation for
engaging in the discussion.   It frustrates me that you feel comfortable
impugning the motives of IETF participants who really tried very hard to
engage on this issue and propose solutions that addressed the use cases
that we were talking about.   It was very frustrating to simply be told
"no, you have to break your protocol for us because we won't use that other
protocol that actually addresses our use case and wouldn't break TLS."

We may be wandering a bit off-topic, but in a sense this is an important
discussion because when we get into a calculus like this, human rights are
very much at risk.

On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins <
[email-masked]> wrote:

> clear technical goal: make connections as secure as reasonably >possible
> me to >debug my network without retooling completely.   The business goal
> the problem, it feels like a technical problem, but ultimately >it's a
> added security of TLS 1.3, not because there's actually a >technical
> problem with TLS 1.3.
>
> Business problems are realities.  No one has unlimited funds.  I know my
> daughter thinks that money grows on trees, but I would beg to differ.
>
> In another example, quite a few of our villages in India have only 2g.
> This is due to economic realities.  We are trying to work with this in
> protocol design. It is a reality of life where resources are not infinite.
>
> I do not know if you have seen protocol changes / RFCs in certain working
> groups which are intended to advantage certain businesses or vendor
> products.  I know I certainly have.  This is certainly business.
>
> Some companies also send 50 or 100 people to the IETF.  This could be
> because they are generous contributors to the common good.  I suspect it is
> more likely because they find there is an economic advantage to be gained
> by doing so.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
>
> with TLS 1.3.
> relationship that couldn't be enforced..   RPKI creates problems for human
>  Not using RPKI creates problems we can't deal with.
>

---

From: Bill Jouris <[email-masked]>
Date: Thu, 15 Nov 2018 21:32:00 +0000 (UTC)

It seems to me, however, that there is a fair amount of space between accounting for every possible business case that might arise (which we clearly can't) and totally ignoring the business impact of anything we do (which seems to have been the case heretofore).  

Simply saying "slippery slope" ignores the possibility of actually considering the impacts in specific cases and making judgement calls.  Certainly life is easier if we have a clear and simple rule about just where on the spectrum we will draw the line.  But developing that, to the extent it can be done, will require amassing a lot more experience than we have yet acquired on specific cases.  It seems past time that we at least start paying attention to something besides the narrowest technical issues. 
Bill Jouris

      From: Ted Lemon <[email-masked]>
 To: [email-masked] 
Cc: Mallory Knodel <[email-masked]>; Hrpc <[email-masked]>
 Sent: Thursday, November 15, 2018 1:11 PM
 Subject: Re: [hrpc] "We try to avoid"
   
Yes, I hear your point.   However, if the IETF were to take that on as a policy, the result would be that we would fail as a standards body, because no one protocol can reasonably account for every possible use case.   The problem we had in this case is that TLS is a screwdriver, and the proponents of the "break TLS" use case needed a hammer.   The solution to that is for them to use a hammer, not for the IETF to make a hamdriver.
The appropriate IETF response to the statement "TLS 1.3 doesn't work for my use case" is "hm, what is your use case, and how can we best address it."   We did that.   The problem is that the answer wasn't to the liking of the folks who wanted to instead break TLS.
This is precisely why we say that the IETF's purpose is not to get involved in that calculus.   It's simply out of our possible scope.   Of course there's no point in us building something that nobody will use, but when we build something, we need to build it to fit a particular use case; if there are two incompatible use cases, that means that we need to build two things.
On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris <[email-masked]> wrote:

Bill Jouris

---

From: Melinda Shore <[email-masked]>
Date: Thu, 15 Nov 2018 12:45:52 -0900

On 11/15/18 12:32 PM, Bill Jouris wrote:
> It seems to me, however, that there is a fair amount of space between
> accounting for every possible business case that might arise (which we
> clearly can't) and totally ignoring the business impact of anything we
> do (which seems to have been the case heretofore). 

I think this is represents a misunderstanding of the text.
The question is not about business cases, but how business
*models* are instantiated in the network.  For example, we
tend to assume that we're not going to change protocol
design for certain kinds of network device intermediation,
etc.  Sometimes we come out with competing protocols
(middlebox communication, for example) under the assumption
that it's best to let the market sort it out.  So, I think
you're misreading the intent.

Melinda

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 16:46:54 -0500

Again, I hear you, but you're missing the point.   The IETF has addressed
the particular use case that was being proposed for TLS 1.3.   They just
didn't do it with TLS 1.3.   TLS 1.3 addresses a different use case.   The
reason we "avoid policy and business questions as much as possible" is
precisely because if we don't, we wind up in discussions like the TLS 1.3
discussion and this discussion.   And there is no way for these discussions
to end, because we don't agree on our goals, and we are never going to.
 This is not because I'm a stubborn jerk, or because you're not listening.
 It's because we have different goals.

On Thu, Nov 15, 2018 at 4:32 PM Bill Jouris <[email-masked]> wrote:

> clearly can't) and totally ignoring the business impact of anything we do
> (which seems to have been the case heretofore).
>
> Simply saying "slippery slope" ignores the possibility of actually
> considering the impacts in specific cases and making judgement calls.
> Certainly life is easier if we have a clear and simple rule about just
> where on the spectrum we will draw the line.  But developing that, to the
> extent it can be done, will require amassing a lot more experience than we
> have yet acquired on specific cases.  It seems past time that we at least
> start paying attention to something besides the narrowest technical issues.
> Bill Jouris
>
> *To:* [email-masked]
> *Cc:* Mallory Knodel <[email-masked]>; Hrpc <[email-masked]>
> *Sent:* Thursday, November 15, 2018 1:11 PM
> The appropriate IETF response to the statement "TLS 1.3 doesn't work for
> my use case" is "hm, what is your use case, and how can we best address
> it."   We did that.   The problem is that the answer wasn't to the liking
> of the folks who wanted to instead break TLS.
>
> *To:* Mallory Knodel <[email-masked] <mallory@article19..org>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2018 21:59:01 +0000

> But just wondering, what is the original purpose of that statement?

I suspect that's a question to which you could get 100
answers from 50 IETFers, all of which'd be a little bit
correct:-)

FWIW, my take is a little different to Ted's but not
unrelated.

I think the idea was that it's better (in general) to
develop IETF technologies that interoperate and can be
used with many policies and business/operations models
and to not develop protocols that are specific to one
or a few policies or business models.

That doesn't mean we have to be pseudo-neutral and claim
that all policies and business models are equally ok, but
it does mean we don't need to reach consensus on our
opinions of them.

There are some policies though that are such that we did
need to consider them, e.g. in the case of RFC1984, where
the policy in question that we did need to consider was to
the effect that nobody (else) was allowed to use strong
crypto.

I suspect there's also an element of it just being more
interesting and tractable for IETFers to stick to the more
fun technical stuff and to not have to deal with often
painful discussions that can be involved when mucking about
with (or stopping people mucking about with) protocols
for purely policy or business reasons. It's basically far
easier (in the IETF) to debate the size of packets and
similar than it is to discuss why someone would want to
do something like break TLS or make money from ad auctions
that expose huge amounts of user data to all bidders.

S.

---

From: Mark Perkins <[email-masked]>
Date: Thu, 15 Nov 2018 22:48:25 +0000 (UTC)

Nalini
I think you have 'hit the nail on the head'..
Yes, business problems are realities BUT business problems are not neutral either. 

As you state, 

in some countries bandwidth is limited - Business Case A

on the other hand, large corporations can send large delegations, or become generous donors, to advance their profit making & competitive situation - Business Case B

I am sure we could come up with other business cases.

Protocol design should be about 'end users', with 'business users' being seen as intermediaries (important, but not ultimate). We should be VERY careful in avoiding strengthening existing business players position against newcomers. Just because a new protocol creates a business problem FOR THEM is no reason not to procede when the overall benefit to end users merits it.

As always, the devil is in the details

Mark P.

    On Friday, November 16, 2018, 7:59:55 AM GMT+11, Nalini J Elkins <[email-masked]> wrote:  
 
 Ted,

 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Nov 2018 14:54:57 -0800

> Protocol design should be about 'end users', with 'business users' being seen as intermediaries (important, but not ultimate). We should be VERY careful in avoiding strengthening existing business…

I agreed until you said that big companies (as opposed to small companies) weren't end users. They actually are, and may have different issues than smaller companies or individuals. It seems to me that we miss something important when we decide that, without input or data, we understand "end users" without considering all of them, and pick a solution that seems right to us.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Nov 2018 22:59:19 +0000

The name of this RG is human rights.

I hope we are not going to consider Corporations as possessing human rights.

---

From: Mark Perkins <[email-masked]>
Date: Thu, 15 Nov 2018 23:12:22 +0000 (UTC)

Totally agree Rich - this has become so evident regarding copyright
Mark P.

    On Friday, November 16, 2018, 9:59:28 AM GMT+11, Salz, Rich <[email-masked]> wrote:

---

From: Mark Perkins <[email-masked]>
Date: Thu, 15 Nov 2018 23:24:47 +0000 (UTC)

I agree that B2B implies that businesses are protocol end users - though without human rights. Thus in these terms, they would be out of scope. From a human rights perspective, they are only intermediaries.
In terms of practicalities, business protocol end user problems clearly count (otherwise the implementation of protocols could be limited), but these do not over-ride the human rights concerns (which are beyond business usage problems), 

Nor should business problems be either seen as an excuse for protecting existing advantages (eg. the whole copyright maximalist fiasco) nor as favoring a certain sector. As I stated, this makes the business problem calculus difficult, as protocol design needs to (should) look at the 'GLOBAL business problem(s)' , current & future, and not just particular cases...
Mark P.
   On Friday, November 16, 2018, 9:55:16 AM GMT+11, Fred Baker <[email-masked]> wrote:

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Fri, 16 Nov 2018 01:20:59 +0000

Businesses have HR and other responsibilities that can and do come into conflict with privacy considerations of employees. How that plays out in protocols is an important question.

Eliot

On Nov 16, 2018, at 08:25, Mark Perkins <marknoumea=[email-masked]<mailto:marknoumea=[email-masked]>> wrote:

Mark P.
On Friday, November 16, 2018, 9:55:16 AM GMT+11, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
hrpc mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/hrpc
_______________________________________________
hrpc mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/hrpc

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 06:16:28 +0000 (UTC)

Ted,
> It frustrates me that you feel comfortable impugning the motives of IETF participants who really tried very hard to engage on this issue
I don't know what leads you to say that I am doing that.   I am completely at a loss.   I have re-read what I wrote and I do not think anything in what I wrote would lead to your statement.
I am quite upset by what you are saying.  In the future, I think it is best to not respond to email threads from you.  It seems to lead to too much misunderstanding.   If at some point, you want to talk face to face, I am always open to that. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Ted Lemon <[email-masked]>
 To: Nalini Elkins <[email-masked]> 
Cc: Mallory Knodel <[email-masked]>; Hrpc <[email-masked]>
 Sent: Thursday, November 15, 2018 1:17 PM
 Subject: Re: [hrpc] "We try to avoid"
   
I'm pretty sure that the motivation for keeping TLS secure is that it benefits end users by preventing criminals (and businesses) from eavesdropping on their connections.   That was certainly my motivation for engaging in the discussion.   It frustrates me that you feel comfortable impugning the motives of IETF participants who really tried very hard to engage on this issue and propose solutions that addressed the use cases that we were talking about.   It was very frustrating to simply be told "no, you have to break your protocol for us because we won't use that other protocol that actually addresses our use case and wouldn't break TLS."
We may be wandering a bit off-topic, but in a sense this is an important discussion because when we get into a calculus like this, human rights are very much at risk.
On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins <[email-masked]> wrote:

Ted,

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 06:21:02 +0000 (UTC)

> I hope we are not going to consider Corporations as possessing human rights.
Have you so quickly forgotten Citizen's United?  Since corporations possess free speech rights why should they not possess "human rights"?
(Obviously a joke.) Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: "Salz, Rich" <[email-masked]>
 To: Fred Baker <[email-masked]>; Mark Perkins <marknoumea=[email-masked]> 
Cc: Mallory Knodel <[email-masked]>; Ted Lemon <[email-masked]>; Hrpc <[email-masked]>; Nalini Elkins <[email-masked]>
 Sent: Thursday, November 15, 2018 2:59 PM
 Subject: Re: [hrpc] "We try to avoid"

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 06:27:13 +0000 (UTC)

Mark,

> I think you have 'hit the nail on the head'..

Thanks!   .

> on the other hand, large corporations can send large delegations, or become generous donors, to advance their profit making & competitive situation - Business Case B

Yes, they *could*.  But as someone who works with these corporations daily, upper management does not always understand what problems the technicians have.   Also, there are pressures to make immediate quarterly profits vs. doing real long range planning.  You may wish to read "Tailspin: The People and Forces Behind America's Fifty-Year Fall--and Those Fighting to Reverse It" by Steven Brill.  It really illuminates some of the problems with the U.S. economy.  

It is in some ways the same problem as we have with our roads and infrastructure.  For such a rich country, why are our bridges falling down?   

We are working hard to show people the bigger picture and plan long term but it is not easy.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Mark Perkins <marknoumea=[email-masked]>
To: Ted Lemon <[email-masked]>; Mallory Knodel <[email-masked]>; Nalini J Elkins <[email-masked]> 
Cc: Hrpc <[email-masked]>
Sent: Thursday, November 15, 2018 2:48 PM
Subject: Re: [hrpc] "We try to avoid"

Nalini

As you state, 

Mark P.

Ted,

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Nov 2018 01:53:16 -0500 (EST)

On Fri, 16 Nov 2018, Nalini J Elkins wrote:

> Yes, they *could*.

They did. We were lucky it did not change the outcome this time.

> We are working hard to show people the bigger picture and plan long term but it is not easy.

I think your suggestion that the TLS group did not "see the bigger
picture" is quite wrong. It did see the bigger picture. It looked at
the requirements of the enterprise, the requirement of endusers and the
possible abuse of nation states, and concluded that the requirements for
"enterprise TLS" were at fundemantal disagreement with enduser safety. It
also concluded that everything needed for "enterprise customers" could
be done without protocol changes, provided there was control of the
enterprise user endpoint. It concluded the all proposed "enterprise"
or "datacenter" solutions did nothing to ensure it was actually limited
to that use case and could not be abused by nation states.

What was left was only an argument of "ease of use and money". Frankly,
I see this not as a problem but as an excellent opportunity for a new
StartUp to deliver TLS1.3 enterprise monitoring support. As long as it
is really "prohibitively expensive", there is an opportunity to make a
LOT of money. So I simply do not buy the money argument. Let the next
Cloudflare or Bluecoat or Palantir fix this. And the encumbents can
then likely just buy that startup and make even more money. It is a
win-win-win scenario for endusers, the free market and security.

Paul

---

From: [email-masked]
Date: Fri, 16 Nov 2018 01:45:11 -0500

Business and policy aspects are specialties.

They tend to seem terribly subjective or arbitrary when people trained
in, e.g., engineering try to do them or try to understand them without
that specialized background.

Yet a lot of the world still wants to understand, and is is obligated
to deal with, those aspects of technical progress.

And in the hands of those domain experts it generally isn't quite so
subjective or arbitrary as they rely on a broad knowledge of precedent
and their own forms of modeling etc.

Many years ago when I worked in research in the dept of physiology,
occupational health group, at the harvard school of public health we
employed a full-time economist whose job it was to add his perspective
to, for example, recommendations to limit occupational exposures.

Because it's one thing to show an industrial exposure causes
significant health problems -- what most of us there did for a living
-- but quite a different thing to model the economic and policy issues
mitigation would impose.

Our findings often ended up in front of congress and big insurance
agencies and affected businesses and they really wanted that whole
picture. Occasionally the president of the US would call with some
questions about relevant legislation he was being asked to sign.

The IETF really has only two choices at this point in history, other
than continuing to "wing" it:

Either grow specialized arms to address these issues (much like this
human rights group's intention), or allow others to do that which is
likely to take the engineering aspect out of the equation as we've
seen with important business and policy issues particularly of late.

There's an old expression which goes: The only thing scarier than an
electrical engineer writing software is a software engineer with a
soldering iron (or similar.)

We've reached a juncture where the only thing scarier than a network
engineer trying to develop policy and business models for technical
developments is policy and business people with jurisdiction over
technical standards.

Maybe it's a specialization which the IETF needs rather than this
breast-beating over how distracting it can be for engineers et al to
take responsibility for these aspects.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 16 Nov 2018 10:22:11 +0100 (CET)

> Il 16 novembre 2018 alle 7.53 Paul Wouters <[email-masked]> ha scritto:
> 

Well, the problem is that the distinction between technology and policy/business is artificial and often impossible to draw, as many technical choices have inherent economic and even political implications. Your reply about TLS illustrates this well: you say that this was a technical decision, and yet the statement that certain technical solutions were rejected by the IETF because they "could be abused by nation states" is deeply political: basically, the IETF is claiming the authority to judge what sovereign states do, define it as an abuse and take measures to prevent it from happening. Is there anything less technical and more political than this?

In the end, I think that the distinction was naive at the time it was conceived (or better, the Internet environment then was so small, uniform and specialized that it was possible to only focus on technical arguments, an option that disappeared as soon as the Internet became the main mass communication platform for the planet) and is hypocritical now. Of course this does not apply to every IETF standard, perhaps not even to a majority of them, but there are instances where the new IETF standards fundamentally alter the structure of an existing market or the balancing of powers between States and Internet corporations, yet it is claimed that these are just technical decisions because technology is "objective" and so if you disagree you are just a bad engineer, rather than a stakeholder with different views and needs that should also be accommodated.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 09:22:43 -0500

You said this:

> more likely because they find there is an economic advantage to be gained

On Fri, Nov 16, 2018 at 1:16 AM Nalini J Elkins <
[email-masked]> wrote:

> Ted,
>
> > It frustrates me that you feel comfortable impugning the motives of IETF
> participants who really tried very hard to engage on this issue
>
> I don't know what leads you to say that I am doing that.   I am completely
> at a loss.   I have re-read what I wrote and I do not think anything in
> what I wrote would lead to your statement.
>
> I am quite upset by what you are saying.  In the future, I think it is
> best to not respond to email threads from you.  It seems to lead to too
> much misunderstanding.   If at some point, you want to talk face to face, I
> am always open to that.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> *To:* Nalini Elkins <[email-masked]>
> *Sent:* Thursday, November 15, 2018 1:17 PM

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 09:34:42 -0500

The certain technical aspects of the plan to break TLS to which you refer
were rejected because they allow *anyone* to break TLS.   You are adding
"nation states" to make it political, but nation states are just one
example of who can use a broken TLS to violate users' rights.   My personal
worry is not nation states but identity thieves.   And again this
illustrates the principle nicely.   Because we were arguing over a
technical point, people who are afraid of nation-state eavesdropping can
agree with people who are afraid of getting ripped off by scammers.   The
principle is the same regardless of what is is that you fear.

By comparison, for example, the ability to eavesdrop has valuable societal
benefits in terms of preventing and exposing criminal activity.   How would
the IETF decide which good to promote and which to reject?   The answer is
that we would not, and can not.   As a policy, the IETF doesn't develop
protocols for the purpose of eavesdropping, not so much because we don't
think it's a good idea, although certainly many of us don't, but because
it's not a problem with a technical solution.   There is no way to have a
secure transport that enables eavesdropping, any more than you can find a
piece of ordinary matter that will levitate itself out of a gravity well.

On Fri, Nov 16, 2018 at 4:22 AM Vittorio Bertola <
[email-masked]> wrote:

> Well, the problem is that the distinction between technology and
> policy/business is artificial and often impossible to draw, as many
> technical choices have inherent economic and even political implications.
> Your reply about TLS illustrates this well: you say that this was a
> technical decision, and yet the statement that certain technical solutions
> were rejected by the IETF because they "could be abused by nation states"
> is deeply political: basically, the IETF is claiming the authority to judge
> what sovereign states do, define it as an abuse and take measures to
> prevent it from happening. Is there anything less technical and more
> political than this?
>
> In the end, I think that the distinction was naive at the time it was
> conceived (or better, the Internet environment then was so small, uniform
> and specialized that it was possible to only focus on technical arguments,
> an option that disappeared as soon as the Internet became the main mass
> communication platform for the planet) and is hypocritical now. Of course
> this does not apply to every IETF standard, perhaps not even to a majority
> of them, but there are instances where the new IETF standards fundamentally
> alter the structure of an existing market or the balancing of powers
> between States and Internet corporations, yet it is claimed that these are
> just technical decisions because technology is "objective" and so if you
> disagree you are just a bad engineer, rather than a stakeholder with
> different views and needs that should also be accommodated.
>
> Regards,
> --
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 16 Nov 2018 09:30:45 -0500

On Thu 2018-11-15 16:10:27 -0500, Ted Lemon wrote:
> involved in that calculus.  It's simply out of our possible scope.

I think this thread is fascinating.

IETF decisions (TLS 1.3 forward secrecy is just one example) very often
do have business and policy implications, as this thread alone has
clearly indicated.

So we "do" business and policy whether we want to pretend we do it or
not.

I disagree with Ted that the TLS 1.3 forward secrecy decision came down
to business/policy on one side and technical decisions on the other.
There were mutually-exclusive policy and technical arguments on both
sides, and we made a collective decision about which policy and
technical arguments were more important.

I think that the text Stephane cites (if it says anything meaningful at
all) says "don't expect us to come to consensus about business or policy
decisions", probably because we know that's basically impossible given
the range of competing perspectives and values that we hope will provide
concrete input to the IETF processes.

But we're making decisions about what structural choices are *possible*
on the largest-scale global communications infrastructure available.
And we're making decisions that often guide what becomes *common* in
that same infrastructure.  So of course those decisions have business
and policy implications.

I think it's better that we can make these decisions keeping this fact
in mind, instead of wishing it away or pretending that it ain't so.  But
i also understand that the engineering community has a storied history
of claiming that its work is "technical and apolitical" (up until the
point that it claims that it is "revolutionary"), and that's a tough
habit to break.

just for fun i'll try proposing some (probably terrible) alternate text
to see whether that makes things more clear.

    We try to avoid policy and business questions, as much as possible.

I'd turn it into something like:

    The IETF's work inevitably has business and policy implications,
    which we struggle with.  We appreciate when people raise those
    concerns as clearly as possible while simultaneously addressing the
    mechanical and technical impact of their preferred solutions.

All the best,

    --dkg

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 14:44:58 +0000 (UTC)

> We are working hard to show people the bigger picture and plan long term but it is not easy.
By "people", I meant the management of large enterprises, not the TLS WG. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Paul Wouters <[email-masked]>
 To: Hrpc <[email-masked]> 
 Sent: Thursday, November 15, 2018 10:53 PM
 Subject: Re: [hrpc] "We try to avoid"

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 09:46:32 -0500

Hm.   I think that the decision we made has clear policy implications,
sure.   But was the reason we made it because of those policy implications?

>From my perspective, the reason for rejecting it was that it was
technically bad: it created an attack surface that could only be mitigated
by user action, which as we know from painful experience means an attack
surface that can't be mitigated.

I don't really like your proposed text.   I think we do appreciate it when
people raise their non-technical concerns, but I also don't think we can
always address their non-technical concerns, and we ought not to suggest
otherwise.   Sometimes the right way to mitigate the problem with a
particular tool for a particular set of use cases is not to change the
tool, but to have a second tool.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 09:48:45 -0500

On Fri, Nov 16, 2018 at 9:45 AM Nalini J Elkins <
[email-masked]> wrote:

> By "people", I meant the management of large enterprises, not the TLS WG.
>

Can you unpack the distinction for me?   The TLS WG is made up of
participants most of whom work for companies, most of which have agendas.
 Either we are participating in the IETF process with our best intentions,
or we are tools of the corporate overlords.   You can't have it both ways,
and what you said very clearly implied the latter.

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 14:50:25 +0000 (UTC)

>So we "do" business and policy whether we want to pretend we do it or not.
+100
 Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Daniel Kahn Gillmor <[email-masked]>
 To: Hrpc <[email-masked]> 
 Sent: Friday, November 16, 2018 6:36 AM
 Subject: Re: [hrpc] "We try to avoid"

All the best,

    --dkg

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 14:53:23 +0000 (UTC)

> Can you unpack the distinction for me? 
My comment had absolutely nothing to do with TLS in particular.  I was responding to a comment by Mark about what corporations could do.  I was talking about what I am doing with my organization to bring awareness of standards activities in general to corporations.
 Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Ted Lemon <[email-masked]>
 To: Nalini Elkins <[email-masked]> 
Cc: Paul Wouters <[email-masked]>; Hrpc <[email-masked]>
 Sent: Friday, November 16, 2018 6:49 AM
 Subject: Re: [hrpc] "We try to avoid"
   
On Fri, Nov 16, 2018 at 9:45 AM Nalini J Elkins <[email-masked]> wrote:

> We are working hard to show people the bigger picture and plan long term but it is not easy.By "people", I meant the management of large enterprises, not the TLS WG.

Can you unpack the distinction for me?   The TLS WG is made up of participants most of whom work for companies, most of which have agendas.   Either we are participating in the IETF process with our best intentions, or we are tools of the corporate overlords.   You can't have it both ways, and what you said very clearly implied the latter.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 09:58:34 -0500

On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins <
[email-masked]> wrote:

> My comment had absolutely nothing to do with TLS in particular.
>

Perhaps not, but it clearly applies to the TLS working group as well as any
other.

The IETF consensus process is very deliberately designed to address exactly
the attack you're describing.   It is true that the firewall is not
perfect, but it's better than any other SDO's firewall against the same
problem; most SDOs actually consider this a feature, not a bug.

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 15:04:50 +0000 (UTC)

> exactly the attack you're describing
Excuse me?  What is the "attack"?  I have lost you here. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

 Sent: Friday, November 16, 2018 6:59 AM

Perhaps not, but it clearly applies to the TLS working group as well as any other.
The IETF consensus process is very deliberately designed to address exactly the attack you're describing.   It is true that the firewall is not perfect, but it's better than any other SDO's firewall against the same problem; most SDOs actually consider this a feature, not a bug._______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 16 Nov 2018 16:05:10 +0100 (CET)

Hello Ted,
 
first of all, I am not arguing that the decision of not having backdoors in cryptography was wrong - I am just discussing whether it can be qualified as a purely technical decision "because business models and policy issues are out of scope at the IETF".

> Il 16 novembre 2018 alle 15.34 Ted Lemon <[email-masked]> ha scritto: 
>  
> 
> The certain technical aspects of the plan to break TLS to which you refer were rejected because they allow anyone to break TLS.   You are adding "nation states" to make it political,

No, I did not add it, it was in the message I was quoting - and it shows that while people claim to have taken that decision only on technical arguments, most of them had non-technical issues well clear in their minds.

> but nation states are just one example of who can use a broken TLS to violate users' rights.   My personal worry is not nation states but identity thieves.   And again this illustrates the principle nicely.   Because we were arguing over a technical point, people who are afraid of nation-state eavesdropping can agree with people who are afraid of getting ripped off by scammers.   The principle is the same regardless of what is is that you fear.

But people who are afraid of organized crime, or who work for law enforcement, will disagree and say that you need something different. This kind of composite alliance between different stakeholders is absolutely normal... in any policy discussion.

> By comparison, for example, the ability to eavesdrop has valuable societal benefits in terms of preventing and exposing criminal activity.   How would the IETF decide which good to promote and which to reject?   The answer is that we would not, and can not.   As a policy, the IETF doesn't develop protocols for the purpose of eavesdropping,

So it's a policy chosen by the IETF, not a technical issue.

> not so much because we don't think it's a good idea, although certainly many of us don't, but because it's not a problem with a technical solution.   

This is not true - in fact, there have been technical proposals to add backdoors into cryptography. It's just that they would create more risks than they would solve, but technically it's entirely possible to have them.

> There is no way to have a secure transport that enables eavesdropping, any more than you can find a piece of ordinary matter that will levitate itself out of a gravity well.

That depends on a definition of "security" which is also a matter of policy: some people will argue that a transport protocol that can be easily used by criminals to escape law enforcement is not secure at all.
 
So I rather like dkg's stance - I think it's much closer to reality.
 
Ciao,
--

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 10:06:13 -0500

You described an attack on IETF process where corporations send so many
participants to the organization with the intention of overriding the
consensus process that they succeed in doing so.

On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins <
[email-masked]> wrote:

> Excuse me?  What is the "attack"?  I have lost you here.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> *Cc:* Paul Wouters <[email-masked]>; Hrpc <[email-masked]>
> *Sent:* Friday, November 16, 2018 6:59 AM
> The IETF consensus process is very deliberately designed to address
> exactly the attack you're describing.   It is true that the firewall is not

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 10:11:32 -0500

On Fri, Nov 16, 2018 at 10:05 AM Vittorio Bertola <
[email-masked]> wrote:

> > but nation states are just one example of who can use a broken TLS to
> violate users' rights.   My personal worry is not nation states but
> identity thieves.   And again this illustrates the principle nicely.
>  Because we were arguing over a technical point, people who are afraid of
> nation-state eavesdropping can agree with people who are afraid of getting
> ripped off by scammers.   The principle is the same regardless of what is
> is that you fear.
>
> But people who are afraid of organized crime, or who work for law
> enforcement, will disagree and say that you need something different. This
> kind of composite alliance between different stakeholders is absolutely
> normal... in any policy discussion.
>

People who actually understand the problem will not disagree and say you
need something different.   The problem is that too many people are
weighing in on the problem who don't understand the technical issues.
 Consider:
https://www.theatlantic.com/technology/archive/2018/10/president-trump-and-cell-phone-security/574096/

This is not true - in fact, there have been technical proposals to add
> backdoors into cryptography. It's just that they would create more risks
> than they would solve, but technically it's entirely possible to have them.
>

I think that we are talking across each other here.   Yes, you can make a
hammer that doesn't drive nails.   How to make a hammer that doesn't drive
nails is a technical problem.   But if your goal is to make a hammer that
drives nails, then the technical problem that you have to consider is how
to prevent it from not driving nails, not how to make it both drive nails
and not drive nails.

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 15:34:42 +0000 (UTC)

> where corporations send so many participants to the organization with the intention of overriding the consensus process that they succeed in doing so.
Actually, these people would then be active participants in the IETF, would they not?   Also, you have far more faith in my abilities than I do.    If I only had the eloquence to convince all these corporate heads to give me money and people to pull off such a tactic!  Also, if I had the eloquence to make everyone think all in the same way.   Enterprises are not a *block*.  They actually have different opinions.

Also, why are not other companies who send many people attackers?  If, for example, company x sends 50 people, do they all go from room to room humming in unison?  Is that what you are proposing that we do?
Why would you NOT want more people participating in the process?  That is my goal!   If you would like to sit in on the training and other sessions that I do to teach people from organizations how to participate in the IETF, you are more than welcome.

BTW, I just taught a class / lab on IPv6 where over 132 people from 70+ companies signed up.   Lee Howard will be working with me next year to teach more classes.   One of the people from Google has also offered to teach.   Also talking to ISOC about publicizing.   Don't we WANT enterprises learning about and using IPv6?   Hopefully, then these people will engage in the IETF also as a result.  As I say, if you want to help / sit in / teach, please let me know. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

 Sent: Friday, November 16, 2018 7:07 AM
   
You described an attack on IETF process where corporations send so many participants to the organization with the intention of overriding the consensus process that they succeed in doing so.

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 10:43:47 -0500

This is a very weird conversation.   I think we agree that there is a
potential for this attack.    I think we agree that it's not inevitable.
 I think we agree that we should try to avoid such attacks.   I think we
agree that we want operators to participate in the IETF, and that includes
enterprise operators.

My concern is that I'd really like to avoid a situation where we wind up
doing things that don't make sense technically because it's more convenient
than implementing the right technical solution.

On Fri, Nov 16, 2018 at 10:34 AM Nalini J Elkins <
[email-masked]> wrote:

> > where corporations send so many participants to the organization with
> the intention of overriding the consensus process that they succeed in
> doing so.
>
> Actually, these people would then be active participants in the IETF,
> would they not?   Also, you have far more faith in my abilities than I do.
>   If I only had the eloquence to convince all these corporate heads to give
> me money and people to pull off such a tactic!  Also, if I had the
> eloquence to make everyone think all in the same way.   Enterprises are not
> a *block*.  They actually have different opinions.
>
> Also, why are not other companies who send many people attackers?  If,
> for example, company x sends 50 people, do they all go from room to room
> humming in unison?  Is that what you are proposing that we do?
>
> Why would you NOT want more people participating in the process?  That is
> my goal!   If you would like to sit in on the training and other sessions
> that I do to teach people from organizations how to participate in the
> IETF, you are more than welcome.
>
> BTW, I just taught a class / lab on IPv6 where over 132 people from 70+
> companies signed up.   Lee Howard will be working with me next year to
> teach more classes.   One of the people from Google has also offered to
> teach.   Also talking to ISOC about publicizing.   Don't we WANT
> enterprises learning about and using IPv6?   Hopefully, then these people
> will engage in the IETF also as a result.  As I say, if you want to help /
> sit in / teach, please let me know.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> *Sent:* Friday, November 16, 2018 7:07 AM

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 15:46:17 +0000 (UTC)

> This is a very weird conversation.   
Yes.
> I think we agree that we want operators to participate in the IETF, and that includes enterprise operators.
Great! Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

 Sent: Friday, November 16, 2018 7:44 AM
   
This is a very weird conversation.   I think we agree that there is a potential for this attack.    I think we agree that it's not inevitable.   I think we agree that we should try to avoid such attacks.   I think we agree that we want operators to participate in the IETF, and that includes enterprise operators.
My concern is that I'd really like to avoid a situation where we wind up doing things that don't make sense technically because it's more convenient than implementing the right technical solution.

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Mallory Knodel <[email-masked]>
Date: Fri, 16 Nov 2018 18:50:54 +0300

> or a few policies or business models.

That makes sense. There are some cases where specific policies are the
impetus for a standard and that raised concerns.

> it does mean we don't need to reach consensus on our

Maybe we do, but in the larger context of also weighing policy against
technology. And on a case by case basis, not simply as an exercise on
its own.

> that expose huge amounts of user data to all bidders.

What about the idea of just removing this sentence then?

It happens, but not in any unified way, and on a case-by-case basis and
so perhaps it's just better not to dwell on whether or not we "do" this
and just edit it out.

-Mallory

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 11:03:41 -0500

I'm sorry, but I totally disagree on removing the sentence.   The fact that
we are having this conversation is evidence that the sentence is referring
to a real and relevant phenomenon.   A better approach to this from the
perspective of doing research into protocol considerations for human rights
would be to write a document describing the issue.   It's clear that
there's substantial nuance to this, and it would be good to capture that in
a document.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 16 Nov 2018 10:38:28 -0500

> sure.   But was the reason we made it because of those policy implications?

yes.  the policy outcome that we preferred is: TLS is an end-to-end
protocol with the strongest known cryptographic protections for
application data confidentiality, and we want to prioritize this
capacity so that people can rely on TLS for confidentiality as robustly
as possible.  Note that this is also a technical argument.

The labels "technical" and "policy" aren't mutually-exclusive, which
points to at least one problem with my proposed text.

> surface that can't be mitigated.

I agree with this too :)

> otherwise.

Does my text claim that we can always address every concern raised?  I
didn't intend that, and would welcome edits that made that clearer, if
you're interested.

> Sometimes the right way to mitigate the problem with a particular tool
> for a particular set of use cases is not to change the tool, but to
> have a second tool.

I also agree with this, though understanding which tool is the right
tool for any specific context requires understanding the technical,
political, and business impacts of the different tools.  That means we
need to make those tradeoffs as explicit as possible, if we want people
to be able to use the protocols we design effectively.

   --dkg

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Nov 2018 16:09:58 +0000 (UTC)

Ted,

> A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document 
> describing the issue. It's clear that there's substantial nuance to this,

OK, everyone sit down!   Ted, you and I are in substantial agreement on this.

But, guys, I was reflecting last night and wondering if actually what we need is something like a new RG.  That is "Business Considerations" just as we have "Privacy Considerations".  (Then I got exhausted just thinking about it!)

I don't know that this is really a human rights issue.  But it is an issue and a big one. 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Ted Lemon <[email-masked]>
To: Mallory Knodel <[email-masked]> 
Cc: Hrpc <[email-masked]>; Stephen Farrell <[email-masked]>
Sent: Friday, November 16, 2018 8:04 AM
Subject: Re: [hrpc] "We try to avoid"

I'm sorry, but I totally disagree on removing the sentence.   The fact that we are having this conversation is evidence that the sentence is referring to a real and relevant phenomenon.   A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document describing the issue.   It's clear that there's substantial nuance to this, and it would be good to capture that in a document.

On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 11:13:12 -0500

I think forking more irtf working groups on hrpc-related topics is not
going to work—I had to miss several meetings of this sort in Bangkok due to
conflicts, including the second session of hrpc, and I'm sure I'm not alone
in that.

I do sort of agree that this is out of the current scope, though.   What do
the chairs think about this?

On Fri, Nov 16, 2018 at 11:10 AM Nalini J Elkins <
[email-masked]> wrote:

> Ted,
>
>
> > A better approach to this from the perspective of doing research into
> protocol considerations for human rights would be to write a document
> But, guys, I was reflecting last night and wondering if actually what we
> need is something like a new RG.  That is "Business Considerations" just as
> we have "Privacy Considerations".  (Then I got exhausted just thinking
> about it!)
>
> I'm sorry, but I totally disagree on removing the sentence.   The fact
> that we are having this conversation is evidence that the sentence is
> referring to a real and relevant phenomenon.   A better approach to this
> from the perspective of doing research into protocol considerations for
> human rights would be to write a document describing the issue.   It's
> clear that there's substantial nuance to this, and it would be good to
> capture that in a document.
>

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 16 Nov 2018 18:17:11 +0100

> I'm sorry, but I totally disagree on removing the sentence.   The fact that we are having this conversation is evidence that the sentence is referring to a real and relevant phenomenon.   A better…

Hi Ted,

I would argue that this is exactly what draft-irtf-hrpc-political does: it outlines the inherent political and economical considerations in the standards process.

Best,

Niels

> 
> On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Head of Digital :: article19.org <http://article19.org>
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2018 12:20:41 -0500

I see why you are making this connection, but if that's the use case that
you want hrpc-political to address, it needs a lot of work.   I agree that
there's an overlap, but I don't think that hrpc-political is directly
addressing what Nalini is talking about, at least not as it is currently
written.

On Fri, Nov 16, 2018 at 12:17 PM Niels ten Oever <[email-masked]>
wrote:

> I would argue that this is exactly what draft-irtf-hrpc-political does: it
> outlines the inherent political and economical considerations in the
> standards process.
>
> Best,
>
> Niels
>
> >

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Nov 2018 10:35:37 +0700

> On Nov 16, 2018, at 22:46, Nalini J Elkins <[email-masked]> wrote:
> 
> Great!

I never said otherwise. They ‘participated’ and the outcome was lack of consensus on a use car they wanted. The process properly rejected the use case without consensus. Participating does not mean all your wishes are granted (and I am saying this as someone who saw an important draft die at the last IETF due to failed consensus) . 

Instead of taking the advise that their requirement should not happen at the protocol level but should happen at the implementation level, they went  to ETSI to work around the IETF, even going against previous complains of IETF to ETSI about ETSI calling their TLS protocol modification “xxxTLS”

To me this shows terrible judgement. Not only does it show the participants didn’t agree to our process, it shows they invaded IETF with a single goal and were never going to let themselves be convinced by the technical arguments within the IETF. That is, there was only a pretence of participating at the IETF.

I think bridges have been burned in this process, at the expensive of a safer internet. I for one, will remember this outcome the next time US Bank or the Symantec/Patient approaches me for advise.

Paul

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 17 Nov 2018 15:45:30 +0000 (UTC)

Paul,
>I never said otherwise. They ‘participated’ and the outcome was lack of consensus on a use car they wanted. The process properly rejected the use case without consensus. Participating does not mean all your wishes are granted >(and I am saying this as someone who saw an important draft die at the last IETF due to failed consensus) . 
>Instead of taking the advise that their requirement should not happen at the protocol level but should happen at the implementation level, they went  to ETSI to work around the IETF, even going against previous complains of IETF >to ETSI about ETSI calling their TLS protocol modification “xxxTLS”
>To me this shows terrible judgement. Not only does it show the participants didn’t agree to our process, it shows they invaded IETF with a single goal and were never going to let themselves be convinced by the technical arguments >within the IETF. That is, there was only a pretence of participating at the IETF.
 
They went to ETSI at the advice of IETF leadership and senior IETFers.   People TOLD them to go to another standards organization.  
Others are leading the effort at ETSI.  I am staying at the IETF to try to find a more secure, long-term solution down the road which incorporates their needs (and, of course, I want to stay and work on other issues at the IETF).  I hope people will work with me.
A number of enterprises feel they have their needs in this area.   Their needs will not go away.  They need to be addressed.
I will certainly say that there are hard feelings on both sides.   In fact, it was as a result of this whole incident, as well as others that I have seen at the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conflict Resolution at the IETF".   I do not want to start a discussion of that draft here.  After Thanksgiving, I will post it on the IETF-discuss email list.  This is something that the entire community needs to discuss.
I hope that we can build bridges.   The Internet is used for business.  I know that I myself do Internet banking, payment and so on.  I am not just doing google queries (or looking at the latest episode of "The Trump Show").    There are needs that need to be considered.
We need to work together.   I care deeply about the IETF.  It is a crucial part of the Internet ecosystem.  I do think we can improve some of our processes.   I hope the fact of my actions in continuing to participate actively on a number of issues at the IETF says that to you louder than any words could say by themselves.
I also care deeply about the enterprises and their needs.  I know them, they have been my world for the last 30 years.  When an issue gets passionate,  people can get tunnel vision and stop listening to others.  I hope we can learn to change that.  Believe me, I feel that there is plenty of blame to go around on all sides of this issue.  But, I hope we can learn from it to make our process better.  

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Paul Wouters <[email-masked]>
 To: Nalini J Elkins <[email-masked]> 
Cc: Ted Lemon <[email-masked]>; Hrpc <[email-masked]>
 Sent: Friday, November 16, 2018 7:36 PM
 Subject: Re: [hrpc] "We try to avoid"

Yes.
Great!

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Nov 2018 23:18:45 -0500 (EST)

On Sat, 17 Nov 2018, Nalini J Elkins wrote:

[this is turning into a TLS post mortem, and not just hrpc. Chairs: do let us know if we should take this topic elsewhere]

> They went to ETSI at the advice of IETF leadership and senior IETFers.   People TOLD them to go to another standards organization.  

I cannot speak for the IETF leadership, but I think the advise was
likely phrased as "it is a bad idea, and you cannot get it here. try
elsewhere if you really want to try this bad idea to be standarized".

> A number of enterprises feel they have their needs in this area.   Their needs will not go away.  They need to be addressed.

Since the 80s governments wanted backdoors in crypto. Their need has not
gone away. Yet we still believe not putting that in algorithm design is
the right approach. That is, your undying need in itself is not a
justification. Some things just cannot or should not be done.

> I will certainly say that there are hard feelings on both sides.   In fact, it was as a result of this whole incident, as well as others that I have seen at
> the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conflict Resolution at the IETF".   I do not want to start a discussion of that draft
> here.  After Thanksgiving, I will post it on the IETF-discuss email list.  This is something that the entire community needs to discuss.

I have read it but I feel that you are conflating a failed process with not
geting your desired outcome. While I do think IETF at times fails in
its process, I do not see how it failed on draft-green.
> 
> I hope that we can build bridges.   The Internet is used for business.  I know that I myself do Internet banking, payment and so on.  I am not just doing
> google queries (or looking at the latest episode of "The Trump Show").    There are needs that need to be considered..

Those needs were considerated at length, and the outcome was that there
was no secure way of covering your needs with protocol changes. The
recommendation was to do this at the implementation level.

> We need to work together.

Working together does not mean you are guaranteed your desired outcome.

> I do think we can improve some of our processes.

I agree in general we can and should. But frankly, I do not see a
process improvement that would have an outcome for biulding a MITM
infrastructure that the enterprise people want that is not strictly
limited to enterprise or data center only without potential abuse
by small criminals or nation states.

> I also care deeply about the enterprises and their needs.  I know them, they have been my world for the last 30 years.  When an issue gets passionate, 
> people can get tunnel vision and stop listening to others.  I hope we can learn to change that.  Believe me, I feel that there is plenty of blame to go
> around on all sides of this issue.  But, I hope we can learn from it to make our process better.  

I disagree with "tunnel vision" and "getting passionate" and "make the
process better" with respect to the specific "enterprise TLS" needs. You
feel this is reaching out to the generic IETF, but to me it appears
more as a sign you misunderstood the process and why this outcome was
rightfully reached.

Paul

---

From: Melinda Shore <[email-masked]>
Date: Sat, 17 Nov 2018 19:35:26 -0900

> elsewhere if you really want to try this bad idea to be standarized".

I don't think it was even that, but rather what you cite a few

> recommendation was to do this at the implementation level.

Indeed.  I'll also note that I view forum shopping, as has
been done in this case, is a de facto rejection of the recommendation
that was given.  It's also, by definition, not very consensus-y, so
I'm not sure on what basis advice about process failures is being
advanced, here.

Melinda

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 18 Nov 2018 05:35:17 +0000 (UTC)

Paul,
> [this is turning into a TLS post mortem, and not just hrpc. Chairs: do let us know if we should take this topic elsewhere]
Yes, absolutely happy to take this elsewhere or just have a personal conversation.

>I cannot speak for the IETF leadership, but I think the advise was>likely phrased as "it is a bad idea, and you cannot get it here. try>elsewhere if you really want to try this bad idea to be standarized".

You should really ask the people involved in the leadership to comment on what was said.As I recall at the time, what was said was along the lines of if you have needs, thenyou should go to another standards organization to see if you can get them met. It wasvery definitely NOT phrased in the way you have put it.
And, truthfully, the way you are phrasing it feels quite disrespectful.    

>Since the 80s governments wanted backdoors in crypto. Their need has not>gone away. Yet we still believe not putting that in algorithm design is>the right approach. That is, your undying need in itself is not a>justification. Some things just cannot or should not be done.
Again, with all due respect, this is your opinion rather than an indisputable fact.  I will tell you that others disagreewith you. 

>> I will certainly say that there are hard feelings on both sides.   In fact, it was as a result of this whole incident, as well as others that I have seen at>> the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conflict Resolution at the IETF".   I do not want to start a discussion of that draft>> here.  After Thanksgiving, I will post it on the IETF-discuss email list.  This is something that the entire community needs to discuss.
>I have read it but I feel that you are conflating a failed process with not geting your desired outcome. 

Please do not make assumptions about what I do and don't think.  For example, you don't know that I actually think that draft-green IS the right solution.   What I have always wanted is for enterprises to have a voice.  And for the IETF to work with them.

>While I do think IETF at times fails in its process, I do not see how it failed on draft-green.
The fact that many months after the decision, there are so many hard feelings between so many people that we can hardly talk about this issuewithout it erupting into chaos would lead me to think that there is probably a better way.   You and I are talking about different things.This level of hard feelings is a huge waste of time and energy for many people.  Not to mention the fact that now there are multiple standardswhich may be in conflict.  If you think this is a successful process and outcome, then I would beg to differ.
I suspect that you are talking about the "process" or "outcome" as that draft-green was not adopted. Please let me know if that is true.  I do not want to make assumptions about what you are saying.  Because I certainly do not like people making assumptions about what I am saying.   

> >> I hope that we can build bridges.   The Internet is used for business.  I know that I myself do Internet banking, payment and so on.  I am not just doing>> google queries (or looking at the latest episode of "The Trump Show").    There are needs that need to be considered..
>Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The>recommendation was to do this at the implementation level.
Again, I disagree with you.  I have talked to a number of cryptographers and there may be number of potential ways of doing this without violating thesecurity guarantees of TLS.  But, this is not the time to bring up any potential new ideas.

>Working together does not mean you are guaranteed your desired outcome.
Frankly, this feels condescending.   Please give me credit for a modicum of intelligence. 

>I agree in general we can and should. But frankly, I do not see a>process improvement that would have an outcome for biulding a MITM>infrastructure that the enterprise people want that is not strictly>limited to enterprise or data center only without potential abuse>by small criminals or nation states.

The process improvement is not about anything in TLS but about how we go about getting to consensus.

>> I also care deeply about the enterprises and their needs.  I know them, they have been my world for the last 30 years.  When an issue gets passionate, >> people can get tunnel vision and stop listening to others.  I hope we can learn to change that.  Believe me, I feel that there is plenty of blame to go>> around on all sides of this issue.  But, I hope we can learn from it to make our process better.  
>I disagree with "tunnel vision" and "getting passionate" and "make the>process better" with respect to the specific "enterprise TLS" needs. You>feel this is reaching out to the generic IETF, but to me it appears>more as a sign you misunderstood the process and why this outcome was>rightfully reached.
Again, we are talking about very different things. 
 Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Bill Jouris <[email-masked]>
Date: Sun, 18 Nov 2018 05:43:28 +0000 (UTC)

> Some things just cannot or should not be done. 
I agree completely.  
But it must be noted that this is NOT a purely technical decision.  Indeed, it is inherently a political (or, if you prefer, a moral) judgement.  Precisely the kind of non-technical factor that, previously in this thread, were being denounced as outside IETF's proper sphere.  
Bill Jouris 

Sent from Yahoo Mail on Android 
 
  On Sat, Nov 17, 2018 at 8:19 PM, Paul Wouters<[email-masked]> wrote:   On Sat, 17 Nov 2018, Nalini J Elkins wrote:

Paul

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 18 Nov 2018 13:53:07 +0000 (UTC)

>limited to enterprise or data center only without potential abuse>by small criminals or nation states.
Is the "potential abuse by small criminals and nation states" in the TLS charter or is that your political belief at work?
Is it that certain political stances are OK to hold and others not OK?  
So you are really telling me that the decision is political / moral, not technical? Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Paul Wouters <[email-masked]>
 To: Nalini J Elkins <[email-masked]> 
Cc: Hrpc <[email-masked]>
 Sent: Saturday, November 17, 2018 8:18 PM
 Subject: Re: [hrpc] "We try to avoid"

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Nov 2018 14:19:35 +0000

On 17/11/2018 15:45, Nalini J Elkins wrote:
> They went to ETSI at the advice of IETF leadership and senior
> IETFers.   People TOLD them to go to another standards organization.
I do not believe the above are accurate statements.

If they are, please say who said what to whom. If you cannot,
it'd be far better to not make such statements that you can't
substantiate.

My understanding is that the threat of that kind of forum
shopping was an argument used by those who wanted to break
TLS, as in "if you don't give us what we want, we'll go
<there> and do it" (<there> being either ETSI or ANSI at
the time, as we can now see they forum shopped over to ETSI
for their rubber stamp).

I've no idea where that idea/plan originated but if it did
come from IETF leadership (as in IAB or IESG members), then
it would be useful to the community to know that. If it did
not, then I'd suggest you clarify at least that as some (me
included) would like to give nomcom feedback about any IESG
or IAB member who gave such "advice."

S.

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 18 Nov 2018 14:33:11 +0000 (UTC)

> if it did come from IETF leadership (as in IAB or IESG members), then it would be useful to the community to know that.
Indeed it did.  Our enterprises are frankly not savvy enough to know how to "forum shop".   They did not even know how to spell ETSI.
Let me check with them and get exactly who told them that.     Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Stephen Farrell <[email-masked]>
 To: Nalini J Elkins <[email-masked]> 
Cc: Hrpc <[email-masked]>
 Sent: Sunday, November 18, 2018 6:19 AM
 Subject: Re: [hrpc] "We try to avoid"

S._______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: [email-masked]
Date: Sun, 18 Nov 2018 17:28:35 -0500

> justification. Some things just cannot or should not be done.

What's stopping them?

They should just call their NSA crypto geniuses (and I don't mean that
sarcastically they really do hire many crypto geniuses), or equivalent
for other countries, or form and fund some sort of multinational
research group, and ask them to design something according to their
desired specifications and present that to the world.

I first got on the net ca 1978 and just about every time I showed it
to someone their first question was: Hmm, fascinating, but...who is in
charge of all this?

Every...single...time.

People still imagine there's some core committee in charge of the
internet who, if you could just get on the phone and bend their ear,
would fix perceived deficiencies.

So they yell at Facebook, Google, ICANN, Apple, etc, the headline
target du jour, and often just at megaphones aimed nowhere in
particular.

Next time a govt spokesperson asks for this the right question to ask
is:

  And who are you addressing this request to, specifically?

And you'll be shrugged away because they don't know. They think
they're running some sort of political campaign at best.

-- 
        -Barry Shein

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Nov 2018 23:37:18 +0000

On 18/11/2018 14:33, Nalini J Elkins wrote:
>> if it did come from IETF leadership (as in IAB or IESG members),
>> then it would be useful to the community to know that.
> Indeed it did.  Our enterprises are frankly not savvy enough to know
> how to "forum shop".

The dearth of technology clue from those claiming a need to
break TLS for their enterprise use cases certainly was notable.
Personally, I was extremely puzzled by that as I've never dealt
with any bank that was so ignorant of the technology that they
themselves use in my 20+ years of occasionally dealing with banks.
(Dating back to when I wrote code for EDIFACT message signatures
in the early 1990's.)

> They did not even know how to spell ETSI. 

They do seem to have fairly speedily found a spell checker;-)

> Let
> me check with them and get exactly who told them that.     Thanks,

That'd be good. Or else please do let us know we don't need to
worry that IESG/IAB members are advising people on how to do an
end-run around IETF processes by getting an ETSI rubber stamp.

S.

> 
> Nalini Elkins CEO and Founder Inside Products, Inc. 
> www.insidethestack.com (831) 659-8360
> 
> From: Stephen Farrell <[email-masked]> To: Nalini J Elkins
> <[email-masked]> Cc: Hrpc <[email-masked]> Sent:
> Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try to
> avoid"
> 
> 
> 
> If they are, please say who said what to whom. If you cannot, it'd be
> far better to not make such statements that you can't substantiate.
> 
> My understanding is that the threat of that kind of forum shopping
> was an argument used by those who wanted to break TLS, as in "if you
> don't give us what we want, we'll go <there> and do it" (<there>
> being either ETSI or ANSI at the time, as we can now see they forum
> shopped over to ETSI for their rubber stamp).
> 
> I've no idea where that idea/plan originated but if it did come from
> IETF leadership (as in IAB or IESG members), then it would be useful
> to the community to know that. If it did not, then I'd suggest you
> clarify at least that as some (me included) would like to give nomcom
> feedback about any IESG or IAB member who gave such "advice."
> 
> S._______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> 
> 
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 18 Nov 2018 23:50:40 +0000 (UTC)

>break TLS for their enterprise use cases certainly was notable.

What I meant is that they do not know how the standards world works.
They are users of the protocols.  If there is any ignorance, then inthe interests of getting the best feedback possible, we should behelping them to express themselves instead of criticizing them.   They are novices in this world.
They have a great deal of expertise and experience in operating largenetworks.  We need the help of such operators to make our protocolsbetter.  I am sure there is much about their world that you do not know.
I invite you specifically to work with me on the IPv6 and other trainingthat I do with enterprise operators.  The more the IETF and enterprisesknow each other and their world, the better I believe we all will be.   They are not going away.   For engineers, ignoring portions of realityis a bad idea.
I applaud them for stepping into such an intimidating arena as theTLS Working Group. 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

Sent: Sunday, November 18, 2018 3:37 PM

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Nov 2018 00:01:14 +0000

On 18/11/2018 23:50, Nalini J Elkins wrote:
>> The dearth of technology clue from those claiming a need to break
>> TLS for their enterprise use cases certainly was notable.
> 
> 
> What I meant is that they do not know how the standards world works

Fair enough.

OTOH what I meant was that the level of ignorance of their
own systems demonstrated by the repeated presentation of
slide 3 of [1] seemed then, and still seems, incredible. I
haven't ever had a meeting with a bank that involved such
a lack of knowledge of their own systems. But maybe I've
just been lucky in the banks with which I've had meetings.

   [1]
https://datatracker.ietf.org/meeting/99/materials/slides-99-tls-sessb-impact-of-tls-13-on-network-ops-00

> They are users of the protocols.  If there is any ignorance, then
> inthe interests of getting the best feedback possible, we should
> behelping them to express themselves instead of criticizing them.

I don't see how one can offer meaningful feedback to someone
who openly declares ignorance of their own systems to be honest.
Not in an IETF context anyway. (Perhaps there's a relevant
self-help organisation somewhere for such sysadmins, but the
IETF is not that organisation;-)

S.

> They are novices in this world. They have a great deal of expertise
> and experience in operating largenetworks.  We need the help of such
> operators to make our protocolsbetter.  I am sure there is much about
> their world that you do not know. I invite you specifically to work
> with me on the IPv6 and other trainingthat I do with enterprise
> operators.  The more the IETF and enterprisesknow each other and
> their world, the better I believe we all will be.   They are not
> going away.   For engineers, ignoring portions of realityis a bad
> idea. I applaud them for stepping into such an intimidating arena as
> theTLS Working Group. Thanks,
> 
> ________________________________ From: Stephen Farrell
> <[email-masked]> To: Nalini J Elkins
> Sunday, November 18, 2018 3:37 PM Subject: Re: [hrpc] "We try to
> avoid"
> 
> 
> 
> 
> 
>> Indeed it did.  Our enterprises are frankly not savvy enough to
>> know how to "forum shop".
> 
> The dearth of technology clue from those claiming a need to break TLS
> for their enterprise use cases certainly was notable. Personally, I
> was extremely puzzled by that as I've never dealt with any bank that
> was so ignorant of the technology that they themselves use in my 20+
> years of occasionally dealing with banks. (Dating back to when I
> wrote code for EDIFACT message signatures in the early 1990's.)
> 
> That'd be good. Or else please do let us know we don't need to worry
> that IESG/IAB members are advising people on how to do an end-run
> around IETF processes by getting an ETSI rubber stamp.
> 
> S.
> 
>> 
>> From: Stephen Farrell <[email-masked]> To: Nalini J
>> Elkins <[email-masked]> Cc: Hrpc <[email-masked]>
>> Sent: Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try
>> to avoid"
>> 
>> 
>> 
>> If they are, please say who said what to whom. If you cannot, it'd
>> be far better to not make such statements that you can't
>> substantiate.
>> 
>> was an argument used by those who wanted to break TLS, as in "if
>> you don't give us what we want, we'll go <there> and do it"
>> (<there> being either ETSI or ANSI at the time, as we can now see
>> they forum shopped over to ETSI for their rubber stamp).
>> 
>> I've no idea where that idea/plan originated but if it did come
>> from IETF leadership (as in IAB or IESG members), then it would be
>> useful to the community to know that. If it did not, then I'd
>> suggest you clarify at least that as some (me included) would like
>> to give nomcom feedback about any IESG or IAB member who gave such
>> "advice."
>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Nov 2018 00:13:27 -0500 (EST)

> Is the "potential abuse by small criminals and nation states" in the TLS charter or is that your political belief at work?

A charter cannot cover the denial of every idea that someone might come
up with. The way the IETF works is that you suggest to update the charter. In
this case, I assume there was no consensus for the charter to be updated
to include this request.

> Is it that certain political stances are OK to hold and others not OK?  

This again mixes up technical with political. Since the first Crypto
War, people have tried to come up with a way that ensures the good
people can eavesdrop everyone for safetey and security without giving
the bad people similar or the same capability as a result. To date,
no such solution has been found. Once such a technical solution is
found, a charter discussion could be started, but more likely, this
would have to involve more then the TLS WG, because the identical case
would present itself at various other layers and protocols (eg IPsec)

> So you are really telling me that the decision is political / moral, not technical?

No I am not. I only touched the technical part. I happen to also believe
from a society point of view, that one cannot define good people and bad
people or good governments and bad governments as a static concept. So
if we could find a technical way, then we would have a really hard
non-technical issue at the IETF worth forming a WG over.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Nov 2018 00:45:44 -0500 (EST)

> And, truthfully, the way you are phrasing it feels quite disrespectful.    

And so do your repeated statements that the IETF has not listened to the
enterprise people.

> Again, with all due respect, this is your opinion rather than an indisputable fact.  I will tell you that others disagree

They should look into how Bill Clinton went from Clipper Chip to
dropping crypto export restrictions.

I'm sure some authoritarian or wanna-be-authoritarian regimes disagree
with my opinion on the social aspects of citizen monitoring. I am also
sure some companies believe their network should not comply to local
law, but that does not make it more legal to monitor their employees.

I also realise that different laws are posing a contradicting
requirement to some enterprises. However, that is is not something the
IETF can address.

> Please do not make assumptions about what I do and don't think.  For example, you don't know that I actually think that draft-green IS the
> right solution.   
> What I have always wanted is for enterprises to have a voice.  And for the IETF to work with them.

You are mistaken about my assumptions. My only assumption here is that I
know the enterprise people's voices were heard, and that you keep
repeating they were not. That is why I say you confuse the process with
the outcome. I have no opinion about your opinion on draft-green.

> The fact that many months after the decision, there are so many hard feelings between so many people that we can hardly talk about this issue
> without it erupting into chaos would lead me to think that there is probably a better way.   You and I are talking about different things.
> This level of hard feelings is a huge waste of time and energy for many people.  Not to mention the fact that now there are multiple
> standards
> which may be in conflict.  If you think this is a successful process and outcome, then I would beg to differ.

US bank approached me before going public with their requirements. It
turned out they approached many more individuals privately at first.
I told them during that first meeting that what they wanted was simply
impossible. I am sure many more people told them so as well. I do not
think we could have done much different at the IETF process when they
decided to forge ahead anyway, despite numerous people telling them
they would never get conensus for what they were seeking, and that
their arguments for "our networks are too big" were seen as mostly a
cost-savings requests, and not strong enough to open up a core internet
end-to-end security protocol.

On top of that, the IETF wrote RFC 8404 where it documented the problems
that the enterprise administrators are facing.

> >Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The
> Again, I disagree with you.

You mean you disagree with the TLS WG and/or the IETF Security Area. I
was not talking about my personal opinion here.

> I have talked to a number of cryptographers and there may be number of potential ways of doing this without
> violating the
> security guarantees of TLS.  But, this is not the time to bring up any potential new ideas.

I'm always happy to discuss technical ideas and read drafts.

> Frankly, this feels condescending.   Please give me credit for a modicum of intelligence. 

But do you understand that by saying "we need to work together" that you
are implying that "we did not work well together before" ? And that from
an IETF point of view, the IETF worked very well with the enterprise
people and that the outcome of working together was a lack of consensus?

> The process improvement is not about anything in TLS but about how we go about getting to consensus.

While I appreciate the efforts of your draft, I am still not convinced
there was any way in which we could have gained consensus unless a new
technological invention we haven't managed to invent in 20 years would
suddenly present itself? So I do question the premise of you writing
this draft now. Whether I think we can improve our consensus forming,
then yes I think we can and I have a very specific personal case regarding
a draft in mind. Although I am not sure a document can address some
cultural issues we have within the IETF, it won't hurt to try and
formulate things, so I am happy to continue reading updated drafts
on this.

> Again, we are talking about very different things. 

You keep bringing up the enterprise case as example for bad consensus
forming and now you keep saying you are writing this because of
different things. When you bring up "tunnel vission" and the
"enterprise use case" in one email, it does seem to be related, and
thus in turn that is what upsets me about your emails when it appears
these critisisms of tunnel vission and getting passionate seem aimed
at the part of the TLS WG that spoke out against the enterprise use
case. I will try to feel less personally attacked. but I urge you to
better separate these two topics when talking about either topic.

Paul

---

From: Nalini J Elkins <[email-masked]>
Date: Tue, 20 Nov 2018 02:57:36 +0000 (UTC)

> And so do your repeated statements that the IETF has not listened to the enterprise people.
It is not my intention to be disrespectful.   What I feel is that both parties feel not listened to.
If I can put it in terms of Jane and Bob.
1.  Jane feels that she is listening to Bob.
2.  Bob feels that he is not being heard by Jane.
3.  Bob feels that he is listening to Jane.
4.  Jane feels that she is not being heard by Bob.
I feel that is the situation that we are in.
BTW, it is not just the TLS group and the enterprises.  I think that just happens to be the issue that you and I seem to talk about.   I am sure that you and I will have many differences of opinion in HRPC as well!  I have seen such issues in many WGs : QUIC, v6ops, 6man, and on and on. 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Paul Wouters <[email-masked]>
 To: Nalini J Elkins <[email-masked]> 
Cc: Hrpc <[email-masked]>
 Sent: Sunday, November 18, 2018 9:46 PM
 Subject: Re: [hrpc] "We try to avoid"

Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2018 22:51:56 -0500

The problem is that if what it takes for you to "feel heard" is that you
get your way, then that's not going to work, as you can quickly see if you
game out how this would go in the scenario you offered.   So what does it
take to "feel heard" and not get your way?   This would be something
interesting to explore, but I think the answer is that that was not on the
table in this particular case—in this case "feeling heard" and "getting
your way" were synonymous for the particular enterprise folks who tried to
change the requirements for TLS 1.3.

On Mon, Nov 19, 2018 at 9:57 PM Nalini J Elkins <
[email-masked]> wrote:

> BTW, it is not just the TLS group and the enterprises.  I think that just
> happens to be the issue that you and I seem to talk about.   I am sure that
> you and I will have many differences of opinion in HRPC as well!  I have
> seen such issues in many WGs : QUIC, v6ops, 6man, and on and on.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> *From:* Paul Wouters <[email-masked]>
> *To:* Nalini J Elkins <[email-masked]>
> *Sent:* Sunday, November 18, 2018 9:46 PM
> > >> A number of enterprises feel they have their needs in this area.
>  Their needs will not go away.  They need to be addressed.
> >
> > Again, with all due respect, this is your opinion rather than an
> indisputable fact.  I will tell you that others disagree
> > with you.
>
> > Please do not make assumptions about what I do and don't think.  For
> example, you don't know that I actually think that draft-green IS the
> > right solution.
> > The fact that many months after the decision, there are so many hard
> feelings between so many people that we can hardly talk about this issue
> > without it erupting into chaos would lead me to think that there is
> probably a better way.   You and I are talking about different things.
> > This level of hard feelings is a huge waste of time and energy for many
> people.  Not to mention the fact that now there are multiple
> > standards
> > >> I also care deeply about the enterprises and their needs.  I know
> them, they have been my world for the last 30 years.  When an issue gets
> > passionate,
> > >> people can get tunnel vision and stop listening to others.  I hope we
> can learn to change that.  Believe me, I feel that there is plenty
> > of blame to go
> > >process better" with respect to the specific "enterprise TLS" needs..
> You