Subject: [arch-d] Time to reboot RFC1984 and RFC2804?

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Oct 2020 08:27:05 +1300

Not to mention RFC 7258.

Orders from the Top: The EU’s Timetable for Dismantling End-to-End Encryption:
https://www.eff.org/deeplinks/2020/10/orders-top-eus-timetable-dismantling-end-end-encryption

Five Eyes and Japan call for Facebook backdoor to monitor crime
https://asia.nikkei.com/Business/Technology/Five-Eyes-and-Japan-call-for-Facebook-backdoor-to-monitor-crime
 
Regards
   Brian Carpenter

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Oct 2020 17:20:04 -0400

--On Monday, October 12, 2020 08:27 +1300 Brian E Carpenter
<[email-masked]> wrote:

> Not to mention RFC 7258.
> 
> Orders from the Top: The EU's Timetable for Dismantling
> End-to-End Encryption:
> https://asia.nikkei.com/Business/Technology/Five-Eyes-and-Japa
> n-call-for-Facebook-backdoor-to-monitor-crime  

Brian,

This, plus another variation on the theme [1], is what has been
concerning me for some time.  It has caused an occasional rant
but I'm mostly stayed silent because the IETF consensus (at
least when 7258 was published) seemed clear.

It seems to me that we (very broadly defined) may be headed into
a period in which:

(1) We are forced into a choice between encryption and other
technical privacy protections against attacks (borrowing the
7258 language) by individuals and attacks by governments
(including law enforcement), especially governments who have
jurisdiction over the sender, receiver, or other.  The default
if we don't choose and make the distinction clear to others may
be "neither".

and/or 

(2) We are forced into a choice between an open and global
Internet and one that is very fragmented with security and
privacy protective only within mutually-isolated more local
networks.  We would have either no communication among those
local networks or content filtering, application-level, gateways
at politically selected boundaries.  Refusing to chose might
result in both bad outcomes.

I want to stress that I do not advocate or welcome being forced
into those choices or any of the outcomes they might imply.  But
I think it may be where we are headed, with the two pieces you
cite above, increased pressure for "law enforcement access" in a
variety of places, etc., possibly just being road signs on that
path.

Sadly,
    john

[1] The other concern that goes with this involves assorted
enterprises deciding they need to protect themselves from
assorted bad stuff by examination of content crossing their
boundaries. For a subset of them (and their firewall, etc.)
providers, the shift to "encryption everywhere" creates a
challenge that they see no way to deal with other by eliminating
client desktop to server (or other end to end) encryption and
replacing it with client to middlebox/ middlebox to server
mechanisms, preserving encryption across the public Internet at
the cost of a single point of failure with access to cleartext
at their boundary middleboxes.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 11 Oct 2020 15:50:05 -0700

> result in both bad outcomes.

There may be something else. The government actions typically operate
through application providers acting as gatekeepers, as in "Facebook,
please provide me a clear-text version of these messages". If there are
just a few platforms managing a large share of the communications,
governments merely have to lean onto these platforms to obtain what they
want. And if a company is running a big communication business, it will
come to terms with local governments in order to protect that business.
If the IETF wants to protect individual freedoms, then it might want to
focus on distributed architecture for communication services.

-- Christian Huitema

---

From: Mo Balaa <[email-masked]>
Date: Mon, 12 Oct 2020 02:42:24 -0500

Shameless plug for some experimental protocols we’ve been developing. We call them Noteworthy (class of) distributed overlay protocols. TBH we aren’t experts at this kind of stuff but are concerned that the window of opportunity to establish these types of FOSS standards/strategies is rapidly closing. We are actively seeking contributors, mentors or advisors. We are imagining meta-protocols build atop decentralized messaging protocols like Matrix. We have a working prototype.

https://github.com/decentralabs/noteworthy

> On Oct 11, 2020, at 5:50 PM, Christian Huitema <[email-masked]> wrote:
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Oct 2020 15:27:24 -0400

--On Sunday, October 11, 2020 15:50 -0700 Christian Huitema
<[email-masked]> wrote:

>> It seems to me that we (very broadly defined) may be headed
>> into a period in which:
>> 
>> if we don't choose and make the distinction clear to others
>> may be "neither".
>...

> There may be something else. The government actions typically
> operate through application providers acting as gatekeepers,
> as in "Facebook, please provide me a clear-text version of
> these messages". If there are just a few platforms managing a
> large share of the communications, governments merely have to
> lean onto these platforms to obtain what they want. And if a
> company is running a big communication business, it will come
> to terms with local governments in order to protect that
> business. If the IETF wants to protect individual freedoms,
> then it might want to focus on distributed architecture for
> communication services.

Indeed.  While I see that as a special case of "who are we
trying to protect against", it is quite different in some ways
and worth calling out separately.   But it also means we should
be thinking very carefully about technologies that, rather than
keeping some information private, merely shifts around who has
access to it to a different (and smaller) set of large providers
who might have trouble resisting strong and focused government
pressures such as those you identify.   DoT and DoH come to mind
as things we should probably look again at from the perspective
of whether they increase the kind of concentration (and
associated risks) that you warn against.  So do anti-spam
technologies such as DMARC and, although it is much further from
the IETF's responsibilities, strategies to protect personal
information in DNS registry databases by effectively insuring
that large registry operators are the only ones with general
access to those data.

