Re: Some reasons why mandating use ofSSL for HTTP is a really bad idea

On Wed, Jul 18, 2012 at 1:12 PM, Henry Story <henry.story@bblfish.net> wrote:
>
> On 18 Jul 2012, at 19:01, Zhong Yu wrote:
>
>> On Tue, Jul 17, 2012 at 10:25 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
>>> What about the other hundreds of millions of us running web servers.  You
>>> gonna buy us our certs?
>>
>> Agreed. It's absolutely impractical to mandate officially signed certs
>> on every website. That's a huge hurdle for small sites; and all big
>> sites started from small sites.
>
> Unless of course you start Deploying IETF DANE, which could make the procurement of
> such certs a lot easier, since it just requires placing a public key in DNSsec.
>
>    http://tools.ietf.org/wg/dane/
>
> making it easy to install such certs could be the task of a WG. Then one could add
> other services to verify that these certificate are not tampered with.

But now you have stepped away from mandating support for the TLS in
use today and instead mandating support for a new design based on a
science project.

To implement HTTP/1.1, all I need is a TCP stack and a HTTP stack.
Plenty of people have done both in a week.

To implement HTTP/2.0 with your proposed mandate would require

* TCP
* HTTP 1.1
* HTTP 2.0
* TLS
* PKIX
* DNS
* DNSSEC
* DANE


Oh and by the way:

* PKIX is layered on HTTP creating a potential infinite regression.
How does an OCSP server work over HTTP/2.0? Does the OCSP server cert
need to be validated via OCSP as well? Are CRLs going to be supported?

* Practical deployment of TLS REQUIRES an IPv4 address per connection
since there is a large population of browsers that do not support SNI.
If you mandate support for TLS in HTTP you will find everyone wants
their server to have legacy support as well.

If this is really an attempt to mandate DANE then people should say so.


-- 
Website: http://hallambaker.com/

Received on Wednesday, 18 July 2012 17:46:15 UTC