[TLS] Closing on keys used for handshake and data messages

Joseph Salowey <joe@salowey.net> Fri, 03 June 2016 21:55 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F1E6A12D124 for <tls@ietfa.amsl.com>; Fri, 3 Jun 2016 14:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xeXUoG-1S2Zy for <tls@ietfa.amsl.com>; Fri, 3 Jun 2016 14:55:14 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B73A212D56D for <tls@ietf.org>; Fri, 3 Jun 2016 14:55:13 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id 23so1522548qtq.0 for <tls@ietf.org>; Fri, 03 Jun 2016 14:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eTye4P9BfSc1h6WCrRdgDSOkKKQEv1JT1R4EKGQs2Mw=; b=XdxbcLM1S8kKt8vc3t8xyFPoQK0WmbOg3gXcOuKEIWw04v+uWGLwQAIZrXLyTE3mYc 4Lbxr84WMaScF4MJoohW0jz2GJBxk+txoCC6ZM+rOII51pEL1t3/MG82pBtP3/RKGGHF KIjrVkPpxz6qCkPu8RkL2RF1cpTPhWx0X62ONap4UGWLuKOzkOVeI/AjKWq5u3LJjhVR ROb/SZaQqMQ4kAqYCsvUSsqYPflweMY9tbcsOwBG/n9TMegu7hgwD3Ja/pnobpIRW4Lg WbFUPPZq08RCkOj+1B/780k4t29CrDDZT2gvRuznZA1acJx5l4uEr4WrjZx7QdKSjTFl onuA==
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=eTye4P9BfSc1h6WCrRdgDSOkKKQEv1JT1R4EKGQs2Mw=; b=WV9ByPte7Su7vDHfSThLTo+Yb727cvbofix6y1e/eM79zC+IfhGL4x6QCDn6cBfx6g Li8yRAMwDRcl3LZr+wp1q15fgY8SzsfBWswpMNteU2dpmMZW2gAh8KwxsdzpnJkYpYsL F0YujuNNR73MgZdpp9H7SPpsTOCqHdw7lK8EqvyBHF8vlwhKHS3h6EtU5ILarRGOyEb9 bWg9r/HuzCDr0HLjFhq4UWI+JxYcjd7L1tX42CtLRmqyMU4ZqYiAamj+yg4QD7GOEwNR wHEenGyRCNCLDErxlco7UDJWKP4OK+E+VCr3IxehXio7Fo8ooenPaHZo5dF+qsQvPBak X4Yg==
X-Gm-Message-State: ALyK8tJTZcat7a+zyHXqb4E5J9pdVrTE6nNFWLKgpWQyKEoRDVbZb3MdyQlHgdMUavyIDXpvONqNnabE0RGxjQ==
X-Received: by with SMTP id j24mr5554607qtc.95.1464990912732; Fri, 03 Jun 2016 14:55:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Jun 2016 14:54:53 -0700 (PDT)
From: Joseph Salowey <joe@salowey.net>
Date: Fri, 3 Jun 2016 14:54:53 -0700
Message-ID: <CAOgPGoB6=eH9059u95RJzt_quCN3+auP2NSx+mxLztePVYqGrw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a113c24caf40d90053466c698
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA>
Subject: [TLS] Closing on keys used for handshake and data messages
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, 03 Jun 2016 21:55:17 -0000

We still have a significant outstanding TLS 1.3 issue affecting involving
which key to use for handshake and data records.  Antoine Delignat-Lavaud,
Bjoern Tackmann, Cas Cremers, Eric Rescorla, Felix Guenther and Markulf
Kohlweiss put together a summary of the issue which is included below.  We
need to close on an approach to this issue so we can begin a final
cryptographic review of the protocol.  The plan is to have discussion of
this issue for a week after which the chairs will start a week consensus
call based on this discussion.  After the chairs judge consensus, the
author will produce a draft reflecting the consensus that can go out for
review by the cryptographic community.




TLS 1.3 currently encrypts post-handshake handshake messages
(NewSessionTicket, KeyUpdate, and post-handshake client authentication)
with the application traffic keys. This makes it hard to do certain kinds
of proofs, particularly cryptographic style proofs that make statements
about the entire handshake (including encrypted post-handshake messages)
being composable with application traffic. These proofs rely on having
separate keys for these handshake-type messages and the application

Unfortunately, the TLS record framing is not easily compatible with having
multiple keys used simultaneously: because we encrypt the content type, it
is not possible to use it to determine which key to use to decrypt. We
examined a number of proposals which would allow you to simultaneously have
encrypted content types and separate keys, but they all appear to be
nonviable for one reason or another:


   Trial decryption has serious implementation problems

   Double-encrypting handshake messages in both the handshake key and the
   application key does not actually provide the required key separation

   Separately encrypting the content type is inefficient in a number of
   ways, especially for DTLS (and would need separate security analysis). This
   is probably the most viable of the “try to get both” designs.

This leaves us with two primary alternatives:


   Use the same key (as in the current draft-13)

   Restore a public content type and different keys

I discuss these in a bit more detail below


As stated above, using the same key for handshake and application traffic
precludes certain types of proof. However, this is not to say that either
it is insecure to use the same key or that no proof is possible.


   Using the same key is not an obstacle for symbolic proof methodologies.

   In particular, if one is willing to restrict the proof of the handshake
   to the original handshake messages, then TLS 1.3 still provides key

   Hugo Krawczyk has a forthcoming paper which demonstrates the security of
   the current keying model using cryptographic techniques in a “secure
   channels” model. Also, the miTLS proof of TLS 1.3 does not rely on
   separation, as it considers the record protocol together with the handshake.

Nevertheless, there was broad and strong agreement at TRON that key
separation considerably simplifies cryptographic proofs in the
computational model by enabling modular analysis of handshake encryption
and the record protocol. The motivation for switching keys from handshake
to application traffic is somewhat undermined by late handshake messages
being encrypted under the application traffic key. This can be viewed as a
design compromise that breaks the separation principle for post-handshake
messages while still incurring some of the overhead of separate keys in the


Clearly, having a public content type and separate keys for handshake and
application data provides full key separation, at the cost of revealing
whether a given record is handshake or application data (and potentially
alerts). The major question that the group had was whether it was actually
possible to conceal this information effectively, even with encrypted
content types, since hiding the handshake messages in the application
traffic requires detailed knowledge about the application traffic pattern
(e.g., packet lengths, timing, response patterns, etc.). It’s clear some
analysis of this is needed.

In addition, changing to public content types would potentially necessitate
changes to the packet format: the current record design uses the fact that
the content type is nonzero to overload it as a padding delimiter, and if
we were to add a public content type, we would either need to duplicate the
content type in both locations or remove the inner content type and find
some new way to make the padding unambiguous. Note that because we already
have a dummy content type, even having two copies would not make the packet
longer currently, though we are hoping to eventually remove the external
content type, in which case we might end up having the record not shrink by
as much as one might like [0].

[0] There are probably designs that would actually let us keep the minimal
packet size if we were willing to break the format on the wire. One
potential design would be to retain the inner encrypted content type but
rob a bit from the length (which currently has the first bit always set to
low) to indicate which key is in use.