Subject: Re: [TLS] TLS Impact on Network Security draft updated

From: Dennis Jackson <[email-masked]>
Date: Wed, 24 Jul 2019 00:44:20 +0100

RFC 791  is nearly 40 years old.
RFC 4074 lists 5 forms of deviations from RFC 1034 and explains 
the correct behavior. 
RFC 7021 describes a series of objective tests of RFC 6333 and 
the results. 

The above RFCs describe objective test results and how they 
relate to earlier RFCs. In contrast, this document offers a 
speculative and subjective discussion of possible future impact.

I do not believe there is any precedent supporting publication.

Best,
Dennis

> On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda <[email-masked]> <mailto:[email-masked]&gt>;
> wrote:
>
> > Before any technical or wording feedback, I am confused as to the nature
> > of this document. It does not seem to specify any protocol change or
> > mechanism, and it does not even focus on solutions to move the web further.
> >
> > Instead, it looks like a well edited blog post, presenting the perspective
> > of one segment of the industry. (The perspective seems to also lack
> > consensus, but I believe even that is secondary.) Note how as of
> > draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> > security considerations, and no occurrences of any of the BCP 14 key words
> > (MUST, SHOULD, etc.).
> >
> > Is there precedent for publishing such a document as an RFC?
> >
>
> I was going to say RFC 691 but no, it recommends changes to the protocol
> (as well as being quite amusing). RFC 4074 comes close describing bad
> behavior without an explicit plea to stop doing it, but has a security
> considerations section. RFC 7021 describes the impact of a particular
> networking technique on applications.
>
> So there is precedent.
>
> Sincerely,
> Watson

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 21:55:04 -0400

As a professional organization and part of due diligence, we need to try and understand the risks and ramifications on the deployments of our solutions. This means, understanding exactly how the market uses and needs to use the solutions we create. When we remove or change some technology, we should try hard to provide a work around. If a work around is not possible, we need to cleanly document how these changes are going to impact the market so it can prepare. This is the responsible and prudent thing to do in a professional organization like the IETF. 

The draft that Nancy and others have worked on is a great start to documenting how these new solutions are going to impact organizational networks. Regardless of whether you like the use-cases or regulations that some organizations have, they are valid and our new solutions are going to impact them. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 23, 2019, at 7:44 PM, Dennis Jackson <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Jul 2019 02:03:41 +0000

I repeat my question: What does it say that RFC 8404 doesn’t?

---

From: Dennis Jackson <[email-masked]>
Date: Wed, 24 Jul 2019 03:35:43 +0100

On 24/07/2019 02:55, Bret Jordan wrote:
> As a professional organization and part of due diligence, we need to try
> and understand the risks and ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and
> needs to use the solutions we create. When we remove or change some
> technology, we should try hard to provide a work around. If a work
> around is not possible, we need to cleanly document how these changes
> are going to impact the market so it can prepare. This is the
> responsible and prudent thing to do in a professional organization like
> the IETF. 
> 

The IETF is for development of Internet Standards. If you want to
publish your (subjective) analysis of how a particular standard is going
to impact your market segment, there are any number of better venues:
trade magazines, industry associations, your company website, etc.

> The draft that Nancy and others have worked on is a great start to
> documenting how these new solutions are going to impact organizational
> networks. Regardless of whether you like the use-cases or regulations
> that some organizations have, they are valid and our new solutions are
> going to impact them. 

This isn't a question of quality. The IETF simply doesn't publish
documents of this nature (to my knowledge).

Best,
Dennis

>> On Jul 23, 2019, at 7:44 PM, Dennis Jackson
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Jul 2019 22:13:44 -0500

> trade magazines, industry associations, your company website, etc.

Actually, the Independent stream of the RFC series is purpose-built for
individual commentary on the consequences of a particular standard
[including in a particular segment], and would be superior (at least in
my opinion) to any of the venues you list.  (See RFC 4846.)  But I
believe the current ISE asks authors to try fairly hard to publish their
work in the IETF before accepting it to the Indepndent stream.

