[148136] in cryptography@c2.net mail archive
Re: [Cryptography] HTTP should be deprecated.
daemon@ATHENA.MIT.EDU (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_l)
Tue Nov 12 15:30:23 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAEw2jfwq+=FVpXO34xRZCeB2ogp9aA_1_TKas913mfLF1JUjPQ@mail.gmail.com>
Date: Tue, 12 Nov 2013 10:12:12 +0100
From: =?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl>
To: Patrick Mylund Nielsen <cryptography@patrickmylund.com>
Cc: Russ Nelson <nelson@crynwr.com>, Greg <greg@kinostudios.com>,
John Kelsey <crypto.jmk@gmail.com>,
cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8542621505605008926==
Content-Type: multipart/alternative; boundary=001a11c303507a7b2f04eaf73ee3
--001a11c303507a7b2f04eaf73ee3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Nov 12, 2013 2:03 AM, "Patrick Mylund Nielsen" <
cryptography@patrickmylund.com> wrote:
> On Mon, Nov 11, 2013 at 7:45 PM, Lodewijk andr=C3=A9 de la porte <l@odewi=
jk.nl>
wrote:
>>
>
> I think you missed John's point, which was that, while the information
may be something that is readily accessible to all, the fact that YOU are
accessing it is interesting information. And that's true, but somebody is
going to get that information whether or not the channel is encrypted.
>
>>
>> Think of the caching disadvantages!
>
>
> Which? It's very easy to cache stuff when HTTPS is used, either
server-side or client-side (Cache-Control header.) It's just a transport.
ISPs are suggested to cache common files. The requests can be dealt with
locally, on the same network. Of course it requires static files but it
gives you a free CDN!
(Note it saves an ISP money to employ caches, that's why you can trust them
to do it. (Except when they have pairing agreements with the
destination...))
>
> The fact that the CA model is a mess and browsers depend on it is a much
bigger disadvantage.
But that can be solved and HTTPS upgraded. A solution that works "usually"
is better than one that doesn't exist.
--001a11c303507a7b2f04eaf73ee3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Nov 12, 2013 2:03 AM, "Patrick Mylund Nielsen" <<a href=3D"=
mailto:cryptography@patrickmylund.com">cryptography@patrickmylund.com</a>&g=
t; wrote:<br>
> On Mon, Nov 11, 2013 at 7:45 PM, Lodewijk andr=C3=A9 de la porte <<=
a href=3D"mailto:l@odewijk.nl">l@odewijk.nl</a>> wrote:<br>
>><br>
><br>
> I think you missed John's point, which was that, while the informa=
tion may be something that is readily accessible to all, the fact that YOU =
are accessing it is interesting information. And that's true, but someb=
ody is going to get that information whether or not the channel is encrypte=
d.<br>
> =C2=A0<br>
>><br>
>> Think of the caching disadvantages!<br>
><br>
><br>
> Which? It's very easy to cache stuff when HTTPS is used, either se=
rver-side or client-side (Cache-Control header.) It's just a transport.=
</p>
<p dir=3D"ltr">ISPs are suggested to cache common files. The requests can b=
e dealt with locally, on the same network. Of course it requires static fil=
es but it gives you a free CDN!</p>
<p dir=3D"ltr">(Note it saves an ISP money to employ caches, that's why=
you can trust them to do it. (Except when they have pairing agreements wit=
h the destination...))<br>
><br>
> The fact that the CA model is a mess and browsers depend on it is a mu=
ch bigger disadvantage.</p>
<p dir=3D"ltr">But that can be solved and HTTPS upgraded. A solution that w=
orks "usually" is better than one that doesn't exist.</p>
--001a11c303507a7b2f04eaf73ee3--
--===============8542621505605008926==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8542621505605008926==--