FWIW, I have noticed that there is one big difference between my
running my own servers for mail, storage, etc., and passing
those off to a large cloud or virtual service providers.  If
some governmental entity comes to that provider with sufficient
legal documents or threats (of the sort you mention or of the
use of force) and says "give me his files and records and don't
tell him we asked", they presumably get them and I presumably
don't find out.   If they come to me with the same request
(putting aside whether I would be able to destroy everything and
would have the nerve to do that), they presumably get the files
but there is zero chance of keeping me from finding out about
the request.  Sometimes that is important, sometimes not, but,
where it is important, distributed architectures and protocols
and operational arrangements that encourage highly distributed
services are prerequisite.

thanks,
   john

---

From: Andrew Campling <[email-masked]>
Date: Mon, 12 Oct 2020 21:29:22 +0000

On 10/11/2020 23:50, Christian Huitema wrote: 

> There may be something else. The government actions typically operate through application 
> providers acting as gatekeepers, as in "Facebook, please provide me a clear-text version of 
> these messages". If there are just a few platforms managing a large share of the 
> communications, governments merely have to lean onto these platforms to obtain what they 
> want. And if a company is running a big communication business, it will come to terms with 
> local governments in order to protect that business.
>
> If the IETF wants to protect individual freedoms, then it might want to focus on distributed 
> architecture for communication services.

This could lead to a situation where it appears to be an unaccountable tech sector against democratically elected governments, remembering that the tech sector is responsible for surveillance capitalism, helped enable Cambridge Analytica and its ilk, provides tools facilitating misinformation campaigns etc.  In other words, the sector cannot claim the moral high ground here; this may not end well.  

That said, it would be good news to see action taken to stop the accelerating pace of centralisation which seems likely to undermine the resilience of the Internet and potentially weaken privacy.  

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Oct 2020 10:45:13 +1300

> That said, it would be good news to see action taken to stop the accelerating pace of centralisation which seems likely to undermine the resilience of the Internet and potentially weaken privacy.  

We're not "the tech sector", however, nor are we rampaging libertarian capitalists. The strength of the arguments in RFC1984 and RFC2804 is that they are technical arguments about how to ensure security. RFC7258 is also based on technical arguments, although it's a bit harder to claim that it's 100% technical. I'm sure that we will see more work on fully distributed (serverless) encrypted mechanisms but I'm also wondering whether the IAB should say anything, possibly via ISOC. The basic message is only "please reread RFCs 1984, 2804 and 7258, because nothing has changed."

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Oct 2020 22:51:10 +0100

On 12/10/2020 22:29, Andrew Campling wrote:
> This could lead to a situation where it appears to be an
> unaccountable tech sector against democratically elected governments,

Actually, it mostly seems to be logic and the laws of
physics against the democratically elected governments.
They claim to want to square the circle and that can't
be done.

> remembering that the tech sector is responsible for surveillance
> capitalism,
That is however, true and is certainly something that
has gotten worse since e.g. rfc1984 was written. It is
worth considering whether there are analagous BCPs that
might be useful there.

I'll note in passing that rfc7258 defines PM in a way
that I at least consider does encompass some of the
mechanisms of surveillance capitalism, e.g. devices
"calling home" with telemetry that relates to protocol
artefacts in ways that can enable broad surveillance.
Could be we could improve on that though.

Cheers,
S.

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 13 Oct 2020 13:01:54 +0200 (CEST)

> Il 12/10/2020 21:27 John C Klensin <[email-masked]> ha scritto:
> 
> the request. 

There is also a second big difference: the government that has the right / the opportunity to access your data at a cloud provider may not be the same government that is able to come after you directly. Whether this is good or bad for you depends on the specific set of governments and on how much you like them.

> Sometimes that is important, sometimes not, but,

On the other hand, the more your data are spread out, the more likely it is that someone somewhere has an opportunity to intercept them. Of course it depends whether you are spreading out entire copies or just subsets, whether each subset is enough to give away meaningful information about you, and so on. But something that strikes me is that the IETF community often seems to think that more distribution of data equates to more privacy, while the basic assumption of almost any privacy law is the exact opposite.

> Il 12/10/2020 23:51 Stephen Farrell <[email-masked]> ha scritto:
> 

Even if the IETF fully equated commercial surveillance to governmental surveillance, it would still be hard for many parties to accept the idea that the two things are the same or are similarly bad, or are always bad no matter what. Again, this is an assessment that depends on the specific situation and also, unfortunately, on one's political views of society, but I think that the IETF should develop a more nuanced approach to the topic.

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Oct 2020 13:48:50 +0100

> On 12 Oct 2020, at 22:51, Stephen Farrell <[email-masked]> wrote:
> 

Stephen,

Those governments are looking for ways to stop real harm to real people.

We have to accept that we have unintentionally played a part in causing some of that harm.

So the problem that we have a moral responsibility to address is to find methods that stop or minimise those harms.

The problem may be hard but so were many other problems that we now take for granted as solved.

Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Oct 2020 14:17:36 +0100

Hiya,

> Those governments are looking for ways to stop real harm to real

Some are, yes. That is not all they are interested in doing
of course (they all do like a bit of spying here and there:-)
and all that varies enormously from one to another government.
Some governments want these changes in order to do what I would
call harm.

> causing some of that harm.

And a lot of good. IMO, on balance, and after having done
this stuff for >3 decades, I'm happy that we've done overall
far more good (with crypto in protocols) than harm. (That
doesn't include surveillance capitalism, but that isn't the
same issue.)

> So the problem that we have a moral responsibility to address is to
> find methods that stop or minimise those harms.

