Re: [TLS] Review of PR #209

Martin Thomson <martin.thomson@gmail.com> Mon, 21 September 2015 00:56 UTC

Return-Path: <martin.thomson@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 C95E31B2EF4 for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 17:56:16 -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 zivHcBQhtMEO for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 17:56:13 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 BF50E1B2EF3 for <tls@ietf.org>; Sun, 20 Sep 2015 17:56:13 -0700 (PDT)
Received: by ykft14 with SMTP id t14so90075186ykf.0 for <tls@ietf.org>; Sun, 20 Sep 2015 17:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=io9sl46AAtUbvtCv4KOD0KU7nl4WWf9QR9DTaCqtxp8=; b=fKCi8SgVHgHsxsZnM3GhDER7mkf8TnjAGdtMn7Z0Re6Kh/c0WyKEQwkw7BYgEJM8FM fzLSRRD7JjzXNnOxymNGUkIqR7SjhJ6jcLow89AhP0yI8TF+/nYX2MQLNAlLKUQmK0fG kb+SKa55HtR/7qmYMeeMwsBIMcpC3sWbKX64hSMaGF90DuusvYCJrheaROJzr/LWXYQq G5+NAez3WnqIn4ef6PXfTTpFHqOuzKplvqxDFGwIzlnWAXCBMkH/wT1wOVD8LXzo9J5E h/Z637IfByLwMbTYxCElVS5r4jeJFiAK9gQJu6sMvS6Mi06e1pOvf1YJLkofi8n4EvwM 2p3A==
MIME-Version: 1.0
X-Received: by 10.170.78.65 with SMTP id u62mr14560083yku.118.1442796972936; Sun, 20 Sep 2015 17:56:12 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Sun, 20 Sep 2015 17:56:12 -0700 (PDT)
In-Reply-To: <87eghugo9n.fsf@alice.fifthhorseman.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>
Date: Sun, 20 Sep 2015 17:56:12 -0700
Message-ID: <CABkgnnURBH5XcEfJJoWiCSWGzzzkKhcnZkOwM3v6iviskQPCHQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6hlWvn_XmjU8clukMB6hBqLezpo>
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 00:56:17 -0000

On 19 September 2015 at 13:14, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> 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?

I think that it would have to.  Though I personally think that 1 is
plenty, if there are more and the attestation is retroactive, then it
naturally applies to all of them.

>  (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?

I think that could make an argument for attesting to all previous
communications, but it would be easiest to say that it only applies to
the current session.