Re: [TLS] Review of PR #209

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 21 September 2015 15:38 UTC

Return-Path: <dkg@fifthhorseman.net>
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 270D01B332E for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 08:38:52 -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 AGEXJFMEzrg2 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 08:38:51 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 970301B3331 for <tls@ietf.org>; Mon, 21 Sep 2015 08:38:50 -0700 (PDT)
Received: from fifthhorseman.net (unknown [167.220.103.147]) by che.mayfirst.org (Postfix) with ESMTPSA id D43C1F985; Mon, 21 Sep 2015 11:38:48 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A9617203AE; Mon, 21 Sep 2015 10:22:34 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <84975A12-87F7-4E5A-BC0D-0E0D68FEB2F1@inria.fr>
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>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 21 Sep 2015 07:22:34 -0700
Message-ID: <87613326ol.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FhdQeImWjs-o6YQhQbim0krHZ_E>
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: Mon, 21 Sep 2015 15:38:52 -0000

On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
> As dkg points out, dynamically authenticating clients later in the connection brings up
> API issues of how to notify the application about the scope of this new authentication event.
>
> I think it is inevitable that implementation will store the client credential in the session, and
> that the new (authenticated) stream of data will be concatenated to the older (unauthenticated) stream.
> Both of these design choices will lead to the following answers to dkg’s questions:
> (a) all messages in TLS sessions (past and present) will be attested to by every certificate
> (b) all traffic in earlier and future resumed sessions will be attested to by every certificate
>
> In other words, if we do allow this change to client authentication, to be safe, we must analyze the
> resulting protocol *as if* applications will use the authentication event to attest to all
> data, past and present, that may be associated with the data in the current connection.

But this combination is pretty weird for servers to deal with.  For
example:

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.

The client is currently examining folder Y.

Some client identities *do not* have authorization to visit folder X.
others do.

The client requests a change to folder X.

The server rejects the change.

The client subsequently authenticates to an identity that is authorized
to access folder X.

What is the currently-examined folder for this session?

The "easy" (and right) answer here is "folder Y, of course" -- but
telling peers that the authentication should apply retroactively to all
previous data sent suggests that maybe it should be folder X.

This is confusing.  Confusing semantics are bound to lead to problematic
implementations and usage :(

Sorry that this mail doesn't have a better suggestion to offer.

     --dkg