Re: [TLS] Summarizing identity change discussion so far

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 18 December 2009 07:27 UTC

Return-Path: <jsalowey@cisco.com>
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 E40963A67E1 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 23:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 a++2ibIZmR5j for <tls@core3.amsl.com>; Thu, 17 Dec 2009 23:27:34 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A8873A683F for <tls@ietf.org>; Thu, 17 Dec 2009 23:27:34 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEABq9KkurR7Hu/2dsb2JhbAC9a5cmgi4GgXkE
X-IronPort-AV: E=Sophos;i="4.47,417,1257120000"; d="scan'208";a="281210108"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Dec 2009 07:27:19 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBI7RJvh019987; Fri, 18 Dec 2009 07:27:19 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 23:27:19 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Dec 2009 23:27:16 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5095131C5@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Summarizing identity change discussion so far
Thread-Index: Acp/YSMJ21qxpPadSkKKYtCdVu/oAQAACc+AABOtZVA=
References: <Acp35q+5MB/IK2o8TM+TSRCqs64JxA==><808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Pasi.Eronen@nokia.com, aerowolf@gmail.com
X-OriginalArrivalTime: 18 Dec 2009 07:27:19.0629 (UTC) FILETIME=[884FDFD0:01CA7FB3]
Cc: tls@ietf.org
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 07:27:37 -0000

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

I don't think binary certificate comparison is necessarily the most
valid comparison for applications to use.  I'm not convinced it will
make life simpler for applications.  

Joe





> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Pasi.Eronen@nokia.com
> Sent: Thursday, December 17, 2009 2:06 PM
> To: aerowolf@gmail.com
> Cc: tls@ietf.org
> Subject: Re: [TLS] Summarizing identity change discussion so far
> 
> Kyle Hamilton wrote:
> 
> > No, identity matching SHOULD be done in accordance with 
> PKIX.  memcmp 
> > is not at all sufficient.
> > 
> > However, I would support the following:
> > 
> > - TLS libraries SHOULD provide identity matching services 
> between and 
> > throughout renegotiation handshakes.  Libraries SHOULD 
> implement this 
> > in accordance with PKIX [PKIX], but MAY do so with a direct memory 
> > comparison.  Implementors are cautioned that this latter 
> approach does 
> > not provide for changing the cipher parameters -- such as a 
> > renegotiation with an EC or DH certificate after 
> identification with 
> > an RSA certificate.  If the identity matching service fails 
> to match 
> > the identity, implementations MUST abort the handshake with a fatal 
> > bad_certificate alert.
> 
> Well, the text I proposed just said "different certificate", 
> not "memcmp". I know that's a bit vague, but "in accordance 
> with PKIX [PKIX]" is not very precise either, and would need 
> a more specific reference to where exactly the details are 
> (for example, it can't mean comparing the Subject field, 
> since PKIX allows leaving it empty).
> 
> And the certificate might have extensions (certificate 
> policies, subject directory attributes, extended key usage, 
> etc.) where changes between API calls could surprise the application.
> 
> Here's another shot at that paragraph (also including 
> suggestions from Marsh's email):
> 
>    TLS implementations SHOULD offer the applications the option to
>    disable renegotiation completely.
> 
>    To make life simpler for applications that do not expect the peer's
>    certificate to change once it's been authenticated, TLS
>    implementations may also wish to offer the applications the option
>    abort the renegotiation if the peer tries to authenticate with a
>    different certificate and/or different server name (in the
>    server_name extension) than was used earlier. However, enabling
>    this option by default for all applications could break existing
>    applications that depend on using renegotiation to change from one
>    certificate to another. (For example, long-lived TLS connections
>    could change to a renewed certificate; or renegotiation could
>    select a different cipher suite that requires using a different
>    certificate.)
> 
> Best regards,
> Pasi
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>