Re: [TLS] Summarizing identity change discussion so far

Stephen Farrell <> Fri, 18 December 2009 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A9393A688C for <>; Fri, 18 Dec 2009 04:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.384
X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Md-sVuKPecoT for <>; Fri, 18 Dec 2009 04:20:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 193A13A6A75 for <>; Fri, 18 Dec 2009 04:20:13 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF3C83600A5; Fri, 18 Dec 2009 12:19:57 +0000 (GMT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nNkc9CzWHoV7; Fri, 18 Dec 2009 12:19:56 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id BE407360092; Fri, 18 Dec 2009 12:19:56 +0000 (GMT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 988D77C309; Fri, 18 Dec 2009 12:19:56 +0000 (GMT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KDvqezkt67sJ; Fri, 18 Dec 2009 12:19:55 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTP id E6BF57C323; Fri, 18 Dec 2009 12:19:55 +0000 (GMT)
Message-ID: <>
Date: Fri, 18 Dec 2009 12:20:01 +0000
From: Stephen Farrell <>
User-Agent: Thunderbird (X11/20090812)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Summarizing identity change discussion so far
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2009 12:20:15 -0000

Text like this is much better and would remove the
concern I expressed before (that this spec is not
the place to do more than just fix the renegotiation

Adding positive examples (games/XMPP) as Martin
suggested would be a fine addition to this.

Delving into details of PKIX or other identity
matching would not be fine IMO.

S. wrote:
> Here's proposed text for the Security Considerations section about the
> identity changes. The discussion on the list seemed to favor keeping
> the normative parts quite mild, so much of this is worded as advice
> for people to consider (or ignore, if they so choose), not as strict 
> requirements:
>    While this extension mitigates the man-in-the-middle attack
>    described in the overview, it does not resolve all possible
>    problems an application may face if it is unaware of renegotiation.
>    In particular, either the client or the server can during
>    renegotiation present a different certificate than was used
>    earlier, and this may become as a surprise to application
>    developers (who might have expected, for example, that a
>    "getPeerCertificates()" API call returns the same value if called
>    twice), and might be handled in an insecure way.
>    TLS implementers are encouraged to clearly document how
>    renegotiation interacts with the APIs offered to applications (for
>    example, which API calls might return different values on different
>    calls, or which callbacks might get called multiple times).
>    To make life simpler for applications that do not expect the peer's
>    certificate to change once it's been authentication, TLS
>    implementations MAY 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 present multiple certificates.
>    TLS implementations SHOULD also offer the applications the option
>    to disable renegotiation completely.
>    Finally, designers of applications that depend on renegotiation are
>    reminded that many TLS APIs represent application data as a simple
>    octet stream; applications may not be able to determine exactly
>    which application data octets were received before, during, or
>    after renegotiation. Especially if the peer presents a different 
>    certificate during renegotiation, care is needed when specifying
>    how the application should handle the data.
> Comments (and especially concrete proposals for improving the text)
> are welcome.
> Best regards,
> Pasi
>> -----Original Message-----
>> From: [] On Behalf Of
>> Eronen Pasi (Nokia-NRC/Helsinki)
>> Sent: 08 December, 2009 11:13
>> To:
>> Subject: [TLS] Summarizing identity change discussion so far
>> (wearing Area Director hat)
>> Although the IETF Last Call is still underway, here's a short attempt
>> to summarize the discussion regarding identity changes (Section 7) so
>> far:
>> - We seem to agree that changing the certificate/identity
>> during secure renegotiation (so there's no man-in-the-middle, just two
>> parties) could confuse some applications.  James Manger's email
>> provides
>> IMHO a good example of what that confusion could be (in this particular
>> example, the confusion has security implications, too):
>> - We mostly seem to agree that some applications could not just handle
>> certificate/identity changes correctly, but would actually benefit
>> from them.
>> - We seem to agree that it would be a reasonable idea for the TLS
>> library to offer the applications an option where the TLS library
>> checks that the certificate doesn't change during renegotiation.
>> This is an *option* -- an application could decide not to use it,
>> and e.g. do more complex comparisons.
>> - We have much less support for requiring that every TLS library
>> MUST implement this functionality and/or MUST enable it by default
>> (whatever "by default" means in your API), at least in this draft.
>> Unless I'm badly misreading the situation, or it significantly changes
>> during the rest of the IETF Last Call, my proposal here would be as
>> follows:
>> - We do NOT require (with "MUST") any changes to TLS libraries in this
>> regard.
>> - We describe the situation a bit more clearly than the current text
>> does (it seems many people found the current text somewhat unclear).
>> - We recommend that TLS libraries SHOULD provide identity matching
>> (with memcmp, abort handshake if changed) functionality to
>> applications, and SHOULD allow applications to enable/disable this
>> functionality.
>> - We include a sentence or two describing the pros and cons of
>> enabling/not enabling this feature by default, but don't require or
>> recommend any particular default value.
>> - The text probably needs to note that if the applications wants to
>> deal with identity changes, it may need to consider the "which
>> application_data byte(s) correspond to which identity" question (or it
>> may not -- the answer may depend a lot on the application protocol).
>> Does this sound like a reasonable approach?
>> Best regards,
>> Pasi
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list