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
- [dns-privacy] Spencer Dawkins' Yes on draft-ietf-… Spencer Dawkins
- Re: [dns-privacy] Spencer Dawkins' Yes on draft-i… Shane Kerr
- Re: [dns-privacy] Spencer Dawkins' Yes on draft-i… Tim Wicinski
- Re: [dns-privacy] Spencer Dawkins' Yes on draft-i… Spencer Dawkins at IETF