On 9/22/10 12:07 PM, Jeffrey Hutzelman wrote: > --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 had not previously considered the point, but I think you're right. >>> 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. Yes, that's what I meant -- we shall probably engage in some creative borrowing of the concept, which might be worded similarly or differently (that's yet to be determined). Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
