Re: Upgrade status for impl draft 1

On 28/02/2013 8:31 p.m., Eliot Lear wrote:
> On 2/28/13 6:58 AM, Amos Jeffries wrote:
>
>> 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?
>>
> The case we're talking about is where http://www.example.com:8080 and
> https://www.example.com:4343 have the exact same content and services.
> You don't want a man in the middle to be able to force clients to 8080
> when a more secure encrypted service is advertised.  One simple way
> around this is not to have 8080 available for this purpose.  Otherwise,
> you want to ensure the information you are getting from the DNS is
> accurate and complete.  DNSSEC provides that capability.
>
> Eliot

Fine. MITM have easy access to DNS to learn these details, same as the 
client does. All they will do is intercept the HTTPS channel and answer 
it from fetches sent to 8080, same as they do today. Status Quo.

My point was the only actual gain to be made is that DNS interceptors 
(dnsmasq and similar tools) are hindered by the DNSSEC stage. You get 
the same beneft from DNSSEC signing the A/AAAA records on a plain old 
HTTP/1.x connection. TCP interceptors hit the channel portion at the 
packet level and DNSSEC will not fix that.

Unless you start talking about making the TLS layer actually chain the 
security trust from DNSSEC down to the server TLS certificate the whole 
client trust system will still be vulnerable to HTTPS interceptors even 
if both are used.

Amos

Received on Thursday, 28 February 2013 08:07:11 UTC