W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: The TLS hammer and resource integrity

From: Adrien W. de Croy <adrien@qbik.com>
Date: Thu, 29 Mar 2012 09:15:56 +0000
To: "Robert Collins" <robertc@squid-cache.org>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "Henry Story" <henry.story@bblfish.net>, "patrick mcmanus" <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em6545202a-8f50-448c-9f2e-b68991c74c10@boist>

------ Original Message ------
From: "Robert Collins" <robertc@squid-cache.org>
>
>Its entirely possible as the risks of unencrypted traffic grow, that
>jurisdictions will bring in legislation that makes it illegal *not* to
>take reasonable steps to protect the personal information of users of
>a service. I'd be surprised in fact, if some interpretations of
>existing privacy and data protection law wouldn't in fact find
>negligence on any service not using TLS.
>
  
meanwhile other jurisdictions come to mind that force companies that 
provide secure systems to leave the country or shut down services until 
they can be made insecure.
  
Just talk to RIM about India or Saudi Arabia.
  
Many jurisdictions have laws requiring telcos to enable wire-tapping.  
Even NZ.
  
In other jurisdictions public use of crypto is outright illegal.
  
Wassenaar arrangement anyone?
  
Has anyone even discussed any of this with any government? You might be 
surprised. 
We can't make a shoe that will fit every foot.  Therefore we must allow 
choice.
>
>So, while it is true that *one* factor we have to consider when
>assessing *concrete proposals* is whether the proposal as a whole will
>be seen as an improvement by *most* HTTP implementors, there is scant
>evidence today that either:
>a) requiring TLS would make it 'not an improvement' for most implementors
>or
>
  
have you ever worked on a support desk?
  
There's more to life than even just latency, reliability or CPU / 
memory load.
  
There's administrative burden and human and support cost.
  
People who can't even configure their email client are going to have to 
manage TLS servers.  IMO this can only be simplified for the masses at 
the expense of security.
  
>
>b) not requiring TLS would make it 'not an improvement' for most implementors.
>
>With the exception of the netflix statement, the only evidence I've
>seen put forward here is, frankly hearsay and hyperbole.
>
There are plenty of improvements to be had without requiring TLS.  It's 
ironic you accuse all of us of hyperbole.
>
>We should focus on creating the key criteria we're going to judge the
>concrete proposals on. There have been some very good things mentioned
>in passing as far as TLS goes:
>- the ability to run an implementation on resource constrained
>hardware - sheevaplugs, for instance
>- the ability to have mass market consumer goods, like ADSL gateways,
>which roll off a factory line with identical images.
>- the ability for any device on the internet to be a HTTP/2.0 end
>point without requiring a central registry (either explicit or
>defacto) for such devices.
>- keeping performance in mind: .nz to .uk traffic already pays a high
>setup premium for small HTTP objects, making the *overall* user
>experience suffer would be a sure way to make HTTP/2.0 unpopular for
>many folk.
>
  
Actually this isn't a bad start. I'd add a few more.
  
- keeping cost in mind (financial, human/time/support)
- debugging.  Currently I can debug HTTP issues with a packet sniffer.  
Good-bye to that with TLS.
- keeping supporting infrastructure requirements in mind.  
  
There's a heap of associated infrastructure for PKI.  We don't want to 
make the whole system more fragile.  What happens when a CA root 
private key is breached?  What happens if this coincides with a DoS 
attack on their OCSP servers?  We'll need a replacement protocol for 
OCSP, that's the relatively easy bit.
  
Compared to providers of things like DNS, or HTTP services, there are 
extremely few root CAs.  Moving everyone to TLS will make these few 
organisations linchpins for the whole internet.  Unlike the root DNS 
servers, cert validation is signed, and so can't be delegated (or can 
it?).
  
And proposals to use shared secrets instead of certs won't fly for the 
web where there are billions of peers.
  
In the end, we need to rely on trust.  That's all you're doing with TLS 
anyway.  Trusting the CA.
  
Once we accept that trust is required somewhere along the line, things 
should get a bit simpler.
  
Adrien
>
>So, even if we can't agree on TLS/noTLS *today*, can we at least agree
>that the criteria above are important - and I'm sure there are many
>more such criteria that can be extracted from the conversation so far.
>
>-Rob
>
>
>
Received on Thursday, 29 March 2012 09:16:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT