Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum <jacob@appelbaum.net> Tue, 01 December 2015 01:36 UTC

Return-Path: <jacob@appelbaum.net>
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 06EF71B35FE for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 17:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 EMKWexk8wypv for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 C787C1B35F9 for <tls@ietf.org>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: by ioir85 with SMTP id r85so194480779ioi.1 for <tls@ietf.org>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XcO2E/iCBmKlLtPsd6fWUphvd66Pc/vHttGguVDS/1ouWGRrqMFLP/c5FlITUqJS9L BZVwU0uJZrh16/nRwxxD+6tb0fRB/9h6PIbXPg3cjjDpGodVoZsPvxLSTudbCbz1TNFI KfMMjU+9h02Jne6aBFNygDgxMmceb5DSIGtW/8JIlyMjKsSjhFhHBM+mPCOF/e1zm0Co Wdx6wQsVq6VhkjBPxVvTDOlzwAD0OL869MHj4vvhmYimzMK3co6nMauvW538nGEKTpci hlnYpzvFu115wTgdugbwEuDzJ0QICyxS+cS6RnCBrap0oFSS6+IpY9UHD3ceimMT2Do2 AjPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XAJxWWLKfo3Tuc5/JhdBoVHZrOpsYrXCQT4d4FgynXRkymQvBrbrt9bD9ee1rXnfst Z23RjTcUgahA17lqtEUG6wRnRg1JCRFTpwyg38kvlapi2+h+ubEI+t9LbJhQmbPK3bMc 5z16NLfIAdVnY/9zJlTkUx+Fed+PN5lK3g8K8QecSM/x6PSyz64h9LnbVssIbyhYDj18 o2JkQNpYyfGb3GSh3FI2NIXY7TPnoXqnockp6Zh4g27t/az6NzdljCKlPFgDZs1TVl3h hpzClv5L+psTljxv70ZlLoL3ll71qBDSu9Tb1U4kdPDhx6P9KdVWQkSCivB1UL9mzMui zTyg==
X-Gm-Message-State: ALoCoQmLJZajq+zm864RXIYFPdTFz3mQxVoBf/C75bfLLIRfz/C3RRetnE/K9P8/mk8q3l1SP/Zd
MIME-Version: 1.0
X-Received: by 10.107.137.19 with SMTP id l19mr54263852iod.138.1448933787043; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: by 10.79.70.71 with HTTP; Mon, 30 Nov 2015 17:36:26 -0800 (PST)
X-Originating-IP: [192.42.116.16]
In-Reply-To: <20151201005609.GD18315@mournblade.imrryr.org>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org>
Date: Tue, 01 Dec 2015 01:36:26 +0000
Message-ID: <CAFggDF03fzyAw95Ka8NHtBGEcebAe3RCt5pRd3r8_nhBbR7oNw@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YBkqWZj4_mm3ypy-wQU1fnpugBA>
Subject: Re: [TLS] 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: Tue, 01 Dec 2015 01:36:29 -0000

On 12/1/15, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote:
>
>> Bryan A Ford <brynosaurus@gmail.com> writes:
>>
>> >It would work just as well and in exactly the same way if the AEAD is
>> >replaced with the traditional Encrypt-then-MAC construction, for
>> > example.
>>
>> No it wouldn't, unless the encrypt part is a stream cipher.  You're still
>> locked into using an AEAD stream cipher or the equivalent of an AEAD
>> stream
>> cipher built with encrypt+MAC.  It won't work with, for example, the OCB
>> AEAD
>> mode, or CBC + MAC.
>
> I think we should focus on what would get TLS 1.3 to be adopted:
>
>     * Reasonably implementable in libraries that support older
>       versions alongside TLS 1.3.
>

That doesn't change with Bryan's suggestion, I think.

>     * Interoperable in the field with various capital-intensive
>       middle boxen.

Which would those be? And what is the definition of capital-intensive
for those watching on the sidelines?

>
> This suggests focusing on solidifying the core protocol, and a
> healthy dose of skepticism around bells and whistles.  If the
> protocol is overloaded with too many (alright even more) incompatible
> innovations, the net effect is likely less security due to
> substantially delayed deployment of the key improvements.

This seems borderline absurd. The TLS protocol is doing a major
version revision.

> Encrypting message lengths looks rather marginal from this perspective,
> and quite likely to hinder interoperability and delay both
> implementation and upgrades.  However cool an idea this might be,
> this does not look to me like the right time to add this feature
> to TLS.

I don't think it will hinder interoperability and not one person has
even named a single device that would have issues with it. I think the
only thing that comes close is when I've named a classified US
government surveillance program (XKeyscore) that would probably have
trouble with it.

We should add Bryan's feature and not pander to non-specific concerns
about middleboxes that should be considered as adversaries.

>
> At this point, TLS 1.3 is rather feature rich, and it is I think
> time to focus on reviewing the already agreed changes (maybe even
> drop some if they look inessential).  Make it solid, trim the fat,
> get it out the door in a usable form.

That is part of what is happening in Bryan's suggestion. He found a
reasonably practical way to encrypt record headers. His suggestion
will make TLS more secure. His suggestion includes a review of a part
of the previous state of TLS 1.3 with a proposed improvement.

No one is debating it on the cryptographic merits which is surprising.

All the best,
Jacob