W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Re: DNSSEC indicator

From: Stuart E. Schechter <ses@ll.mit.edu>
Date: Fri, 13 Apr 2007 11:06:16 -0400
To: "'Web Security Context WG'" <public-wsc-wg@w3.org>
CC: Dan Schutzer <dan.schutzer@fstc.org>
Message-ID: <C24514A8.1250B%ses@ll.mit.edu>

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 15:20:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:46 GMT