Subject: Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Jul 2020 10:57:54 +0100

> On 30 Jun 2020, at 01:59, Eric Rescorla <[email-masked]> wrote:
> 
> > 
> > This 3rd WGLC is limited to the following two topics:
> >  
> > 
> >     Whether or not to proceed with a request for RFC publication
> > 
> > of the draft.   The decision on whether or not to proceed will
> > be based on rough consensus of the WG, see RFC 7282.
> > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed
> > strong views that this draft should not be published –  those
> > concerns have not been resolved and are carried forward to
> > this WGLC.  This email message was an attempt to summarize
> > those concerns:
> > 
> > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ <https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/>
> > 
> > Further explanation from both Eric Rescorla and David Schinazi
> > is welcome and encouraged to ensure that their concerns are
> > clearly understood.
> 
> Well, I'll try again, but I'm not sure that I can do better than
> I have before.
> 
> For reasons that are laid out in RFC 7258, the trend in protocol
> design in IETF is towards encrypting more and more.

I agree, but also note that RFC 7258 is clear that some network monitoring can be beneficial and that “an appropriate balance” has to be found between mitigating pervasive monitoring and supporting network management. This draft is intended to highlight issues to be considered by transport protocol designers, to help them find that balance.

And, to be clear, if transport protocol designers consider the issues and decide that all the metadata in their transport protocol must be encrypted, that’s fine. We're not pushing for a particular outcome; rather that the issues be considered and discussed when making a decision on what to encrypt.

> The last two
> transport protocols that were designed and widely deployed (SCTP over
> DTLS and QUIC) both encrypt the vast majority of the protocol
> metadata. This document advertises itself as "considerations"
> for design of such protocols:
> 
>    The transport protocols developed for the Internet are used across a
>    wide range of paths across network segments with many different
>    regulatory, commercial, and engineering considerations.  This
>    document considers some of the costs and changes to network
>    management and research that are implied by widespread use of
>    transport protocols that encrypt their transport header information.
>    It reviews the implications of developing transport protocols that
>    use end-to-end encryption to provide confidentiality of their
>    transport layer headers, and considers the effect of such changes on
>    transport protocol design, transport protocol evolution, and network
>    operations.  It also considers some anticipated implications on
>    application evolution.  This provides considerations relating to the
>    design of transport protocols and features where the transport
>    protocol encrypts some or all of their header information.
> 
> However, as I said above, the new transport protocols that are
> actually being designed already feature metadata encryption and as far
> as I can tell, there is no prospective protocol new transport protocol
> design project for which these issues might be live.

The issues highlighted in the draft were certainly considered in the design of QUIC, especially in the discussions around the spin bit and operational aspects. I cannot envisage that they won’t also be considered in the design of future transports.

> In that context,
> it's hard not to read this document with its long litany of practices
> which are impacted by metadata encryption as a critique of the
> decisions by SCTP/DTLS and QUIC to encrypt most of the metadata.

I tend to regard critiques of protocol design as a good thing, but then we maybe have a different interpretations of that term. Certainly there are implications of the decision to encrypt transport metadata. There are benefits to it, but also costs. It’s important to understand both, to make an informed judgement on what to encrypt.

> This impression is reinforced by the description of the actual
> practices themselves, which focuses almost entirely on practices
> which appear to be benignly motivated (e.g., performance monitoring,
> troubleshooting, etc.) However, we also know that metadata is widely
> used for practices in which the network operator is adversarial
> to the user, for instance:
> 
> - Blocking traffic based on TCP port, IP address, SNI, etc.
> 
> - Performance-based traffic class discrimination
> 
> - Monitoring the user's behavior via indicia like the ones above
>   or via traffic analysis (see [0])
> 
> Yes, I understand that the authors explicitly disclaim judgement on
> these practices, and the document does briefly touch on the general
> idea, though the "concerns...have been voiced" tends to minimize those
> concerns [1] but the selection of practices to focus on is extremely
> telling. Focusing on the downsides of encryption for (at least
> arguably well-meaning) network players while mostly ignoring the large
> class of non-benign behaviors which encryption is intended to protect
> against has the effect of overemphasizing the costs of encryption to
> those players and minimizing the benefits to the endpoints whom it is
> intended to protect.

Different communities have different interpretations on what’s the neutral point of view phrasing here, but I'm comfortable with further highlighting malicious uses of transport metadata in the draft. We’d tried to mostly do this by reference, since such things have been widely discussed in the past, but perhaps that’s not sufficient.

