Re: Mandatory encryption *is* theater

On Aug 25, 2013 5:02 PM, "Eliot Lear" <lear@cisco.com> wrote:
>
> 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:

OK I see. Sure, we can discuss previously decided matters on mandatory to
use security, but I'm not very interested. I'm at this moment more
interested in the discussion around mandatory to offer encryption. If
people are interested in clarifying the reasons they disagreed with
mandatory to use security, go ahead and I'll stay out of the way.

>
>> 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.

If your point is mandatory to offer encryption => mandatory to use
encryption, then I am happy to discuss this.

There's a key distinction that may be getting lost here. Yes, the proposal
is that it is mandatory for the server to implement and offer encryption.
But it's not mandatory for a client to choose to use encrypted HTTP/2.

Another key distinction is encryption does not require authentication, so a
proper cert is not mandatory. I'm surprised you mention requiring a proper
cert given that you clearly understand a proper cert isn't necessary, given
your reply to Yoav below. I think it's worthwhile to discuss the asserted
benefit, but any statement about the current proposal requiring proper
certificates sounds factually incorrect as far as I can tell. Did I miss
something here?

>
> 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