[TLS] Headerless records (was: padding)

Dave Garrett <davemgarrett@gmail.com> Tue, 25 August 2015 04:04 UTC

Return-Path: <davemgarrett@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 3EF0F1A89D3 for <tls@ietfa.amsl.com>; Mon, 24 Aug 2015 21:04:41 -0700 (PDT)
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 6jf4R-c70BU9 for <tls@ietfa.amsl.com>; Mon, 24 Aug 2015 21:04:39 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 413601A907A for <tls@ietf.org>; Mon, 24 Aug 2015 21:04:39 -0700 (PDT)
Received: by qkfh127 with SMTP id h127so94277827qkf.1 for <tls@ietf.org>; Mon, 24 Aug 2015 21:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=qTB8VQpRpsE8Te2f3Ol5852MZCFYq38dHkSEDgBTAJI=; b=hRldjFLaunRIMzzco2PDndc8ciNhwFQpeUYaDOrJHbg9K0mA8KA2E6KOsG4YKPDhHo +RLHszgzINckvIPsL3QXbwHuSRgmXW3ilBbzJ2eMfCPMg+oS//PjStfzeTTwHGvK4sTv lpr3a/Pa1a1j2PdsbszM57Mj/GWTcJJoQ+qpnM/29/QXFpH2KMqB5w/PwDIrzdG7Tce7 mvasUIXnlQwEXqOlvQIHGV7EgraOIrgjZvmkSVKBO8IQUFvWx7O7OdG3DrOr+CCiVKZm nNcqYQWrn+mb64yDWqS381mjcCXpdRlOKcwP4CUJl7fesUyh2TqaTAykDwLK79AAhToq G2fA==
X-Received: by with SMTP id 15mr29744574qkw.38.1440475478507; Mon, 24 Aug 2015 21:04:38 -0700 (PDT)
Received: from dave-laptop.localnet (pool-108-52-139-147.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id q76sm9384898qkq.22.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Aug 2015 21:04:37 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Tom Ritter <tom@ritter.vg>, IETF TLS <tls@ietf.org>
Date: Tue, 25 Aug 2015 00:04:35 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com> <201508222028.46145.davemgarrett@gmail.com> <CA+cU71kS=x7_hVRXb8Q8m=DmqMaM65GaEn1SnzH_fQHP9mzyqA@mail.gmail.com>
In-Reply-To: <CA+cU71kS=x7_hVRXb8Q8m=DmqMaM65GaEn1SnzH_fQHP9mzyqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201508250004.36291.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/5Gfi2djzjHzeKiIkOgCqWcrd6NU>
Subject: [TLS] Headerless records (was: 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: <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: Tue, 25 Aug 2015 04:04:41 -0000

The topic of encrypting the content type came up again, and a core WG charter goal is to encrypt as much as possible. To this end, I suggest we consider going all the way in this area: headerless records. Each protected record would contain nothing but an aead-ciphered struct with the bare minimum it needs, namely ContentType & content, plus maybe padding. Nothing else is really needed. The only thing that needs to know anything here is the peer with the key.

struct {
    aead-ciphered struct {
        ContentType type;
        uint16 length = TLSPlaintext.length;
        opaque content[TLSPlaintext.length];
        opaque padding[padding_length];
} TLSCiphertext;

Arbitrary padding can be added after the content, up to the total record maximum size. If we even wanted to ditch the length field, we could do:

struct {
    aead-ciphered struct {
        if (padding_allowed) {
            opaque padding<0..(2^14+256-TLSPlaintext.length)>;
        ContentType type;
        opaque content[TLSPlaintext.length];
} TLSCiphertext;

In which case content is just the remainder of the record after the type. (without the explicit length field, padding needs to come first so it can have its length in its vector first)

Cleartext records would of course be unchanged, as they need to stay as-is for backwards compatibility.

With an encrypted record format like one of the above, everything after the handshake is opaque and potentially padded.

The additional data fed to the AEAD cipher is just the sequence number at this point. The version can easily be mixed into the keying material by adding it to the HKDF label, and then we don't need to re-verify it after the fact if they key depends on it.