I don't accept that. The "we" isn't clear, but what
does seem clear is that meeting the requirements posed
is (IMO anyway) likely to do more harm. I've never
seen any proponent of borked crypto do a proper analysis
of the damage that would be done - they almost always
seem to approach it as mostly a PR exercise and so go
straight to the "think of the children" and "what about
the terrorists" talking points.

> take for granted as solved.

I didn't say "hard." I said "squaring the circle." The
latter isn't possible and is much more like the "magic"
that is being asked for, and has been asked for since
the Clipper days, without any technical progress at all
in those 25 years.

S.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Oct 2020 14:34:45 +0100

> On 13 Oct 2020, at 14:17, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Engineering calls for a pragmatic balance of results and costs.

From where I sit, I see a significant downside in allowing bad people to do bad things to innocent people.

> the terrorists" talking points.

Well I am certainly concerned about those two groups.

So the interesting question is whether there is any other way of addressing the requirement without borking the crypto, at least for the majority of applications used by those causing the harm.

> the Clipper days, without any technical progress at all

Are, but that is my point. Maybe we cannot exactly square the circle, but perhaps, if we look at the problem in the right way we can create a sufficiently close approximation that it satisfies the requirement?

Stewart

> <0x5AB2FAF17B172BEA.asc>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Oct 2020 09:46:56 -0400

Stewart, please do not describe this as "allowing people to do bad 
things to innocent people".  We are not "allowing"anything.  We are 
trying to properly protect communication, without regard to the content.

Recasting it as the IETF allowing harm misrepresents almost all aspects 
of the problem.

As for squaring teh circle, I tend to trust the many crypto 
professionals who have repeatedly looked at this trying to find 
compromises, and the many reports they have produced about it.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Oct 2020 15:28:45 +0100

> On 13 Oct 2020, at 14:46, Joel M. Halpern <[email-masked]> wrote:
> 
> Stewart, please do not describe this as "allowing people to do bad things to innocent people".  We are not "allowing"anything.  We are trying to properly protect communication, without regard to the content.
> 
> Recasting it as the IETF allowing harm misrepresents almost all aspects of the problem.

Joel, we are the current shepherds of the base technology that enables the harm.

You could say that car manufacturers do not kill pedestrians, drivers kill pedestrians, but by governmnets forcing car manufacturers to change their design a lot less pedestrians are killed these days. So the question as I see it is whether we can do anything, even if slightly expensive or inconvenient, that mitigates the key harms.

> 
> As for squaring teh circle, I tend to trust the many crypto professionals who have repeatedly looked at this trying to find compromises, and the many reports they have produced about it.
> 

In 1956 we were not sure we could launch a satellite, let alone walk on the Moon 13 years later. I consider us to be quoting the convention wisdom of 1956 without looking at what we might be able to do in 1969.

Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Oct 2020 16:29:38 +0200

Some crazy thoughts:

One technical aspect IMHO worth of technical consideration is to think and work
along the motivation of RFC3924. From my understanding, Fred did this to provide more
awareness and transparency of perpass technology used (i hope he will correct me
if this is wrong).

Aka: Government actions such as filtering and perpass will increase, for better
or worse. They may only happen at application layer or at network layer. What
technical stndards could be build to record, track and supervise these government
actions ? 

For example: could we create standardized methods for more transparency of
these government actions and policies ? Of course, there are a lot of policy
and dministrative aspects to any such means for transparency, e.g.: who is given
the ability to review and control the actions of the legal enforcers. Could the
metadata about filtering and perpass for example be anonymized such that control
and review of such legal enforcers could more easily be done by more independent
entities. Could there be a data-model about the metadata that an SP could
directly expose to such independent watchdogs ? Think from the minimum
to the maximum: Total number of new filter/perpass requests in a period
as an example of a minimum. Any degree of visibility IMHO would help. Time
delayed availability to not impact immediate executive action etc. pp!

Aka: This is not talking about defining how to do filter/perpass, but how
to monitor and control those who do perform those legal actions.

IMHO: There is not only more privacy for individuals, there is also the
need for more transparency of legal activities. IMHO, the core reason why we have
the quagmire about democratic government actions is their secrecy,
unaccountability and therefore uncontrollability.

Practically speaking, SPs could simply create databases of all executives
LI requests/actions, and then regularily but accidentially the database is
leaked like all our credit card numbers regularily are. 

Cheers
    Toerless

On Mon, Oct 12, 2020 at 08:27:05AM +1300, Brian E Carpenter wrote:
> Not to mention RFC 7258.
> 
> Orders from the Top: The EU???s Timetable for Dismantling End-to-End Encryption:

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Oct 2020 17:24:56 +0200

> the Clipper days, without any technical progress at all

If we find encryption that can only be cracked by the good people when
they do good things, then i am sure we will also find Unicorns, because
both are mythical creatures from the same alien planet, so i am really excited
for this to happen! I will sell the encryption to the government and
keep the Unicorn.

Ok. beside cynicism i can only think about better school education about
this. It will be tough to teach middle school children about the fundamental
limitations about complex systems, but we have more and more of such
problems.

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Oct 2020 14:00:46 -0400

--On Tuesday, October 13, 2020 14:34 +0100 Stewart Bryant
<[email-masked]> wrote:

>> Some governments want these changes in order to do what I
>> would call harm.
> 
> From where I sit, I see a significant downside in allowing bad
> people to do bad things to innocent people.
 
>> doesn't include surveillance capitalism, but that isn't the

