W3C home > Mailing lists > Public > public-usable-authentication@w3.org > April 2007

RE: DNSSEC indicator

From: <michael.mccormick@wellsfargo.com>
Date: Fri, 27 Apr 2007 15:42:12 -0500
Message-ID: <8A794A6D6932D146B2949441ECFC9D6802B4D3D9@msgswbmnmsp17.wellsfargo.com>
To: <beltzner@mozilla.com>
Cc: <public-usable-authentication@w3.org>

I believe this type of two-tier UI model is what will work out best.  A
single primary security indicator* combined with a detailed secondary
indicator that sys admins, security pros, and other techno geeks can
pull up as needed.

Items on the secondary panel -- such as TLS version/cipher/keysize, name
resolution basis (DNS/DNSSEC/HOSTFILE), certificate type (self-signed,
trusted root, EV root), certificate status (expiration, revocation,
DN/hostname match)-- should all be inputs into the primary indicator as

WSC could provide the web software industry a model for:
(a) what those inputs are,
(b) how they should be weighted & aggregated to yield an overall
security "score" for web pages,
(c) how that score should be turned into a visual primary indicator.


*At most 2 primary indicators if we really want to separate site
identity/authenticity/reputation from connection
security/privacy/encryption.  The IE7 analogs would be colored address
bar and padlock icon.

-----Original Message-----
From: public-usable-authentication-request@w3.org
[mailto:public-usable-authentication-request@w3.org] On Behalf Of Mike
Sent: Thursday, April 26, 2007 7:44 AM
To: sthomas2@ups.com; public-usable-authentication-request@w3.org;
Subject: Re: DNSSEC indicator

Like page encoding, the presence/absense of DNSSEC will be interesting
to a select few users, and should be relegated accordingly to secondary,
diagnostic UI. The client should - when DNSSEC actually exists in the
wild - be modified such that its presence or absence can be used to
provide the client (not the poor user, who doesn't care about the
topsy-turvy world of TCP/IP) with an additional criteria on which to
base its security policy in terms of how to treat the source content.
This is purely an implementation detail at the connection later plugging
what Dick correctly termed a "leaky hole". 


-----Original Message-----
From: <sthomas2@ups.com>
Date: Thu, 26 Apr 2007 08:19:32
Subject: RE: DNSSEC indicator

Dick is quite right. DNSSEC could indeed provide another tool in the
toolbox to make sure that the network is doing what the user really
wants. My issue, though, is elevating the DNSSEC status to a
human-visible indication. The more indicators that are displayed to a
user, the less likely the user is to pay attention to them. Research is
already showing that users are ignoring the indications that browsers
give them today. For that reason, browser designers need to be very
parsimonious in displaying security indications and focus on showing
information that is really important. Given the relative rarity of
attacks involving improper name resolutions, a DNSSEC indication would
not seem to have enough value to justify its use.

Received on Friday, 27 April 2007 20:42:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:16 UTC