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

Jeffrey Hutzelman <> Wed, 22 September 2010 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 191993A67D4; Wed, 22 Sep 2010 11:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.541
X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZvcP5ctfuFE6; Wed, 22 Sep 2010 11:07:03 -0700 (PDT)
Received: from (SMTP03.SRV.CS.CMU.EDU []) by (Postfix) with ESMTP id D2D9B3A6A70; Wed, 22 Sep 2010 11:07:02 -0700 (PDT)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id o8MI7SjV015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:07:28 -0400 (EDT)
Date: Wed, 22 Sep 2010 14:07:28 -0400
From: Jeffrey Hutzelman <>
To: Peter Saint-Andre <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on
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:07:04 -0000

--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 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