But unless we can figure out a way to make that distinction a
lot more clear to those who do not share the same technical,
economic, and political views, it is not clear that there is a
difference between "surveillance capitalism" and assorted things
you consider "overall good".   Not disagreeing, just pointing
out that such distinctions are not universally accepted, that
one can favor availability of crypto in protocols and still want
restrictions and access in some cases.

I can't tell if Stewart and I are in agreement or not, but all
I'm suggesting is that we need to see many of these things as
relatively complex systems that involve the policy-makers
(however clueless, friendly, or hostile one might consider them)
as well as the technology.  That means doing a better job of
looking at possible tradeoffs and then being explicit about what
they are and what choices we are making and why.    If there are
different types of attackers and we can optimize for resisting
one type and not the other, then we need to get that out in the
open and be explicit about the decisions or compromises we are
making and why.  If both "more concentration" and "having things
more widely distributed" have things going for them, then we
need to look at how to balance the two, not just denounce one or
the other and pretend there are no side effects.   

As an important example, while the message has been clear from
crypto experts that there is no way to build back doors into
systems and avoid having those back doors create
vulnerabilities, "we" may need to think more carefully about
alternatives (technical or otherwise) to explain to regulators
and legislators.  If they decide that something must be done and
we convince them that, e.g., law enforcement access to encrypted
streams is impossible without creating larger problems, they
will (and have in the past) consider banning crypto entirely
(something we all agree would be a bad outcome).  So, when I
first read the subject line and first part of Brian's note, I
interpreted "revisit" as "maybe it is time to move away from the
absolutes of "doing that is bad and won't work" or "that is an
evil and will hurt the Internet" and to start looking more at
why others might think that a particular approach might be worth
it despite the disadvantages,  We should, IMO, be willing to
look at those issues to see if we can find alternatives or
middle grounds.

  john

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Oct 2020 20:14:17 +0100

Hiya,

On 13/10/2020 19:00, John C Klensin wrote:
>  So, when I

I don't believe our current BCPs (nor 2404) are at all
absolutist. Describing them that way seems to me fairly
inaccurate.

That is a form of argument that one sees repeated though:
"I disagree with what you write/say. What you say is
absolutist. I'm reasonable and prefer a middle ground.
Therefore you are wrong to not compromise regardless of
any particular set of facts (even if what I want is
not possible;-)" I'd find it hard to be convinced that
compromise or some middle-ground was desirable if we
have engineering cast as one "extreme" and a desire for
magic as the other.

But maybe we're better off not re-litigating rfc1984
though...

FWIW, I thought Brian's mail might turn into considerations
as to the risks of client-side near-monopolies - the fact
we live with those creates an opportunity to mandate that
certain software or functionality (e.g. a snooping process,
reporting to someone someone else has chosen) can easily
become a requirement for nearly all devices in a particular
region. I'm not sure how much of that is within the IETF's
purview though, but that is one of the angles of attack
that those who'd like to snoop more seem to be taking,
rather than failing yet again to square that circle. I do
agree though that the fact that some of those widely
deployed client platforms are intimately involved in
surveilling for advertising purposes makes it harder to
argue that it's somehow bad for governments to want or
insist on similar things.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Oct 2020 08:53:54 +1300

Hi Stewart,
> From where I sit, I see a significant downside in allowing bad people to do bad things to innocent people.

Please explain what has changed in the fundamentals since RFC1984 and
RFC2804 were published, and what *technical* errors in those documents
now need correction.

We all agree, I think, that many bad things have been done using the
Internet. How many of those were done using cryptography, and how many
bad things have been *prevented* by cryptography are both objectively
unknowable. Therefore, we simply don't know the balance between good
and evil here.

IMHO, we should stick to our technical knitting, and that's the basis
on which the above RFCs were published.

   Brian

> .

---

From: Andrew Campling <[email-masked]>
Date: Tue, 13 Oct 2020 20:33:57 +0000

On 13-Oct-20 20:54, Brian E Carpenter wrote: 

> We all agree, I think, that many bad things have been done using the Internet. How 
> many of those were done using cryptography, and how many bad things have been 
> *prevented* by cryptography are both objectively unknowable. Therefore, we 
> simply don't know the balance between good and evil here.

I think one of the challenges here is that there are no easy answers - if there were then this particular issue would not keep coming up.  We have a conflict between preventing harm by "bad actors" on the one hand and protecting privacy on the other.  

In my view this is not a technical problem, but is instead a case of determining which of two sets of conflicting requirements should be prioritised.  RFC 8890 suggests that, in such circumstances, we should try to minimize negative impact whilst also noting that when a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good trade-off.  Based on the arguments made that initiated this discussion, we could conclude that the approach taken by the IETF to date appears to have harmed at least some users.  

