Re: [TLS] Summarizing identity change discussion so far

Nelson B Bolyard <nelson@bolyard.me> Fri, 18 December 2009 19:49 UTC

Return-Path: <nelson@bolyard.me>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB38E3A69D7 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599]
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 58GDwNwdugte for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:49:24 -0800 (PST)
Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id E61CC3A68FA for <tls@ietf.org>; Fri, 18 Dec 2009 11:49:23 -0800 (PST)
Received: (qmail 8183 invoked from network); 18 Dec 2009 19:49:08 -0000
Received: from unknown (24.5.142.42) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 18 Dec 2009 19:49:08 -0000
Message-ID: <4B2BDCAC.1040802@bolyard.me>
Date: Fri, 18 Dec 2009 11:49:00 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: IETF TLS Working Group <tls@ietf.org>
References: <Acp35q+5MB/IK2o8TM+TSRCqs64JxA==><808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> <AC1CFD94F59A264488DC2BEC3E890DE5095131C5@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5095131C5@xmb-sjc-225.amer.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Summarizing identity change discussion so far
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2009 19:49:24 -0000

On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote:
> I share the opinion that identity checking belongs in the application,
> performed according to whatever mechanism is appropriate.  We should not
> be mandating any particular PKIX processing in the TLS specs. 
> 
> I also think if an application is not prepared to be aware of
> renegotiation and handle any identity change associated with it then
> renegotiation should be disabled.  This implies that renegotiation
> should be disabled by default and specifically enabled by an
> application.  So I would say
> 
> "TLS implementations SHOULD disable renegotiation by default and offer
> the applications the option to enable renegotiation.  When an
> application enables renegotiation it must handle identity processing for
> each handshake."

With my Idealist hat on, I agree with that 100%.  But after 13.25 years
of working on SSL/TLS libraries, I know that 98+% of the app developers
who use TLS have no idea what that means or how to do it.  IMO, they are
likely to just call a function for each handshake that does the same
thing as for the first handshake, validating the cert chain and (if we're
lucky) checking that some aspect of the cert contains some expected name,
without any regard to what prior certificates may have contained.

So, IMO, it makes sense of TLS implementations to offer some sort of
"default" handling of certs to attempt to ensure continuity of identity
in the absence of something much better from the application.  I'd
suggest that, unless the applications direct them to do otherwise, perhaps
by registering some callback, TLS implementations should check that the
cert in a renegotiation is the same one as in the previous full handshake,
either by memcmp of the entire cert, or by memcmp of the subject name and
subjectAltName (if any).   Anything less will ensure that most apps continue
to get this wrong, IMO.