Proposal: error handling / minimizing trust decisions

I've dropped an initial proposal for error handling into the
editor's draft; as usual for my first stabs, all the references to
definitions and so on are dangling links.  Will fix that later. ;-)

This is to address the "minimization of trust decisions" goal, as
far as TLS is concerned.

  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
  @@Web Security Context@@
  Editor's Draft $Date: 2007/08/12 14:40:49 $

My current take is that this could usefully get some initial review
on the list.  The presentation is less than perfect, and could use
some polishing and rearranging which I might do without advance
warning.

The error handling section heavily depends on the "Applying TLS to
the Web" section to put in place most of the protocol and
certificate related groundwork.

Essentially, all the various TLS-related conditions are broken down
into three possible states that an interaction can be in:

- strongly TLS protected -- all is well

- weakly TLS protected -- we get some protection, and things don't
  look too fishy

- change of security level -- something went seriously wrong

  * change against historical practice (EV->anything,
    strong->anything, ...); there is a huge amount of discussion
    fodder here -- enough that I'm not going to open issues just
    yet.

  * certificate errors if we're basically dealing with a good cert

  * anything else the user agent implementor decides is fishy (think
    blacklists)

(We don't deal with no TLS here. ;-)

There are some substates that relate to EV and self-signed certs
that I'll gloss over for the purposes of this e-mail.

The error handling proposal is the following:

- SHOULD display an error page for change of security level, with a
  path back to the state before the user interaction that got us
  there, and a "more info" interaction;

- SHOULD NOT interrupt user interaction if we're "just" dealing with
  weakly protected interactions.


For certain MITM attacks (i.e., we ask for http://a.example.com, but
get a perfectly good certificate for http://b.example.com), there's
a proposal for an extended interaction: Instead of just stopping the
user in their tracks, user agents MAY tell them who was trying to
intercept things (taking the identity from the certificate subject),
and offer just going to that site.  Constraints include a safe HTTP
method (i.e., no POST), and the ability to construct the target URL
independent of the one the user originally intended to go to.

This is intended to provide a both useful and safe way to deal with
captive portals during TLS interactions.


Validity period errors are dealt with in two ways:

- If the user agent does not perform certificate status checks as a
  matter of policy, then we don't pay attention to expiry of
  certificate -- the validity period basically says during what
  period the CA will keep certificate status around.

- If the user agent performs certificate status checks, then a
  validity date error is a hard one.  There is an assumption in the
  current spec text that EV implies certificate status checks; I
  haven't bothered to check whether that's actually correct.

(Note that this is somewhat implicit, yet clear once you read the
spec.)


Unknown CAs and self-signed certificates lead to weak TLS
protection, which means that they don't cause a strong error
message, but won't trigger any nice, passive identity indicators,
either.  Changing from a known CA to an unknown CA (or a self-signed
cert) leads to a change of security level.


Repeated use of a self-signed cert over time MAY lead to a strongly
protected interaction; however, attributes in the certificate are
ignored.

I think Serge has been arguing that the same should be true for
certificates from an unknown CA, and I'm inclined to agree.

One question is, then, whether we'd want to do path validation for
such certs; the editor's draft currently implies that we wouldn't.
That's probably a bug.

I've opened ISSUE-103 to capture these two points, and suggest to
discuss them in that thread.


Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Sunday, 12 August 2007 15:07:17 UTC