Resent-Date: Sun, 14 Jul 2013 00:17:25 +0000
Resent-Message-Id: <E1UyA0D-0004XD-PQ@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <51E1D7AF.20708@jrn.me.uk>
References: <5672.1373710085@critter.freebsd.dk> <51E1D7AF.20708@jrn.me.uk>
Date: Sat, 13 Jul 2013 17:16:50 -0700
Message-ID: <CAP+FsNekY4WWdsYdUX3_vUWm1pqepWOH7PdiS9ZxpFwkHnqXWA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: J Ross Nicoll <jrn@jrn.me.uk>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>,
 HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11330b2209caed04e16da9f6
Received-SPF: pass client-ip=209.85.219.48; envelope-from=grmocg@gmail.com;
 helo=mail-oa0-f48.google.com
Subject: Re: PRISM and HTTP/2.0
Archived-At: <http://www.w3.org/mid/CAP+FsNekY4WWdsYdUX3_vUWm1pqepWOH7PdiS9ZxpFwkHnqXWA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--001a11330b2209caed04e16da9f6
Content-Type: text/plain; charset=ISO-8859-1

I have a difficult time believing that any solution, short of new
physics-based technologies, will overcome the tradition of users'
ambivalence when faced with any obstacle to convenience.
-=R


On Sat, Jul 13, 2013 at 3:41 PM, J Ross Nicoll <jrn@jrn.me.uk> wrote:

