[TLS] On the possibility of AEAD modes that require padding

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 20 June 2014 18:12 UTC

Return-Path: <dkg@fifthhorseman.net>
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 98F191B289B for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 11:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 h97psPezjX3I for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 11:12:25 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 793E11A02B2 for <tls@ietf.org>; Fri, 20 Jun 2014 11:12:14 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id DC617F984 for <tls@ietf.org>; Fri, 20 Jun 2014 14:12:11 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7C96F1FF69; Fri, 20 Jun 2014 14:12:02 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF TLS Working Group <tls@ietf.org>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Fri, 20 Jun 2014 14:11:58 -0400
Message-ID: <87k38bzc0h.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XLmFWE3dOdnvM1oZ2AxIUsS3OrU
Subject: [TLS] On the possibility of AEAD modes that require padding
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: <http://www.ietf.org/mail-archive/web/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, 20 Jun 2014 18:12:28 -0000

hi IETF folks--

If an AEAD mode is ever defined that must pad its input to a blocksize
before encrypting, the current spec seems like it will break.

This is a currently-theoretical concern, since (fixed authentication tag
notwithstanding) GCM does not pad its input, and OCB and
chacha20-poly1305 (and other AEAD modes i could find data on) also don't
pad their input.

(note that this question is independent of the various proposals for
explicitly introducing padding into TLS, which i don't go into here)

The 1.3 draft currently says:

> The additional authenticated data, which we denote as additional_data, is
> defined as follows:
> 
>        additional_data = seq_num + TLSPlaintext.type +
>                          TLSPlaintext.version + TLSPlaintext.length;
> 
> where "+" denotes concatenation.
> 
> The aead_output consists of the ciphertext output by the AEAD encryption
> operation. The length will generally be larger than TLSPlaintext.length, but
> by an amount that varies with the AEAD cipher. Since the ciphers might
> incorporate padding, the amount of overhead could vary with different
> TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an expansion of
> greater than 1024 bytes.

It goes on to define AEAD-Decrypt this way:

>       TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce,
>                                            AEADEncrypted,
>                                            additional_data)

Consider the decryption step.  The decryptor knows:

 * the AEAD mode (including the taglength)
 * the nonce
 * the write key
 * the sequence number
 * the record type
 * the TLS version
 * the ciphertext (including its length)

To create additional_data, it must be able to derive TLSPlaintext.length
From the above information.

All the AEAD modes i know about have a ciphertext expansion of a
fixed-length tag.  so:

 TLSPlaintext.length = TLSCiphertext.length - AEADmode.taglength

But if an AEAD mode were to additionally pad its input ("Since the
ciphers might incorporate padding, the amount of overhead could vary
with different TLSPlaintext.length values"), there would be no clear way
to derive additional_data because the length of the plaintext is unknown
before doing the decryption.

So i think the fix is to specify that additional_data should be derived
From the padded length of the TLSPlaintext.fragment, not from
TLSPlaintext.length.  For GCM (and other AEAD modes i know of) these
values are of course identical.

Making this explicit seems like it would require a bit of gymnastics in
the spec, all for the sake of holding open the door for future modes
with variable-length ciphertext expansion.  I can try to make a patch
for this change, but i want to know if we think it's necessary.

Alternately, we could decide that we won't accept modes that require
this kind of padding (maybe stripping out the sentence about "might
incorporate padding").

Have i missed an obvious solution or misunderstood the situation?  What
do people think we should do here?

     --dkg