> To be maximally clear: I don't object to this document existing
> and I don't think that the opinions implicit in it are ones that
> should not be expressed. I merely don't think that it should be
> published as an IETF Consensus document.
> 
> -Ekr
> 
> [0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5 <https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5>
> [1]    Another motivation stems from increased concerns about privacy and
>       surveillance.  Users value the ability to protect their identity
>       and location, and defend against analysis of the traffic.
>       Revelations about the use of pervasive surveillance [RFC7624]
>       have, to some extent, eroded trust in the service offered by
>       network operators and have led to an increased use of encryption
>       to avoid unwanted eavesdropping on communications.  Concerns have
>       also been voiced about the addition of information to packets by
>       third parties to provide analytics, customisation, advertising,
>       cross-site tracking of users, to bill the customer, or to
>       selectively allow or block content.  Whatever the reasons, the
>       IETF is designing protocols that include transport header
>       encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement
>       the already widespread payload encryption, and to further limit
>       exposure of transport metadata to the network.
>   
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: <[email-masked]>
Date: Wed, 1 Jul 2020 12:57:57 +0000

Hi Hannes,

It would be helpful if you can explicit the “wrong message” you are referring to, and preferably with text from the draft conveying that message.

Thank you.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Hannes Tschofenig
Envoyé : mardi 30 juin 2020 07:50
À : Eric Rescorla; Black, David
Cc : int-area; [email-masked]; IETF SAAG
Objet : Re: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

I believe this document signals a wrong message to the wider Internet community. I agree that it should not be published as a consensus document.

I understand that some people are unhappy about encrypting more meta-data. This prevents them from doing things they used to do in the past, some of which they should have never done in the first place.
Improving the protection of meta-data is important and well supported by a large number of activities in the IETF (the notable exception being CoAP+OSCORE).

Ciao
Hannes

From: saag <[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, June 30, 2020 3:00 AM
To: Black, David <[email-masked]>
Cc: int-area <[email-masked]>; [email-masked]; IETF SAAG <[email-masked]>
Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

> https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/
>

design in IETF is towards encrypting more and more. The last two

design project for which these issues might be live. In that context,

-Ekr

[0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 1 Jul 2020 13:20:29 +0000

I noticed this in various IETF discussions and so I will describe it in the abstract.

A group of people propose an idea. Those who do not like the idea are then asked to convince the original contributors that their idea is not sound or contribute text so make it look nicer.
Not only is this requiring me to spend my time on something I don’t agree with but it turns out that no discussions will change the mind of the original contributors. They just strongly believe in their ideas. They will keep proposing the same idea over and over again (for years) till it gets published as an RFC.

Ciao
Hannes

From: [email-masked] <[email-masked]>
Sent: Wednesday, July 1, 2020 2:58 PM
To: Hannes Tschofenig <[email-masked]>; Black, David <[email-masked]>
Cc: int-area <[email-masked]>; [email-masked]; IETF SAAG <[email-masked]>
Subject: RE: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

Hi Hannes,

Thank you.

Cheers,
Med

Cc : int-area; [email-masked]<mailto:[email-masked]>; IETF SAAG

Ciao
Hannes

From: saag <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Tuesday, June 30, 2020 3:00 AM
To: Black, David <[email-masked]<mailto:[email-masked]>>
Cc: int-area <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IETF SAAG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

-Ekr

Thank you.

---

From: <[email-masked]>
Date: Wed, 1 Jul 2020 13:55:59 +0000

Hi Hannes,

do I understand you correctly that exposing transport information to calculate a flow RTT or a flow loss rate by a passive observer along a path is a break in security to you ( sorry if I’m asking something where you’ve expressed your opinion already elsewhere, I didn’t follow the transport exposure vs encryption discussion) ?

Just to understand whether there is absolutely no common ground.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Hannes Tschofenig
Gesendet: Mittwoch, 1. Juli 2020 15:20
An: [email-masked]; Black, David <[email-masked]>
Cc: int-area <[email-masked]>; [email-masked]; IETF SAAG <[email-masked]>
Betreff: Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

Ciao
Hannes

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 1, 2020 2:58 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Black, David <[email-masked]<mailto:[email-masked]>>
Cc: int-area <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IETF SAAG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

Hi Hannes,

Thank you.

Cheers,
Med

Ciao
Hannes

-Ekr

Thank you.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 1 Jul 2020 09:57:27 -0400

On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <[email-masked]>
wrote:

> A group of people propose an idea. Those who do not like the idea are then
> asked to convince the original contributors that their idea is not sound or
> contribute text so make it look nicer.
>
> Not only is this requiring me to spend my time on something I don’t agree
> with but it turns out that no discussions will change the mind of the
> original contributors. They just strongly believe in their ideas. They will
> keep proposing the same idea over and over again (for years) till it gets
> published as an RFC.
>

I don't understand why so many are opposed to publishing a document that
merely describes how operators manage protocols in the absence of header
encryption, and how header encryption interferes with those practices. That
is, at least, in its original form, before this WG decided it needed to
incorporate pro-encryption advocacy, greatly complicating the document and
the resulting analysis.

For the OG version, I ask myself the following questions:

Does the document describe reality? Yes: it tells us what practices
operators employ today.
Is the document useful? Yes: see above, plus it makes clear that there will
be an impact to operators and/or protocol users from this evolution.
Does the document establish an IETF position on encryption? No. There are
plenty of other published RFCs that embody the spirit "encrypt all the
things". This document does not change that.
Does the document make normative statements about future protocol
development? No.

On what basis would I therefore oppose publication?

I may or may not have opinions about prioritization of user privacy over
manageability, the tussle between manageability and deployability, and what
alternatives are available to operators for managing protocols with
encrypted headers. I would be happy to help express those in a follow-on
document. But this document describing where those conflicts lie is a
*prerequisite* to developing those alternatives. And frankly those opinions
are irrelevant to the intended content of *this* document.

Kyle

---

From: <[email-masked]>
Date: Wed, 1 Jul 2020 14:11:16 +0000

+1
Thanks, Kyle!
Kind regards
Dirk

From: Int-area <[email-masked]> On Behalf Of Kyle Rose
Sent: Mittwoch, 1. Juli 2020 15:57
To: Hannes Tschofenig <[email-masked]>
Cc: int-area <[email-masked]>; [email-masked]; IETF SAAG <[email-masked]>
Subject: Re: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
I noticed this in various IETF discussions and so I will describe it in the abstract.

A group of people propose an idea. Those who do not like the idea are then asked to convince the original contributors that their idea is not sound or contribute text so make it look nicer.
Not only is this requiring me to spend my time on something I don’t agree with but it turns out that no discussions will change the mind of the original contributors. They just strongly believe in their ideas. They will keep proposing the same idea over and over again (for years) till it gets published as an RFC..

I don't understand why so many are opposed to publishing a document that merely describes how operators manage protocols in the absence of header encryption, and how header encryption interferes with those practices. That is, at least, in its original form, before this WG decided it needed to incorporate pro-encryption advocacy, greatly complicating the document and the resulting analysis.

Does the document describe reality? Yes: it tells us what practices operators employ today.
Is the document useful? Yes: see above, plus it makes clear that there will be an impact to operators and/or protocol users from this evolution.
Does the document establish an IETF position on encryption? No. There are plenty of other published RFCs that embody the spirit "encrypt all the things". This document does not change that.
Does the document make normative statements about future protocol development? No.

I may or may not have opinions about prioritization of user privacy over manageability, the tussle between manageability and deployability, and what alternatives are available to operators for managing protocols with encrypted headers. I would be happy to help express those in a follow-on document. But this document describing where those conflicts lie is a *prerequisite* to developing those alternatives. And frankly those opinions are irrelevant to the intended content of *this* document.

Kyle

---

From: Joseph Touch <[email-masked]>
Date: Wed, 1 Jul 2020 08:10:13 -0700

-1

Although it’s understandable to describe “what operators do”, the IETF isn’t a news service. We typically summarize these behaviors to take a position on them.

The draft provides a good description of the tradeoff between the privacy rights of endpoints and the rights of operators and the impact of both on protocol design on that tradeoff.

What I seem to be seeing is increasing “rough consensus” that the summary position should be closer to endpoint privacy than in the current form.

Although I don’t feel strongly that the text absolutely needs revision in that direction, I would oppose changes to relax or shift in the other direct.

Joe

> On Jul 1, 2020, at 7:11 AM, [email-masked] wrote:
> 
> +1
> Thanks, Kyle!
> Kind regards
> Dirk
>  
> From: Int-area <[email-masked] <mailto:[email-masked]>> On Behalf Of Kyle Rose
> To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> Cc: int-area <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; IETF SAAG <[email-masked] <mailto:[email-masked]>>
> On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Jul 2020 15:33:15 -0500

+1

I think it is a good draft, out of very hard work, a lot of sweat.

Behcet

On Wed, Jul 1, 2020 at 10:10 AM Joseph Touch <[email-masked]> wrote:

> -1
>
> Although it’s understandable to describe “what operators do”, the IETF
> isn’t a news service. We typically summarize these behaviors to take a
> position on them.
>
> The draft provides a good description of the tradeoff between the privacy
> rights of endpoints and the rights of operators and the impact of both on
> protocol design on that tradeoff.
>
> What I seem to be seeing is increasing “rough consensus” that the summary
> position should be closer to endpoint privacy than in the current form.
>
> Although I don’t feel strongly that the text absolutely needs revision in
> that direction, I would oppose changes to relax or shift in the other
> direct.
>
> Joe
>
> *From:* Int-area <[email-masked]> *On Behalf Of *Kyle Rose
> *Sent:* Mittwoch, 1. Juli 2020 15:57
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* int-area <[email-masked]>; [email-masked]; IETF SAAG <
> [email-masked]>
> *Subject:* Re: [Int-area] [saag] 3rd WGLC (limited-scope):
> draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
>
> On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <
> [email-masked]> wrote:
>
> published as an RFC..
> Is the document useful? Yes: see above, plus it makes clear that there
> will be an impact to operators and/or protocol users from this evolution.
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: tom petch <[email-masked]>
Date: Thu, 2 Jul 2020 10:59:15 +0000

From: Int-area <[email-masked]> on behalf of Colin Perkins <[email-masked]>
Sent: 01 July 2020 10:57

> be based on rough consensus of the WG, see RFC 7282.

Publish.

Operators need help in understanding the impact of emerging technology on their ability to operate a network.  This may not be easy to understand but it does at least provide something to stick out and alert them.

Tom Petch

The last two

In that context,

-Ekr

--
Colin Perkins
https://csperkins.org/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Jul 2020 07:15:40 -0500

Top-posting to note that this "WGLC" is now being copied to INT-AREA and
SAAG, people are making statements about value to operators (but no
operator-area entity is being copied), and people are making statements
about whether this could be published in the IETF stream, with the IETF
consensus boilerplate.

All of these are fine conversations during *IETF* Last Call, and it seems
like we're about halfway to including the rest of the IETF in the WGLC
anyway, but is this a sign that the discussion has moved beyond WGLC, so
the venue for the discussion should move, too?

And this isn't remotely my call. I just had to ask.

Best,

Spencer, not ranting

On Thu, Jul 2, 2020 at 6:00 AM tom petch <[email-masked]> wrote:

> Operators need help in understanding the impact of emerging technology on
> their ability to operate a network.  This may not be easy to understand but
> it does at least provide something to stick out and alert them.
>
> Tom Petch
>
> I agree, but also note that RFC 7258 is clear that some network monitoring
> can be beneficial and that “an appropriate balance” has to be found between
> mitigating pervasive monitoring and supporting network management. This
> draft is intended to highlight issues to be considered by transport
> protocol designers, to help them find that balance.
>
> And, to be clear, if transport protocol designers consider the issues and
> decide that all the metadata in their transport protocol must be encrypted,
> that’s fine. We're not pushing for a particular outcome; rather that the
> issues be considered and discussed when making a decision on what to
> encrypt.
>
> The last two
> The issues highlighted in the draft were certainly considered in the
> design of QUIC, especially in the discussions around the spin bit and
> operational aspects. I cannot envisage that they won’t also be considered
> in the design of future transports.
>
> In that context,
> I tend to regard critiques of protocol design as a good thing, but then we
> maybe have a different interpretations of that term. Certainly there are
> implications of the decision to encrypt transport metadata. There are
> benefits to it, but also costs. It’s important to understand both, to make
> an informed judgement on what to encrypt.
>
> Different communities have different interpretations on what’s the neutral
> point of view phrasing here, but I'm comfortable with further highlighting
> malicious uses of transport metadata in the draft. We’d tried to mostly do
> this by reference, since such things have been widely discussed in the
> past, but perhaps that’s not sufficient.
>
> [0]
> https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 3 Jul 2020 20:24:02 -0400

On Fri, Jun 12, 2020 at 12:04 PM Tony Rutkowski
<[email-masked]> wrote:
>
> The term “let’s encrypt” is used countless times as a generic reference in the IETF, other SDOs and the marketplace.  It is about as generic a term as exists today.  However, it appear that the ISRG is attempting to claim the term as their own in the marketplace through the US Patent and Trademark Office coupled with complaints about alleged infringements.
>
>  https://www.theregister.com/2020/06/10/lets_encrypt_trademark_complaints/
>
> This is preposterous and an abuse of the trademark and standards systems to create a marketplace monopoly.
>
> If you use the USPTO online system, you can see the full history.
> http://tmsearch.uspto.gov/
> Click on "Basic Word Mark Search" and enter “Let’s Encrypt”
>
> This was originally Comodo’s mark filed on 16 Oct 2015 and abandoned 25 June 2016.  Thirteen days later, ISRG which exists as a tax-exempt, non-profit corporation for advancing "educational" objectives, filed for the mark.
>
> A considerable number of entities have used the term Let's Encrypt in the marketplace for all kinds of purposes, including as a political movement.  Google Search finds about 6,840,00 of them going back almost 20 years.
>
> It is found 447 times in the IETF alone for advancing all manner of activities without ever disclosing a trademark assertion.
>
> For the ISRG to threaten some other company for using the term “Let’s Encrypt” with the arguments at the end of The Register article is beyond inappropriate.  The term is generic and used by countless others in the marketplace.
>
> Lastly and most significantly, the actual Let’s Encrypt word mark – Serial Number 88828174 was just filed on 10 March 2020, asserting first use in commerce on 24 Feb 2020, and is just being published for Opposition on 7 July 2020.
>
> Interested parties should file a USPTO opposition.  Those representing the ISRG minimally owe the IETF Trust the courtesy of filing an IPR notice.

Dell attempted to trademark "cloud computing" 12 years ago but it was
declined: https://web.archive.org/web/20081002195739/http://www.techworld.com/opsys/news/index.cfm?newsid=102279
.

I wonder why the trademark was issued in this case. Let's Encrypt was
in the vernacular long before the application of the trademark.

Jeff

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 3 Jul 2020 20:52:01 -0400

Hi Jeff,

PTO examiners make mistakes all the time.  Fortunately there are 
administrative and judicial appeals processes when push comes to shove 
and the world collectively ignores the trademark holder and the 
registrant  tries to enforce it.

We went through the same process with the trademark INTERNET.  A PTO 
examiner bought off on registration by a banking consortium for their 
own internet protocol network supporting ATMs globally. In the early 
90s, they started sending out threatening letters. After several years 
of machinations on appeal, the matter was settled in 2000 when all the 
parties agreed that the term was generic and couldn't be claimed by anyone.

--tony

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2020 03:06:53 -0000

In article <[email-masked]>,
Tony Rutkowski  <[email-masked]> wrote:
>The term �let�s encrypt� is used countless times as a generic reference 
>in the IETF, ...

I've looked through all of the published RFCs and the only places the
phrase "Let's Encrypt" appears in any capitalization is in RFCs 8555
and 8659 to refer to the IRSG as theauthors' workplace.

I've looked through all of the active I-D's and find it in
draft-ietf-acme-star-11, draft-sheffer-hum-app-req-00, and
draft-trammell-optional-security-not-02 where it also refers to the
IRSG's project.

Could you help us out and specifically identify some of the 447 places
it's used in a generic sense in the IETF? Tnx.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 4 Jul 2020 07:18:11 -0400

It has plainly been turned into a generic slogan via the IETF to 
dominate a marketplace and put other companies out of business through 
what are generally considered anticompetitive practices. There was never 
an assertion of trademark.

This is a matter to be pursued by competition and trademark authorities 
and the judicial system, not here.

--tony

On 7/3/2020 11:06 PM, John Levine wrote:
>> The term ï¿½letï¿½s encryptï¿½ is used countless times as a generic reference
>> in the IETF, ...

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 4 Jul 2020 07:26:00 -0400

I should have added...pursued by the law enforcement authorities as 
well.  See, e.g., https://www.ic3.gov/media/2019/190610.aspx

--tony

On 7/4/2020 7:18 AM, Tony Rutkowski wrote:
>
> This is a matter to be pursued by competition and trademark 
> authorities and the judicial system, not here.
>

---

From: "John R Levine" <[email-masked]>
Date: 4 Jul 2020 10:04:03 -0400

> It has plainly been turned into a generic slogan via the IETF to dominate a 
> marketplace and put other companies out of business through what are 
> generally considered anticompetitive practices. There was never an assertion 
> of trademark.

Hi, Tony.  If you're not familiar with the way that search enginges work, 
they can't tell the difference between generic and nominative use.  When I 
type that into Duck Duck Go, I see a lot of nominative use, to 
refer to the IRSG's service.

So I'm concluding that the answer to my question is "No".

>> it's used in a generic sense in the IETF? Tnx.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly