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

Peter Saint-Andre <> Wed, 22 September 2010 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F4DA3A6ABC; Wed, 22 Sep 2010 11:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qLy5VWFc+Alc; Wed, 22 Sep 2010 11:13:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3AD193A6A30; Wed, 22 Sep 2010 11:13:29 -0700 (PDT)
Received: from ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 6E3DE40074; Wed, 22 Sep 2010 12:18:50 -0600 (MDT)
Message-ID: <>
Date: Wed, 22 Sep 2010 12:13:54 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100914 Thunderbird/3.0.8
MIME-Version: 1.0
To: Jeffrey Hutzelman <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: url=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700
Cc:,, IETF cert-based identity <>,,
Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Sep 2010 18:13:32 -0000

On 9/22/10 12:07 PM, Jeffrey Hutzelman wrote:
> --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre
> <> 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 Saint-Andre