Re: Mandatory encryption *is* theater

On Sun, Aug 25, 2013 at 1:27 PM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

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

Oh it was worse that that :) Put correct HTTP over port 80 and it often
won't end up at the other side because you used a portion of the spec that
is not often used.


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

The market is efficient only when there are numerous choices and the
barrier to entry is low. That isn't true for things like this. The
endpoints currently have no choice about whether or not some portion of the
network is deploying what hardware/software, and often there is only once
choice of vendor. The only real choices clients/servers have is what the
bytes look like when they're sent.


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

You wouldn't be able to do that with a signed stream either without
allowing for proxies to do arbitrary transformations, at which point we're
back to where we are today in terms of reliability. These things are 100%
competitive with each other-- you can't both require signed data and
require not signed data!

I'd rather see explicitly configured proxies for this kind of thing-- then
the consumers are making the choice and can decide to not use it if it
doesn't provide a benefit (if the providers block encrypted traffic then
then only offer insecure traffic, which would not be tolerated in most
non-completely-backwards jurisdictions and entities).

-=R


>
>
> /Salvatore
>
>
>
>
>  -=R
>
>
> On Sun, Aug 25, 2013 at 1:07 PM, Salvatore Loreto <
> 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> 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
>>>
>>
>>
>>
>>
>