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

Jacob Appelbaum <jacob@appelbaum.net> Thu, 03 December 2015 11: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 D30531B33D4 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 03:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6] 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 B5bXhibPWAZj for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 03:36:42 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 433C21A884B for <tls@ietf.org>; Thu, 3 Dec 2015 03:36:42 -0800 (PST)
Received: by igcmv3 with SMTP id mv3so10846511igc.0 for <tls@ietf.org>; Thu, 03 Dec 2015 03:36:41 -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 :cc:content-type:content-transfer-encoding; bh=lOIBJkHWTIsN/ISeuVRdbgHfpNRMmiUSXW79q3OgQck=; b=ka6CS7YpebaJuEIYHzKCSn/XrtpxDMH9KveU36kIIaYumtZElB6UwfSNMoG/ucHnMX DrCCmoXNE3Lz9DEvAtkVyiUn2TkIwg0LjUsIsPE3SU3FeTnhDJ+EXPoXhiOR2ESmsPtf ZOml18xTv7fhM1htdzO/GHh6OONDdMOhXiRag8Ixw01DZgydfOnC29h8XBEszeAR/PUO bTffMfP9a7XsYOHFF3i2nLam6JSqQF6a5F6K5ZYJNZpslPe/BeE4fFQZPLqcxSdlYPgb aDXBrFZiq+897aONtfDCjQZxZuYFviZesmjZxgjvNs/5jWdOZg1898r3NpoYdkPvNias +6Xw==
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:cc:content-type :content-transfer-encoding; bh=lOIBJkHWTIsN/ISeuVRdbgHfpNRMmiUSXW79q3OgQck=; b=EdENe5mO7E8sqnmid3YUGp5Sy8OQpM0L0tR0NssHZyQkWPUnB8V24c+zcGWFDnDu7y 3fvU1nwmCXff9su8tNzsJ5WrtIUgjpWcuSZtM3kXfkcNhRDukk0Qtk6PKSFDlYBuT1Ii y5sd/61uNqSYhgrXQ7sIbV3yWFtv3mF6zbShXBlrcQ9OQmDZW9Lpjj63sfD6HzgMZ5H9 sCD6/6bxnqklhbKvISCnjY5tL9i3UFhFL9/cSgup524p7N+coty8oltsyvIGgQz3jX71 TSeNp2vHdeaKZNW8cxrtF98LoXjtISxzzmxzziulb5wvSPtG1LdnvEg1Ka7QfGZM2oPs 4t4Q==
X-Gm-Message-State: ALoCoQmLcguOS1v5OdQygKBQes3Lo0JSD+aLM8bVG9K19rnfjWl436EFyVpp624Bs17ITuZHTAqI
MIME-Version: 1.0
X-Received: by 10.50.143.12 with SMTP id sa12mr5931181igb.82.1449142601490; Thu, 03 Dec 2015 03:36:41 -0800 (PST)
Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 03:36:40 -0800 (PST)
X-Originating-IP: [193.171.202.150]
In-Reply-To: <CABcZeBP2eyncPVkRMMbBk7ysco++-E9oiiu7JHOjs73wS=R5og@mail.gmail.com>
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> <CABcZeBP2eyncPVkRMMbBk7ysco++-E9oiiu7JHOjs73wS=R5og@mail.gmail.com>
Date: Thu, 03 Dec 2015 11:36:40 +0000
Message-ID: <CAFggDF17f4N=+x9hf1RFFjwcnG9j2XKLia659KUuFmXVhsDZKg@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GiRXJFGisQATpfrOw1e6haQ9O0Y>
Cc: "tls@ietf.org" <tls@ietf.org>
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 11:36:47 -0000

On 12/2/15, Eric Rescorla <ekr@rtfm.com> wrote:
> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum <jacob@appelbaum.net>
> wrote:
>
>> On 12/2/15, Eric Rescorla <ekr@rtfm.com> wrote:
>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <brynosaurus@gmail.com>
>> wrote:
>> >
>> >> On 02 Dec 2015, at 06:02, Martin Thomson <martin.thomson@gmail.com>
>> >> wrote:
>> >> > On 1 December 2015 at 08:22, Bryan A Ford <brynosaurus@gmail.com>
>> >> > wrote:
>> >> >> The 2-byte length field in each record's header no longer indicates
>> >> >> the length of the *current* record but instead indicates the length
>> of
>> >> >> the *next* record.
>> >> >
>> >> > Ensuring that you know the length of the *next* record is difficult
>> >> > and could dramatically degrade latency, or adding extra bogus
>> >> > padding
>> >> > or extra bogus records.  For instance, I can always send in bursts
>> >> > of
>> >> > two packets, a one octet packet that promises the remainder of the
>> >> > burst and one that promises a single octet packet.  At that point, I
>> >> > get to do what I've always done and you have gained little other
>> >> > than
>> >> > an increase in packet size of around 19 octets (best case).
>> >>
>> >> That type of inefficiency is extremely easy to avoid; please read the
>> >> rest
>> >> of my proposal where I discussed exactly that at length.  Yes, a
>> >> particularly stupid implementation could send everything in bursts of
>> two
>> >> packets, but it’s ridiculously easy for a slightly smarter
>> implementation
>> >> to avoid doing that.  And what you’ve gained is complete encryption
>> >> and
>> >> integrity-checking of the whole TLS record before any part is
>> >> interpreted,
>> >> which seems like a nontrivial security improvement.
>> >
>> >
>> > 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.
>
>
> Wouldn't that benefit be equally achieved by simply padding all records
> to a fixed length? You could do this with no protocol change and, as I
> said, it's far easier for the implementation.
>

Padding is potentially useful but has two issues that come to mind
which are both non-issues in most cases. The first is the economic
cost for extra bytes and the second is the security of the padding
scheme.

Padding strategies are a complement super encryption but probably not
a replacement. Padding protects against one set of attackers (bean
counters) and super encryption provides confidentiality against
another set of attackers (GPA/APA).

>> > [0] This issue doesn't apply to DTLS because the stack will just move
>> onto
>> > the next UDP datagram.
>>
>> An off-path attacker can't do much with DTLS, if designed correctly.
>> Especially if they only see some packets - they'd only get the UDP
>> headers and then the rest should be uniformly distributed random data,
>> no?
>
>
> DTLS records do in fact contain a length field because it's possible to
> pack >1 record into a single UDP datagram. In practice, I think that
> most stacks do 1:1 except perhaps during the handshake. They also
> contain a sequence number to aid in reconstruction (important
> in this case because TLS 1.3 uses the sequence number to
> form the AEAD nonce).
>
> However, as you suggest, an attacker can't DoS DTLS connections by
> injecting a small number of packets because the DTLS stack will just
> reject bogus packets.

This alone makes me think that DTLS with encrypted record headers is
going to be a killer feature. Especially if an implementation rotates
over ip:port and keeps sessions open even as clients move between
networks. We'll hopefully see clients keyex on one network and keep a
session open as they move to another network. That would make
interception or attacking that client very difficult for an off-path
partial view attacker, as well as very difficult even for a fully
on-path mitm. The downside is that it won't compose very well with
existing anonymity systems. The other other upside is that those
systems can use this mode in the future for client -> network, inter
network communication and network -> everywhere communications.

All the best,
Jacob