The RFC also encourages stakeholder engagement.  We have a clear message here from one group of stakeholders that harm is occurring and that changes are needed.  It would seem reasonable to take steps to understand their case in more detail rather than just dismissing it as wrong, too difficult, badly defined or ill thought out (to be clear, I'm not suggesting that Brian has in fact done any of those things!).  

Therefore, rather than trying to debate the topic and solve it here, surely the most appropriate next step would be to seek discussion with the affected stakeholders, and possibly others to ensure a balanced view has been gained.  

Andrew

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Oct 2020 02:12:46 +0200

Andrew,

inline

On Tue, Oct 13, 2020 at 08:33:57PM +0000, Andrew Campling wrote:
> In my view this is not a technical problem, but is instead a case of determining which of two sets of conflicting requirements should be prioritised.

This reads to me as you proliferate what i think to be the core fallacy
that the IETF: it has allowed rough consensus to be abused to prohibit
work that some rough mayority does not like. In many cases because it
is against their business interest, and annoyingly enough that real goal
is often hidden behind a shield of "its not good for the Internet, its
not good for the users".

There may only be one solution for the "Internet", but there can easily
be many competing and contradicting solutions for different markets.

[ insert toerless again comparing TCP/IP solution with an iceberg: 
  10 % across the waterline is Internet, 90% invisible below the waterline
  are controlled networks].

TLS 1.3 is the best example. The abuse of IETF principles by its
rough mayority was not the rough consensis on rfc8446, but how it was
made clear that dissenting profiles, even if mean to be used only for
controlled networks would not find a home in the IETF.

In result we have stuff like ETSI TS 103 523-3 happening outside the
IETF. If such a document would have been done inside the IETF it would
have showed much better the will of the IETF to not only serve 10 %
of the iceberg but also significant parts of the other 90%. Even more so,
the outcome could have been technically better or at least be a lot more
elaborating of the risk and possible mitigation strategies of such a
"weakened" security solution.

>  RFC 8890 suggests that, in such circumstances,
> we should try to minimize negative impact whilst also noting that when a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good trade-off.  Based on the arguments made that initiated this discussion, we could conclude that the approach taken by the IETF to date appears to have harmed at least some users.  

Given how RFC8890 is only scoped for the Internet: What is and what
is not allowed/desired on public IP networks will more and more be
subject to non-IETF controlled policies. Be those of big OTT App
providers with global networks or governments of any kind. The
more dogmatic the IETF is about what can and what can not be branded
Internet, the more the Internet will be more the Internet will
shrink to that subset of operators/regions/countries that agree
with those "Internet" policies. 

I for once am all for keeping the spirit of a clear and strict open
policy for "Internet", even at the risk of shrinkage. I would like
to avoid the IETF to become less relevant by excluding more and more
of the demands of the non-Internet TCP/IP networks from its work scope.
Especially when a lot of this non-technology-inclusiveness is not even
driven from the Internet values but from business and political
interest of groups inside the IETF.

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Oct 2020 01:23:03 +0100

> controlled networks would not find a home in the IETF.

If I understand your grammar correctly, I consider that
counterfactual nonsense. TLS1.3 was quite a good example
of running the process and even of extending the set of
people participating to bring in lots of new and real
expertise.

S.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 13 Oct 2020 17:25:22 -0700

> I think one of the challenges here is that there are no easy answers - if there were then this particular issue would not keep coming up.  We have a conflict between preventing harm by "bad actors"…

First, let's agree with Brian that the IETF is best at solving technical
problems. The kind of balance that we describe here is a political and
possibly cultural issue. It has been solved in the past in adjacent
domains, for example with habeas corpus, innocent until proven guilty,
or the prohibition of torture. These are widely agreed principles in
democratic societies -- but not necessarily in all societies. And these
principle do recognize a balance between good and evil. Stating for
example that society would rather have a culprit walking free than an
innocent in jail is an explicit choice. I wish society would be able to
make similar choices regarding the privacy of communications, but this
is definitely not a technical issue.

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Oct 2020 02:51:37 +0200

On Wed, Oct 14, 2020 at 01:23:03AM +0100, Stephen Farrell wrote:
> counterfactual nonsense.
  ^^^^^^^^^^^^^^^^^^^^^^^

Offensive, dismissive judgements are not a technical argument.

> TLS1.3 was quite a good example

Thanks for rephrasing the first part of what i said. My criticism was
about the additional TLS profile RFC(s) that did not happen in the IETF due
to very clear resistance to them even though there was a big enough
community supporting them. Aka: The TLS RFC NOT for the Internet but
for controlled networks with specific three party trust.

Cheers
    Toerless

> S.

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <[email-masked]>
> sub   RSA 4096/36CB8BB6 2017-12-22
> 

-- 
---
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Oct 2020 02:12:50 +0100

>> If I understand your grammar correctly, I consider that

Asserting that something is counterfactual should not be
offensive. Well perhaps it might to someone who found some
facts offensive, I'm not sure;-) Nonsensical statements are
the opposite of sensible ones, and are common on IETF
lists. I'm quite surprised any of that is surprising to
anyone that posts often.

All that said, I do think a bit of dismissal is warranted
though - the TLS WG wasted a year and a bit on that stuff
for no good reason, so yes I do think those who claim those
nonsense arguments don't deserve to be dismissed are wrong.
(Surely we're ok to dismiss zombie arguments like these,
if for no other reason than efficiency in the face of an
utter lack of new [or actually also of old!] facts?)

> community supporting them. 

Again, that's counterfactual. The proponents of breaking
TLS1.3 in that way, (draft-green et. al.) had many many
opportunities to make their (weak) case. They did that,
some very badly, some less so. And they failed to be
convincing.

Then some of them went to a captive group in ETSI and got a
rubber stamp for their (IMO terrible) idea. For me, that
says more about a lack of quality control in ETSI than
anything else. I hope TLS and web implementers continue to
entirely ignore the output of that supposed piece of
"work."

> Aka: The TLS RFC NOT for the Internet but

That discussion was had. TLS is a two party protocol. You
may wish the outcome had been otherwise but it was not.

S.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Oct 2020 03:34:32 +0200

Stephen,

You are making all my argument better than i can.

I can only predict that if your line of thinking and talking persists in I*
leadership then IETF will continue to loose relevance for the industry at large.
Too bad.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Oct 2020 02:49:30 +0100

> You are making all my argument better than i can.

We seem to agree about that:-)

