[TLS] Handshake padding in TLS 1.3 (PR #147)

Henrik Grubbström <grubba@gmail.com> Wed, 18 March 2015 17:42 UTC

Return-Path: <grubba@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 6F3F61A879A for <tls@ietfa.amsl.com>; Wed, 18 Mar 2015 10:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v9sN0NEV_Whb for <tls@ietfa.amsl.com>; Wed, 18 Mar 2015 10:42:22 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 0C3E11A1B5E for <tls@ietf.org>; Wed, 18 Mar 2015 10:42:22 -0700 (PDT)
Received: by lagg8 with SMTP id g8so42359917lag.1 for <tls@ietf.org>; Wed, 18 Mar 2015 10:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0VQV6egmI3NJCW7725KJs2VMrg25lGRmG3DUuNIOx6o=; b=rOWvvvq6MM1gClIMqEff9jrrXBxh3OE2UGd08mOI9fLm1KInxOQ1dCBAcw+oC2yiC5 RMCDnC3YzIn4uolU1LoxDAc8Krr0zOQGYAkmGvCDLvspSjbYNRSonnMSjQW1aJH83+vX DRdWn2LxfdZOyj5Ta6Ndbj5tabXhMccb6nsK7SOrIXcXYbCCP3JH1dp2tigAKa57EnI3 JJQ+JdKsrx1lUREOdUKtfvKksdEiSElHHr5xTa1OWivGwbJmUwS47aSoYqeL0laiKphc 1OnLbIX5+1L/FcLTrUPU0Il/nCzKguddi8Q05wGiWXVNI9LLrAI4t06GtKsYDad7vhZ5 F7VA==
MIME-Version: 1.0
X-Received: by with SMTP id vk3mr33716451lbb.26.1426700540401; Wed, 18 Mar 2015 10:42:20 -0700 (PDT)
Received: by with HTTP; Wed, 18 Mar 2015 10:42:20 -0700 (PDT)
Date: Wed, 18 Mar 2015 18:42:20 +0100
Message-ID: <CALuAYvZ9EO5tNAywRhOS5XQ_y0C7qYJXga20U3V5cQ4SEQ=9WQ@mail.gmail.com>
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= <grubba@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/OpWWR0E-fZsW8wWaEtx6jTPcx-Q>
Subject: [TLS] Handshake padding in TLS 1.3 (PR #147)
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: Wed, 18 Mar 2015 17:42:23 -0000


I've taken a look at the feasibility of adding handshake padding as
currently drafted in PR #147 to my implementation of TLS 1.3.

>From the PR draft:

> handshake_messages
> : All of the data from all messages in this handshake up to, but not including,
> this message. This is only data visible at the handshake layer and does not
> include record layer headers. For encrypted handshake records, the hash
> includes the two bytes specifying the length of the padding, as well as any
> padding present. handshake_messages is the concatenation of all the
> Handshake structures as defined in {{handshake-protocol}}, exchanged thus
> far. {:br }

The above seems to assume that packet breaks (ie the places where
padding is inserted) and handshake message breaks align. This is not
true in the general case, and the above is a protocol layering

The problem shows up clearly if you have distinct layers of code for
handling coalescing (and apparently padding) of packets and the
handling of handshake messages, and the higher layer is about to send
a Finished message; to be able to calculate the payload for the
packet, it needs to know in advance where the lower layer will break
the packets, and what padding it will insert as this will affect the
handshake_messages hash.

The recipient also runs into trouble, as it can no longer just add all
handshake packet payloads to a buffer from which it extracts a message
at a time, as it also needs to keep track of any padding (which may
appear in the middle of messages).

Adding such complexity is likely to frustrate implementators and lead
to even buggier implementations.

I believe that the easiest way to reduce the complexity while still
retaining the features of padding, would be to move the padding from
the handshake packet layer to the handshake message layer. Ie
introduce a handshake_padding message (allocated from HandshakeType)
which may be sent at any point in the handshake, and which only
affects the handshake_messages hash.

This would be trivial to implement on the recipient side, have no
overhead if padding isn't used, and be reasonably simple to implement
on the sender side. The down side is that the minimum padding would be
4 bytes and not 2.


Henrik Grubbström                                       grubba@grubba.org
Roxen Internet Software AB                              grubba@roxen.com