Re: [TLS] Review of PR #209

Geoffrey Keating <> Tue, 22 September 2015 00:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B06251ACD9B for <>; Mon, 21 Sep 2015 17:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fNhmPz4QBCTH for <>; Mon, 21 Sep 2015 17:40:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB9781ACDF2 for <>; Mon, 21 Sep 2015 17:40:03 -0700 (PDT)
Received: by (Postfix, from userid 501) id 17A0A33D080; Tue, 22 Sep 2015 00:40:03 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Daniel Kahn Gillmor <>
References: <> <> <20150916153041.GA14682@LK-Perkele-VII> <> <> <> <>
From: Geoffrey Keating <>
Date: Mon, 21 Sep 2015 17:40:02 -0700
In-Reply-To: <>
Message-ID: <m2fv278exp.fsf@localhost.localdomain>
Lines: 31
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: <>
Cc: Karthikeyan Bhargavan <>, "" <>
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 00:40:06 -0000

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

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.