Re: [TLS] Review of PR #209
Geoffrey Keating <geoffk@geoffk.org> Tue, 22 September 2015 17:27 UTC
Return-Path: <geoffk@geoffk.org>
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 152B21A9054 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 10:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 ZCq8eO53_O9t for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 10:27:47 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2AC1B2C6B for <tls@ietf.org>; Tue, 22 Sep 2015 10:27:44 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 2706233D080; Tue, 22 Sep 2015 17:27:43 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: "henry.story@bblfish.net" <henry.story@bblfish.net>
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> <E1EF63EA-C301-4229-AD77-1475298F753C@bblfish.net>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Tue, 22 Sep 2015 10:27:43 -0700
In-Reply-To: <E1EF63EA-C301-4229-AD77-1475298F753C@bblfish.net>
Message-ID: <m2bncu8iuo.fsf@localhost.localdomain>
Lines: 52
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NE5k_g1UTjWnkNl89xBBBxiBkpg>
Cc: "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 17:27:49 -0000
"henry.story@bblfish.net" <henry.story@bblfish.net> writes: > > 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, I think this is still under discussion. In the most recent draft, no, but in that draft you can only send a client certificate before sending application data. However a possibility under discussion is that you could send a client certificate at any point in the stream. > 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 ? IMO, this is outside the scope of TLS, a higher-layer protocol will have to determine what it means. TLS need only report 'you got a client certificate here and another client certificate here'. > If that were to work correctly would one not also have to change the > encryption for each user? No. Even if the client private key is possessed by an untrusted entity, all that needs to be revealed to that entity to perform the signature is the current value of the handshake hash.
- [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Karthikeyan Bhargavan
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 henry.story@bblfish.net
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 Henry Story