Re: [TLS] Review of PR #209

Henry Story <henry.story@co-operating.systems> Tue, 22 September 2015 12:22 UTC

Return-Path: <henry.story@co-operating.systems>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC761A6F8C for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 05:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aogiWYtedFEG for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 05:22:20 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E27A1A6F88 for <tls@ietf.org>; Tue, 22 Sep 2015 05:22:20 -0700 (PDT)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 51CC1FB89F; Tue, 22 Sep 2015 14:22:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0eXL8mnhBE-6; Tue, 22 Sep 2015 14:22:16 +0200 (CEST)
X-Originating-IP: 86.21.242.52
Received: from [192.168.0.2] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net [86.21.242.52]) (Authenticated sender: henry.story@co-operating.systems) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 2506CFB8DF; Tue, 22 Sep 2015 14:22:15 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Henry Story <henry.story@co-operating.systems>
In-Reply-To: <m2fv278exp.fsf@localhost.localdomain>
Date: Tue, 22 Sep 2015 13:22:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <546EB96F-46E0-4CD2-87C3-DB6B42CCF93A@co-operating.systems>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com> <20150916153041.GA14682@LK-Perkele-VII> <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com> <87eghugo9n.fsf@alice.fifthhorseman.net> <84975A12-87F7-4E5A-BC0D-0E0D68FEB2F1@inria.fr> <87613326ol.fsf@alice.fifthhorseman.net> <m2fv278exp.fsf@localhost.localdomain>
To: Geoffrey Keating <geoffk@geoffk.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Y2YgUY09vzf6zCYyN_gsUP9eqpk>
X-Mailman-Approved-At: Tue, 22 Sep 2015 23:09:40 -0700
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Review of PR #209
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 22 Sep 2015 12:22:22 -0000

> On 22 Sep 2015, at 01:40, Geoffrey Keating <geoffk@geoffk.org> wrote:
> 
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls