[certid] Bad certificate handling

[Matt McCutchen <[e-mail]>]

On Wed, 2010-09-22 at 09:59 -0600, Peter Saint-Andre wrote:
> The part of the text that you have not quoted does say that this
> practice is typically offered only to advanced users (and I don't think
> that Barry's mother counts as an advanced user). However, we've
> provisionally made the text even more scary, as follows:
> 
>       Security Note: Some existing interactive user agents give advanced
>       users the option of proceeding despite an identity mismatch.
>       Although this behavior can be appropriate in certain specialized
>       circumstances, in general it needs to be exposed only to advanced
>       users and even then needs to be handled with extreme caution, for
>       example by first encouraging even an advanced user to terminate
>       the connection and, if the advanced user chooses to proceed
>       anyway, by forcing the user to view the entire certification path
>       and only then allowing the user to accept the certificate on a
>       temporary basis (i.e., for this connection attempt and all
>       subsequent connection attempts for the life of the application
>       session, but not for connection attempts during future application
>       sessions).
> 
> Jeff still needs to review that text before we finalize it.

There is a trade-off in making the acceptance temporary.  If the
certificate belongs to a MITM attacker, the user avoids becoming
permanently vulnerable to that particular attacker.  If it belongs to
the desired server, he misses an opportunity to cache it permanently and
avoid developing a habit of accepting a bad certificate on every
session, which would make him vulnerable to MITM every time.  Of course,
there is no way to know which is the case.

If the user provides a password after accepting the certificate, one can
argue that he has already lost everything in the case of an attack, and
hence he should focus on securing the other case by accepting the
certificate permanently.  It can also be useful to cache the certificate
received over a relatively more trustworthy network connection for later
use on a less trustworthy one (e.g., the proverbial public wireless
access point).

The current remark about temporary acceptance might suggest to readers
that it is better than permanent acceptance, which is at best an
oversimplification and possibly untrue.  Thus, I propose that the remark
be removed.

Separately, I wonder if it makes sense for server-id-check to
specifically discuss the handling of certificates that don't match a
reference identifier when the considerations are essentially the same
for certificates with other problems (most commonly, expired or
untrusted issuer) and, indeed, modern browsers tend to provide a single
UI for these three most common problems.  I'm not sure where would be
the right place to standardize handling of bad certificates in general.
There is a W3C document, but it only applies to interactive user agents:

http://www.w3.org/TR/wsc-ui/#def-pinned-cert

-- 
Matt