[TLS] draft-ietf-tls-tls13-19 posted

Eric Rescorla <ekr@rtfm.com> Fri, 10 March 2017 23:35 UTC

Return-Path: <ekr@rtfm.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 C881A129462 for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 15:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 G7nIYt0IWgwF for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 15:35:21 -0800 (PST)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 0E1A3127A91 for <tls@ietf.org>; Fri, 10 Mar 2017 15:35:21 -0800 (PST)
Received: by mail-yw0-x230.google.com with SMTP id v76so33174967ywg.0 for <tls@ietf.org>; Fri, 10 Mar 2017 15:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BFkq6Zu5D5tyD7695ddN2JyWRcdlkDIMj4zq6Ki9wnk=; b=k1lxbeeNtWz9F5THd6MZ83EPU7aDuiXOpwtVd8JArtwA1EcV88CwFIMtZg5LTgvcWM PSDNf1NxIuAEMhLmdtNi5eZNtovH9Dx/eMyPycBPfbEE3/kYA94/YZm5it3b5POaENiS 4gRzM6U70OI8mVk8CqOsrPxoBeSOUI567vCstPGtQMxTbdOs0z/C2TKTYuSKHVwuWFPs PrW/dGpgVOH6qlTC9CiKqP0UyQmzfIanRbYEB5740VhMeOp5duXRyUvco90iBA//Npsc /e5Y5BwYRDVM4YF30D7+xGbc/pk7rncDvR5WakxrZccY1HQL6zO7jZP4VP5zjcg6HaJ7 ym+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BFkq6Zu5D5tyD7695ddN2JyWRcdlkDIMj4zq6Ki9wnk=; b=NbDq5NO7RnMgCdiiWv2QNRIFgiJD5Xw7hY1qOxKvKE43inyugdJHflLwTVJzKrO+fS /lKT6v0/ipkA9bDN76qUN06HBeW+LgzPRNUPS5iiuwqr5bKpanNhtc1kLbny6bLL9pAi yu87oSJswqSFQOIBq9fXfEz3O+KS3xaH/BtEyu6XXYAaAR3M5zfZ8/CK9Sw0U88Gxv9J kG8JSAXpBQTa1DYxrf7aXjAXtX3yhd0/4FaGycVmYnZ35H0xnBxWasKwCT3FVOD/HnVS wA4F+m6LYjCs5UywNkV5SOVuBDQ0WE1TTIsp+nFGuk0/APzeXRc7PDvYexigCycuRNeI Ngug==
X-Gm-Message-State: AMke39ks786pvZp5yIvYxz6tOlFQnggjldzeJOFz7nF+SoNnQNoYMGUwGctGlUpxuP5/vKnEDwCem90wXuAxqQ==
X-Received: by 10.129.125.5 with SMTP id y5mr9385238ywc.120.1489188919925; Fri, 10 Mar 2017 15:35:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 15:34:39 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 Mar 2017 15:34:39 -0800
Message-ID: <CABcZeBOZQQPSJFZJZe_a5LSe63BjLg+_argPTuexXzwPW04nig@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11493644939eb5054a68d038
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XiHhbvODOaUAZRoy3CA2PDY6XHc>
Subject: [TLS] draft-ietf-tls-tls13-19 posted
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, 10 Mar 2017 23:35:23 -0000

I just posted draft-19 at:

  https://tools.ietf.org/html/draft-ietf-tls-tls13-19

This draft includes all the outstanding wire format changes that I believe
we are going
to make before publication (changelog below). There are three remaining
issues that
we need to address somehow. I've listed them and proposed resolutions.

1. DH Key Reuse Considerations (https://github.com/tlswg/tls13-spec/pull/768
)
I'm not entirely confident of the analysis here and I'm not that excited
about encouraging
people to re-use, so I propose that we simply drop this PR.

2. Short headers (https://github.com/tlswg/tls13-spec/pull/762)
Both the Chrome team and the Firefox team have concerns about the middlebox
compatibility impact of this change, and I believe if necessary we can add
it as
an extension later. Thus, I propose we defer it. We can make this change
directly
in DTLS 1.3, however.

3. The various non-X509 cert RFCs (no PR).
As Ilari points out, there is significant incompatibility between these
RFCs and
TLS 1.3, so we'll probably need new versions of them if people want this
functionality.
Absent objection, I'll pull them out of the "usable with TLS 1.3 list" in S
4.2
and then add some handwaving about how we can support them with new
drafts (though, as Ilari indicates, we may be able to keep cached-info with
some
small text changes here).

In terms of implementation, we will probably try to have something for NSS
by IETF, but I doubt it will be actually in Firefox.

As usual, comments welcome, including anything I missed.
-Ekr


ChangeLog:
   -  Hash context_value input to Exporters (*)

   -  Add an additional Derive-Secret stage to Exporters (*).

   -  Hash ClientHello1 in the transcript when HRR is used.  This
      reduces the state that needs to be carried in cookies. (*)

   -  Restructure CertificateRequest to have the selectors in
      extensions.  This also allowed defining a
      "certificate_authorities" extension which can be used by the
      client instead of trusted_ca_keys (*).

   -  Tighten record framing requirements and require checking of them
      (*).

   -  Consolidate "ticket_early_data_info" and "early_data" into a
      single extension (*).

   -  Change end_of_early_data to be a handshake message (*).

   -  Add pre-extract Derive-Secret stages to key schedule (*).

   -  Remove spurious requirement to implement "pre_shared_key".

   -  Clarify location of "early_data" from server (it goes in EE, as
      indicated by the table in S 10).

   -  Require peer public key validation

   -  Add state machine diagram.