Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Bryan A Ford <brynosaurus@gmail.com> Thu, 03 December 2015 08:50 UTC

Return-Path: <brynosaurus@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 1F8F81B32CA for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 00:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWGMmgvXJdWL for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 00:50:11 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 DF8291A1BDD for <tls@ietf.org>; Thu, 3 Dec 2015 00:50:10 -0800 (PST)
Received: by wmuu63 with SMTP id u63so11444058wmu.0 for <tls@ietf.org>; Thu, 03 Dec 2015 00:50:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=xMGInjA5CwnGqBrH+EJdrzPP8qDZSW3Na0krpczpaDU=; b=Hi325vi2YNZZnrLjJnLFA6pa9z7gYTYxIDQNCLQnYBI5V3RzTStlZILcWPZRzg8yea BSVuHifNuLAj4d47pEOpFbtJT2hPDFxaCQG1U+WdSbn18mBty4dfxsSDJlWw3J7Mob1k Ln566XVTlZVJ9r5IqX5O8GsGCZyiUORmFKFCjAfn1MHTwsHuWJaimRW8ps62BiIdFLnL pHNCRGYfstm035A0KmUViZhHLDOQbye4d5Jh4xkKYokhzmrN/ZYsANtMJnqJsoMIn16Z 0orGTCq+j6ojGsYIMboM9UVarFO+TfFJHrN8jWPwVyzweYuC0GBCtoxowcuTRbU54o74 HdCQ==
X-Received: by 10.194.249.97 with SMTP id yt1mr10127970wjc.89.1449132609270; Thu, 03 Dec 2015 00:50:09 -0800 (PST)
Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id jt9sm6535380wjc.24.2015.12.03.00.50.07 for <tls@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 00:50:07 -0800 (PST)
To: tls@ietf.org
References: <56586A2F.1070703@gmail.com> <FB2973EF-F16C-404A-980D-CA0042EC4AEB@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <CABkgnnUoyVPC5QVc=ErzAm6DR8usjBw5scc==o4=-XaBoK5AWQ@mail.gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> <CABcZeBMuSeis6KNQ-D_ZAfKmWb7Ts_Lq=QM0z6YWVSSUwueZmg@mail.gmail.com> <CAFggDF1SHzU_w30Rk469G2ypTx-pRVsFexv9JHSQdAMJTf5xLQ@mail.gmail.com> <CACsn0c=F5PUcXu=Sw5eubeZspaj_jGn3ohuryGMrjwW=e=wvaQ@mail.gmail.com>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56600243.2010308@gmail.com>
Date: Thu, 03 Dec 2015 09:50:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CACsn0c=F5PUcXu=Sw5eubeZspaj_jGn3ohuryGMrjwW=e=wvaQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070900040107050009020609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ulnZQZIjQ2WsJaSEy2XgRoGCeT4>
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
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: Thu, 03 Dec 2015 08:50:13 -0000

On 12/2/15 4:45 PM, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
>> On 12/2/15, Eric Rescorla <ekr@rtfm.com> wrote:
>>> It's not really clear to me what the anti-traffic-analysis benefit of your
>>> proposal
>>> is over and above just padding everything to a fixed size. That's certainly
>>> far
>>> easier for the implementation to do, especially in typical stacks where the
>>> application just calls SSL_Write (or whatever) and so there's no obvious
>>> API point to provide the "next length", so as a practical matter the stack
>>> will very often if not always be in "last block" mode.
>>>
>>
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
> 
> What's a "static distinguisher"? Padding solves this problem as well,
> but it also solves problems resulting from TCP segmentation down the
> stack, which header encryption doesn't. What does header encryption
> offer that padding does not?

Once again (for the n'th time in this thread):  Padding is great and we
should encourage implementations to do it, but it may be impractical to
mandate (a) that *every* TLS 1.3 implementation use padding all the
time, and (b) that *every* implementation that does use padding uses the
*same* padded record size as every other TLS implementation.

If TLS 1.3 did mandate that all implementations always pad to the same
standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM!
:) ), then it might be arguably the case that encrypting headers
wouldn't add any further benefit.

But short of that, encrypting TLS headers makes it strictly harder for a
passive adversary - or an active adversary who can only inject but not
block traffic - to distinguish between padded or unpadded TLS 1.3
streams, or to distinguish between TLS 1.3 streams padded to different
block sizes.

In particular, with encrypted records, we get a guarantee that nothing
in the transmitted TCP stream content itself leaks information about the
internal pattern of records, even if it's un-padded or differently
padded from other streams.  The attacker has to use other side-channels
to perform such distinguishing attacks, and other side-channels are
often lower-bandwidth (e.g., the total length of whole streams or bursts
rather than individual records), and/or more noisy (e.g., the lengths
and timings of TCP segments, which may get retimed and/or resegmented by
all sorts of activities both at the endpoints and in the network).

B

> 
> Sincerely,
> Watson
>