Re: DNSSEC indicator

> From: <michael.mccormick@wellsfargo.com>
> Date: Fri, 13 Apr 2007 13:24:14 -0500
> Subject: RE: DNSSEC indicator
> 
> Hi Stuart,
> 
> I remember that discussion at the March 2006 meeting.  I think it's an
> intriguing proposal.  I definitely see a need for sites to define
> security parameters they want browsers to adhere to (e.g., "MS IE can
> only access my web site if Security Level is set to High").  Ideally
> this kind of security metadata would be exchanged as part of the TLS
> handshake so server & browser can negotiate and come to agreement (e.g.,
> "3DES cipher is acceptable if you really can't do AES").

   Yes, but the choice to activate TLS cannot be implemented as part of the
TLS handshake.  It's a chicken and egg problem that is impossible for TLS to
solve.

> However I'm not convinced DNS records are the optimal way to publish
> security metadata because it's not real conducive to a 2-way negotiation
> dialog between agent & server.

   This is simply false.  The 2-way negotiation in TLS is really just a
negotiation where one side presents options and the other chooses them.
DNSSEC is just another means for one party (the server) to publish options.
The client can then choose the options it wants to use and the server can
still verify that they are ones it considers acceptable.  The only
difference that results to moving the first step of the negotiation into the
DNS lookup is that the negotiation can now include the choice of protocol
(e.g. TLS or plaintext) and not just protocol options (AES or Blowfish).
 
> Also I'm concerned about putting
> security metadata in DNS because it's vulnerable to poisoning & other
> attacks (yes, DNSSEC would help here) and because propagation of record
> changes is unpredictable.

   Even if DNSSEC isn't available, the standard is written to ensure that
record can only increase the required level of security.

> I'm also not persuaded that any such solution is needed for sites to
> force agents to use SSL.  That can be achieved more easily by either
> turning off port 80, or by responding to http requests with a redirect
> response to https.

   That is a "defense" that only works if there is no attack.  Just because
you turn off port 80, doesn't mean the attacker can't answer on port 80 when
the browser requests the page.  HTTP redirects to HTTPS are vulnerable to
the very same man-in-the-middle attacks that HTTPS is supposed to prevent in
the first place.

   If you are relying on HTTP to redirect, you are not noticeably more
secure than if you didn't use HTTPS at all.  Recall that in our "Emeperor's
New Security Indicators" study, 27 of 27 users entered their online banking
passwords even though we had prevented HTTP redirection from taking place.

   Cheers

   Stuart

> -----Original Message-----
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
> On Behalf Of Stuart E. Schechter
> Sent: Friday, April 13, 2007 10:06 AM
> To: 'Web Security Context WG'
> Cc: Dan Schutzer
> Subject: Re: DNSSEC indicator
> 
> 
> This is the proposal I first discussed at the W3C meeting at Citibank in
> March of last year.  I'd be happy to share the draft individually with
> working group participants, but I haven't received approval to post it
> on publicly archived lists.
> 
> The proposal adds a new record to the domain name system.  Browsers can
> query the DNS for this record before contacting a named site, just as
> they would query the address record for the site.  If the record is
> present and certain flags are set, browsers will activate HTTPS before
> initiating a web connection to the site's domain name.  Users are thus
> freed from the responsibility of activating HTTPS or ensuring that HTTPS
> was activated.
> 
> The proposal is closely tied to DNSSEC because DNSSEC protects this
> records against attacks that would modify it or make it appear to be
> absent.
> 
> Cheers
> 
> Stuart
> 
>> From: Dan Schutzer <dan.schutzer@fstc.org>
>> Date: Fri, 13 Apr 2007 07:03:06 -0400
>> To: "'Stuart E. Schechter'" <ses@ll.mit.edu>
>> Cc: 'Web Security Context WG' <public-wsc-wg@w3.org>, 'Dan Schutzer'
>> <dan.schutzer@fstc.org>
>> Subject: DNSSEC indicator
>> 
>> Stuart can you elaborate on:
>> 
>>  
>> 
>> I have been working on a new standard that would employ DNSSEC to
>> reduce,
>> 
>> rather than increase, the amount of security information that users
>> need to
>> 
>> be made aware of.  The standard removes the need for users to pay
>> attention
>> 
>> to the browser padlock icon and other HTTPS indicators.
>> 
>>  
>> 
>> Thanks
>> 
>>  
>> 
>> Dan Schutzer
>> 
>> -----Original Message-----
>> From: public-wsc-wg-request@w3.org
>> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Stuart E. Schechter
>> Sent: Thursday, April 12, 2007 3:58 PM
>> To: Web Security Context WG
>> Subject: Re: DNSSEC indicator
>> 
>>  
>> 
>>  
>> 
>> I just realized I followed suit in sending this to the wrong address.
>> -s
>> 
>>  
>> 
>> ------ Forwarded Message
>> 
>> From: "Stuart E. Schechter" <ses@ll.mit.edu>
>> 
>> Subject: Re: DNSSEC indicator
>> 
>>  
>> 
>>> From: <michael.mccormick@wellsfargo.com>
>> 
>>  
>> 
>>> One issue SwedBank has run into as DNSSEC rolls out in Sweden
>>> (quoting
>> Kjell's
>> 
>>> presentation): "Will Microsoft and Mozilla implement a DNSSEC
>>> indicator in
>> 
>>> their browsers?"
>> 
>> ...  
>> 
>>> My personal opinion is DNSSEC should probably be another input to the
>> agent
>> 
>>> security context display along with the others we've talked about
>>> (e.g.,
>> 
>>> SSL/TLS).  There are some practical obstacles to overcome -- for
>>> instance
>> the
>> 
>>> name resolver built into the client OS or browser has to be
>>> DNSSEC-capable
>> as
>> 
>>> a prerequisite for this -- but it seems it ought to be on the
>>> roadmap.  I
>> 
>>> believe DNSSEC has more potential benefit if it's visible to end
> users.
>> 
>>  
>> 
>> Michael:
>> 
>>  
>> 
>>    I'm a strong advocate of DNSSEC, but I'm certain it will fail users
> 
>> are
>> 
>> required to notice an indictor of its presence or absence.  SSL
>> indicators
>> 
>> are visible to end users and users don't notice them.
>> 
>>  
>> 
>>    I have been working on a new standard that would employ DNSSEC to
>> reduce,
>> 
>> rather than increase, the amount of security information that users
>> need to
>> 
>> be made aware of.  The standard removes the need for users to pay
>> attention
>> 
>> to the browser padlock icon and other HTTPS indicators.  When I've
>> talked to
>> 
>> folks at Mozilla and on Microsoft's IE team, I've found the generally
>> agree
>> 
>> that this is the area where DNSSEC can provide value to them.  Alas,
>> because
>> 
>> it introduces a new record into the DNS, it is out of scope for this
>> working
>> 
>> group.
>> 
>>  
>> 
>>    When it comes to security indicators, more is not necessarily
> better.
>> 
>>  
>> 
>>    Cheers
>> 
>>  
>> 
>>    Stuart
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
> 
> 
> 
> 
> 
>

Received on Friday, 13 April 2007 20:07:54 UTC