Re: [TLS] Review of PR #209
Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Mon, 21 September 2015 05:38 UTC
Return-Path: <karthik.bhargavan@gmail.com>
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 4009E1A21BF for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 22:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XXQ8xgViJ22x for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 22:38:49 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E381A21BE for <tls@ietf.org>; Sun, 20 Sep 2015 22:38:49 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so129890193wic.0 for <tls@ietf.org>; Sun, 20 Sep 2015 22:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :message-id:references:to; bh=uVb1SOYRPtiFc8WMkQ4IHjd8zqFBcIpdqBExj64Xjqc=; b=GdEkq5OBBs6UmQowMIMppfcm35KWMDVYrt+r+ORzDr6hGOLGYZBTYGRiAJdho2SHwW AedZtR7NCJcEqrwWUumO/KrJRIBVRijRLFGC1Nxb20+mGyDZlbH/k8LPLauUOQIDxukz GRUoBpPxfGAwHrKk5GGRh1mwd3neZdSfA+sLDtdU7r391MtJ1Cst8KfCkONRRaGxGwX2 RsAjvInqE/81tb8N/kCSSqLva0dsm2MgPKR9vs+KSwTlQ+IGMyQYRhvp4EtI+WMRKOd1 fyyduLF8qSHOPvSPFgOSluqfhnCquTpuVRiyFlDT3qSWp4KzsiDnYuBqie76pELTi0w/ maRA==
X-Received: by 10.194.175.104 with SMTP id bz8mr20815324wjc.42.1442813927717; Sun, 20 Sep 2015 22:38:47 -0700 (PDT)
Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id t7sm15452606wje.13.2015.09.20.22.38.46 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 22:38:46 -0700 (PDT)
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
X-Google-Original-From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A14C15CF-E7C6-49CD-B025-EF35B2309251"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
In-Reply-To: <87eghugo9n.fsf@alice.fifthhorseman.net>
Date: Mon, 21 Sep 2015 07:38:45 +0200
Message-Id: <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>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4sfVXYS0dNnrvmfVvODufDy8dhU>
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 05:38:51 -0000
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. -K. > On 19 Sep 2015, at 22:14, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > > On Wed 2015-09-16 13:48:27 -0400, Martin Thomson <martin.thomson@gmail.com> wrote: >> On 16 September 2015 at 08:30, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: >>> As then the application needs to ensure that the authentication >>> occurs between TLS handshake and actually starting up the protocol. >> >> I'm not sure that is necessarily a problem. If the claim is that the >> authentication attests to everything prior to its appearance, then you >> have no problem. I think that claim is reasonable, but I'm happy to >> discuss it. > > I think this claim sounds confusing, for (at least) two reasons: > > (a) it interacts oddly with the possibility of > 1 CertificateVerify > message -- does it imply that all messages in a TLS session > (past and present) are attested to by every client certificate ever > sent in the session? > > (b) it has unclear semantics around session resumption. If i resume a > session and send a ClientCert+CertificateVerify, am i retroactively > attesting to all the communications from the previous session(s)? > What does that even mean to the server which has already processed > the traffic from previous sessions? > > Can we communicate these semantics to application developers who might > have an "accelerating" TLS session cache available, or who might share a > session cache between systems? Can we help clients make sense of the > implications of retroactive attestation when confronted with a > certificateRequest? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [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