Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

Larry Zhu <> Tue, 23 March 2010 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FE553A690F; Tue, 23 Mar 2010 13:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.725
X-Spam-Status: No, score=-8.725 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 64yMFxnuA7mN; Tue, 23 Mar 2010 13:48:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A006C3A68DC; Tue, 23 Mar 2010 13:48:44 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 23 Mar 2010 13:49:04 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 23 Mar 2010 13:49:03 -0700
Received: from ([]) by ([]) with mapi; Tue, 23 Mar 2010 13:48:57 -0700
From: Larry Zhu <>
To: Nicolas Williams <>
Thread-Topic: [CHANNEL-BINDING] [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)
Thread-Index: AQHKysPEBfd6t/asyEy5KpzyaD91gZH//Krw
Date: Tue, 23 Mar 2010 20:48:41 +0000
Message-ID: <>
References: <20100317231522.GA18167@Sun.COM> <20100322232150.GB21244@Sun.COM> <20100323065301.GE21244@Sun.COM> <20100323190629.GR21244@Sun.COM> <> <20100323195956.GY21244@Sun.COM>
In-Reply-To: <20100323195956.GY21244@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Mark Novak <>, "" <>, Pasi Eronen <>, "" <>, "" <>
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)
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: Tue, 23 Mar 2010 20:48:45 -0000

I briefly chatted with Sam who was in the tls-unique design/discussion meeting last Sunday. It turns out that the community as represented by key stake holders in that meeting believed that:

1) TLS renegotiation is driven by TLS apps.
2) as the result, the apps can figure out, based on the app specific context, which TLS side will start renegotiation and when, e.g. in a locked-step fashion.
2) therefore it is acceptable to leave the behavior in the case of the described synchronization undefined.

If this does not capture the spirit of that discussion, please let me know. 

Shall we proceed with that and capture the discussion in the ID (that means another update to the ID). Personally I am not aware of any new data points that would invalidate the above recommendation.



-----Original Message-----
From: Nicolas Williams [] 
Sent: Tuesday, March 23, 2010 1:00 PM
To: Larry Zhu
Cc:;;; Mark Novak; Pasi Eronen
Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

On Tue, Mar 23, 2010 at 07:56:19PM +0000, Larry Zhu wrote:
> > It occurs to me that it must be very unlikely that any apps using the
> > MSFT variant of tls-unique are doing authentication after TLS
> > re-negotiation.
> Should we instead say that the receiver/verifier of the tls-unique
> binding is encouraged to remember the previous finished structure
> before re-negotiation. If the synchronization is more than 2 finished
> messages apart, the auth request is expected to fail.

What's the motivation?  Is it really that hard to keep the initial CB
around?  It is tiny...

> This way we have a solution when the actual need arises, without
> complicating either the interface or the protocol. Hopefully the
> burden to implementation is minimal as well. Is that reasonable?

Ah, I think I understand.  In your API it's the application's burden to
remember the CB from the initial handshake.  But even so, that does not
seem like such a tough burden.

Your proposal is more reasonable than the earlier one for the simple
reason that we'll never see three handshakes prior to authentication,
and accepting the possibility of spurious authentication failures in
such cases, if they happened, would be OK with me.