Re: [TLS] Review of PR #209

Karthikeyan Bhargavan <> Mon, 21 September 2015 05:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4009E1A21BF for <>; Sun, 20 Sep 2015 22:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XXQ8xgViJ22x for <>; Sun, 20 Sep 2015 22:38:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29E381A21BE for <>; Sun, 20 Sep 2015 22:38:49 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so129890193wic.0 for <>; Sun, 20 Sep 2015 22:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id bz8mr20815324wjc.42.1442813927717; Sun, 20 Sep 2015 22:38:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t7sm15452606wje.13.2015. (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 22:38:46 -0700 (PDT)
From: Karthikeyan Bhargavan <>
X-Google-Original-From: Karthikeyan Bhargavan <>
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: <>
Date: Mon, 21 Sep 2015 07:38:45 +0200
Message-Id: <>
References: <> <> <20150916153041.GA14682@LK-Perkele-VII> <> <>
To: Daniel Kahn Gillmor <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>
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: 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.


> On 19 Sep 2015, at 22:14, Daniel Kahn Gillmor <> wrote:
> On Wed 2015-09-16 13:48:27 -0400, Martin Thomson <> wrote:
>> On 16 September 2015 at 08:30, Ilari Liusvaara <> 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