Re: Mandatory encryption *is* theater

Just chiming in here since I'm concerned that a misinterpretation of the
minutes may have led to an accidental straw man argument.

Eliot, can you clarify what section of the minutes you're responding to? I
see only one hum for HTTP/2:
"""
Who believes that these issues are worthy of further discussion: Hum in
support:strong hum. Hum against: silence. Good, and we are now at the end of
the alloted time for this.
"""

I don't see anything on humming on mandatory encryption. I note that
there's a section of the minutes where Larry and Mark are clarifying the
topic, since Larry said the topic was introduced as mandatory to implement
security, whereas Mark clarified:
"""
Mark says “mandatory to offer” is closer
to what he said.
"""

So, I don't believe "mandatory encryption" was even discussed at the last
IETF, merely mandatory to offer [i forget if it was security or encryption,
but I suspect encryption]. And let's be precise about the language, since
security != encryption. You mentioned encryption, and then talked about
certificate warnings. Let's remember you can try to encrypt without
authenticating the peer.

Now, we can have a debate about whether or not mandatory encryption is
security theater, but I think no one is beating that drum right now
(although I won't preclude the possibility of someone stepping up to do
so). So it's probably best to stick to the topic that we discussed at the
last IETF, namely mandatory to offer [encryption?], unless someone would
like to discuss mandatory encryption right now.

Cheers.


On Sun, Aug 25, 2013 at 2:16 PM, Eliot Lear <lear@cisco.com> wrote:

> Mark,
>
> Regarding the minutes of the group, the working group declined to
> mandate encryption for a number of reasons, not just back end services.
> What I said the last time, was that we can damage overall Internet
> security by inuring people to certificate warnings � or we will inhibit
> adoption of HTTP2 � unless the mechanisms to manage certificates
> improve.  In addition many thousands of small devices exist without a
> simple means to enroll � and pay.  Even if they do enroll � and pay, the
> current certificate mechanisms require that they re-enroll - and pay.
> And so they don't.  There simply is no magic bullet.  The economics are
> clear.  The means to encrypt has existed nearly two decades.   Mandating
> encryption from the IETF has been tried before � specifically with IPv6
> and IPsec.  If anything, that mandate may have acted as an inhibitor to
> IPv6 implementations and deployment and served as a point of ridicule.
>
> And so, I do not agree with those who hummed in favor of mandatory
> encryption.  HTTP2 is already very complex and is biting off enough.
> The more it bites off the less likelihood of broad adoption.  We've seen
> this movie before.  What we will have instead of HTTP/2 will be an
> optional alternative to HTTP/1.1 that is deployed by large scale high
> performance services.  Maybe that was always the goal, but if so, let's
> recognize that and relabel.  I was under a different impression.
>
> If we wish to explore new means to authenticate endpoints, that would be
> a better starting point.
>
> Eliot
>
>