Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 01 November 2016 20:36 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EA61299EE for <dns-privacy@ietfa.amsl.com>; Tue, 1 Nov 2016 13:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 X8W2fHJMC6Cy for <dns-privacy@ietfa.amsl.com>; Tue, 1 Nov 2016 13:36:00 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4421294D8 for <dns-privacy@ietf.org>; Tue, 1 Nov 2016 13:36:00 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5B812F98C; Tue, 1 Nov 2016 16:35:59 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 9285B1FFA0; Tue, 1 Nov 2016 16:35:46 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Hugo Connery <hmco@env.dtu.dk>, Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>, dns-privacy@ietf.org
In-Reply-To: <1477998568.4843.13.camel@env.dtu.dk>
References: <CAHXf=0p+Afhs27SQraupwyF4DO9on4a3aJKJ_B7Gc+gHzBmqtQ@mail.gmail.com> <1477998568.4843.13.camel@env.dtu.dk>
Date: Tue, 01 Nov 2016 16:35:43 -0400
Message-ID: <874m3r3pls.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Po9uk6pb1UyvJgNAHvdtPe9RJUA>
Subject: Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 20:36:02 -0000

Thanks for
https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00,
Alex!

On Tue 2016-11-01 07:09:28 -0400, Hugo Connery wrote:
> The list of strategies looks great.  Perhaps you could mention
> the "pad the message to the maximum possible message length"
> explicitly as a sub-case of "Block Length Padding".

The draft does mention "the maximum message length as dictated by
protocol negotiations" in the "General Guidance" section, but doesn't
make it an explicit padding option, or spell out what it is.  if you're
going to talk about "maximum possible message length" then it becomes
necessary to think about that here.

Note that the limits are different depending on whether you're using UDP
(DTLS) or TCP (TLS), and that the UDP limit depends on the underlying
MTU, which servers might not know.  the length limit over TCP (TLS)
connections is arguably bounded by either the size of the DNS query (16
bits?) or the TLS record boundary (2^14 + 1024, see
https://tools.ietf.org/html/rfc5246#page-21).

It might be worthwhile to have some discussion about choosing packet
size of the (D)TLS cleartext vs. packet size of the TLS ciphertext,
since those can be different values.

In implementations i've done, it's often much easier to pad the
cleartext to a fixed size, and to ensure that the security
considerations of https://tools.ietf.org/html/rfc7830#section-6 are
followed and that TLS compression is *off*.

Bob Harold wrote:

> Yes, I hope that the final document specifies all options, including
> the bad ones, and provides clear descriptions about the trade-offs
> involved.

I'm not convinced that documenting all possible patterns, including the
bad ones is a great strategy for a standards-track document.  I'd much
rather this document pick a single strategy, endorse it clearly, and
maybe at most include a mention of a few other strategies and why those
strategies are not recommended.

We want to make things *easier* for implementers, not harder.

fwiw, i'm puzzled by the claim that "Random Length Padding [...] is (at
first glance) the best strategy".  At first glance, i am not necessarily
convinced of this -- i found "block length padding" to be the easiest
and most understandable strategy when implementing.

(I'm also not convinced that a well-seeded, efficient CSPRNG would be
any sort of noticable hindrance to a server doing DNS-over-TLS at
wirespeed, but it's simply not necessary for block-length padding)

One missing proposal is "power of two padding" -- pad up to the nearest
power of two, with some minimum.  For example, pad up to 128 octets, and
then pad to 256 octets, 512 octets, 1024 octets, etc.

What would be really great (not as a standards draft, but as a regular
study) would be to frame the problem as an adversarial analysis "game",
taking samples of real-world DNS traffic, and see what can be inferred
From each of these strategies.  That might help to quantify the
differences between the schemes.

            --dkg

PS you've got RFC 7803 where you mean RFC 7830