You are as entirely welcome to misinterpret what I'm saying
as ETSI are to call their weirdo horror-movie thing TLS:-)

S.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Oct 2020 04:20:30 +0200

> You are as entirely welcome to misinterpret what I'm saying

I don't. You made yourself very clear.

> as ETSI are to call their weirdo horror-movie thing TLS:-)

You missed your window of opportunity for dismissive
name calling to have a lasting effect. If this work was done
in the IETF it could easily have been distinguished better
against TLS, including in name. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Oct 2020 08:42:56 +0100

John and I are largely aligned, although I do wonder if it is technically possible to provide a method of providing access to clear text in such a way that it was safe from anything other than through the cooperation of multiple independent trusted bodies operating within an agreed international legal framework.

Stewart

> On 13 Oct 2020, at 19:00, John C Klensin <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Oct 2020 11:10:51 +0200

Hi Stephen

> On 13 Oct 2020, at 15:17, Stephen Farrell <[email-masked]> wrote:
> 
>> 

There are (at least) two threads going on here.  The first is what the social responsibility of the IETF community actually is.  The nature of our work has always been dual use.  Crypto is the classic example of that.  We have to accept that.  But in so doing, do we also have a responsibility to ameliorate risks or even articulate them?  That’s not to say that crypto is bad- it is a foundational technology without which the Internet could not have grown to its current size of O(10^10) devices and over 4 billion users.  I do think it’s reasonable to evaluate the societal impact of our work.  The hrpc was sort of a nudge in that direction, but very small one.

The second is the risks of having these conversations in the abstract.  That generates more heat than light.  When we talking about “borked crypto”, what do we mean?  Do we mean algorithms that are weak?  Do we mean key sharing and escrow schemes?  Do we mean something else? I like the approach that the Carnegie Endowment committee led by Steve Bellovin and Susan Landau took in dissecting this problem, in order to find starting points and common ground with law enforcement.[1]. But even that presents challenges.  It assumes that there are, as you more than allude, a limited number of well-governed actors in the conversation.

I’m not taking a position on updating any documents, but I do think it’s good for us to ponder these questions as we consider new mechanisms.

Eliot

[1] https://carnegieendowment.org/2019/09/10/moving-encryption-policy-conversation-forward-pub-79573

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Oct 2020 10:54:14 +0100

A good summary.

- Stewart

> On 14 Oct 2020, at 10:10, Eliot Lear <[email-masked]> wrote:
> 
> Hi Stephen
> 
>> On 13 Oct 2020, at 15:17, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
> [1] https://carnegieendowment.org/2019/09/10/moving-encryption-policy-conversation-forward-pub-79573 <https://carnegieendowment.org/2019/09/10/moving-encryption-policy-conversation-forward-pub-79573>
> 
> 
>

---

From: Andrew Campling <[email-masked]>
Date: Wed, 14 Oct 2020 10:41:10 +0000

On 10/14/2020 1:25 AM, Christian Huitema wrote:

First, let's agree with Brian that the IETF is best at solving technical problems. The kind of balance that we describe here is a political and possibly cultural issue. It has been solved in the past in adjacent domains, for example with habeas corpus, innocent until proven guilty, or the prohibition of torture. These are widely agreed principles in democratic societies -- but not necessarily in all societies. And these principle do recognize a balance between good and evil. Stating for example that society would rather have a culprit walking free than an innocent in jail is an explicit choice. I wish society would be able to make similar choices regarding the privacy of communications, but this is definitely not a technical issue.

I agree that the IETF is best at solving technical problems and note that it has previously determined both that end-to-end encryption is the correct technical solution to protect privacy and that privacy should be prioritised over at least some other considerations such as the significant harms caused by certain behaviours that have benefited from that encryption – I will desist from giving examples to hopefully avoid this becoming an overly emotive discussion.

I believe that there is a case to make that the current direction of travel of the development of the Internet, underpinned by end-to-end encryption, centralisation etc, is having, and will continue to have, consequences that are likely to include further fragmentation of the Internet and a loss of the desired privacy.  Some of this is addressed in a little more detail in a short submission for the IAB’s proposed Covid-19 Network Impacts Workshop so I’ll not restate the detail here for now on the assumption that the paper will be accessible shortly alongside other workshop submissions.

I therefore respectfully challenge the assumptions: (i) that the status quo is the correct and indeed only technically valid position; (ii) that privacy is best protected over the long-term by end-to-end encryption; and (iii) whether privacy should be prioritised over all other harms affecting end users.  In addition, I challenge the presumption that the IETF is the only body able to make such a determination about these matters and that it can and should do so without undertaking full consultation with other stakeholders.

It is my view that these three points warrant proper evaluation that needs to be undertaken through a true multi-stakeholder consultation process as suggested by the IAB’s RFC 8890.  Let’s first prioritise the harms and agree how the Internet should evolve *before* determining the most appropriate technical solution, the latter task in particular being proper to the remit of the IETF.  It may be that the outcome of that process is that the status quo is in fact the least worst way forward but this needs to be properly tested rather that stated as a fait accompli.

Andrew

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Oct 2020 12:04:21 +0100

Hiya,

On 14/10/2020 11:41, Andrew Campling wrote:
> I agree that the IETF is best at solving technical problems and note
> that it has previously determined both that end-to-end encryption is
> the correct technical solution to protect privacy and that privacy
> should be prioritised over at least some other considerations such as
> the significant harms caused by certain behaviours that have
> benefited from that encryption
The above is not accurate. Encryption mechanisms provide
different services (confid, auth) that are of use for more
than just user privacy. For example, I'd guess we'd all
be unhappy if various bug trackers leaked plaintext.
There are many other examples of confidentiality being
required for security and not only privacy.

