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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
