Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09

[Jeffrey Hutzelman <[e-mail]>]

--On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre 
<[e-mail]> 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