[TLS] Simpler encrypted headers for DTLS (and TLS)

Bryan A Ford <brynosaurus@gmail.com> Sun, 06 December 2015 10:14 UTC

Return-Path: <brynosaurus@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 41FEB1ACD0A for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 02:14:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9BLe5g_g7lNk for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 02:14:49 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 39CFD1ACD02 for <tls@ietf.org>; Sun, 6 Dec 2015 02:14:49 -0800 (PST)
Received: by wmvv187 with SMTP id v187so129093028wmv.1 for <tls@ietf.org>; Sun, 06 Dec 2015 02:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=EkmgTvmQ8eEyyAn9KqW/oY0P1gAzjaKWQTPplFne1dw=; b=HKT0/o6qfzi/YK54VCPpozZO38NgJe4PKy+AVmweWiEBcBtQxoYLxG+vdpMNmKKJkM lnQiW1/aw36APFR7z+0O4sazDs9vli/ifScVIWp40lVOnZbmdGyFsOz8niD07S9F8NtZ r2EEyWNK2TtkOLGcDg8KfuWPAipdkdFbMi71YP8mcpr+PDFN+oV22zad+rxHRlZkimqO NX9FHz482VpjaHfwNKdCokPua8OnGcgKTPR8zvavg5WS4BeCW3PsQYd2Zq/gXjr824UM 86dFD3A8iuZAoGpr73f5NuBuvLX0I1tnTB/udrgT0ktmpHKL2V6Z1k66F+tC2Hztg6ox fHlQ==
X-Received: by with SMTP id f80mr15548034wme.41.1449396887665; Sun, 06 Dec 2015 02:14:47 -0800 (PST)
Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. []) by smtp.gmail.com with ESMTPSA id pc2sm15789246wjb.11.2015. for <tls@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 02:14:46 -0800 (PST)
To: "tls@ietf.org" <tls@ietf.org>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56640AAE.3040708@gmail.com>
Date: Sun, 6 Dec 2015 11:15:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000900040802020609030505"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/o7r7DprAaHz4xi50HkitY_-V5vk>
Subject: [TLS] Simpler encrypted headers for DTLS (and TLS)
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: Sun, 06 Dec 2015 10:14:51 -0000

While I think the approach I suggested for encrypted DTLS headers would
work, it does have the downsides of (a) the complexity of managing the
hash table of encrypted sequence numbers, and (b) the risk of
desynchronization after long bursts of missed packets.

But further discussion with Philipp Jovanovic led me to the realization
that the simplest and cleanest solution in the DTLS case would simply be
to rely on AEAD ciphers that either support "secret message numbers" or
have a "misuse-resistance" property.  In particular:

- Secret message numbers basically do "precisely what DTLS needs",
namely allow a message/record/sequence number to be transmitted under
encryption along with the AEAD payload.  Secret message numbers are
specified as an optional feature for AEAD submissions to the ongoing
CAESAR cipher competition (see
http://competitions.cr.yp.to/caesar-call.html), and further elaborated
in this useful message by DJB in 2013:


- Another optional feature that some CAESAR competition submissions
have, and *all* are required to document one way or another, is
"misuse-resistance".  In particular, a misuse-resistant AEAD does not
rely on nonce uniqueness for security.  With a misuse-resistant AEAD
(which we might alternatively just refer to as a "nonceless AEAD"), you
can simply move the complete DTLS header from the additional_data field
into the plaintext, and leave the sequence number out of the nonce.  The
sequence number will still be in (encrypted) header and thus available
for replay-protection purposes and such, and will automatically ensure
that all DTLS plaintexts (and hence all resulting ciphertexts) are
cryptographically unique.

I'm not proposing necessarily that the "next version of DTLS"
(presumably based on TLS 1.3) should *only* allow AEADs that support
secret message numbers or misuse-resistance.  Rather, I'm proposing that
the next DTLS should support at least one such cipher, and that when
DTLS negotiates such a cipher, it simply takes advantage of the relevant
property to move the DTLS header under encryption.

So the upshot is that simply "using relevant AEAD features when
available" would seem to take care of the DTLS case completely, with no
special fuss or additional complexity.  Which means that we can focus on
the TLS case now, without worrying about whether and how easily it will
translate to DTLS.

And given that, for the TLS case I'm inclined to prefer my second
proposal, namely just reinterpreting the "length" field to be a
"next-record-length" field.  This requires no special mucking with the
AEAD in TLS either, and no extra complexity at all in TLS
implementations that pad to constant record sizes (which I hope many will).

For reference, some background pointers misuse-resistant ciphers
(definitely not comprehensive):

- https://eprint.iacr.org/2006/221.pdf
- https://eprint.iacr.org/2015/999.pdf