[TLS] Proposed Change to Certificate message (#654)

Nick Sullivan <nicholas.sullivan@gmail.com> Fri, 23 September 2016 00:42 UTC

Return-Path: <nicholas.sullivan@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE12612BE42 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 17:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fhfmsqhBr9-y for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 17:42:25 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 DF63112BE97 for <TLS@ietf.org>; Thu, 22 Sep 2016 17:42:21 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id o3so1340673ita.1 for <TLS@ietf.org>; Thu, 22 Sep 2016 17:42:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UF8/WEFeNyyRWnKCIVxKdMiCDplneW32dDTI6INcc8o=; b=s4VhGzrqww4oSHJcITL9cnsfnQwkt2BSNqJe/6wwsacX84BjmjZr2R/Q75kLvrv81F q+npUS0vJq6VD9EKpuO8DjFe76helHk0rQap6fYS7MdnDlLu0nwrBxVhJncgTpv/Q68Q WUmDCfRbO1Sqpn0Nt6oRMmUwK/2QXgcYWdWpOXqFc+K7EIwfTvn0CWmNigto5tPdOBFv LfcGrk2XJSSlbSbSlhLx8YRlxtZ9Lm4sP4BXGb5dmyJ+XIVPowTWkx5biaYLWAFs7Mce tTnWLQ5zmpdgWXSJa5B2hig8dEQLAY3xmp0GpVUdIIRlPn8bfc6q6oYBp4REbrHZ79Gy S8yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UF8/WEFeNyyRWnKCIVxKdMiCDplneW32dDTI6INcc8o=; b=JRG33cKe0K69DAJgFB3nVDNAVfa1Qgz8uSecc3p2a3u34D8VJJPVqApBZ8MC/os/pc e9F7FhKOK+HBUYVpV1x/RxSte5s97d4tVF/0eFBLNvDf28IEHPuAlR7N7F5x3qaRiLQ6 5QwB7uWHI7clzA3e8FE+41YKY82ikX2TQ/dbRDBBp3ZBFqwdVSLp9i1U0urZCnx2rwbz 2PW5vlKZT7zm4gkFXB+JfRFEfC8EWjziaI3EcbVOB5/nw7xftidiBjcwle85Q3zqDo3a BKtFP4pnuKKeFcFvWCrZdkztcv8QZPC6wvC6rYnVAiX1FqSbTcadmVqtHVG7H0A2aoqm VRAQ==
X-Gm-Message-State: AA6/9RmcoYuCiUebqLvx5104oggIrfUN3f3/6eOLpbA82dCocFS2x56tH0HfzanqPIxGqg2UV11+VaTgk4nBEw==
X-Received: by 10.36.190.5 with SMTP id i5mr134350itf.100.1474591340619; Thu, 22 Sep 2016 17:42:20 -0700 (PDT)
MIME-Version: 1.0
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Fri, 23 Sep 2016 00:42:09 +0000
Message-ID: <CAOjisRyDx0Wa5tcFT3gN496jhf-AjLfDH4JNN+w70r8jBsxt5g@mail.gmail.com>
To: "tls@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c19d5800bf2c5053d220da6
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UhMrmAh1UIkNTDbxZ1OEwZgSAIU>
Subject: [TLS] Proposed Change to Certificate message (#654)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 00:42:27 -0000

PR: https://github.com/tlswg/tls13-spec/pull/654

Hello,

I'd like to propose a small to the Certificate message format to allow for
future extensibility of the protocol.

This change adds a set of extensions to the Certificate message. With this
change, the Certificate message can now hold all extension messages that
are certificate-specific (rather than connection-specific). This change
also resolves the anomaly of OCSP messages appearing before certificates in
the handshake.

Reasoning:
I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
per-connection metadata. By putting these responses in the
EncryptedExtensions, you limit these extensions to being shown once per
connection. This restricts future protocol extensions from using multiple
Certificate messages to support multiple certificates on the same
connection. An example of this is the post-handshake authentication
proposal (
https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
which currently requires a modified post-handshake Certificate message.
This proposed change would simplify the post-handshake auth proposal
significantly and generally make more sense as more certificate-specific
extensions are created.

Nick