Re: DNSSEC indicator

Hi Dan:

Dan Schutzer wrote:
> Here is my take
>
> If they got the mapping from the domain name to the IP address securely, it
> indicates that they are at the correct web site (the site belonging to the
> url they typed in), so if they send sensitive information to the site, it is
> going to the correct site. 
This is not entirely correct.  What the use of DNSSEC provides is
evidence that a specific class of attacks against the DNS protocol have
not been performed.  The use of DNSSEC tells the user that she has
received without modification the result of the query that the
authoritative database reports.  It says nothing about whether or not IP
spoofing attacks have been performed or whether or not the contents of
the authoritative database are correct.
> However, if the connection is not secured, then
> the information can be intercepted by a man in the middle attack. However,
> if the link is TLS secured, then the information cannot be intercepted in
> transit. To be confident one's personal information is not being stolen, one
> would need to look at both indicators.
TLS, when secured by a server side certificate that has been properly
verified, protects against MITM attacks.  If the user enters
https://www.citicard.com and gets a certificate containing the name
"www.citicard.com" which has been issued by a CA trusted by the user (or
the user's knowledgeable IT staff) and the certificate chain verifies,
then DNSSEC adds nothing useful.

DNSSEC can show a reduced risk when all of the factors necessary to
establish trust are not present.

   1. The certificate that is received from the server contains
      "www.citibank.com" instead of "www.citicard.com".  [I'm using this
      example because it is real.]
   2. The user didn't specify "https".  [I think that there should be a
      way for a web server to instruct the browser as part of a redirect
      that only "https" should be used in the future.]
   3. The CA certificates in the trusted CA list are not in fact trusted
      by the user (or his knowledgeable IT staff) but were simply
      preloaded by the browser vendor.
   4. When self-signed certificates are in use as part of a "Leap of
      Faith" authentication scheme.  [With Leap of Faith the client
      caches the self-signed certificate presented by the server the
      first time it is seen and the user can trust it has returned to
      the same server in the future.]
   5. When certificates are not used as part of the TLS authentication. 
      (Anonymous mode)

The problem with locks or other symbols to indicate security is that
they are binary.  The lock is either there or not there.  Adding
multiple symbols for different risk avoidance mechanisms that the user
doesn't understand will only take up more screen real estate and create
further confusion.

What I believe would be valuable from the user's perspective is a visual
display showing the results of a risk assessment of the current
connection based upon past connection history, the security of the DNS
lookup, the use of TLS, the verifications applied to the certificate,
the trust level of the CA, etc.  This visual indicator should provide
access to a risk assessment tool that explains to the user the details
of the analysis.  This would provide a level of education to the end
user as well as provide a framework for adding additional security
techniques in the future as they become available.

Jeffrey Altman
Secure Endpoints Inc.