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

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 22 September 2010 18:07 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191993A67D4; Wed, 22 Sep 2010 11:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.541
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvcP5ctfuFE6; Wed, 22 Sep 2010 11:07:03 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (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 [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (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 <jhutz@cmu.edu>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu>
In-Reply-To: <4C9A428C.2030807@stpeter.im>
References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> <4C9A428C.2030807@stpeter.im>
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 128.2.217.198
Cc: secdir@ietf.org, IETF cert-based identity <certid@ietf.org>, tls@ietf.org, iesg@ietf.org, barryleiba@computer.org
Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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 
<stpeter@stpeter.im>; 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