From fanf2@hermes.cam.ac.uk Fri Nov 1 03:19:36 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF5511E811B; Fri, 1 Nov 2013 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaastaGYQhxU; Fri, 1 Nov 2013 03:19:35 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE8811E8113; Fri, 1 Nov 2013 03:19:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-144-165-142.range86-144.btcentralplus.com ([86.144.165.142]:50302 helo=[192.168.1.66]) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1VcBm8-0001fG-gz (Exim 4.80_167-5a66dd3) (return-path ); Fri, 01 Nov 2013 10:16:20 +0000 References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <52734A38.9060708@necom830.hpcl.titech.ac.jp> <20131101063552.GB76903@isc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20131101063552.GB76903@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11A501) From: Tony Finch Date: Fri, 1 Nov 2013 10:16:16 +0000 To: Evan Hunt Sender: Tony Finch Cc: Andrew Sullivan , "DNSOP@ietf.org" , "dnsext@ietf.org" Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:19:36 -0000 > On 1 Nov 2013, at 06:35, Evan Hunt wrote: >=20 >> On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote: >> TLS is another PKI and is inherently insecure as CAs can be >> compromised. >=20 > True, but Tony's quorum-based approach could be made exhaustive enough > that the adversary would have to have compromised *every* CA. If they > can do that, I'm not sure any realistic defense is possible anyway. Right. At the moment the code is just trying different host names. This deal= s with compromised server certs OK, but is not enough for compromised CA cer= ts. So the quorum needs to be counted in terms of different CAs. The usual way for TLS MitM attacks to work is by installing a malicious cert= in the user's CA store. I think I have heard of malware doing this, and TLS= interceptors usually require corporations to enforce self-abuse of this kin= d on their desktop systems. In this situation the attacker can trivially foo= l tlsdate. But not if you check that you got the time from several different= hosts authenticated by different CAs. The next question is how feasible it would be for an adversary to mount a Sy= bil attack on your CA store. That probably requires complete pwnage at which= point getting the right time is the least of your problems. Tony. -- f.anthony.n.finch http://dotat.at/= From gih902@gmail.com Fri Nov 1 07:48:14 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2306711E811A for ; Fri, 1 Nov 2013 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvXrpDggjWWV for ; Fri, 1 Nov 2013 07:48:13 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 811BC11E831F for ; Fri, 1 Nov 2013 07:48:10 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id w10so3954216pde.30 for ; Fri, 01 Nov 2013 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RCHVZtEwEvRNWR9reskcjrrRX6Kgsg7fsXsWLrwJTfA=; b=HLToP++vukMEa2E1ml7pL9yNZUqwRiDAyHxQOv1KKFF5uJ0c43Xgx4KuDI1pFosQgg T3/KVa5c1c829r9ys7weqmPismYVrfNOrDvCf/NmGU11urQp/+dcGR9Yg6pSxL8QluTh 5Qpny63w2wcViFraPE1XmC2D2Pw0VhT82GV/7QXzV89JpeR7Ps4E71YfA1Df9KU/oKOD V5YDXMWaFPGQ04189eDQpMyDFUdZd+0Lgc/mfyDv8ydU9SY7ulqITkj/yLtbGF9K2Yri ZUsyhszwHAu+pcidf36hGD3dFj3SmJk96vMDk1GBNn5mJQNLUIAKp6qQasBex7BYcb9d yVTg== X-Received: by 10.68.223.131 with SMTP id qu3mr3618732pbc.4.1383317290249; Fri, 01 Nov 2013 07:48:10 -0700 (PDT) Received: from [192.168.6.113] (ip-64-134-235-126.public.wayport.net. [64.134.235.126]) by mx.google.com with ESMTPSA id tu6sm11242054pbc.41.2013.11.01.07.48.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 07:48:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Geoff Huston In-Reply-To: <5359785363432515507@unknownmsgid> Date: Sat, 2 Nov 2013 01:47:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <308D6D2A-C638-48B3-B361-19BBC8883E16@gmail.com> References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> <5359785363432515507@unknownmsgid> To: Joe Abley X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Fri, 01 Nov 2013 07:49:19 -0700 Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in draft-wouters-edns-tcp-chain-query-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:48:14 -0000 On 1 Nov 2013, at 11:38 am, Joe Abley wrote: > On Oct 31, 2013, at 9:17, Ray Bellis = wrote: >=20 >>=20 >>> On 31 Oct 2013, at 13:03, Olaf Kolkman wrote: >>>=20 >>> I am not sure if there are clients out there that get all nauseous = from OPT RRs in the responses >>=20 >> There are bound to be - I've certainly seen CPE that get nauseous = (FORMERR) with OPT RRs in the request, and I've no reason to believe = they wouldn't do just the same for an unsolicited OPT RR in the = response. >=20 > Geoff and George to the courtesy phone! It's a testable / measureable hypothesis. Geoff From nweaver@icsi.berkeley.edu Fri Nov 1 07:52:31 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E88621E837A for ; Fri, 1 Nov 2013 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFiNPzeNzd1m for ; Fri, 1 Nov 2013 07:52:26 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 41E2E21E821A for ; Fri, 1 Nov 2013 07:52:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 18F1A2C4005; Fri, 1 Nov 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TFl4Zyzpk83f; Fri, 1 Nov 2013 07:52:24 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B91F42C400F; Fri, 1 Nov 2013 07:52:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9DCBA479-5180-40EF-8F07-F3ED3B703C0B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <308D6D2A-C638-48B3-B361-19BBC8883E16@gmail.com> Date: Fri, 1 Nov 2013 07:52:24 -0700 Message-Id: <6A7BB2E4-C068-4349-950A-40555DEEA37B@icsi.berkeley.edu> References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> <5359785363432515507@unknownmsgid> <308D6D2A-C638-48B3-B361-19BBC8883E16@gmail.com> To: Geoff Huston X-Mailer: Apple Mail (2.1510) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in draft-wouters-edns-tcp-chain-query-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:52:31 -0000 --Apple-Mail=_9DCBA479-5180-40EF-8F07-F3ED3B703C0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 1, 2013, at 7:47 AM, Geoff Huston wrote: >>> There are bound to be - I've certainly seen CPE that get nauseous = (FORMERR) with OPT RRs in the request, and I've no reason to believe = they wouldn't do just the same for an unsolicited OPT RR in the = response. >>=20 >> Geoff and George to the courtesy phone! >=20 > It's a testable / measureable hypothesis. The question is "Is the CPE bypassable?". So much of it is insanely = broken on the forwarding resolver side it isn't funny, but if you can = get around it, things are OK. Unfortunately, for networks like hotspots etc that's often not possible, = as we've seen in Netalyzr. =20 ObAdvertisement: We now also have Netalyzr on Android, so we should get = some cellphone network and more hotspot-type information. If you use an = Android phone, download it and run it... -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_9DCBA479-5180-40EF-8F07-F3ED3B703C0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSc8AoAAoJEG2B1w+SDi/uCpEP/0a8EVWKpJ5KM/sgVBML+6ef rxXUAFNDEUSUqNdhoM3Yg4oJ+5/sSAp+nc4I7X3lXnjp5dQxCf7Bt8p89fr/2foP w0ryLKSdN7HvLFpuXDdBeX90QATZym9bAthjieXp4X9ifpbnhddwn7Xtp6vhVgBY RSF4atFlMfLbbsN6oTWTLznNSwvT31SnirRHMxrgMiJXJl/L0NDt678vjMNMQlbP 64oJxigVK9IMkavR06cNmLiUkRJDqSobxA9dJYBKsbjHXl5aJfQlfqeTj5dHJ6G+ +kP0x5fsnovDSOUGoBSEzeO6vwIax9ndMayKOTIBVLgWEQjAJDnZxWKgw3qII8yY AQAAs7h/uZU8sOX0bnAx8qdgMoObIsJWKa38ig5AxCNQCrhC49LRVIpxiOYYwiYk mZRqoHPlhZ1iphNNUBG/Agld8LuGoA6nvcia8veulpjhF2rtvXL9CfwSnKvAdBlk nLmfY0LwrcOhfXki8idANpanBgxV8yYY3sV1HIfUn45ajqpX/GTfkKaNdusXstkQ dTzYZNczOccp4aOpTF2t9J1jO4liHBn8OHquO2MJMCS0zVCFAXDSgOpiDdJnk/qK pHYWOssz8Fp+4CZHFVLH7qnf7yHi3oecgSrJ84RJfyCIX8hi5h8W7E5hTj8GgSym erBZAoOzbQpY79U+/l61 =2cob -----END PGP SIGNATURE----- --Apple-Mail=_9DCBA479-5180-40EF-8F07-F3ED3B703C0B-- From derek@ihtfp.com Fri Nov 1 07:57:19 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CBA11E8391; Fri, 1 Nov 2013 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcwpCLMa7fIc; Fri, 1 Nov 2013 07:57:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8411E83A1; Fri, 1 Nov 2013 07:57:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1D5DD2602BA; Fri, 1 Nov 2013 10:57:09 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26039-05; Fri, 1 Nov 2013 10:57:03 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id A35A62600B9; Fri, 1 Nov 2013 10:57:03 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id rA1Ev15V029286; Fri, 1 Nov 2013 10:57:01 -0400 From: Derek Atkins To: Masataka Ohta References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> <52734CB0.60506@necom830.hpcl.titech.ac.jp> Date: Fri, 01 Nov 2013 10:57:00 -0400 In-Reply-To: <52734CB0.60506@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Fri, 01 Nov 2013 15:39:44 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Fri, 01 Nov 2013 08:02:07 -0700 Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:57:19 -0000 Masataka Ohta writes: > Hi, Hosnieh, > >> Do you think it will be relevant to this document or it can be >> another informational document only discuss about the >> vulnerabilities of cryptographic algorithms? > > As I said, it is a known vulnerability. That is, we don't > need a generic new document very much. > > However, Snowden taught us that we must avoid any fancy > cryptography strongly promoted by NIST, including all the > EC related ones, which may be documented somewhere. It is unclear to me that ECC as a generic technology is bad, although any specific curves creates by NIST/NSA are certainly suspect. Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash, Public Key, or Cipher algorithm, and we don't use it in DNS for anything, AFAIK. > Masataka Ohta -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nweaver@icsi.berkeley.edu Fri Nov 1 08:18:54 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4331811E8212; Fri, 1 Nov 2013 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as9hxv7kBGBR; Fri, 1 Nov 2013 08:18:49 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77811E817D; Fri, 1 Nov 2013 08:18:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C75592C4017; Fri, 1 Nov 2013 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LTX7CWhhVKwD; Fri, 1 Nov 2013 08:18:44 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E64C82C4012; Fri, 1 Nov 2013 08:18:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_07A9B152-6CD0-4BA5-95B0-5178AF93A36C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 1 Nov 2013 08:18:44 -0700 Message-Id: <0536EF5D-7567-45B8-851A-A696B6DBB235@icsi.berkeley.edu> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> <52734CB0.60506@necom830.hpcl.titech.ac.jp> To: Derek Atkins X-Mailer: Apple Mail (2.1510) Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:18:54 -0000 --Apple-Mail=_07A9B152-6CD0-4BA5-95B0-5178AF93A36C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 1, 2013, at 7:57 AM, Derek Atkins wrote: > It is unclear to me that ECC as a generic technology is bad, although > any specific curves creates by NIST/NSA are certainly suspect. >=20 > Having said that, Dual-EC-DRBG is a Random Number Generator, not a = Hash, > Public Key, or Cipher algorithm, and we don't use it in DNS for > anything, AFAIK. Random Number Generators are used to generate the key material, since = bare entropy is often not enough, so you use your entropy pool to seed a = pRNG. Bind, for example, ends up using OpenSSL. Certified versions of OpenSSL do have Dual_EC_DRBG, although its not by = default (or is it?).=20 The threat is probably a lot less, however, since everything else signed = in DNSSEC-land is deterministic, and even if Dual_EC_DRBG was used, = hopefully the raw stream doesn't leak (the backdoor requires seeing some = of the random output to make it predictable). -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_07A9B152-6CD0-4BA5-95B0-5178AF93A36C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSc8ZUAAoJEG2B1w+SDi/uSwcQAMrDARLhdnfHUK8+ubA7xmxA v6ZaNGiBI8UPa350x4t8yT/gixKaxonVanf7iCoqjJDG5AhXDA9MIJaMZXnaVy6D vP20y2OMn+IfyJCsnpTdbU6KfbCpZ3W3LieqAD4QKPj0kzKW2RwuczTtyHBTH0Q5 Sqh4oDjnY9tcQCh4uRnJFT8sMQ4g4+u7BhGtCJ0MaEIkIs4xrm/nGXqet9sMLpU1 JJeeB2Iub8PGjO4AzlxiH4a1Vegyjr3kkoKLZVW6T9C2L2rHDe4emiG4vplhJZOW 62X5PgcH5RhoF/KiJ4O3oCHC/q6VIrwDlIhDMDiL1/qPZnABvNVJT813D+R0jj4j KEdPqKsEqbTnGlGeuBxngTy/UgW5k1CXuahnLRLdE8cO3LaFmatL0xvKBBCE6Ksy sSodfWBtYKUyigxgJodia7EFnWk6fF17CZHE8gDcxvXI+CIUoowrpilhLu0UOG/q rKAQ79tT2iTtoqqAcS89GWj3SzTHEsgj1XFha1LG/I2z/2Z1JXR98CKNH5jKttvo qp+3djs1Xja4U2n/FCaF5w/vw3xINPpofRqxflgsAV02LDuol4+Bdq6JHBwS7Vlz zw5NKjNHqbj/IppOSjFpAvlKmpo5e71dodlQBs/5U7DXXzUCdm37Lq/cMOIgMdlY 8YvjLwI5fMd47giIg+Le =svKp -----END PGP SIGNATURE----- --Apple-Mail=_07A9B152-6CD0-4BA5-95B0-5178AF93A36C-- From derek@ihtfp.com Fri Nov 1 08:38:11 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65A721E8383; Fri, 1 Nov 2013 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx9DqctSAxQY; Fri, 1 Nov 2013 08:38:07 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 604B621E80CC; Fri, 1 Nov 2013 08:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B95AF2602BA; Fri, 1 Nov 2013 11:38:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26363-04; Fri, 1 Nov 2013 11:38:05 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 63F4D2600B9; Fri, 1 Nov 2013 11:38:05 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id rA1Fc43j030060; Fri, 1 Nov 2013 11:38:04 -0400 From: Derek Atkins To: Nicholas Weaver References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> <52734CB0.60506@necom830.hpcl.titech.ac.jp> <0536EF5D-7567-45B8-851A-A696B6DBB235@icsi.berkeley.edu> Date: Fri, 01 Nov 2013 11:38:04 -0400 In-Reply-To: <0536EF5D-7567-45B8-851A-A696B6DBB235@icsi.berkeley.edu> (Nicholas Weaver's message of "Fri, 1 Nov 2013 08:18:44 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:38:11 -0000 Nicholas Weaver writes: > On Nov 1, 2013, at 7:57 AM, Derek Atkins wrote: >> It is unclear to me that ECC as a generic technology is bad, although >> any specific curves creates by NIST/NSA are certainly suspect. >> >> Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash, >> Public Key, or Cipher algorithm, and we don't use it in DNS for >> anything, AFAIK. > > > Random Number Generators are used to generate the key material, since > bare entropy is often not enough, so you use your entropy pool to seed > a pRNG. Bind, for example, ends up using OpenSSL. Fair enough, but I consider key generation "outside the DNS protocol". Named isn't generating the key(s), you use tools to do that. So yes, those tools need an RNG. > Certified versions of OpenSSL do have Dual_EC_DRBG, although its not > by default (or is it?). It historically has been present; I do not know if it's the default RNG or not. > The threat is probably a lot less, however, since everything else > signed in DNSSEC-land is deterministic, and even if Dual_EC_DRBG was > used, hopefully the raw stream doesn't leak (the backdoor requires > seeing some of the random output to make it predictable). This was my point. > Nicholas Weaver it is a tale, told by an idiot, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From gih@apnic.net Fri Nov 1 08:40:09 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6321E8279 for ; Fri, 1 Nov 2013 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.443 X-Spam-Level: X-Spam-Status: No, score=-99.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZrogPWUjPWb for ; Fri, 1 Nov 2013 08:40:04 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id ED90A21E80CC for ; Fri, 1 Nov 2013 08:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:content-type:mime-version:subject:from:in-reply-to: date:cc:content-transfer-encoding:message-id:references:to:x-mailer: return-path; bh=RCHVZtEwEvRNWR9reskcjrrRX6Kgsg7fsXsWLrwJTfA=; b=XhiybhCTIyRrxU7hkkLCmBXcWQOuxLAcKIODh0C6Wd6+awTUhgQzQqsb5dmU5+68J2BYRhJ6XamkD IFOaiq6DiMsmGAJh4iPuLGHVHStnmAsOXJAw0T2kgLk0MeOUyvUgFgwSBzJKVW90M7BKRy6wEiopg6 qWul4rgSs7BF70cc= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Sat, 2 Nov 2013 01:40:00 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sat, 2 Nov 2013 01:40:00 +1000 Received: from [192.168.6.113] (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Sat, 2 Nov 2013 01:39:54 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Geoff Huston In-Reply-To: <5359785363432515507@unknownmsgid> Date: Sat, 2 Nov 2013 02:39:48 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <77A43692-9FA0-409F-A9FF-21E86E46F10C@apnic.net> References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> <5359785363432515507@unknownmsgid> To: Joe Abley X-Mailer: Apple Mail (2.1816) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in draft-wouters-edns-tcp-chain-query-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:40:09 -0000 On 1 Nov 2013, at 11:38 am, Joe Abley wrote: > On Oct 31, 2013, at 9:17, Ray Bellis = wrote: >=20 >>=20 >>> On 31 Oct 2013, at 13:03, Olaf Kolkman wrote: >>>=20 >>> I am not sure if there are clients out there that get all nauseous = from OPT RRs in the responses >>=20 >> There are bound to be - I've certainly seen CPE that get nauseous = (FORMERR) with OPT RRs in the request, and I've no reason to believe = they wouldn't do just the same for an unsolicited OPT RR in the = response. >=20 > Geoff and George to the courtesy phone! It's a testable / measureable hypothesis. Geoff From mohta@necom830.hpcl.titech.ac.jp Fri Nov 1 15:11:52 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CD211E8110 for ; Fri, 1 Nov 2013 15:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPxZ5+trJQlA for ; Fri, 1 Nov 2013 15:11:47 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 6055711E813A for ; Fri, 1 Nov 2013 15:11:41 -0700 (PDT) Received: (qmail 12256 invoked from network); 1 Nov 2013 22:05:48 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 1 Nov 2013 22:05:48 -0000 Message-ID: <527427C5.7010505@necom830.hpcl.titech.ac.jp> Date: Sat, 02 Nov 2013 07:14:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Derek Atkins References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> <52734CB0.60506@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:11:52 -0000 Derek Atkins wrote: >> However, Snowden taught us that we must avoid any fancy >> cryptography strongly promoted by NIST, including all the >> EC related ones, which may be documented somewhere. > > It is unclear to me that ECC as a generic technology is bad, although > any specific curves creates by NIST/NSA are certainly suspect. My feeling is that NIST has been promoting EC, in general, unnaturally. Masataka Ohta From sm@resistor.net Tue Nov 5 14:57:17 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18911E815E for ; Tue, 5 Nov 2013 14:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBTtf8FshNmz for ; Tue, 5 Nov 2013 14:57:15 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E04C711E811A for ; Tue, 5 Nov 2013 14:57:14 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rA5Mv9PV014887; Tue, 5 Nov 2013 14:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383692233; bh=jkQUBHK50lnIPoQyW9aetiWlduA/RWoDccKAvkZ0AQs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gJaFpEzTPUJeaOJZrY1mWUrSjn2+m0Q74PFRjAWLthbjO+svs9wD0rNMW7IN61qGR aksmQDyFLec/BxfXQ6jMupEQkFRYFugfViEBip3yXxVKPKxYnvcDjYN9Hm3nFRUd0/ Uxcv7J8NS1gPVzAGF2taMQ7c2bkFC9TD3h7k61Ms= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1383692233; i=@resistor.net; bh=jkQUBHK50lnIPoQyW9aetiWlduA/RWoDccKAvkZ0AQs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LUF9yQ+QuqK+USHpgoCxWNRmRjfXr1uIBg1YPNKPb+xrTm2U/CWsDDrsMAyXeYE7h 4qhmGDETBBH4dozUMOBZV4FHQvAwv2xYjvRdAEFucRX8E31NXUjpI3OaBduy9JTQMt IUvqVylY9L6GtGtXMDdHeBNCfmCWqQBcUb8ADix8= Message-Id: <6.2.5.6.2.20131105144849.0cca0958@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Nov 2013 14:57:02 -0800 To: Nicholas Weaver From: SM In-Reply-To: <0536EF5D-7567-45B8-851A-A696B6DBB235@icsi.berkeley.edu> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> <52734CB0.60506@necom830.hpcl.titech.ac.jp> <0536EF5D-7567-45B8-851A-A696B6DBB235@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:57:17 -0000 Hi Nicholas, At 07:18 01-11-2013, Nicholas Weaver wrote: >Certified versions of OpenSSL do have Dual_EC_DRBG, although its not >by default (or is it?). It will likely be removed. Regards, -sm From envite@rolamasao.org Mon Nov 11 15:43:02 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11CA21E80C2 for ; Mon, 11 Nov 2013 15:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.018 X-Spam-Level: * X-Spam-Status: No, score=1.018 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwxYncfFaJJ0 for ; Mon, 11 Nov 2013 15:42:57 -0800 (PST) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7203021E809C for ; Mon, 11 Nov 2013 15:42:56 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 96D5211E99 for ; Mon, 11 Nov 2013 23:42:54 +0000 (WET) Message-ID: <52816B7D.8040409@rolamasao.org> Date: Mon, 11 Nov 2013 23:42:53 +0000 From: Noel Torres User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20131026025614.3676.qmail@joyce.lan> In-Reply-To: <20131026025614.3676.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 23:43:02 -0000 On 26/10/13 03:56, John Levine wrote: [...] > The real problem is that most provisioning software makes it too > painful to support new RR types. A handful of TXT-like RRs that > people will use insonsistently seems unlikely to fix that. Why should we try to fix bugs on broken provisioning software? We should, instead, encourage users to ask their providers or software vendors to Do The Right Thing. SPF record is The Right Thing. TXT spf-like record is an ugly hack, even if it is widely supported. While we can not go against the river flow, we should try to direct it, on the long run, to the proper place. Regards Noel Torre er Envite From marka@isc.org Mon Nov 11 16:12:40 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035BF21E80E9 for ; Mon, 11 Nov 2013 16:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.837 X-Spam-Level: X-Spam-Status: No, score=-6.837 tagged_above=-999 required=5 tests=[AWL=3.162, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuwwu2WN-aDz for ; Mon, 11 Nov 2013 16:12:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0E321E80D0 for ; Mon, 11 Nov 2013 16:12:33 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 9EC5E2383CF; Tue, 12 Nov 2013 00:12:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B81E16043C; Tue, 12 Nov 2013 00:18:27 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E0294160436; Tue, 12 Nov 2013 00:18:26 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 03F4E9D6D32; Tue, 12 Nov 2013 11:12:12 +1100 (EST) To: Noel Torres From: Mark Andrews References: <20131026025614.3676.qmail@joyce.lan> <52816B7D.8040409@rolamasao.org> In-reply-to: Your message of "Mon, 11 Nov 2013 23:42:53 -0000." <52816B7D.8040409@rolamasao.org> Date: Tue, 12 Nov 2013 11:12:12 +1100 Message-Id: <20131112001213.03F4E9D6D32@rock.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 00:12:40 -0000 In message <52816B7D.8040409@rolamasao.org>, Noel Torres writes: > On 26/10/13 03:56, John Levine wrote: > [...] > > The real problem is that most provisioning software makes it too > > painful to support new RR types. A handful of TXT-like RRs that > > people will use insonsistently seems unlikely to fix that. > > Why should we try to fix bugs on broken provisioning software? We > should, instead, encourage users to ask their providers or software > vendors to Do The Right Thing. > > SPF record is The Right Thing. TXT spf-like record is an ugly hack, even > if it is widely supported. > > While we can not go against the river flow, we should try to direct it, > on the long run, to the proper place. > > Regards > > Noel Torre > er Envite > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext It really shouldn't be too hard to design provisioning software to be easily upgradable. It's not like we don't have a 20 year history of new records being added regularly. To help BIND 9.10 includes a tool which is designed to be be used by provisioning software for checking entered records. Mark % nroff -man bin/tools/named-rrchecker.1 NAMED-RRCHECKER(1) BIND9 NAMED-RRCHECKER(1) NAME named-rrchecker - A syntax checker for individual DNS resource records DESCRIPTION named-rrchecker read a individual DNS resource record from standard input and checks if it is syntactically correct. The -h prints out the help menu. The -o origin option specifies a origin to be used when interpreting the record. The -p prints out the resulting record in cannonical form. If there is no cannonical form defined then the record will be printed in unknown record format. The -u prints out the resulting record in unknown record form. The -C, -T and -P print out the known class, standard type and private type nmeomics respectively. SEE ALSO RFC 1034, RFC 1035, named(8) COPYRIGHT Copyright © 2013 Internet Systems Consortium, Inc. ("ISC") BIND9 Aug 25, 2009 NAMED-RRCHECKER(1) % echo "IN A 10.0.0.1" | bin/tools/named-rrchecker -u CLASS1 TYPE1 \# 4 0a000001 % echo 'CLASS1 TYPE1 \# 4 0a000001' | bin/tools/named-rrchecker -p IN A 10.0.0.1 % bin/tools/named-rrchecker -T | fmt A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA HIP SPF UINFO UID GID UNSPEC NID L32 L64 LP EUI48 EUI64 URI DLV % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Mon Nov 11 17:41:44 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6519A21E80D4 for ; Mon, 11 Nov 2013 17:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL60hokPdptE for ; Mon, 11 Nov 2013 17:41:21 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3021F9B5A for ; Mon, 11 Nov 2013 17:41:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id A0B364B7F53 for ; Tue, 12 Nov 2013 14:41:12 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orPczaD4YVLF for ; Tue, 12 Nov 2013 14:41:04 +1300 (NZDT) Received: from [192.168.5.169] (vedra.internetnz.net.nz [202.46.176.54]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C5DB84B7F1D for ; Tue, 12 Nov 2013 14:41:04 +1300 (NZDT) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9AFD146E-7995-46C4-85BE-18BF4FBF28D1@nzrs.net.nz> Date: Tue, 12 Nov 2013 14:41:04 +1300 To: "dnsext@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [dnsext] I-D Action: draft-daley-updatezones-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:41:44 -0000 I've written up a draft following the discussion we've had on list. A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Extending DNS UPDATE for 'whole of zone' = operations Author(s) : Jay Daley Filename : draft-daley-updatezones-00.txt Pages : 8 Date : 2013-11-11 Abstract: This memo describes an extension to the DNS protocol that support the remote provisioning of zones on authoritative servers. This addition is complementary to the existing mechanisms for provisioning zone data using the DNS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-daley-updatezones There's also a htmlized version available at: http://tools.ietf.org/html/draft-daley-updatezones-00 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From prvs=0021a5d8c1=johnl@iecc.com Mon Nov 11 18:28:26 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F42221E8106 for ; Mon, 11 Nov 2013 18:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeXyHHCye9et for ; Mon, 11 Nov 2013 18:28:22 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69121E8109 for ; Mon, 11 Nov 2013 18:28:20 -0800 (PST) Received: (qmail 65050 invoked from network); 12 Nov 2013 02:28:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Nov 2013 02:28:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52819243.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=vphIFw6VL6XU9BFBOgMjSgsv3aOGUbmOjaImW+4FgNE=; b=sdbxGA89JF80tKBnRcc3lw9vowmBrQO4UdQswWFu0brlIrj4PEtHnGrTsAQODx932A+k6OKmeOIXpnVg/qARlNS3mfuqvzci39zrgZb5jsNbSxq0C6Ipkq4InF0yqvqoy3U5pNLUp0YoFtbxFT4m+KfrA6ZSHIBaFhkbeOdwWt9MRF3T1YAaT7katimfnUzHkV5ES3Ge/dj3GKtAcg19rxo0LVe3AU4t2nwCyQrSCitviKraowkvo+jEj1bW0fTp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52819243.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=vphIFw6VL6XU9BFBOgMjSgsv3aOGUbmOjaImW+4FgNE=; b=Zjj8pW9VI/SCfgNyejO5nBRpouthxoxBbY9XK4+gNWYPyItNnjuDU/6Xm0+HCPpM4dsXBUIZjD201mxXE5x1zgYAXATRsWs7EBpCPOTOTVHnNmwaKJdyQFs+4aGgCcY/Cp0Q7zol7d6I0o7H6SBaBjTjFVWqE9ZUzmEE2l2iieJZl402qor4sH34dTMU/HUmKsscZJj3+JWKGAvAkkWbj2aLmTXdIz+iJUzuU33xAu8Q7WLSXbokHRNTSLCh4dH8 Date: 12 Nov 2013 02:27:57 -0000 Message-ID: <20131112022757.63806.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20131112001213.03F4E9D6D32@rock.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:28:26 -0000 >It really shouldn't be too hard to design provisioning software to be >easily upgradable. It's not like we don't have a 20 year history of >new records being added regularly. Uh, yeah. You might want to take a look at draft-levine-dnsextlang-07. From askuma@microsoft.com Fri Nov 15 04:09:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51311E8166 for ; Fri, 15 Nov 2013 04:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DHo8LN9va1T for ; Fri, 15 Nov 2013 04:08:59 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01811E8191 for ; Fri, 15 Nov 2013 04:08:32 -0800 (PST) Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BL2PR03MB604.namprd03.prod.outlook.com (10.255.109.38) with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 15 Nov 2013 12:08:30 +0000 Received: from BN1AFFO11FD029.protection.gbl (2a01:111:f400:7c10::104) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.820.5 via Frontend Transport; Fri, 15 Nov 2013 12:08:30 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD029.mail.protection.outlook.com (10.58.52.184) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Fri, 15 Nov 2013 12:08:30 +0000 Received: from SINEX14HUBC501.southpacific.corp.microsoft.com (157.60.220.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.3.158.2; Fri, 15 Nov 2013 12:08:01 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.239]) by SINEX14HUBC501.southpacific.corp.microsoft.com ([fe80::58dd:5b00:bb08:9b24%11]) with mapi id 14.03.0158.002; Fri, 15 Nov 2013 12:07:37 +0000 From: Kumar Ashutosh To: "dnsext@ietf.org" Thread-Topic: RRSIGs in additional section Thread-Index: Ac7h+qAka+eaW0zuTlqm6K+ptvVi4w== Date: Fri, 15 Nov 2013 12:07:36 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.91] Content-Type: multipart/alternative; boundary="_000_E66B38BB793BAF439EF374F3E7EBEE464B63C0E2SINEX14MBXC415s_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(54356001)(512954002)(74706001)(76796001)(76786001)(74876001)(84326002)(51856001)(79102001)(76176001)(56816003)(16236675002)(20776003)(59766001)(77096001)(69226001)(19300405004)(85306002)(63696002)(6806004)(15202345003)(53806001)(77982001)(15975445006)(83072001)(55846006)(76482001)(65816001)(33656001)(47446002)(74502001)(19580395003)(50986001)(47976001)(87936001)(54316002)(81342001)(2656002)(31966008)(83322001)(80022001)(46102001)(74662001)(56776001)(71186001)(44976005)(81542001)(81686001)(87266001)(4396001)(80976001)(47736001)(81816001)(74366001)(16796002)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB604; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0031A0FFAF X-OriginatorOrg: microsoft.com Subject: [dnsext] RRSIGs in additional section X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 12:09:14 -0000 --_000_E66B38BB793BAF439EF374F3E7EBEE464B63C0E2SINEX14MBXC415s_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As per RFC 4035 section 3.1.1 When placing a signed RRset in the Additional section, the name server MUST= also place its RRSIG RRs in the Additional section. If space does not perm= it inclusion of both the RRset and its associated RRSIG RRs, the name serve= r MAY retain the RRset while dropping the RRSIG RRs. If this happens, the = name server MUST NOT set the TC bit solely because these RRSIG RRs didn't f= it. If such a response is received by a caching resolver it may Cache the RRSet= in additional section without their RRSIGs and subsequent queries from thi= s resolver might be responded without RRSIGs. Will not this lead to issues?= Is there any update to this behaviour? Am I missing something? Thanks Ashu --_000_E66B38BB793BAF439EF374F3E7EBEE464B63C0E2SINEX14MBXC415s_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

As per RFC 4035 section 3.1.1

When placing a signed = RRset in the Additional section, the name server MUST also place its RRSIG = RRs in the Additional section. If space does not permit inclusion of both t= he RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs.  I= f this happens, the name server MUST NOT set the TC bit solely because thes= e RRSIG RRs didn't fit.

 <= /p>

If such a response is received by a caching resolver= it may Cache the RRSet in additional section without their RRSIGs and subs= equent queries from this resolver might be responded without RRSIGs. Will n= ot this lead to issues? Is there any update to this behaviour? Am I missing something?

 

Thanks

Ashu

--_000_E66B38BB793BAF439EF374F3E7EBEE464B63C0E2SINEX14MBXC415s_-- From fanf2@hermes.cam.ac.uk Fri Nov 15 06:06:07 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42B511E81BB for ; Fri, 15 Nov 2013 06:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+3nH4ZlEf9a for ; Fri, 15 Nov 2013 06:06:07 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 0056D11E81B9 for ; Fri, 15 Nov 2013 06:06:06 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51371) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VhK29-0003bS-83 (Exim 4.82_3-c0e5623) (return-path ); Fri, 15 Nov 2013 14:06:05 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VhK29-0002kb-Cg (Exim 4.72) (return-path ); Fri, 15 Nov 2013 14:06:05 +0000 Date: Fri, 15 Nov 2013 14:06:05 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Kumar Ashutosh In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] RRSIGs in additional section X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 14:06:08 -0000 Kumar Ashutosh wrote: > > As per RFC 4035 section 3.1.1 > > When placing a signed RRset in the Additional section, the name server > MUST also place its RRSIG RRs in the Additional section. If space does > not permit inclusion of both the RRset and its associated RRSIG RRs, the > name server MAY retain the RRset while dropping the RRSIG RRs. If this > happens, the name server MUST NOT set the TC bit solely because these > RRSIG RRs didn't fit. This is sort-of consistent with RFC 2181 (depending on whether you view the RRSIG as part of the RRset or not): 9. The TC (truncated) header bit The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately. Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. > If such a response is received by a caching resolver it may Cache the > RRSet in additional section without their RRSIGs and subsequent queries > from this resolver might be responded without RRSIGs. No. See RFC 2181 section 5.4.1: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From ogud@ogud.com Fri Nov 15 06:16:19 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3D11E814B for ; Fri, 15 Nov 2013 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4QydXpOO1t7 for ; Fri, 15 Nov 2013 06:16:13 -0800 (PST) Received: from smtp107.ord1c.emailsrvr.com (smtp107.ord1c.emailsrvr.com [108.166.43.107]) by ietfa.amsl.com (Postfix) with ESMTP id E77DB11E8145 for ; Fri, 15 Nov 2013 06:16:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A6F1B98155; Fri, 15 Nov 2013 09:16:09 -0500 (EST) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 79E29980F5; Fri, 15 Nov 2013 09:16:07 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_52F23B2B-5135-4A7D-88D9-B75813B9D7D0" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: Date: Fri, 15 Nov 2013 09:16:08 -0500 Message-Id: <174120BF-36E0-4043-8BFD-AF32D6749CD7@ogud.com> References: To: Kumar Ashutosh X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] RRSIGs in additional section X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 14:16:19 -0000 --Apple-Mail=_52F23B2B-5135-4A7D-88D9-B75813B9D7D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2013, at 7:07 AM, Kumar Ashutosh = wrote: > Hi > =20 > As per RFC 4035 section 3.1.1 > When placing a signed RRset in the Additional section, the name server = MUST also place its RRSIG RRs in the Additional section. If space does = not permit inclusion of both the RRset and its associated RRSIG RRs, the = name server MAY retain the RRset while dropping the RRSIG RRs. If this = happens, the name server MUST NOT set the TC bit solely because these = RRSIG RRs didn't fit. > =20 > If such a response is received by a caching resolver it may Cache the = RRSet in additional section without their RRSIGs and subsequent queries = from this resolver might be responded without RRSIGs. Will not this lead = to issues? Is there any update to this behaviour? Am I missing = something? > =20 Good question, answer is no=20 but that is complicated and requires full compliance with RFC2181.=20 Just some back ground,=20 a) The motivation for this text is to avoid TCP connection just = because not all the additional data did fits in the packet. b) in many cases the resolver has the same data in its cache = thus the additional section is redundant.=20 c) RFC2181 says resolver MUST not promote cached data to higher = criticality by placing it in an earlier section than it came in,=20 thus cached additional data section MUST NOT be placed in answer = section. In this case the resolver needs to recurse before answering. d) DNSSEC packets are big and we need to make them smaller thus = suppressing out-of-zone glue is a good idea (minimall-answers)=20 Olafur=20 --Apple-Mail=_52F23B2B-5135-4A7D-88D9-B75813B9D7D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 15, 2013, = at 7:07 AM, Kumar Ashutosh <askuma@microsoft.com> = wrote:

