[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.112.154.3 with SMTP id vk3mr33716451lbb.26.1426700540401; Wed, 18 Mar 2015 10:42:20 -0700 (PDT)
Received: by 10.112.204.5 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: Henrik Grubbström <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
Hi. 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 violation. 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. /grubba -- Henrik Grubbström grubba@grubba.org Roxen Internet Software AB grubba@roxen.com
- [TLS] Handshake padding in TLS 1.3 (PR #147) Henrik Grubbström