Re: [TLS] Headerless records (was: padding)

Martin Thomson <martin.thomson@gmail.com> Tue, 25 August 2015 15:26 UTC

Return-Path: <martin.thomson@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 AEFAC1B34F5 for <tls@ietfa.amsl.com>; Tue, 25 Aug 2015 08:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-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 JaocY85_sbgV for <tls@ietfa.amsl.com>; Tue, 25 Aug 2015 08:26:36 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 070071B34F4 for <tls@ietf.org>; Tue, 25 Aug 2015 08:26:36 -0700 (PDT)
Received: by ykfw73 with SMTP id w73so160138868ykf.3 for <tls@ietf.org>; Tue, 25 Aug 2015 08:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FxFIWfMbYEDJDLJmkmYXMx8lB8hGgZ8ih03UsMALzTs=; b=q1RqZrVTEvNOq7Gx9ouMcvU693/D0nm+9/bf/lnrtCi59T4XY9jLAvbAH5b6WtjSj1 khvum6PBWtKCaKWrp70PhVx07ZCMKi8+PW4V7DJvk5lr5I3hT1oAuxhGZsw1CqA6sLs4 A3YmDR8uNQMo7an75OKKqgIjOiana2z41UCQjMWZix8/X78Ja+ZhoWXZB484d4GU+77j kUamSuZqZC/a67lSU5G8q5uYBgj2nIcc15u9Eio4UixFJ6c/NUExpJI8ThLInAgtWilN BQb/Rqbvz10yEvnQzpDCa07tovphvV5baDL8QnjOGIt1jyWXlaUuakIsl8FDDSHfmKfr ly8Q==
MIME-Version: 1.0
X-Received: by 10.129.49.200 with SMTP id x191mr37757276ywx.56.1440516395397; Tue, 25 Aug 2015 08:26:35 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:26:35 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:26:35 -0700 (PDT)
In-Reply-To: <CAJU8_nVd7sV-=9g231c2fo0vun52BgJ5NOxkpBXQn+Z8-RNPqg@mail.gmail.com>
References: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com> <201508222028.46145.davemgarrett@gmail.com> <CA+cU71kS=x7_hVRXb8Q8m=DmqMaM65GaEn1SnzH_fQHP9mzyqA@mail.gmail.com> <201508250004.36291.davemgarrett@gmail.com> <CABkgnnX+S5De7pBC_VChz15daNcSpxgF6_ofxdPAv2vhpFigSg@mail.gmail.com> <CAJU8_nVd7sV-=9g231c2fo0vun52BgJ5NOxkpBXQn+Z8-RNPqg@mail.gmail.com>
Date: Tue, 25 Aug 2015 08:26:35 -0700
Message-ID: <CABkgnnVRKAB4tVZkH1Df8h9E_SQ2ZrukKYisfO_P0q71JQ+JgA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Kyle Rose <krose@krose.org>
Content-Type: multipart/alternative; boundary="001a1142196e0a7a42051e245c50"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gCAae9LV3-mbaQVIaTpECyHufgg>
Cc: tls@ietf.org
Subject: Re: [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 15:26:37 -0000

On Aug 25, 2015 7:26 AM, "Kyle Rose" <krose@krose.org> wrote:
>
> >>         uint16 length = TLSPlaintext.length;
> >
> > You can't recover the plaintext without knowing how long it is.  This
> > part at a minimum needs to be in the clear.  At which point you need
> > it to be based on TLSCiphertext.length
>
> Is that really true? You could decrypt the first block/few bytes to
> get the length (without authentication, of course) and then decrypt
> the remainder according to this candidate length. Then authenticate
> the entire record to make sure the candidate length was correct.

That depends on the aead - and the implementation. GCM can - maybe - be
broken apart that way*, but I can't think that going to all the trouble of
formulating an aead just to break it open at the first point that it
becomes inconvenient.

You could imagine an aead that made that difficult or impossible (just
reverse the order of the bytes...). Or, without imagining at all, you can
have hardware module that enforce authentication before releasing plaintext.