S.

---

From: Andrew Campling <[email-masked]>
Date: Wed, 14 Oct 2020 11:11:35 +0000

You are correct, I agree that I have not provided an exhaustive list of the uses of encryption, nor indeed have I included an exhaustive list of the harms that could be associated with some of those uses.  This does not detract from the rest of the post and I look forward to seeing views on the substantive points made.  

Andrew

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: 14 October 2020 12:04
To: Andrew Campling <[email-masked]>
Cc: [email-masked]
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?

Hiya,

On 14/10/2020 11:41, Andrew Campling wrote:
> the significant harms caused by certain behaviours that have benefited 
> from that encryption
The above is not accurate. Encryption mechanisms provide different services (confid, auth) that are of use for more than just user privacy. For example, I'd guess we'd all be unhappy if various bug trackers leaked plaintext.
There are many other examples of confidentiality being required for security and not only privacy.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Oct 2020 12:17:20 +0100

On 14/10/2020 12:11, Andrew Campling wrote:
> You are correct, I agree that I have not provided an exhaustive list
> of the uses of encryption, nor indeed have I included an exhaustive
> list of the harms that could be associated with some of those uses.
> This does not detract from the rest of the post and I look forward to
> seeing views on the substantive points made.

I might have gotten confused by the quoting in that post
but I do believe it does undermine your argument which
seemed to be assuming that the only justification for
confidentiality was privacy.

Given we agree that is not the case, ISTM any attempt to
setup a <e2e-crypto==privacy> vs. <whatever> argument fails
because <e2e-crypto!=privacy>.

S.

> 
> Andrew
> 
> -----Original Message----- From: Stephen Farrell
> <[email-masked]> Sent: 14 October 2020 12:04 To: Andrew
> Campling <[email-masked]> Cc:
> [email-masked] Subject: Re: [arch-d] Time to reboot
> RFC1984 and RFC2804?
> 
> 
> Hiya,
> 
>> I agree that the IETF is best at solving technical problems and
>> note that it has previously determined both that end-to-end
>> encryption is the correct technical solution to protect privacy and
>> that privacy should be prioritised over at least some other
>> considerations such as the significant harms caused by certain
>> behaviours that have benefited from that encryption
> The above is not accurate. Encryption mechanisms provide different
> services (confid, auth) that are of use for more than just user
> privacy. For example, I'd guess we'd all be unhappy if various bug
> trackers leaked plaintext. There are many other examples of
> confidentiality being required for security and not only privacy.
> 
> S.
>

---

From: Andrew Campling <[email-masked]>
Date: Wed, 14 Oct 2020 11:27:47 +0000

My argument does not state that privacy is the only benefit of crypto.  For clarity, it does state that some in the IETF have "previously determined both that end-to-end encryption is the correct technical solution to protect privacy and that privacy should be prioritised over at least some other considerations such as the significant harms caused by certain behaviours that have benefited from that encryption".  I hope this clears up any confusion.  

I think it would be more beneficial to focus our energies on addressing the substantive points.  

Andrew 

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: 14 October 2020 12:17
To: Andrew Campling <[email-masked]>
Cc: [email-masked]
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?

> seeing views on the substantive points made.

I might have gotten confused by the quoting in that post but I do believe it does undermine your argument which seemed to be assuming that the only justification for confidentiality was privacy.

Given we agree that is not the case, ISTM any attempt to setup a <e2e-crypto==privacy> vs. <whatever> argument fails because <e2e-crypto!=privacy>.

S.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Oct 2020 17:31:49 +0200

If i may rant about context, and like the rest of the thread
it is somewhat recurring:

We should remember that a good amount of desire for end-to-end encryption is
not only driven by user privacy desire but by the commercial interests of over the
top providers wanting to prohibit the underlay operator to interfere with its
business model. This is never openly talked about in the IETF, but instead all those
OTT that want Internet end-to-end encryption for this reason put all their
efforts into promoting the value of privacy over any other conflicting goals:
Sounds a lot better than "we don't want SP to get a share in our ad revenue
for just transporting our bits" (just as an example).

Aka: The IETF has a commercially driven biased view on the relative importance
of privacy via end-to-end encryption. And its behaving like a single-issue
organization in this respect. As shown through the complete absence of
any attempts to tackle / discuss the competing problems that need to be solved
such as those of law enforcement. I sent a prior email about additional work
that could be done. Same as writing to /dev/null.

Let me try a more fundamental competing issue: Firewalls in any commercial
organization are there to keep bad stuff from coming in and protected stuff
from going out. To that end, in the face of encryption, more and more data-model
level inspection devices are emerging allowing organizational security teams
to control / inspect if/how cloud based services do comply with those organizational
security demands. Nothing of this AFAIK is done in the IETF.

Even as a "User", i am a lot more worried these days about all the IoT devices i
could have at home and how they perpass and resell my data, than law enforcement
agencies putting backdoors into my PC. Where is the IETF on this problem ? It is
owned primarily by organizations whose core business model is the (ab)use of User data
or those that support such organizations through infrastructure (depending on them) .
Considered IOTOPS WG of course has this problem not on the proposed charter either.

Any similar IETF statements like  RFC7258 about this application level behavior ?
AFAIK, no: It is the "evil" (see below) EU that did the first globally relevant scheme to
put limits to that abuse: GDPR. Is it as simple and elegant as TLS ? Of course not.
Its just like Democracy: worst solution except for all the others.

