Re: [TLS] Review of PR #209

"" <> Tue, 22 September 2015 13:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6BBC61A7014 for <>; Tue, 22 Sep 2015 06:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uMHzo1HlHJVR for <>; Tue, 22 Sep 2015 06:09:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DE281A7004 for <>; Tue, 22 Sep 2015 06:09:52 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so23022766wic.0 for <>; Tue, 22 Sep 2015 06:09:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=ekiWqZCnkE8QWTkNb/9jxoJP3oBJs9jZ4ypvOjid13Q=; b=Qs/G1Uo0Ng0gyT7wr1W9cLovbgt/H31d9GaOCf9zqaA9Kv+hHCYSTUsm4JBi7+2TKq JCl5UIlgD9HBpljb9Dk24I3yN2woKhdroE5FFTCCe+iUUYkY1g3xCUTMDkGTRaFp7bIx JkGdLbvV2M8UsZtPZ2QJA2eSlA9fi0i2qoulUEiUG46it+TrwATRS5MDzQDt07QXLJWt h5Emt/mDGzt07oIJMIq5ye8NzVgvV+SfEJjr5pITNdQOgkbM8pWusrSSQEwL4ngNa63/ HZd3E1+risgDRJJaYg/Md4aQJXRx1VduvfaSCtAwi1rGtR3Kkes+ZehFMH30WE8EDZ3v oC1g==
X-Gm-Message-State: ALoCoQlyh1GUlevJN5xkSQlah0w+BsNEel6siRF+kt0G6SuIaZfQXS5UyBQ3ZQXlQyP90YF3wJL0
X-Received: by with SMTP id gp10mr18334879wib.51.1442927390690; Tue, 22 Sep 2015 06:09:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id lh11sm3078514wic.18.2015. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 06:09:48 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "" <>
In-Reply-To: <m2fv278exp.fsf@localhost.localdomain>
Date: Tue, 22 Sep 2015 14:09:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <20150916153041.GA14682@LK-Perkele-VII> <> <> <> <> <m2fv278exp.fsf@localhost.localdomain>
To: "" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [TLS] Review of PR #209
X-Mailman-Version: 2.1.15
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, 22 Sep 2015 13:09:54 -0000

> On 22 Sep 2015, at 01:40, Geoffrey Keating <> wrote:
> Daniel Kahn Gillmor <> writes:
>> Consider a server has an ongoing session wrapped in TLS that uses client
>> authentication to approve or deny some requests from the client.  It
>> remembers what requests the client has made as some sort of relevant
>> state.  Let's take an imap server working with a client that has state
>> of a "currently-examined folder", but this applies to servers and
>> clients with much more complex state as well.
> ...
> I think for such a protocol, you'd want to say that authentication is
> not retroactive.
> For other protocols, you might want something else.  For example, in a
> protocol which uses client authentication for billing, you might want
> to treat an authentication half-way through the session as the account
> to bill for the entire session.
> Some protocols will also want to support multiple identities, and some
> will not.  For some protocols a new authentication might want to in
> some fashion dis-trust previous authentications, other protocols might
> say that all previous authentications are valid until the end of the
> session.

If I get this right: 
1) it will be possible on the same connection to authenticate
with multiple different certificates,
2) the different identities won't ( necessarily ? ) be cumulative
ie, a server getting the identity I1 and then I2 on the same TLS connection
won't be able to conclude that the referent of I1 is the same as the referent 
of  I2 ?

Thinking of a possible use of this over HTTP I find this surprising. So perhaps
it is not meant to be applied there. Where is it?

If that were to work correctly would one not also have to change the encryption
for each user?

(sorry to enter the discussion but I am also just checking because I 
seem to have made a mistaken claim on the HTTP list if 1) is true )

> I think this is something that TLS should allow higher-level protocols
> to specify.  The TLS model could be that each client authentication
> happens at a particular point in the session, breaking it up into
> segments, and TLS informs the higher-level protocols of where the
> segments start and end; it's up to the higher-level protocol to work
> out what that means.
> _______________________________________________
> TLS mailing list

Social Web Architect