Re: Mandatory encryption *is* theater

On 8/25/13 10:18 PM, Roberto Peon wrote:
> We've seen that the network delays bytes on some ports because (we 
> assume) of inspecting proxies, even when the data is incomprehensible 
> to the proxy.
maybe I am naif but the delay can be just because the proxies (lets just 
talk of HTTP here) expect HTTP traffic and they get confuse when they 
see something else

> If the bytes are merely signed then the bytes are visible and 
> modification is still performed-- the modification becomes 
> time-domain, e.g. dropping/delaying packets, etc.

If we let always possible to discover the presence of a proxy by the 
client... and the client realize that dropping/delaying packets is much 
higher
when there is that proxy in between ... it is just a matter of the time 
and the market will decide

>
> In any case, if you're doing the work of signing, why not just encrypt?
because you can still use all the positive aspects of the proxy/cache

/Salvatore

>
> -=R
>
>
> On Sun, Aug 25, 2013 at 1:07 PM, Salvatore Loreto 
> <salvatore.loreto@ericsson.com <mailto:salvatore.loreto@ericsson.com>> 
> wrote:
>
>     so now I have a question
>     if one of the reasons to use encryption is to let the bytestreams
>     traverse the networks without modifications
>     why don't just sign them instead that encrypt them?
>
>     /Sal
>
>
>     On 8/25/13 9:09 PM, Roberto Peon wrote:
>>     Remember that encryption != security.
>>     Part of the reasons to use encryption have nothing to do with
>>     security, but rather reliability-- encrypted bytestreams traverse
>>     the network without modification far more successfully.
>>
>>     There should be no reason that the client shouldn't be able to
>>     request this more reliable channel when the URL is HTTP.
>>
>>     As far as I understand, this is what we're talking about-- the
>>     client's ability to request an encrypted channel for HTTP urls.
>>
>>     -=R
>>
>>
>>
>>     On Sun, Aug 25, 2013 at 11:46 AM, Eliot Lear <lear@cisco.com
>>     <mailto:lear@cisco.com>> wrote:
>>
>>         Will,
>>
>>
>>         On 8/25/13 5:29 PM, William Chan (陈智昌) wrote:
>>>
>>>         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?
>>>
>>
>>         Possibly you did or possibly I did.  I have two specific
>>         issues with anonymous encryption:
>>
>>         1.  The threat it is addressing may be better dealt with at
>>         other layers; and
>>         2.  It is often sold as more than it is.
>>
>>         As I wrote, I do like the idea of DANE + DNSSEC and then
>>         expanding on that.  Got code for that?  If it's real privacy
>>         (not just encryption) then I'd probably be convinced (there
>>         is a matter of responsibility, but I think  DANE + DNSSEC
>>         could get us there, as can certs from credible CAs).
>>
>>         And just for the record:
>>
>>
>>>         Yes, the proposal is that it is mandatory for the server to
>>>         implement and offer encryption.
>>
>>         That is in fact my objection, particularly the "offer" part. 
>>         You seem to be assuming (forgive me if you are not) that many
>>         implementations small and large AND many deployments small
>>         and large will do a whole lot of work for that offer where
>>         past experience shows that they won't, but rather that it
>>         will in fact hinder implementation and deployment of the rest
>>         of HTTP2.  There is an obvious question about the goals for
>>         HTTP2...
>>
>>         Eliot
>>
>>
>
>