> With regards to #1, I'm not sure the concept of "more encryption" is
> really what's meant here. Minimum key lengths could be increased, perhaps
> different encryption methods merged such that if one approach is broken
> then the message is still secure... however I think we can fairly
> realistically assume no-one's going to try tackling the encryption itself
> head-on.
>
> Bogus certificates and server-side backdoors seem inevitable, at least in
> the current political climate. I don't think any realistic changes at the
> transport layer will affect that (unrealistic changes would include "move
> to a web of trust"). Equally I don't think there's any need for changes to
> enable access; they're doing that just fine without us, and inevitably any
> such hooks are weaknesses that can potentially be exploited by an attacker.
>
> About the only changes I could suggest from a technical point of view
> would be user-interface related. Indicate when a server certificate
> changes, for example, especially if the previous certificate's expiry
> wasn't due for a while. The same sort of defences that are relevant against
> phishing attacks, are useful for evading other forms of site impersonation.
>
> I think this is a discussion worth having, because even "There is nothing
> to be changed" is a concrete conclusion to come to, but that may be the
> answer here.
>
> Ross
>
>
> On 13/07/2013 11:08, Poul-Henning Kamp wrote:
>
>> I would like to advocate that everybody spends a little bit of time
>> reconsidering how we design protocols after the PRISM disclosures.
>>
>> We don't need to have a long discussion about the actual legality
>> of the US spy operation, the sheer scale and the kind of efforts
>> that went in to it is the relevant message to us.
>>
>> The take-home message is that encryption will be broken, disabled,
>> circumvented og watered down, if it gets in the way of political
>> objectives.
>>
>> We can do three things in light of this:
>>
>> 1) We can try to add more encryption to fight back.
>>
>> 2) We can recognize that there needs to be hooks for duly authorized
>> access.
>>
>> 3) We can change or at least influence the political objectives
>>
>> I think PRISM is ample evidence that #1 will have the 100% certain
>> result is that all encryption will be circumvented, with bogus CA
>> certs all the way up to PRISM and designed-in backdoors, and the
>> net result is less or even no privacy for anybody everywhere.
>>
>> In my view, that would be very counterproductive.
>>
>> #2 is not without challenges, but at least there are plausible paths
>> from there to a state of affairs where innocent people might still
>> have access to private communications, and it might seem to be a
>> necessary precondition for any hope on #3
>>
>> #3 is clearly not inside HTTPbis scope, but it may be time for
>> all good nerds to come to the aid of their country and humanity.
>>
>> A "market based" argument can be made under #3, that if we design
>> protocols with the necessary access (#2), programs like PRISM will
>> not be cost effective, but that will take some serious effort
>> of education and politics.
>>
>> Anyway:  Edward Snowden has moved the rug under the HTTP/2.0
>> standardization process, and we should not ignore that.
>>
>> Think about it.
>>
>>
>
>

--001a11330b2209caed04e16da9f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have a difficult time believing that any solution, short=
 of new physics-based technologies, will overcome the tradition of users=
9; ambivalence when faced with any obstacle to convenience.<div><div>-=3DR<=
/div>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Sat, Jul 13, 2013 at 3:41 PM, J Ross Nicoll <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jrn@jrn.me.uk" target=3D"_blank">jrn@jrn.me.uk</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">With regards to #1, I&#39;m not sure the con=
cept of &quot;more encryption&quot; is really what&#39;s meant here. Minimu=
m key lengths could be increased, perhaps different encryption methods merg=
ed such that if one approach is broken then the message is still secure... =
however I think we can fairly realistically assume no-one&#39;s going to tr=
y tackling the encryption itself head-on.<br>

<br>
Bogus certificates and server-side backdoors seem inevitable, at least in t=
he current political climate. I don&#39;t think any realistic changes at th=
e transport layer will affect that (unrealistic changes would include &quot=
;move to a web of trust&quot;). Equally I don&#39;t think there&#39;s any n=
eed for changes to enable access; they&#39;re doing that just fine without =
us, and inevitably any such hooks are weaknesses that can potentially be ex=
ploited by an attacker.<br>

<br>
About the only changes I could suggest from a technical point of view would=
 be user-interface related. Indicate when a server certificate changes, for=
 example, especially if the previous certificate&#39;s expiry wasn&#39;t du=
e for a while. The same sort of defences that are relevant against phishing=
 attacks, are useful for evading other forms of site impersonation.<br>

<br>
I think this is a discussion worth having, because even &quot;There is noth=
ing to be changed&quot; is a concrete conclusion to come to, but that may b=
e the answer here.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Ross</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 13/07/2013 11:08, Poul-Henning Kamp wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I would like to advocate that everybody spends a little bit of time<br>
reconsidering how we design protocols after the PRISM disclosures.<br>
<br>
We don&#39;t need to have a long discussion about the actual legality<br>
of the US spy operation, the sheer scale and the kind of efforts<br>
that went in to it is the relevant message to us.<br>
<br>
The take-home message is that encryption will be broken, disabled,<br>
circumvented og watered down, if it gets in the way of political<br>
objectives.<br>
<br>
We can do three things in light of this:<br>
<br>
1) We can try to add more encryption to fight back.<br>
<br>
2) We can recognize that there needs to be hooks for duly authorized access=
.<br>
<br>
3) We can change or at least influence the political objectives<br>
<br>
I think PRISM is ample evidence that #1 will have the 100% certain<br>
result is that all encryption will be circumvented, with bogus CA<br>
certs all the way up to PRISM and designed-in backdoors, and the<br>
net result is less or even no privacy for anybody everywhere.<br>
<br>
In my view, that would be very counterproductive.<br>
<br>
#2 is not without challenges, but at least there are plausible paths<br>
from there to a state of affairs where innocent people might still<br>
have access to private communications, and it might seem to be a<br>
necessary precondition for any hope on #3<br>
<br>
#3 is clearly not inside HTTPbis scope, but it may be time for<br>
all good nerds to come to the aid of their country and humanity.<br>
<br>
A &quot;market based&quot; argument can be made under #3, that if we design=
<br>
protocols with the necessary access (#2), programs like PRISM will<br>
not be cost effective, but that will take some serious effort<br>
of education and politics.<br>
<br>
Anyway: =A0Edward Snowden has moved the rug under the HTTP/2.0<br>
standardization process, and we should not ignore that.<br>
<br>
Think about it.<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div>

--001a11330b2209caed04e16da9f6--