Re: Mandatory encryption *is* theater

I don't think we were questioning the possibility to speak between 
client and server
without any encryption if both parties agree to speak in clear (i.e. TLS 
is not mandatory to use)

The hum, at least how I understood it, was only in favor to investigate 
a way to provide
from one side equal power to the client:
i.e. to provide to the client the possibility to require/negotiate the 
use of encryption;
and from the other side provide to the client the possibility to 
discovery the interposition
and then eventually interact with that proxy in between.

Having said that I agree with Eliot that solving everything just saying 
lets use TLS
is a theater, instead we should work on a way to authenticate endpoints, 
proxies,
how to provide data integrity etc.


/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com



On 8/25/13 8:16 AM, Eliot Lear 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
>
>
>

Received on Sunday, 25 August 2013 07:10:41 UTC