--On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre
<[email protected]> wrote:
The second issue is the advice that the user should be allowed to accept
a certificate with a mismatched name only on a temporary basis. This is
almost certain to be the wrong thing to do; if a name mismatch is
acceptable, it's also not likely to change anytime soon, and requiring
the user to accept the certificate again in a later session just because
the client has restarted is just annoying with no security benefit.
That's an interesting point. In feedback we received from implementers
of interactive user agents (most browsers), we heard that at least some
user agents do enforce a distinction between accepting an identity
mismatch temporarily and accepting it permenantly. The security
properties of that distinction did not come up in previous mailing list
threads about this I-D, but your editorial team will do a bit more
research and might return with proposed text changes.
I have no issue with making that distinction, and indeed, many existing
user agents do so. I take issue only with the argument that user agents
should disallow the "permanent" option in the name of "security", when
doing so is in fact counterproductive.
I think the advice in this paragraph is a little over-restrictive. What
should be prohibited is not automated rewriting, but automated rewriting
based on the use of insecure sources. RFC4120 has the following to say
on this subject, as it relates to Kerberos:
One can also rely on trusted third parties to make this
determination, but only when the data obtained from the third party
is suitably integrity-protected while resident on the third-party
server and when transmitted. Thus, for example, one should not rely
on an unprotected DNS record to map a host alias to the primary name
of a server, accepting the primary name as the party that one intends
to contact, since an attacker can modify the mapping and impersonate
the party.
Thanks for the pointer to RFC 4120. We're looking into how to
appropriate reference that in the next version of this spec.
I'm not sure a reference is the best approach, since in fact we're not
talking here about Kerberos and that might just be confusing. But
borrowing some of the language might be appropriate.
-- Jeff
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