Sorry for the interruption. Please carry on.

> Not to mention RFC 7258.
Well, obviously all the law enforcemenet actions are not pervasive but highly selective
against legally determined suspects of criminal activity for whom then the right
of privacy is forfeit for the subject of the investigation. So democratic governments
would never do PerPass

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Oct 2020 08:58:30 +1300

Andrew,

On 14-Oct-20 23:41, Andrew Campling wrote:
...
>  In addition, I challenge the presumption that the IETF is the only body able to make such a determination about these matters and that it can and should do so without undertaking full consultation with other stakeholders.

I for one make no such presumption. But we have never made that claim. The claim we've made is that we know how to make *our* protocols secure against inspection or forgery by 3rd parties, and that it's our job to do so.

When we try to go wider than that, we fail. I am not very sympathetic to "a true multi-stakeholder consultation process as suggested by the IAB’s RFC 8890". The IETF is not in any way a suitable vehicle for that kind of process, as anyway who remembers WGIG/WSIS is well aware.

Regards
    Brian

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Oct 2020 09:20:37 +0000

Brian

>When we try to go wider than that, we fail. I am not very sympathetic to "a true multi-stakeholder consultation process as suggested by the IAB’s RFC 8890". The IETF is not in any way a suitable veh…

I suspect that the key area where we diverge is whether due consideration is given to the impact of the decisions made by the IETF, looking beyond the purely technical aspects.  The IETF does not operate in a vacuum, it cannot reasonably ignore the real-world impacts of its decisions nor should it ignore the views of relevant stakeholders including end users, governments, civil society etc.  

I note your concerns about the suitability of the IETF to conduct a stakeholder engagement process but nevertheless, for the reasons stated in my earlier post, I believe that it is both entirely reasonable and necessary that such activity is undertaken as per the IAB's recent RFC 8890 publication.  Of course it may be that the IETF doesn't have to discharge the activity itself, instead does so via a third party.  As it is an IAB document, perhaps the IAB could comment how it envisaged this stakeholder engagement being undertaken.  

Andrew

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Oct 2020 12:14:19 +0200

Hi Brian,

> On 14 Oct 2020, at 21:58, Brian E Carpenter <[email-masked]> wrote:
> 

The reason in the end that I supported that document was that I believe there are aspects that the IETF could really stand to improve.  In particular, outreach is not something from which we should shy away.  Rather we individually should view it as a responsibility.  To think otherwise leads to ill-considered proposals that either get deployed and later cause problems, or simply don’t get deployed.

Eliot

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Thu, 15 Oct 2020 19:38:50 +0700

Dear Brian, Andrew, &
architecture-discuss,

I am attempting to read this thread which may be around "how the IETF in
relation with the politics of the Internet":

Mr Brian said: "... to make *our* protocols secure against inspection or
forgery by 3rd parties, and that it's our job to do so".

Thanks to the Internet among others, the world society is no globalized: by
such machine of communication operating globally, it is about societal
elements of the economic, the political and the cultural among others. As
well national as international goverments ('policies) are part of the
event. What would global economy, politics and culture supposedly be...?

To the matter above we may find questions about engineering the Internet,
especially its protocols, and its institutional supports. There are
interests and whereas protocols define how a tech works/operates, does
changed invariants* of a tech not mean another, or new, tech...? As the
Internet is not the telephone so that new invariants makes the new tech not
to be the Internet --considering a history of the Internet which
collaborates with the telephone...?

* Being cited from the "2019 ISOC Global Report: Consolidation in the
Internet Economy":
(We) may think of the I as an idea of how networks of computers
communicate, and the
invariants describe the most important features of that idea. This concept
of the Internet as an idea is operationalised through some familiar
protocols (e.g., Internet Protocol, Border Gateway Protocol) and functions
(e.g., the Internet Assigned
Numbers Authority).)

The invariants are:
-global reach, integrity
-general purpose
- supports innovation without requiring permission
- accessible
- based on interoperability and mutual agreement
- collaboration
- technology, reusable building block

https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

Regard,
Guntur Wiseno Putra

Pada Kamis, 15 Oktober 2020, Brian E Carpenter <[email-masked]>
menulis:

> >  In addition, I challenge the presumption that the IETF is the only body
> able to make such a determination about these matters and that it can and
> should do so without undertaking full consultation with other stakeholders.
>
> I for one make no such presumption. But we have never made that claim. The
> claim we've made is that we know how to make *our* protocols secure against
> inspection or forgery by 3rd parties, and that it's our job to do so.
>
> When we try to go wider than that, we fail. I am not very sympathetic to
> "a true multi-stakeholder consultation process as suggested by the IAB’s
> RFC 8890". The IETF is not in any way a suitable vehicle for that kind of
> process, as anyway who remembers WGIG/WSIS is well aware.
>
> Regards
>     Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2020 11:46:44 +1300

On 15-Oct-20 23:14, Eliot Lear wrote:
> Hi Brian,
> 
>> On 14 Oct 2020, at 21:58, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>

Yes, and I certainly support the higher level message of RFC8890. But actually organizing outreach to civil society and governments is way outside the IETF's and IAB's skill set. We have traditionally relied on ISOC for that, and that's one of the reasons that the IAB is chartered "as a source of advice and guidance to the Board of Trustees and Officers of the Internet Society concerning technical, architectural, procedural, and (where appropriate) policy matters". Has the ISOC Board discussed RFC8890?

    Brian