Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

From: Sean Turner <[email-masked]>
Date: Thu, 2 Nov 2017 12:38:39 -0400

> On Oct 24, 2017, at 12:49, Joseph Salowey <[email-masked]> wrote:
> 
> As is normal IETF practice, we will be giving this topic agenda time in Singapore to see if a consensus emerges one way or the other.

Just in case you’re following this thread and not the other administrivia emails, please see my email concerning agenda requests related to this draft:
https://mailarchive.ietf.org/arch/msg/tls/AX5eg4dzS4QBMcNkXK25UCMpFmA

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Nov 2017 15:34:24 -0500

Friday afternoon seems like a tolerable time to do something so
questionably productive as mailing to this thread...

On 10/25/2017 09:50 AM, David A. Cooper wrote:
> This question is based on your that belief that this protocol will
> "escape" onto the public Internet, that browsers and other clients
> used by individuals will feel forced to implement it, and that clients
> will then be forced to enable the extension in order to get through
> middleboxes that would filter traffic based on whether or not the
> extension is present in the ClientHello. I've already explained why I
> believe that scenario will never happen, and so no I do not agree that
> it is a "fundamental change."

Not picking on David in particular, it just happened to be the first
message I found going back through the thread that exhibited this
phenomenon.

Namely, I have seen a lot of reasoning along the lines of "this would
never happen on the public internet because there are so many other,
cheaper/more efficient/easier ways to do it".  I don't  find that line
of reasoning very persuasive.  This is not necessarily because I
disagree with the cheaper/more efficient/easier classification, but
rather because it seems out of scope for us as a technology
organization.  IMO, we ought to be considering all the potential
ramifications of a protocol change, in all the environments where that
protocol is or might be deployed, as a purely technological matter, so
that we can understand its potential impacts.  Just because something is
expensive or inefficient today does not mean that it is not a capability
of the technology we are developing, and cost and efficiency can change
over time.  In cryptanalysis, we do not discount attacks that require
large amounts of storage, because they are still valid algorithmic
attacks, and lo and behold, as storage gets cheaper, we find that these
sorts of attacks do get used.  Similarly for protocol design/analysis,
we should not discount a particular protocol interaction just because
there are at present other ways to do a similar thing, and those other
ways currently seem more attractive.

-Ben