Hi
As per RFC 4035 = section 3.1.1
When = placing a signed RRset in the Additional section, the name server MUST = also place its RRSIG RRs in the Additional section. If space does not = permit inclusion of both the RRset and its associated RRSIG RRs, the = name server MAY retain the RRset while dropping the RRSIG RRs.  If = this happens, the name server MUST NOT set the TC bit solely because = these RRSIG RRs didn't fit.
 
If such a response = is received by a caching resolver it may Cache the RRSet in additional = section without their RRSIGs and subsequent queries from this resolver = might be responded without RRSIGs. Will not this lead to issues? Is = there any update to this behaviour? Am I missing = something?
a)  The motivation for this = text is to avoid TCP connection just because not all the additional data = did fits in the packet.

b) in = many cases the resolver has the same data in its cache thus the = additional section is redundant. 

c) = RFC2181 says resolver MUST not promote cached data to higher criticality = by placing it in an earlier section than it came = in, 
thus cached additional data = section MUST NOT be placed in answer section. In this case the resolver = needs to recurse before answering.

d) DNSSEC = packets are big and we need to make them smaller thus suppressing = out-of-zone glue is a good idea = (minimall-answers) 

Olafur 
<= br>
= --Apple-Mail=_52F23B2B-5135-4A7D-88D9-B75813B9D7D0-- From Ted.Lemon@nominum.com Tue Nov 19 19:30:20 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEE01AE104 for ; Tue, 19 Nov 2013 19:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mYhByWFqGhX4 for ; Tue, 19 Nov 2013 19:30:19 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 650821AE0FC for ; Tue, 19 Nov 2013 19:30:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUowsxYCx9tZXO8pFg6v5q2Fuvw6hdTzb@postini.com; Tue, 19 Nov 2013 19:30:13 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 21CC21B814C for ; Tue, 19 Nov 2013 19:30:13 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5774C190043 for ; Tue, 19 Nov 2013 19:30:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 19:30:08 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 19 Nov 2013 22:30:04 -0500 To: " Group" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Subject: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 03:30:21 -0000 Is this on anyone's radar? What are your thoughts about it? https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ From bmanning@karoshi.com Tue Nov 19 21:52:07 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151091AE326 for ; Tue, 19 Nov 2013 21:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] 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 yV-PLCmrpD1t for ; Tue, 19 Nov 2013 21:52:05 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 830B11AE325 for ; Tue, 19 Nov 2013 21:52:05 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id rAK5pw7L008223; Wed, 20 Nov 2013 05:51:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id rAK5pwUE008222; Wed, 20 Nov 2013 05:51:58 GMT Date: Wed, 20 Nov 2013 05:51:58 +0000 From: bmanning@vacation.karoshi.com To: Ted Lemon Message-ID: <20131120055158.GB7117@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 05:52:07 -0000 yes. did you read/follow the NSEC4 discussions a few years back? this is a fine piece of work that clearly lays out the path of NSEC work and the ramifications for wildcards (5.3 & 5.4)... overall a needed addition to the DNS documentation library. why do you ask? /bill On Tue, Nov 19, 2013 at 10:30:04PM -0500, Ted Lemon wrote: > Is this on anyone's radar? What are your thoughts about it? > > https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From Ted.Lemon@nominum.com Tue Nov 19 22:28:08 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D51AE34A for ; Tue, 19 Nov 2013 22:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 0R16-dr538Y7 for ; Tue, 19 Nov 2013 22:28:07 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E91AE349 for ; Tue, 19 Nov 2013 22:28:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUoxWcBFtfW0g9Rb1kbb0jBjBIIJu5lQu@postini.com; Tue, 19 Nov 2013 22:28:01 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9BDC91B82C3 for ; Tue, 19 Nov 2013 22:28:00 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 80473190043; Tue, 19 Nov 2013 22:28:00 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 22:28:00 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <20131120055158.GB7117@vacation.karoshi.com.> Date: Wed, 20 Nov 2013 01:27:56 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20131120055158.GB7117@vacation.karoshi.com.> To: X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:28:08 -0000 On Nov 20, 2013, at 12:51 AM, bmanning@vacation.karoshi.com wrote: > why do you ask? Conflict review. My impression is the same, and it can be argued that = since DNSEXT no longer exists, there can't be a conflict. But I wanted = to bounce it off the list before making that claim, since in principle = the work could be done in INTAREA, but would probably be done by people = who read this mailing list. Thanks! From bmanning@karoshi.com Tue Nov 19 22:52:29 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCFF1AE35F for ; Tue, 19 Nov 2013 22:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] 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 ew9eiX5XdNwF for ; Tue, 19 Nov 2013 22:52:28 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id F0AF71AE359 for ; Tue, 19 Nov 2013 22:52:27 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id rAK6qL7L008379; Wed, 20 Nov 2013 06:52:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id rAK6qLLh008378; Wed, 20 Nov 2013 06:52:21 GMT Date: Wed, 20 Nov 2013 06:52:21 +0000 From: bmanning@vacation.karoshi.com To: Ted Lemon Message-ID: <20131120065221.GA8367@vacation.karoshi.com.> References: <20131120055158.GB7117@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:52:29 -0000 dnsext does exist, its just not meeting. it (in a perfect world) would be shut down. if the "conflict" is DNSEXT (not currently accepting new work, but still existing) and ISE, then there is really no other route than ISE, since the WG refuses to take the work on and there is no other existent venue. e.g. a conflict, but self-imposed by the lack of will to actually shut down a zombie WG. IMHO of course. /bill On Wed, Nov 20, 2013 at 01:27:56AM -0500, Ted Lemon wrote: > On Nov 20, 2013, at 12:51 AM, bmanning@vacation.karoshi.com wrote: > > why do you ask? > > Conflict review. My impression is the same, and it can be argued that since DNSEXT no longer exists, there can't be a conflict. But I wanted to bounce it off the list before making that claim, since in principle the work could be done in INTAREA, but would probably be done by people who read this mailing list. > > Thanks! > From Ted.Lemon@nominum.com Tue Nov 19 22:55:08 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1E1A1F5D for ; Tue, 19 Nov 2013 22:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 eAtNPBrZ5OTX for ; Tue, 19 Nov 2013 22:55:07 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6418C1AE36F for ; Tue, 19 Nov 2013 22:55:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUoxcwkBODPviHjJaGUm/6AuP/9+X1+JC@postini.com; Tue, 19 Nov 2013 22:54:58 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2B34B1B82C6 for ; Tue, 19 Nov 2013 22:54:58 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 10E27190043; Tue, 19 Nov 2013 22:54:58 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 22:54:57 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <20131120065221.GA8367@vacation.karoshi.com.> Date: Wed, 20 Nov 2013 01:54:54 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <934F103F-75B1-402A-B233-BB52364F0601@nominum.com> References: <20131120055158.GB7117@vacation.karoshi.com.> <20131120065221.GA8367@vacation.karoshi.com.> To: X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:55:08 -0000 On Nov 20, 2013, at 1:52 AM, = wrote: > e.g. a conflict, but self-imposed by the lack of will to actually shut = down a zombie WG. Au contraire, the working group was shut down a while back. The = mailing list remains. From joelja@bogus.com Tue Nov 19 22:57:01 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48B21AE36F for ; Tue, 19 Nov 2013 22:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 eY36g1T-lFej for ; Tue, 19 Nov 2013 22:57:00 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 728201AE36C for ; Tue, 19 Nov 2013 22:57:00 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rAK6ureP083016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 06:56:53 GMT (envelope-from joelja@bogus.com) Message-ID: <528C5D2F.4020905@bogus.com> Date: Tue, 19 Nov 2013 22:56:47 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com, Ted Lemon References: <20131120055158.GB7117@vacation.karoshi.com.> <20131120065221.GA8367@vacation.karoshi.com.> In-Reply-To: <20131120065221.GA8367@vacation.karoshi.com.> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m6EWFu8KhDgmBl9Q7p7AtwDnbRBHLdf06" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 20 Nov 2013 06:56:54 +0000 (UTC) Cc: " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:57:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m6EWFu8KhDgmBl9Q7p7AtwDnbRBHLdf06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 11/19/13, 10:52 PM, bmanning@vacation.karoshi.com wrote: > dnsext does exist, its just not meeting. it (in a perfect world) woul= d be shut down. > if the "conflict" is DNSEXT (not currently accepting new work, but sti= ll existing) and ISE, > then there is really no other route than ISE, since the WG refuses to = take the work on and > there is no other existent venue. DNSEXT is concluded. the mailing list continues. >=20 > e.g. a conflict, but self-imposed by the lack of will to actually shut= down a zombie WG. >=20 > IMHO of course. >=20 > /bill >=20 >=20 > On Wed, Nov 20, 2013 at 01:27:56AM -0500, Ted Lemon wrote: >> On Nov 20, 2013, at 12:51 AM, bmanning@vacation.karoshi.com wrote: >>> why do you ask? >> >> Conflict review. My impression is the same, and it can be argued that= since DNSEXT no longer exists, there can't be a conflict. But I wanted = to bounce it off the list before making that claim, since in principle th= e work could be done in INTAREA, but would probably be done by people who= read this mailing list. >> >> Thanks! >> > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 --m6EWFu8KhDgmBl9Q7p7AtwDnbRBHLdf06 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKMXS8ACgkQ8AA1q7Z/VrJbQgCdEcaPOZudqwemlxz26pmolwO+ k/cAnjTr0rJsnIJt33FEC8CnH3dYnMcn =E5kd -----END PGP SIGNATURE----- --m6EWFu8KhDgmBl9Q7p7AtwDnbRBHLdf06-- From yaojk@cnnic.cn Tue Nov 19 22:59:53 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479D21A1F7B for ; Tue, 19 Nov 2013 22:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525] 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 s6aolX7HZjan for ; Tue, 19 Nov 2013 22:59:51 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 3AC871A1F76 for ; Tue, 19 Nov 2013 22:59:50 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 20 Nov 2013 14:59:39 +0800 Date: Wed, 20 Nov 2013 14:59:40 +0800 From: "Jiankang Yao" To: "Ted Lemon" , "dnsext@ietf.org Group" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201311201459364160303@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart011677867318_=----" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:59:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart011677867318_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpnb29kIHdyaXRpbmcgb2YgdGhpcyBkcmFmdC4NCg0KSSBhbSBpbnRlcmVzdGVkIHRoZSBmb2xs b3dpbmcgdGV4dCBpbiBzZWN0aW9uIDM6DQoiICAgMi4gIFRoZSBETlMgcGFja2V0IGhlYWRlciBp cyBub3Qgc2lnbmVkLiAgVGhpcyBtZWFucyB0aGF0IGEgInN0YXR1czoNCiAgICAgICBOWERPTUFJ TiIgY2FuIG5vdCBiZSB0cnVzdGVkLiAgSW4gZmFjdCB0aGUgZW50aXJlIGhlYWRlciBtYXkgYmUN CiAgICAgICBmb3JnZWQsIGluY2x1ZGluZyB0aGUgQUQgYml0IChBRCBzdGFuZHMgZm9yIEF1dGhl bnRpYyBEYXRhLCBzZWUNCiAgICAgICBSRkMgMzY1NSBbUkZDMzY1NV0pLCB3aGljaCBtYXkgZ2l2 ZSBzb21lIGZvb2QgZm9yIHRob3VnaHQ7DQoiDQpzbyBpZiB0aGUgcmVzb2x2ZXIgaXMgYXR0YWNr ZWQsIHN1Y2ggYXMgaGFja2luZyB0aGUgInN0YXR1cyIgZmllbGQgb3IgdGhlIHdob2xlIGhlYWRl ciwgd2hhdCB3aWxsIGhhcHBlbj8NCg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0KRnJvbTogVGVk IExlbW9uDQpEYXRlOiAyMDEzLTExLTIwIDExOjMwDQpUbzogR3JvdXAgDQpTdWJqZWN0OiBbZG5z ZXh0XSBBdXRoZW50aWNhdGVkIGRlbmlhbCBvZiBleGlzdGVuY2UuLi4NCklzIHRoaXMgb24gYW55 b25lJ3MgcmFkYXI/ICAgV2hhdCBhcmUgeW91ciB0aG91Z2h0cyBhYm91dCBpdD8NCg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2llYmVuLWF1dGgtZGVuaWFsLW9mLWV4 aXN0ZW5jZS1kbnMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpkbnNleHQgbWFpbGluZyBsaXN0DQpkbnNleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0 ------=_001_NextPart011677867318_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
good writing of this draft.
 
