- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 28 Feb 2013 18:58:36 +1300
- To: ietf-http-wg@w3.org
On 28/02/2013 10:52 a.m., Ted Hardie wrote: > On Wed, Feb 27, 2013 at 1:44 PM, Eliot Lear wrote: >> Ted, the problem is that then we are essentially requiring TLS for >> implementation of HTTP 2.0. We've said we're not going to do that. > I don't think this is quite right. I think it means that if you use > the DNS hints mechanism, you should expect TLS. If you have other > upgrade methods, they would not be impacted. That doesn't require TLS > for implementation of HTTP 2.0 itself. > >> But >> also, the problem you describe is within control of both clients (albeit >> with a linkage to DNSSEC) and servers by not linking two secure and >> insecure services. Ultimately what is proposed represents no change >> because the server itself has to provide whatever capability we're >> discussing. >> > I don't really follow this; can you rephrase it? > > Ted > Can we take a step back folks and outline _exactly_ what it is that needs protecting here? - the datum responded by DNS? - the HTTP channel? Status Quo is that neither is protected. Unless you are embedding all sorts of security related ifnormation into this RR is can be no worse than A/AAAA records pointing at a domain are today. Some of you seem to be indicating that DNSSEC protected records pointing at non-TS connections is a major problem. It is *not* that major. That case is the Status Quo. We do want to improve it, but nothing proposed is making it _worse_ and nothing at either step is mandating anything about the other step. Amos
Received on Thursday, 28 February 2013 05:59:11 UTC