Re: Mandatory encryption *is* theater

I'm answering a few messages at once, starting with Will's & Roberto's,
and then going on to Yoav's,

Will, you asked:
> Eliot, can you clarify what section of the minutes you're responding to?

Yes.  Starting with:
> SPDY introduced Madatory [sic] to Use Security; this was
> discussed for HTTP2.0; the working group declined, because of use cases like
> back end services.

Certainly home services can't be considered "backend" and most
enterprises uses could only be considered "backend" with the broadest
use of the term.  In short, there were *many *reasons why the group came
to the decision it came to.  And then moving on, Mark said:

> Mark says "mandatory to offer" is closer to what he said.

Which is in effect mandating of encryption.  After all, how can the
server offer it if it doesn't support it or if a proper certificate
isn't configured.  And the complexity issue arises as well.  The 2nd hum
as stated in the minutes was a vague question, as I wasn't in the room
at that precise moment, that's what I'm going by.

Yoav, you wrote:

On 8/25/13 9:33 AM, Yoav Nir wrote:
> Hi Eliot.
>
> Your message implies that the choice is between cleartext HTTP and an annual fee to a certificate vendor.

Yes.  Maybe really large enterprises have their own CA or even PCA, but
the cost still has to be paid for that.
>
> IETF standards provide at least two other options:
>
> DANE allows you to use a self-issued certificate and register the key in the DNS. This is not implemented in the many thousands of small devices that you mention, or in any browser, but then neither is HTTP/2. 

I agree with you, except for your last assertion - http2 *is* being
implemented in several browsers.  I think it would great if those who
hummed for this discussion exerted some effort to support DNSSEC and
then DANE.

> There is a deployment issue in that publishing a random RR is a non-trivial process. For example, [1] makes no mention of how to generate TLSA records, and GoDaddy (largest registrar in the world) has nothing about it in their support. But all that could change.

The principal issue with DANE is its dependency on DNSSEC.  As nearly
large an issue is the publication of different RRs.  *That* is a big
deal (see the IETF main list and the discussion of SPF), but probably
not appropriate here.

>
> TLS as anonymous ciphersuites that do not require a certificate at all. True, these ciphersuites do not protect against on-path attacks, but they do stop passive listeners, and there is some value in that. Not enough to call it "HTTPS", but it is better than nothing. And the application can still use some channel binding to discover the MitM, such as Trevor's Smart Cookie proposal where the cookie (which is a secret shared by client and server) is bound to the current master secret ([3]). Even without this, defeating passive listeners is a worthy goal.

Yes, but I would be concerned about the benefit being overstated.  I say
this because the reason the chair revisited the discussion is as follows:

> There is new information; there are widespread deployments of sniffers. More
> details have since been released. As Chair, Mark felt that this was enough to
> re-open the discussion.

Anonymous cypher suites might well have changed the character of this
problem, but probably not have reduced it, and may have introduced
unintended consequences.   They still may help with the so-called
"Starbucks" problem, but to me that problem is better dealt with at a
lower layer so that ALL communications on that network can be
protected.  I also believe that the underlying issues of the above
quoted statement lie elsewhere (about 3  to 4 layers above HTTP). 
Again, let's tease out the threat.

Eliot