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
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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. =C2=A0Perhaps 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=20each 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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJYGPyfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy
NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKK20QAJ23cTme8GliQIft/Ld3/0JJ
2O2HMdZubamK1AAXoKF5bFhjHdsxOQG3/NnSSZtw4PNpFZ8tyzAAe8mZAyS2Lfh5
CpWmYKX6H1I7GJxUWXcA0MIuEulWrhgDtooTYL+2djY2nw2rcHOL8kP8+dtVHOzY
TFQr9csBJ/3QjDiLdn2P+qJtT/nYG7OcDLPBdybToPB7kh356mcKlYm/F7Q6CGL4
rQSkp2MLNijstIXFQPToTo/lujAlZotfNW2TvWUmlFbSoeB3otTz3EyiQBlvQixu
diJc8xVnXSk+Slyqpxaqvpi7/cIPUHbtSUS89iiBsptTMZI5uwy2fLjtJ5UwBBdQ
uTg4GcfrBbMlxdCH5g1oA/pxHb89yVe5bNxOyGWHtrPrf0EWjJ+ToNWz73KIKt6h
uiFeJDSO71lOPZpEs6aYsV8G1IfAAf/nD1UTpwQUmxy3QfMb29JQMYVQTWJJyiCI
DHlJTjt6hnDr3i9aZip+1rc/yTgUU9ahzxkjGIWuZC9zwcuOMhWDmliav7v7Msyd
bptCCqGVvxIqg3Fk7yTKqpBrEJkGOYaSn6yQBqUyvEb1PNeJx/GTs+TKi4glO+kA
7XELZ1mXFdKYk0OjSKW672xHAXAaMxbE0HRoT2bF18yKfU6hq0WoW4Gz64FR0FCX
o493sw45bEezYlgsDlew
=6Nfo
-----END PGP SIGNATURE-----
--=-=-=--