IETF Logo Mail Archive

Re: [dns-privacy] draft-mayrhofer-edns0-padding

Mark Andrews <marka@isc.org> Fri, 24 July 2015 03:02 UTC

Return-Path: <marka@isc.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 449491ACEA6; Thu, 23 Jul 2015 20:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9N-iydmA1rKl; Thu, 23 Jul 2015 20:01:58 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55301ACE98; Thu, 23 Jul 2015 20:01:58 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 4ACDE3493BA; Fri, 24 Jul 2015 03:01:55 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 13D2516005B; Fri, 24 Jul 2015 03:02:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F25CD16005C; Fri, 24 Jul 2015 03:02:52 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LetLGI1nNqRJ; Fri, 24 Jul 2015 03:02:52 +0000 (UTC)
Received: from rock.dv.isc.org (89.100.broadband6.iol.cz [88.101.100.89]) by zmx1.isc.org (Postfix) with ESMTPSA id E9FDF16005B; Fri, 24 Jul 2015 03:02:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 99E3933AD26C; Fri, 24 Jul 2015 13:01:48 +1000 (EST)
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
From: Mark Andrews <marka@isc.org>
References: <19F54F2956911544A32543B8A9BDE0754689AF17@NICS-EXCH2.sbg.nic.at> <87a8umihra.fsf@alice.fifthhorseman.net>
In-reply-to: Your message of "Fri, 24 Jul 2015 01:19:53 +0200." <87a8umihra.fsf@alice.fifthhorseman.net>
Date: Fri, 24 Jul 2015 13:01:48 +1000
Message-Id: <20150724030148.99E3933AD26C@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/yX3ZeeeivfeBB3HLLz4qDGgT2tE>
Cc: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [dns-privacy] draft-mayrhofer-edns0-padding
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: Fri, 24 Jul 2015 03:02:00 -0000

This can be dropped.  EDNS aware clients are required to ignore unknown EDNS options.

   A server MUST use the 'Padding' option in a DNS response (QR=1) only
   when that response correlates to a query that contained the 'Padding'
   option.

For QUERY I would be padding the request out to 400 octets.  This allows for
all legal query names (max question size is 255+2+2 octets), some EDNS options
and the pad option.

Mark

In message <87a8umihra.fsf@alice.fifthhorseman.net>, Daniel Kahn Gillmor writes:
> On Thu 2015-07-23 18:50:14 +0200, Alexander Mayrhofer wrote:
> 
> > I had a discussion with Daniel Khan Gillmor today, and we talked about
> > his proposal to specify a padding option in TLS so that message-size
> > based correlation attacks on encrypted DNS packets could be
> > prevented. We continued discussing other options (such as "artificial"
> > RRs in the additional section), and I floated the idea that we could
> > use EDNS0 to include padding in DNS packets.
> >
> > So, I've created a quick-and-dirty strawman proposal draft for this
> > idea, and i'm happy to discuss this during tomorrow's DPRIVE session
> > if we have time:
> >
> > https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt
> 
> wow, thanks for the incredibly quick writeup!
> 
> I think this draft could have an informative reference to Haya Shulman's
> research on difficulties in DNS encryption, which won the recent ANRP:
> 
>   https://irtf.org/anrp
>   https://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf
> 
> Section 3.2.2 shows that her mechanism for inferring the contents of
> queries becomes *even more effective* by including the size of the
> packets in her analysis.  (Everyone working on dprive should read this
> paper to get a sense of some of the massive difficulties we need to
> consider because of the structure of DNS traffic analysis; just
> encrypting the traffic is insufficient for several reasons)
> 
> I also note that draft-mayrhofer-edns0-padding curently suggests that
> the minimum padding size is 1 octet.  Is there any reason to avoid a
> padding size of 0? 
> 
>         --dkg
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email