I am interested the following text in = section=20 3:
"   2.  The DNS packet = header=20 is not signed.  This means that a=20 "status:
       NXDOMAIN" can not be=20 trusted.  In fact the entire header may=20 be
       forged, including the AD bit (A= D=20 stands for Authentic Data, see
       RFC= 3655=20 [RFC3655]), which may give some food for thought;
"
so if the resolver is attacked, such a= s=20 hacking the "status" field or the whole header, what will happen?
 
 
Jiankang Yao
 
Date: 2013-11-20 11:30
Subject: [dnsext] Authenticated denial of=20 existence...
Is this on anyone's radar?   What&= nbsp;are your thoughts about it?
 
https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existenc= e-dns/
 
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
------=_001_NextPart011677867318_=------ From miek@miek.nl Tue Nov 19 23:54:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571881AC4AC for ; Tue, 19 Nov 2013 23:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 s_xtsZAn3Pjj for ; Tue, 19 Nov 2013 23:54:11 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 53D731AE381 for ; Tue, 19 Nov 2013 23:54:10 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id t61so2159094wes.32 for ; Tue, 19 Nov 2013 23:54:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=DoTgLj180NyXqNRXgtdmDmU2ZOwecMpJioaSm5nwz74=; b=kQjWYpdc6wEqqRRm1jKSvcsHCWN0h56WvFeUH8t8NnGQ4M3MOfPHE4gcXWMazvBZG9 lPojrp3OYAKRHBJMwXQ4LEGhDuXJkrMzctg+2djgAH5Knq30AXgHlFIQIhxSAH1Jb0bF YL20Ck/MKi5vJ0IEKgSJscfRkdkrEHMQwEJzBCsqRb0CGLlX6c8YcLjuj/JWpicPUQcJ x5AqpW3eofmhstdtFcVwRQcjjsWw2cPrr2pmvTMVrRr6uSotHQF/65WePWgvEWOXp71p XMD6TttrZqnEk4WmmDdFzTppxBX1fYhJ20ibCMQYNYnZKvIsN6bNbZqQ0bkeMja1jF/+ +PZQ== X-Gm-Message-State: ALoCoQknQL32ZcaLSSMfQ9KS0YoOfhTnHOqi7mD3yLScVPrQYmeBSGBEQwsGDvCQijDxIP8jKlUT X-Received: by 10.180.14.226 with SMTP id s2mr4155wic.41.1384934044029; Tue, 19 Nov 2013 23:54:04 -0800 (PST) Received: from miek.nl (host86-145-158-57.range86-145.btcentralplus.com. [86.145.158.57]) by mx.google.com with ESMTPSA id qc10sm42362859wic.9.2013.11.19.23.54.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:54:03 -0800 (PST) Date: Wed, 20 Nov 2013 07:53:59 +0000 From: Miek Gieben To: Jiankang Yao Message-ID: <20131120075359.GA23121@miek.nl> Mail-Followup-To: Jiankang Yao , Ted Lemon , "dnsext@ietf.org Group" References: <201311201459364160303@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201311201459364160303@cnnic.cn> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: Ted Lemon , "dnsext@ietf.org Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:54:13 -0000 [ Quoting in "Re: [dnsext] Authenticated denial o..." ] > > good writing of this draft. > > I am interested the following text in section 3: > " 2. The DNS packet header is not signed. This means that a "status: > NXDOMAIN" can not be trusted. In fact the entire header may be > forged, including the AD bit (AD stands for Authentic Data, see > RFC 3655 [RFC3655]), which may give some food for thought; > " > so if the resolver is attacked, such as hacking the "status" field or the whole header, what will happen? A good resolver should check the complete message and then header so see if they match. Of course this only works if the message contains signatures. Should we add something along these lines to the draft. Currently it is an "exercise for the reader", which I kinda like. Regards, Miek From fanf2@hermes.cam.ac.uk Wed Nov 20 04:12:30 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8651ADEB4 for ; Wed, 20 Nov 2013 04:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 g5ewn6VRqupL for ; Wed, 20 Nov 2013 04:12:28 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 30F241ADEBE for ; Wed, 20 Nov 2013 04:12:28 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40308) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Vj6dn-0007pr-gP (Exim 4.82_3-c0e5623) (return-path ); Wed, 20 Nov 2013 12:12:19 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vj6dn-0006TT-3J (Exim 4.72) (return-path ); Wed, 20 Nov 2013 12:12:19 +0000 Date: Wed, 20 Nov 2013 12:12:19 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ted Lemon , Miek Gieben In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:12:31 -0000 Ted Lemon wrote: > Is this on anyone's radar? What are your thoughts about it? > > https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ A really nice and helpful document. A suggestion: It should discuss RFC 4470 Minimally Covering NSEC Records, and the related idea of NSEC3 "white lies" implemented by Dan Kaminsky's Phreebird. (I can't immediately find a good description of how the latter works.) Both these require on-demand synthesizing and signing of negative responses, whereas the mechanisms that Miek's draft currently covers are all designed for serving from a pre-signed zone file without requiring online private keys. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From miek@miek.nl Wed Nov 20 05:05:57 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DD1ADF7E for ; Wed, 20 Nov 2013 05:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 omLjra0BAJlF for ; Wed, 20 Nov 2013 05:05:55 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0001ADF89 for ; Wed, 20 Nov 2013 05:05:55 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so9073840wgh.23 for ; Wed, 20 Nov 2013 05:05:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=xIn2lDyizgjSh/5hLLzjC35qcEql3PPleYFyPgnZZ5s=; b=iK4+zofrhlqAmIoVymECH/mHzsRKlZRs/f2qUxy/b1QtOJnihwV0fsLqVpB/kqIC0l +7sJO/NfJkUsVzhQw0PWCQ9QE/5vwBToODqcGjY/fV5VTiSht942iCDsIkn9DenbBEeC h8Cy1fgU/Xgur4sT3tzJW32RZCGpdiUktpwt20un3vQ+u+LCrxqRxE0TR7cL+unSSf9u 9xrHCBViY34QaLMNseBTrZUTrGyPLGvyqAUhtnHUHRpcvAbWMfm0OVZOrr3U9uUDZJ2n p3zUgNbTFVMS+7FpBfYJ0Eu64cC5aQC0velN+3nnVgTAEUadulyafs6plKokIp8tsSuy nMlw== X-Gm-Message-State: ALoCoQlO9xYSYqE3zDFAp7PFcEENgb/lbjxT20ihDgkRCpdICHpGRolb0mYR6JmaZ7Zaby8eqCcK X-Received: by 10.194.1.139 with SMTP id 11mr533418wjm.33.1384952748674; Wed, 20 Nov 2013 05:05:48 -0800 (PST) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id je17sm16038887wic.4.2013.11.20.05.05.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Nov 2013 05:05:47 -0800 (PST) Date: Wed, 20 Nov 2013 13:05:46 +0000 From: Miek Gieben To: Tony Finch Message-ID: <20131120130546.GA28610@miek.nl> Mail-Followup-To: Tony Finch , Ted Lemon , " Group" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: Ted Lemon , " Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 13:05:58 -0000 [ Quoting in "Re: [dnsext] Authenticated denial o..." ] > Ted Lemon wrote: > > > Is this on anyone's radar? What are your thoughts about it? > > > > https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ > > A really nice and helpful document. Thanks. > A suggestion: > > It should discuss RFC 4470 Minimally Covering NSEC Records, and the > related idea of NSEC3 "white lies" implemented by Dan Kaminsky's > Phreebird. (I can't immediately find a good description of how the latter > works.) Both these require on-demand synthesizing and signing of negative > responses, whereas the mechanisms that Miek's draft currently covers are > all designed for serving from a pre-signed zone file without requiring > online private keys. I'm not sure how far in the review process we actually are with this draft, and adding text about this is a considerable effort. However I think it is valuable to have text on this in this draft too. Regards, -- Miek Gieben From matthijs@nlnetlabs.nl Wed Nov 20 05:40:32 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960721ADF76 for ; Wed, 20 Nov 2013 05:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 uXpjyonIcmUb for ; Wed, 20 Nov 2013 05:40:30 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 782F91ADF6C for ; Wed, 20 Nov 2013 05:40:30 -0800 (PST) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rAKDeBht071233 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 14:40:12 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rAKDeBht071233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1384954820; bh=HYbxiWSqCFag7kUvtgbvY/7JaJ0DqIMDZdnkA5SuHfo=; h=Date:From:To:Subject:References:In-Reply-To; b=ZsifuSG8kHPtPbyIKtpIw1J0glQa954s/SIgzZC0UoPafgNb7Hc0a3Wg4Awy+JqU/ YDlSWd/mDza3i7hnZV7K1ux9EKq4aoOwsXMrWXhLewoGiRkISkEwaGMUwsdjX4PoIj PBPIzHU9Natz+QQj1NMasxyKwZk2cOOc2/XJhb4Y= X-Authentication-Warning: open.nlnetlabs.nl: Host zoidberg.nlnetlabs.nl [213.154.224.18] claimed to be [213.154.224.18] Message-ID: <528CBBBB.5050506@nlnetlabs.nl> Date: Wed, 20 Nov 2013 14:40:11 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tony Finch , Ted Lemon , " Group" References: <20131120130546.GA28610@miek.nl> In-Reply-To: <20131120130546.GA28610@miek.nl> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Wed, 20 Nov 2013 14:40:14 +0100 (CET) Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 13:40:32 -0000 I would like to add some more text about minimally covering records, but I would not like to disturb the current flow of the document. In other words, I suggest it to be either a short notice, or to appear as an appendix. Best regards, Matthijs On 11/20/2013 02:05 PM, Miek Gieben wrote: > [ Quoting in "Re: [dnsext] Authenticated denial o..." ] >> Ted Lemon wrote: >> >>> Is this on anyone's radar? What are your thoughts about it? >>> >>> https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ >> >> A really nice and helpful document. > > Thanks. > >> A suggestion: >> >> It should discuss RFC 4470 Minimally Covering NSEC Records, and the >> related idea of NSEC3 "white lies" implemented by Dan Kaminsky's >> Phreebird. (I can't immediately find a good description of how the latter >> works.) Both these require on-demand synthesizing and signing of negative >> responses, whereas the mechanisms that Miek's draft currently covers are >> all designed for serving from a pre-signed zone file without requiring >> online private keys. > > I'm not sure how far in the review process we actually are with this draft, > and adding text about this is a considerable effort. However I think it is > valuable to have text on this in this draft too. > > Regards, > From Ted.Lemon@nominum.com Wed Nov 20 07:22:34 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4C1ADFFC for ; Wed, 20 Nov 2013 07:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ph3K9lJEOJc6 for ; Wed, 20 Nov 2013 07:22:33 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 182B11AE01E for ; Wed, 20 Nov 2013 07:22:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUozToAihk5+AFJlPW7CDnMJZxtlHibnK@postini.com; Wed, 20 Nov 2013 07:22:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A318C1B82D0 for ; Wed, 20 Nov 2013 07:22:08 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 75374190043; Wed, 20 Nov 2013 07:22:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 07:22:08 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <20131120075359.GA23121@miek.nl> Date: Wed, 20 Nov 2013 10:22:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9978C9F9-598B-41B9-A938-C0E23EC58E5A@nominum.com> References: <201311201459364160303@cnnic.cn> <20131120075359.GA23121@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:22:35 -0000 On Nov 20, 2013, at 2:53 AM, Miek Gieben wrote: > Should we add something along these lines to the draft. Currently it = is an > "exercise for the reader", which I kinda like. It's an ISE document. Do it the way you want. If you see a = suggestion here that you think is worth following, please go ahead, but = you are under no obligation to do so. A conflict review simply checks = to make sure that there isn't somewhere that this work ought to be = happening within the IETF. From miek@miek.nl Wed Nov 20 07:38:30 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644481ADFE3 for ; Wed, 20 Nov 2013 07:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 kxC-6xa1aDTd for ; Wed, 20 Nov 2013 07:38:29 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id EFBCF1AE018 for ; Wed, 20 Nov 2013 07:38:28 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so2428395wib.2 for ; Wed, 20 Nov 2013 07:38:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uCWHMJmXLhZryM/pPQOkcTXf1Th3wE2UdkYBFt1k93M=; b=JLMn3g3Bp9gk52jUMDcAMmPoUNqZFgK2S1hvU9OhgHGG8ZOI942qveEKvhpR3G+woL qldQuEi9mdjoBFmqgX6q8IKNMXOI4QZJH/jXAg2eWd80gsO8M9xkBj9pT3j58CAMRB8l B3IpqDATBSqsmxbf9saGo9HCZLxHK5LLrmfKEdcq0sGBJztkFr9FI8UAFf+na9KEYPC4 i/TwG4j87yb3AY9NCIN4qD0T6DSCVQ5iNITTJFlboh5GDU6bb8iZyBRzK9n+hDrDa/vm DEFhdXt42vbyW1dMbhfLyWx23yFoVrLNKmlJc02pRgXmfbzrVKJYM7+WvO+olOIcpXFX ZJMg== X-Gm-Message-State: ALoCoQnIDQetuSkHOReqCZ4rkgdvAiwJ2qMBlxrkkXFLf346GK8Tui5AFiDaR9fftsOcAIYoq3nR X-Received: by 10.180.77.74 with SMTP id q10mr1734010wiw.65.1384961901829; Wed, 20 Nov 2013 07:38:21 -0800 (PST) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id qc10sm46107954wic.9.2013.11.20.07.38.20 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Nov 2013 07:38:21 -0800 (PST) Date: Wed, 20 Nov 2013 15:38:19 +0000 From: Miek Gieben To: Ted Lemon Message-ID: <20131120153819.GA12162@miek.nl> Mail-Followup-To: Ted Lemon , Jiankang Yao , "dnsext@ietf.org Group" References: <201311201459364160303@cnnic.cn> <20131120075359.GA23121@miek.nl> <9978C9F9-598B-41B9-A938-C0E23EC58E5A@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9978C9F9-598B-41B9-A938-C0E23EC58E5A@nominum.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:38:30 -0000 [ Quoting in "Re: [dnsext] Authenticated denial o..." ] > On Nov 20, 2013, at 2:53 AM, Miek Gieben wrote: > > Should we add something along these lines to the draft. Currently it is an > > "exercise for the reader", which I kinda like. > > It's an ISE document. Do it the way you want. If you see a suggestion here that you think is worth following, please go ahead, but you are under no obligation to do so. A conflict review simply checks to make sure that there isn't somewhere that this work ought to be happening within the IETF. Ack. Thanks for the clarification. -- Miek Gieben From tale@dd.org Wed Nov 20 09:53:33 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC91AE086 for ; Wed, 20 Nov 2013 09:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 vkWGvz5ruuJs for ; Wed, 20 Nov 2013 09:53:31 -0800 (PST) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 69B681AE0B3 for ; Wed, 20 Nov 2013 09:53:30 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id DE2283F432; Wed, 20 Nov 2013 12:53:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21132.63250.716415.755401@gro.dd.org> Date: Wed, 20 Nov 2013 12:53:22 -0500 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: References: Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:53:33 -0000 Tony Finch writes: > > https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ > > A really nice and helpful document. Agreed. Really well put-together. I do like the previously mentioned ideas of including a bit about RFC 4470 and a few short words on alternatives to managing the nsec3 hash space (like Kaminsky's). Appendix is fine to not disrupt the flow, and it probably doesn't really need more than a paragraph or so for each. Section 3[.0] should probably elaborate on this: When you are querying a name server for a record that actually exists, a man-in-the-middle may replay that generic denial record and it would be impossible to tell whether the response was genuine or spoofed. especially when later on 3.2 says this: Therefore, the RRSIG's RDATA include a validity period (not visible in the zone above), so that an attacker cannot replay this NXDOMAIN response for "c.example.org" forever. which could easily leave the reader wondering, "so why doesn't having a validity period on a generic denial record adequately address this?" I realize the answer is obvious to us, but it isn't obvious in the document, which is meant to be accessible by people outside the security sphere. Maybe this subtle would work? I'm not entirely sure how much it does help, but does start to point in the right direction. When you are querying a name server for any record that actually exists, a man-in-the-middle could replay that generic denial record that is not limited in its scope and it would be impossible to tell whether the response was genuine or spoofed. From marka@isc.org Wed Nov 20 12:51:17 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82FC1AE4C0 for ; Wed, 20 Nov 2013 12:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 68Ieu99uoEhI for ; Wed, 20 Nov 2013 12:51:16 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8081AE4B3 for ; Wed, 20 Nov 2013 12:51:16 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1ACF32383A8 for ; Wed, 20 Nov 2013 20:50:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5A86C16042E for ; Wed, 20 Nov 2013 20:57:46 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2DE981603E9 for ; Wed, 20 Nov 2013 20:57:46 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1A8F5AA86C9 for ; Thu, 21 Nov 2013 07:50:53 +1100 (EST) To: "dnsext@ietf.org Group" From: Mark Andrews References: <201311201459364160303@cnnic.cn> <20131120075359.GA23121@miek.nl> <9978C9F9-598B-41B9-A938-C0E23EC58E5A@nominum.com> <20131120153819.GA12162@miek.nl> Mail-Followup-To: Ted Lemon , Jiankang Yao , "dnsext@ietf.org Group" In-reply-to: Your message of "Wed, 20 Nov 2013 15:38:19 -0000." <20131120153819.GA12162@miek.nl> Date: Thu, 21 Nov 2013 07:50:53 +1100 Message-Id: <20131120205053.1A8F5AA86C9@rock.dv.isc.org> Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:51:18 -0000 You may want to have some discussion about the pointlessness of NSEC3 in highly structured zones like ip6.arpa and in-addr.arpa. These can be walked even with NSEC3 due to their structure. You may want to point out that a NSEC proves the existance of all empty non-terminals between the two names in it hence contains the closest provable encloser. There is a bias that NSEC3 is better than NSEC. They are just different. NSEC3 is actually worse for the typical trivial zone as it doesn't help with zone walking as you can guess the names and adds pointless computational load on both authoritative servers and validators. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From miek@miek.nl Wed Nov 20 13:37:53 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8BE1AE1E1 for ; Wed, 20 Nov 2013 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 VsGdfCPUvZ6z for ; Wed, 20 Nov 2013 13:37:51 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44F1AE1DD for ; Wed, 20 Nov 2013 13:37:51 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id p61so5041154wes.6 for ; Wed, 20 Nov 2013 13:37:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=fOdiix0/LLQYSfcwnHnx/pKnOvvTwZf41s45Ad9RIsk=; b=b624Ysyppa5nSIZg+FbYAGx57IdpLfEHySiintLX3fSmIbHcl41A8zTgWyXJfD5k2d Kw7VT58tR8cFPEooNpC4LHedb6KB486wBszvmBR1YfWOhLQidfQprX3Qros1J0PFTFTw ETbSEcpFYFNNRUatpMrrObCjxuPz/1g91dJ9mugva00EftlIgWcHqS/Q+amf6Q7meNxH 2fxPmu2xImQD/xmm5pmJr2pyWogKbmv6HY9K7If3A6yRU+hjes8JCd5XJlstwD9ecvKw Oh5CawX2XukD/SGVwrSjp2OXmq1WuzDoMP3H9s+5+3W9S1RnC9c5k3RnLo6YZrrcySzR JpDw== X-Gm-Message-State: ALoCoQmvm81uX7kfkmtd/YBPc7MxzEn1aHAGfFk7vR0x2I4JTDrEKyVXm0b86iSkg5lneCj6jrxh X-Received: by 10.194.123.8 with SMTP id lw8mr2628225wjb.40.1384983464389; Wed, 20 Nov 2013 13:37:44 -0800 (PST) Received: from miek.nl (host86-145-158-57.range86-145.btcentralplus.com. [86.145.158.57]) by mx.google.com with ESMTPSA id ey4sm49016696wic.11.2013.11.20.13.37.43 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Nov 2013 13:37:43 -0800 (PST) Date: Wed, 20 Nov 2013 21:37:40 +0000 From: Miek Gieben To: Ted Lemon , Jiankang Yao , "dnsext@ietf.org Group" Message-ID: <20131120213740.GB30164@miek.nl> Mail-Followup-To: Ted Lemon , Jiankang Yao , "dnsext@ietf.org Group" References: <201311201459364160303@cnnic.cn> <20131120075359.GA23121@miek.nl> <9978C9F9-598B-41B9-A938-C0E23EC58E5A@nominum.com> <20131120153819.GA12162@miek.nl> <20131120205053.1A8F5AA86C9@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131120205053.1A8F5AA86C9@rock.dv.isc.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 21:37:53 -0000 [ Quoting in "Re: [dnsext] Authenticated denial o..." ] > > You may want to have some discussion about the pointlessness of > NSEC3 in highly structured zones like ip6.arpa and in-addr.arpa. > These can be walked even with NSEC3 due to their structure. > > You may want to point out that a NSEC proves the existance of all > empty non-terminals between the two names in it hence contains the > closest provable encloser. Ack and ack. These would indeed be good things to add. > There is a bias that NSEC3 is better than NSEC. They are just > different. NSEC3 is actually worse for the typical trivial zone > as it doesn't help with zone walking as you can guess the names and > adds pointless computational load on both authoritative servers and > validators. I agree with your assertions, but I hope to keep the draft purely technical. Grtz, Miek From matthijs@nlnetlabs.nl Wed Nov 20 23:33:04 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD461AE0B2 for ; Wed, 20 Nov 2013 23:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 QudHfEYI59ef for ; Wed, 20 Nov 2013 23:33:02 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 502921AE08B for ; Wed, 20 Nov 2013 23:33:02 -0800 (PST) Received: from [IPv6:2001:981:19be:1:851e:b7f0:265c:4402] ([IPv6:2001:981:19be:1:851e:b7f0:265c:4402]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rAL7VPBa016702 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Nov 2013 08:31:26 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rAL7VPBa016702 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1385019087; bh=mYZLqPI8UA9UlWZu3QJYCJ0Vec6tgdtkdRlWEeJNoUg=; h=Date:From:To:Subject:References:In-Reply-To; b=dThJQ3qDFlvjJAvoFU/Kj4MqqQ36PbYrJ5nnhnE6zw5/qSB7MXNs8STzxHYVZx2NL Uc7wPt2VCwwmw/IE1IH9tNl/iOxUwvwzwcT9aTFTJGcFvCkEVGMzb5FDbPMlvgPogp gWzOyZiYTtSzeifhluLmUM44aNQrysRsxzoFAYy4= Message-ID: <528DB6CB.1040404@nlnetlabs.nl> Date: Thu, 21 Nov 2013 08:31:23 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dave Lawrence , dnsext@ietf.org References: <21132.63250.716415.755401@gro.dd.org> In-Reply-To: <21132.63250.716415.755401@gro.dd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 21 Nov 2013 08:31:27 +0100 (CET) Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 07:33:04 -0000 Hi, On 11/20/2013 06:53 PM, Dave Lawrence wrote: > Tony Finch writes: >>> https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ >> >> A really nice and helpful document. > > Agreed. Really well put-together. I do like the previously mentioned > ideas of including a bit about RFC 4470 and a few short words on > alternatives to managing the nsec3 hash space (like Kaminsky's). > Appendix is fine to not disrupt the flow, and it probably doesn't > really need more than a paragraph or so for each. Thanks. Miek and I are going to cover the topic. > Section 3[.0] should probably elaborate on this: > > When you are querying a name server for a record that actually > exists, a man-in-the-middle may replay that generic denial record > and it would be impossible to tell whether the response was genuine > or spoofed. > > especially when later on 3.2 says this: > > Therefore, the RRSIG's RDATA include a validity period (not visible > in the zone above), so that an attacker cannot replay this NXDOMAIN > response for "c.example.org" forever. > > which could easily leave the reader wondering, "so why doesn't having > a validity period on a generic denial record adequately address this?" > > I realize the answer is obvious to us, but it isn't obvious in the > document, which is meant to be accessible by people outside the > security sphere. > > Maybe this subtle would work? I'm not entirely sure how much it does > help, but does start to point in the right direction. > > When you are querying a name server for any record that actually > exists, a man-in-the-middle could replay that generic denial record > that is not limited in its scope and it would be impossible to tell > whether the response was genuine or spoofed. I agree. Thank you for providing text. Best regards, Matthijs > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From matthijs@nlnetlabs.nl Fri Nov 22 01:43:36 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059891ACAD7 for ; Fri, 22 Nov 2013 01:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 Vbl-xXsvQi1x for ; Fri, 22 Nov 2013 01:43:31 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F111ACC86 for ; Fri, 22 Nov 2013 01:43:31 -0800 (PST) Received: from [IPv6:2001:981:19be:1:70cd:5583:2262:3804] ([IPv6:2001:981:19be:1:70cd:5583:2262:3804]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rAM9hKHL074178 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 22 Nov 2013 10:43:20 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rAM9hKHL074178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1385113403; bh=254uypD+2hMmWEj5ypZzelxPK9gnu3CGB+1vg3FHscU=; h=Date:From:To:Subject:References:In-Reply-To; b=SkgOjKEWCfgTcF5n5cOndN4GDJZzfXkz7MvwwtA7fz+Ww6lUSgJsaitz4sH8y44QE 2UPIK8jFKMHUIIHgAJWuycsvUKjsE6l4AC+ntVMgbr3LTOVTzUAFpJpU+8Pfp0qJL6 0OdNDtu5OYNF9sGEmCvOrvDTUTs8g9rqPDNZNWjk= Message-ID: <528F2737.1020002@nlnetlabs.nl> Date: Fri, 22 Nov 2013 10:43:19 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 22 Nov 2013 10:43:21 +0100 (CET) Subject: [dnsext] RFC 4470 bitmap (Was Re: Authenticated denial of existence...) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:43:36 -0000 As a result of writing down text relating RFC 4470 in draft-gieben-auth-denial-of-existence-dns, I come to the following observation: RFC 4470 sets requirements for the next owner name in the generated NSEC record. Specifically, the next owner name is lexically before the actual next existing name in the zone. The next owner name must be lexically after the QNAME. The span may not cover any existing names. Main point: I cannot find requirements for the owner name. In other words, that may be an existing name. But the RFC explicitly says: The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. That is only true if the owner name does not exist. So either this requirement should be relaxed, or there should be an additional requirement that the generated NSEC owner name may not exist. (By the way, I think the requirement should be relaxed, because a minimally covering NSEC record may also be used in a NODATA response) Best regards, Matthijs On 11/20/2013 01:12 PM, Tony Finch wrote: > Ted Lemon wrote: > >> Is this on anyone's radar? What are your thoughts about it? >> >> https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ > > A really nice and helpful document. > > A suggestion: > > It should discuss RFC 4470 Minimally Covering NSEC Records, and the > related idea of NSEC3 "white lies" implemented by Dan Kaminsky's > Phreebird. (I can't immediately find a good description of how the latter > works.) Both these require on-demand synthesizing and signing of negative > responses, whereas the mechanisms that Miek's draft currently covers are > all designed for serving from a pre-signed zone file without requiring > online private keys. > > Tony. > From fanf2@hermes.cam.ac.uk Fri Nov 22 06:06:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7031AE0B7 for ; Fri, 22 Nov 2013 06:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 txx-l_UfhQBK for ; Fri, 22 Nov 2013 06:06:20 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 920461AE0EE for ; Fri, 22 Nov 2013 06:06:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56156) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VjrN5-00085Z-74 (Exim 4.82_3-c0e5623) (return-path ); Fri, 22 Nov 2013 14:06:11 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VjrN5-0004qW-1u (Exim 4.72) (return-path ); Fri, 22 Nov 2013 14:06:11 +0000 Date: Fri, 22 Nov 2013 14:06:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <528F2737.1020002@nlnetlabs.nl> Message-ID: References: <528F2737.1020002@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4470 bitmap (Was Re: Authenticated denial of existence...) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 14:06:25 -0000 Matthijs Mekking wrote: > > Main point: I cannot find requirements for the owner name. In other > words, that may be an existing name. There are two cases: "instantiated names" which are names that exist in the zone, in which case the owner name of the NSEC record matches the owner name of the other records (para. 2 of sect. 3); and proofs of nonexistence generated on-demand (para. 3 of sect. 3): Whenever an NSEC record is needed to prove the non-existence of a name, a new NSEC record is dynamically produced and signed. The new NSEC record has an owner name lexically before the QNAME but lexically following any existing name and a "next name" lexically following the QNAME but before any existing name. > But the RFC explicitly says: > > The generated NSEC record's type bitmap MUST have the RRSIG and NSEC > bits set and SHOULD NOT have any other bits set. That is the first sentence of para. 4 of sect. 3 which refers to the on-demand NSEC records described in the previous paragraph. > (By the way, I think the requirement should be relaxed, because a > minimally covering NSEC record may also be used in a NODATA response) For NODATA responses you use the NSEC record of an instantiated name, which can be minimally covering as described in para. 2 of sect. 3. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From matthijs@nlnetlabs.nl Fri Nov 22 07:52:32 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC471AE3D8 for ; Fri, 22 Nov 2013 07:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 MQUdN4Gw4Xqj for ; Fri, 22 Nov 2013 07:52:31 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2011AE3CE for ; Fri, 22 Nov 2013 07:52:30 -0800 (PST) Received: from [IPv6:2001:981:19be:1:70cd:5583:2262:3804] ([IPv6:2001:981:19be:1:70cd:5583:2262:3804]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rAMFqJxj086986 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Nov 2013 16:52:21 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rAMFqJxj086986 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1385135541; bh=Zg5dLPcGjATszOgDYxKbZoubGlOlSdaywy4LLmlsFTA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fXSJVog4yTtCJ4Z4BCT44O1aJw+7jbPJNqPi4Qx06MzPKUtDu+aya5A+/J4mRN+QF RM8dRiBA0ZPjbxEYm3UnZacRvBG3CzbH2iTAxwGyOuBatWd6AxMNVje8RSaOonGZvs WkG8BsonDGZr8qOsg8d8McqXP2Zbrj42usaXxqMY= Message-ID: <528F7DB4.10102@nlnetlabs.nl> Date: Fri, 22 Nov 2013 16:52:20 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tony Finch References: <528F2737.1020002@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 22 Nov 2013 16:52:21 +0100 (CET) Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4470 bitmap (Was Re: Authenticated denial of existence...) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 15:52:32 -0000 On 11/22/2013 03:06 PM, Tony Finch wrote: > Matthijs Mekking wrote: >> >> Main point: I cannot find requirements for the owner name. In other >> words, that may be an existing name. > > There are two cases: "instantiated names" which are names that exist in > the zone, in which case the owner name of the NSEC record matches the > owner name of the other records (para. 2 of sect. 3); and proofs of > nonexistence generated on-demand (para. 3 of sect. 3): > > Whenever an NSEC record is needed to prove the non-existence of a > name, a new NSEC record is dynamically produced and signed. The new > NSEC record has an owner name lexically before the QNAME but > lexically following any existing name and a "next name" lexically > following the QNAME but before any existing name. > >> But the RFC explicitly says: >> >> The generated NSEC record's type bitmap MUST have the RRSIG and NSEC >> bits set and SHOULD NOT have any other bits set. > > That is the first sentence of para. 4 of sect. 3 which refers to the > on-demand NSEC records described in the previous paragraph. It is not clear to me that this sentence only refers to the on-demand NSEC records. Especially because the sentence talks about "generated NSEC record's type bitmap" and in para. 1 of sect 3. it is mentioned that for instantiated names, NSEC records can still be generated and signed in advance. But yes, it makes sense that the rule only applies to non-existent names. Best regards, Matthijs > >> (By the way, I think the requirement should be relaxed, because a >> minimally covering NSEC record may also be used in a NODATA response) > > For NODATA responses you use the NSEC record of an instantiated name, > which can be minimally covering as described in para. 2 of sect. 3. > > Tony. > From fanf2@hermes.cam.ac.uk Fri Nov 22 07:59:26 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2C1AE15B for ; Fri, 22 Nov 2013 07:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 BWpCgrScVeLp for ; Fri, 22 Nov 2013 07:59:24 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 468D61ADFDA for ; Fri, 22 Nov 2013 07:59:24 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:55093) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Vjt8W-0001ux-Db (Exim 4.82_3-c0e5623) (return-path ); Fri, 22 Nov 2013 15:59:16 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vjt8W-0004rp-3v (Exim 4.72) (return-path ); Fri, 22 Nov 2013 15:59:16 +0000 Date: Fri, 22 Nov 2013 15:59:16 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <528F7DB4.10102@nlnetlabs.nl> Message-ID: References: <528F2737.1020002@nlnetlabs.nl> <528F7DB4.10102@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4470 bitmap (Was Re: Authenticated denial of existence...) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 15:59:26 -0000 Matthijs Mekking wrote: > It is not clear to me that this sentence only refers to the on-demand > NSEC records. I think the other sentence in the same paragraph makes it clear that the whole paragraph is about NXDOMAIN responses: The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at names that did not exist before the zone was signed. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From miek@miek.nl Mon Nov 25 06:05:17 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6C1ADBCE for ; Mon, 25 Nov 2013 06:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 dXG29RBHXsdN for ; Mon, 25 Nov 2013 06:05:15 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0938E1ADBCC for ; Mon, 25 Nov 2013 06:05:14 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so3609374wid.5 for ; Mon, 25 Nov 2013 06:05:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=j5oN4YSt7UNhzU4fjFFdx95uH4qnJuHPzWnxbOt+WVw=; b=glEdMMGGXF3gU8w7OsopOOkZjsNMpNrIA2rnEi2++P6WQgwOHE1mDeKGP4BGK5oFnT HLOFCIkLDYxT0BmPuYpHT/sCNNVm0o1I4M5Q//WXctre68PfBltFBZgc/buyqc17aF4m pSwdWBdF41swmEjQS0eeISmXR2ENHfqmNTK8dB8uQYtozU2LrYYUUB8ppVYyXtEhTPL+ w8G17m3zq1YrMmjWBcvGTizA9k4LsvEufpUkrN7QtXZ2hjfS6vTH/zaoR4x0zGlLl9ja J88GFfJxjjHIN6TGVnL5h/ZWLp6eFpD+nz6chC3rXi2ZNyKdbovgfFlY/cjIQkki5KvK wpxQ== X-Gm-Message-State: ALoCoQm6aQeywtjqs/uzM7wqBmePtUYJBU6TUL2AA6TCWAuND4iVJrwo8p6GE4RVC8oEBg5QjHEG X-Received: by 10.180.210.206 with SMTP id mw14mr13962484wic.14.1385388314531; Mon, 25 Nov 2013 06:05:14 -0800 (PST) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id s20sm50470926wib.1.2013.11.25.06.05.13 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Nov 2013 06:05:13 -0800 (PST) Date: Mon, 25 Nov 2013 14:05:08 +0000 From: Miek Gieben To: Dave Lawrence Message-ID: <20131125140508.GB20994@miek.nl> Mail-Followup-To: Dave Lawrence , dnsext@ietf.org References: <21132.63250.716415.755401@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21132.63250.716415.755401@gro.dd.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:05:17 -0000 [ Quoting in "Re: [dnsext] Authenticated denial o..." ] > Tony Finch writes: > > > https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/ > > > > A really nice and helpful document. > > Agreed. Really well put-together. I do like the previously mentioned > ideas of including a bit about RFC 4470 and a few short words on > alternatives to managing the nsec3 hash space (like Kaminsky's). > Appendix is fine to not disrupt the flow, and it probably doesn't > really need more than a paragraph or so for each. Hi, Matthijs and I added an extra appendix to cover on-line signing and made some tweaks to the rest of the text. See: http://www.ietf.org/id/draft-gieben-auth-denial-of-existence-dns-04.txt Diff: http://www.ietf.org/rfcdiff?url2=draft-gieben-auth-denial-of-existence-dns-04 Regards, Miek Gieben From fanf2@hermes.cam.ac.uk Mon Nov 25 07:44:01 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911761ADED5 for ; Mon, 25 Nov 2013 07:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-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 rohgG7qblt2C for ; Mon, 25 Nov 2013 07:43:58 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4D01ADF56 for ; Mon, 25 Nov 2013 07:43:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41674) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VkyKL-0006ua-6V (Exim 4.82_3-c0e5623) (return-path ); Mon, 25 Nov 2013 15:43:57 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VkyKK-0003Q0-Ul (Exim 4.72) (return-path ); Mon, 25 Nov 2013 15:43:56 +0000 Date: Mon, 25 Nov 2013 15:43:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Miek Gieben In-Reply-To: <20131125140508.GB20994@miek.nl> Message-ID: References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:44:01 -0000 Miek Gieben wrote: > Matthijs and I added an extra appendix to cover on-line signing and > made some tweaks to the rest of the text. Looks good. A point I just noticed in section 3 which I think could do with elaborating: Given all these troubles, why didn't the designers of DNSSEC go for the (easy) route and allowed for on-line signing? Well, at that time (pre 2000), on-line signing was not feasible with the then current hardware. Keep in mind that the larger servers get between 2000 and 6000 queries per second (qps), with peaks up to 20,000 qps or more. Scaling signature generation to these kind of levels is always a challenge. Another issue was (and is) key management, for on-line signing to work you need access to the private key(s). This is considered a security risk. I think it is worth saying that online signing makes it difficult to have third party secondary authoritative servers, since they would need a copy of the private ZSK. With normal DNSSEC, even with a dynamically updated zone, the private keys do not need to be on a publicly accessible machine. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Jelte.Jansen@sidn.nl Mon Nov 25 07:56:22 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1C1ADEA7 for ; Mon, 25 Nov 2013 07:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.093 X-Spam-Level: X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 YZKR_rs78_WS for ; Mon, 25 Nov 2013 07:56:20 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 37CFA1ADBFF for ; Mon, 25 Nov 2013 07:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=nLkt0uPbNH3O8VajyGaCTcW4STF035wZrmq9frpkD/8=; b=EmN6Ujtm7Nrhb1N3Nbc8sL+coQ1UKKna+49xm0i/eMvMzeMRLg+zQTfG3jk4ZNJDi6TzBdHPmRpMJtqvjVSNxUchOvAyPptYAhbt7Ai/p3wtB/Y8E4oJPcnaR1wg7lJVcTKHKLgJLd8aw/iFyha6wZd17AlBu3QyEvi3WwwlexU= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id rAPFtmUM031687-rAPFtmUO031687 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Mon, 25 Nov 2013 16:55:48 +0100 Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 16:55:47 +0100 Message-ID: <52937303.4070904@sidn.nl> Date: Mon, 25 Nov 2013 16:55:47 +0100 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tony Finch , Miek Gieben References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.214] Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:56:22 -0000 On 11/25/2013 04:43 PM, Tony Finch wrote: > Miek Gieben wrote: > >> Matthijs and I added an extra appendix to cover on-line signing and >> made some tweaks to the rest of the text. > > Looks good. > > A point I just noticed in section 3 which I think could do with > elaborating: > > Given all these troubles, why didn't the designers of DNSSEC go > for the (easy) route and allowed for on-line signing? Well, at > that time (pre 2000), on-line signing was not feasible with the > then current hardware. Keep in mind that the larger servers get > between 2000 and 6000 queries per second (qps), with peaks up to > 20,000 qps or more. Scaling signature generation to these kind of > levels is always a challenge. Another issue was (and is) key > management, for on-line signing to work you need access to the > private key(s). This is considered a security risk. > > I think it is worth saying that online signing makes it difficult to have > third party secondary authoritative servers, since they would need a copy > of the private ZSK. With normal DNSSEC, even with a dynamically updated > zone, the private keys do not need to be on a publicly accessible machine. > now that you quote it like that, I think that using 'allowed' in that first line is misleading; it's not so much that the protocol doesn't allow on-line signing, the requirement was that it didn't have to rely on it. Also, IIRC the preferred term was on-the-fly rather than on-line. Need to re-read doc :) Jelte From fanf2@hermes.cam.ac.uk Mon Nov 25 07:59:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCCA1ADED7 for ; Mon, 25 Nov 2013 07:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 sXRqNZUnqq_p for ; Mon, 25 Nov 2013 07:59:12 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id CABCB1ADEA7 for ; Mon, 25 Nov 2013 07:59:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44721) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1VkyZ4-0002ya-2X (Exim 4.82_3-c0e5623) (return-path ); Mon, 25 Nov 2013 15:59:10 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VkyZ4-0004aU-Nd (Exim 4.72) (return-path ); Mon, 25 Nov 2013 15:59:10 +0000 Date: Mon, 25 Nov 2013 15:59:10 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jelte Jansen In-Reply-To: <52937303.4070904@sidn.nl> Message-ID: References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> <52937303.4070904@sidn.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:59:14 -0000 Jelte Jansen wrote: > > now that you quote it like that, I think that using 'allowed' in that > first line is misleading; it's not so much that the protocol doesn't > allow on-line signing, the requirement was that it didn't have to rely > on it. Also, IIRC the preferred term was on-the-fly rather than on-line. Good points. What's the best opposite for on-the-fly? Pre-signed? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Jelte.Jansen@sidn.nl Mon Nov 25 08:05:16 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3A1ADF7F for ; Mon, 25 Nov 2013 08:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.093 X-Spam-Level: X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 DUs6eVMjkyoh for ; Mon, 25 Nov 2013 08:05:14 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id BC2781ADF6E for ; Mon, 25 Nov 2013 08:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=oxRcACLE7bxHwU1LJ7CE3OhOE3gVUlQTF0/OJxcfpnY=; b=KShBl2esFckAa2rlzZB2U0V+i2pT3qaoiLlyN83pYv+K5R1ygduX63mmPSC8DX3wZoDY8Y4ajIbhFhKWKv4DI48ilRfKPusa1Hp6stcIuX/KpWirIchMcWI60xiJ130l54DD5+2wAifmrNVCboDYd947v38W3bxDHG+Bc8D9nG8= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id rAPG4WkB032155-rAPG4WkE032155 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Mon, 25 Nov 2013 17:04:42 +0100 Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 17:04:39 +0100 Message-ID: <52937517.9060503@sidn.nl> Date: Mon, 25 Nov 2013 17:04:39 +0100 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tony Finch References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> <52937303.4070904@sidn.nl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.214] Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:05:17 -0000 On 11/25/2013 04:59 PM, Tony Finch wrote: > Jelte Jansen wrote: >> >> now that you quote it like that, I think that using 'allowed' in that >> first line is misleading; it's not so much that the protocol doesn't >> allow on-line signing, the requirement was that it didn't have to rely >> on it. Also, IIRC the preferred term was on-the-fly rather than on-line. > > Good points. What's the best opposite for on-the-fly? Pre-signed? > I guess so, or maybe pre-generated in a slightly wider context Jelte From matthijs@nlnetlabs.nl Mon Nov 25 23:14:08 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3031AE194 for ; Mon, 25 Nov 2013 23:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.907 X-Spam-Level: X-Spam-Status: No, score=-99.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 rhePWSpLbmRA for ; Mon, 25 Nov 2013 23:14:06 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 691241AE192 for ; Mon, 25 Nov 2013 23:14:06 -0800 (PST) Received: from [IPv6:2001:981:19be:1:b8ae:58e:dfb5:8bd1] ([IPv6:2001:981:19be:1:b8ae:58e:dfb5:8bd1]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rAQ7E1g2080732 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 26 Nov 2013 08:14:02 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rAQ7E1g2080732 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1385450043; bh=qe1XWFfVxU0o0NC9lbbMpW/czpljh9l0okTpWlcoiSU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=tX2/pw+vgdoS8RKfwpFpghN5ESByTORzc4e8lxYmrNSDHkdyGPhcqkHvhCSqr44vM x7d0MhkTf2ZjsePVak96X5r1MJdZlwdDQ4M/XFIpbnCmOaJ9s6lE56r2NKSmF/zOcx z7XUdCmCKBvyFuJDc+pvcz7gY/u3B4yOboY7qhJE= Message-ID: <52944A39.50602@nlnetlabs.nl> Date: Tue, 26 Nov 2013 08:14:01 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tony Finch , Jelte Jansen References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> <52937303.4070904@sidn.nl> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 26 Nov 2013 08:14:03 +0100 (CET) Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 07:14:08 -0000 On 11/25/2013 04:59 PM, Tony Finch wrote: > Jelte Jansen wrote: >> >> now that you quote it like that, I think that using 'allowed' in that >> first line is misleading; it's not so much that the protocol doesn't >> allow on-line signing, the requirement was that it didn't have to rely >> on it. Also, IIRC the preferred term was on-the-fly rather than on-line. > > Good points. What's the best opposite for on-the-fly? Pre-signed? > > Tony. > I don't want to be nitpicking on words, but RFC 4470 has "on-line signing" in its title. And then off-line seems to me the obvious opposite. I do prefer "requirement of not relying on it" better than "allowed" Best regards, Matthijs From fanf2@hermes.cam.ac.uk Tue Nov 26 02:56:46 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DBF1AE1B0 for ; Tue, 26 Nov 2013 02:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 7j5uCWIMeLpD for ; Tue, 26 Nov 2013 02:56:44 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id D86C21AE1A2 for ; Tue, 26 Nov 2013 02:56:43 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58610) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VlGJs-00051D-Fh (Exim 4.82_3-c0e5623) (return-path ); Tue, 26 Nov 2013 10:56:40 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VlGJs-0008Sw-QK (Exim 4.72) (return-path ); Tue, 26 Nov 2013 10:56:40 +0000 Date: Tue, 26 Nov 2013 10:56:40 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <52944A39.50602@nlnetlabs.nl> Message-ID: References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> <52937303.4070904@sidn.nl> <52944A39.50602@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:56:46 -0000 Matthijs Mekking wrote: > > I don't want to be nitpicking on words, but RFC 4470 has "on-line > signing" in its title. And then off-line seems to me the obvious opposite. I would really like to avoid that because too many people think DNSSEC zone signing has to be a batch operation. It would be nice to have a phrase that also covers incremental dynamic signing. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From matthijs@nlnetlabs.nl Thu Nov 28 02:14:36 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14A21AD687 for ; Thu, 28 Nov 2013 02:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.907 X-Spam-Level: X-Spam-Status: No, score=-99.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 oIU9YTklbTAK for ; Thu, 28 Nov 2013 02:14:35 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 617481ABBB1 for ; Thu, 28 Nov 2013 02:14:35 -0800 (PST) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rASAESDc015490 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 28 Nov 2013 11:14:29 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rASAESDc015490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1385633673; bh=2+xDzeOODLsQ4Y2rnk3WFkZDekBb/aNhjNGmbsjKQ1E=; h=Date:From:To:Subject:References:In-Reply-To; b=A5X3u/bC5rKkYZaHrLn0sFqpDslTi422pZ46zsMIWZAinW6t8vmaE1ORRjwOL28ib M3Jv5yITaudp35kPJbskwQF0FWk0L0qpE7b6iifg17Wm1SwsDVY5HbePdhCHCP/fjI ML2LxlZFSbxN/owoKIXbMzzOcFPMMudhk2wNckuc= X-Authentication-Warning: open.nlnetlabs.nl: Host zoidberg.nlnetlabs.nl [213.154.224.18] claimed to be [213.154.224.18] Message-ID: <52971784.6050700@nlnetlabs.nl> Date: Thu, 28 Nov 2013 11:14:28 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <21132.63250.716415.755401@gro.dd.org> <20131125140508.GB20994@miek.nl> <52937303.4070904@sidn.nl> <52944A39.50602@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 28 Nov 2013 11:14:29 +0100 (CET) Subject: Re: [dnsext] Authenticated denial of existence... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 10:14:37 -0000 Hi, FYI, Miek and I posted a new version of this document which diff is very small compared to -04. Best regards, Matthijs Changelog: 1. Minor fixes and adjustments. URL: http://www.ietf.org/internet-drafts/draft-gieben-auth-denial-of-existence-dns-05.txt Diff: http://www.ietf.org/rfcdiff?url2=draft-gieben-auth-denial-of-existence-dns-05 Abstract: Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists, but does not have the specific RR type you were asking for. When returning a negative DNSSEC response, a name server usually includes up to two NSEC records. With NSEC3 this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial of existence responses.