Re: [dns-privacy] Spencer Dawkins' Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

Shane Kerr <shane@time-travellers.org> Tue, 01 March 2016 10:39 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42FE1B3F11; Tue, 1 Mar 2016 02:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 8W489ArOMNYq; Tue, 1 Mar 2016 02:39:50 -0800 (PST)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8234D1B3F10; Tue, 1 Mar 2016 02:39:49 -0800 (PST)
Received: from [2001:67c:2e8:13:224:9bff:fe13:3a9c] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1aahiS-00048K-Sl; Tue, 01 Mar 2016 10:39:44 +0000
Date: Tue, 01 Mar 2016 11:39:40 +0100
From: Shane Kerr <shane@time-travellers.org>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Message-ID: <20160301113940.518dc7f9@pallas.home.time-travellers.org>
In-Reply-To: <20160301043834.28800.4700.idtracker@ietfa.amsl.com>
References: <20160301043834.28800.4700.idtracker@ietfa.amsl.com>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/IWF_V2Ux-CSukRCDWuBlAjyP8ok>
Cc: tjw.ietf@gmail.com, draft-ietf-dprive-edns0-padding@ietf.org, dns-privacy@ietf.org, The IESG <iesg@ietf.org>, dprive-chairs@ietf.org
Subject: Re: [dns-privacy] Spencer Dawkins' Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
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 Mar 2016 10:39:52 -0000

Spencer,

At 2016-02-29 20:38:34 -0800
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> wrote:
> Thanks for producing this draft. I do have one question about this text:
> 
>    The PADDING octets SHOULD be set to 0x00.  Other values MAY be used;
>    for example, in cases where there is a concern that the padded
>    message could be subject to compression before encryption.  PADDING
>    octets of any value MUST be accepted in messages received.
> 
> I'm not entirely sure I understand the point of "SHOULD be set to 0x00".
> I'm not questioning the SHOULD (you explain why choosing another value
> would be a good idea, thank you ), but I'm wondering why there's a
> normative requirement at all. 
> 
> I was trying to guess, and one hypothesis was that if the padding is
> consistently 0x00, it's less likely to provide a covert channel (or at
> least you'd be more likely to notice packets using different padding),
> but the security considerations section didn't mention that, so I'm still
> lost.
> 
> If there's a reason to zero the padding bytes in the uncompressed case, a
> sentence of explanation might be useful.

There was a lot of discussion on the list about this very topic,
actually. I'm not sure if it can be reduced to a sentence or two.

IIRC, the idea is that we should recommend some value there to give
guidance for implementors to avoid common mistakes (such as using
uninitialized memory, which might contain left-over values).

Someone did raise the possibility of having a covert channel, but it
was recognized that there are so many places for putting covert data
into DNS that this is not really a concern. For example, one could
simply use any unregistered EDNS(0) option and stick data in there, or
encode it into the QNAME, or put values in the query ID, or...

Putting random data in the padding was considered, but it did not seem
to add any real value beyond zero-padding.

Cheers,

--
Shane "not an editor on the draft" Kerr