> documents of this nature (to my knowledge).

The IETF can publish whatever there is IETF consensus to publish.  (And
a little bit more, besides, though that is probably not relevant to the
current discussion.)

I don't have a great sense of what you mean by "documents of this
nature".  If you were to say "the IETF does not publish speculative and
subjective discussion of possible future impact", I'd be fairly likely
to agree with you (but I have also seen a fair bit of speculation get
published).  I'd feel rather differently about "the IETF does not
publish objective analysis of the consequences of protocol changes on
previously deployed configurations", and would ask if you think a
document in the latter category is impossible for the TLS 1.2->1.3
transition.  (My understanding is that the latter category of document
is the desired proposal, regardless of the current state of the draft in
question.)

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Jul 2019 20:18:27 -0700

On Tue, Jul 23, 2019, 6:55 PM Bret Jordan <[email-masked]> wrote:

> solutions. This means, understanding exactly how the market uses and needs
> to use the solutions we create. When we remove or change some technology,
> we should try hard to provide a work around. If a work around is not
> possible, we need to cleanly document how these changes are going to impact
> the market so it can prepare. This is the responsible and prudent thing to
> do in a professional organization like the IETF.
>

What technology was removed?

Was it TLS proxies equipped with the private key? No, those still work.
Interception devices with a root? No, still work. So what broke?

> networks. Regardless of whether you like the use-cases or regulations that
> some organizations have, they are valid and our new solutions are going to
> impact them.
>

It continually conflates some methods of achieving a goal with all of them.
As shown by some of the exchanges the draft substantially overstates the
issues.

---

From: Dennis Jackson <[email-masked]>
Date: Wed, 24 Jul 2019 05:19:46 +0100

> work in the IETF before accepting it to the Indepndent stream.

I was thinking of 'published by the IETF' to mean the IETF stream.
Publishing in the Independent stream, without any proper review,
consensus or claim of fitness is a different matter altogether.

> published).  

This was my intended meaning.

I'd feel rather differently about "the IETF does not
> is the desired proposal, regardless of the current state of the draft in

The authors initiated this discussion by stating their draft was stable
and requesting publication. Consequently, I think it must be judged on
the current state, rather than the desired outcome.

Even considering your more generous interpretation... the objective
discussion is only 3 out of 15 pages and none of the 5 claims appears to
be correct. (As others have pointed out).

Best,
Dennis

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Jul 2019 06:27:33 -0500

> I was thinking of 'published by the IETF' to mean the IETF stream.

Thanks for clarifying (more below).

> consensus or claim of fitness is a different matter altogether.

My understanding is that the ISE insists on getting at least three
reviews from knowledgable people in the field as a condition of
publication.  I don't know what constitutes "proper review" to you, but
I do believe that the ISE takes the job seriously.

> This was my intended meaning.

Thanks (again) for clarifying.

> the current state, rather than the desired outcome.

Sure, and I appreciate the frank comments; I hope the authors do as
well.  However, my and the chairs' job is to tell them something like
"make these changes and come back" or "make these changes and go to the
ISE", so I have to seek feedback on a broader question than just "is it
ready to go right now".

> be correct. (As others have pointed out).

In light of my previous remark, I'll try to summarize that it sounds
like you think that it's not worth trying to make all the changes that
would be needed to meet your expectations for the output of the TLS WG.

Thanks,

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2019 16:49:25 +0100

I'm not in favour of adoption or discussion of this draft on the
WG list. I'm also against publishing it in the IETF stream. It's
a waste of everyone's time. I hope the chairs take the opportunity
to close this thread soon.

On 24/07/2019 04:13, Benjamin Kaduk wrote:
> the Independent stream of the RFC series is purpose-built for

Yes. If the authors want an RFC for this text they ought contact
the ISE.

Cheers,
S.