From nobody Wed Feb 10 04:26:44 2016 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 15A971A21A4 for ; Wed, 10 Feb 2016 04:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] 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 YELhhi22Ne1O for ; Wed, 10 Feb 2016 04:26:41 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CE01A21B2 for ; Wed, 10 Feb 2016 04:26:41 -0800 (PST) Received: from [46.227.151.81] (port=51655 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1aTTqv-000685-LH (Exim 4.72) (return-path ); Wed, 10 Feb 2016 12:26:37 +0000 To: wriedel@cisco.com From: Ray Bellis X-Enigmail-Draft-Status: N1110 Message-ID: <56BB2C7E.2000206@bellis.me.uk> Date: Wed, 10 Feb 2016 12:26:38 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] DNS-AS RRTYPE PARAMETER ALLOCATION 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, 10 Feb 2016 12:26:43 -0000 Wolfgang, I've been appointed as the designated expert to review your RRTYPE application per RFC 6895. In principle the application is OK, and it's highly desirable that you avoid use of TXT. Within my remit however I do have some concerns over the name of the RRTYPE: - the term "authoritative" has a particular meaning in the DNS protocol, and "authoritative source" is a commonly used term too. Typing "dns authoritative source" into Google already produces 75,000 results, none that I could see relating to your project. - using "DNS" within the RRTYPE name seems redundant - we're already in the DNS. - the letters "AS" are also commonly used to refer to a BGP "Autonomous System". [FWIW, when I first saw your requested mnemonic in the subject of your application I was expecting to see an application for an RRTYPE to represent a BGP AS number!] Also missing is any explicit statement that the intended wire and presentation format are identical to that of a TXT record. Consideration should also be given to what happens if the data does not fit within a single 255 octet "character-string" sub-field. Incidentally, the "CISCO-CLS=" prefix in the RDATA would appear to be redundant when you get your own RRTYPE, and if it's expected that other vendors would use this then I suggest that you either omit it or use something more neutral. At a higher level I have concerns about the overall use case that should be addressed if you plan to document "DNS Authoritative Source" in an Internet Draft (although I don't expect these to be a factor in my decision as they're probably outside the scope of RFC 6895): - why DNS? How does the client know what domain names are supposed to be looked up? - if the "Application Name" is the primary key, why not incorporate that into the domain name? - (corollary) is it expected that a client would want to (or even be allowed to) obtain information about all known applications at a domain with a single DNS query? - what about DNS Security? What happens in your SDN if someone manages to poison a record? The decision will be reached within two weeks of today, and before approval the explicit linking to the TXT record format must be resolved. I urge you to reconsider your project name of "DNS Authoritative Source" as being a clash with existing terminology. I'm not currently inclined to reject the application on that basis of the requested DNSAS mnemonic, but welcome community feedback on that issue. kind regards, Ray Bellis From nobody Wed Feb 10 07:54:27 2016 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 0D1D21B2B76 for ; Wed, 10 Feb 2016 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 7zp6ZnfTEP_2 for ; Wed, 10 Feb 2016 07:54:21 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F021A9118 for ; Wed, 10 Feb 2016 07:54:21 -0800 (PST) Received: from [46.227.151.81] (port=55555 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1aTX5t-0005jI-KB (Exim 4.72) for dnsext@ietf.org (return-path ); Wed, 10 Feb 2016 15:54:17 +0000 To: dnsext@ietf.org References: <56BB2C7E.2000206@bellis.me.uk> From: Ray Bellis Message-ID: <56BB5D2B.3090007@bellis.me.uk> Date: Wed, 10 Feb 2016 15:54:19 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BB2C7E.2000206@bellis.me.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnsext] DNS-AS RRTYPE PARAMETER ALLOCATION 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, 10 Feb 2016 15:54:26 -0000 For reference, since the requester didn't send the application to dnsext, the application can be seen at: with the filled-in template at: Ray From nobody Sat Feb 13 13:42:05 2016 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 D6C031A7013 for ; Sat, 13 Feb 2016 12:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.806 X-Spam-Level: X-Spam-Status: No, score=-13.806 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fizRxFmbGErj for ; Sat, 13 Feb 2016 12:36:41 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4991A1AB3 for ; Sat, 13 Feb 2016 12:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24772; q=dns/txt; s=iport; t=1455395801; x=1456605401; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M4Zre4w66sk4oaiGdGcH2kzUY+krGUQJElx1ZqhQi2Q=; b=JkhV5EJvNsGELQKp6zKGNFQx0VQHKwt291i8/zDX8nDfr6u9gL3ATpo6 ssWEfycTSX281E+m2IpaRlvJrmhbngG30tI/DNVYHT+TJrfGqE1m8epPi JeFh2MIcP1Y4ttUNSff5slkw7sTlR13WCa2a+4UHfnP/RYoru+At7VACo o=; X-Files: signature.asc : 872 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AgDWkr9W/5hdJa1UCoJuTFJtBrd9g?= =?us-ascii?q?hMOgWcZhXQCgSg4FAEBAQEBAQGBCoRBAQEBAwEjSA4FCwIBCBggCgICMiUCBA4?= =?us-ascii?q?FDgYLh3MIrDuOQgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhhGBa4JKhAgSVoJCK?= =?us-ascii?q?4EPBYdVhVKFR4QLAYMAgWRqiAaBXIRDiFWOPQEPDwFDg2NqiTV8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,442,1449532800"; d="asc'?scan'208,217";a="238045796" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2016 20:36:40 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1DKadIT024899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2016 20:36:40 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 13 Feb 2016 14:36:39 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Sat, 13 Feb 2016 14:36:39 -0600 From: "Wolfgang Riedel (wriedel)" To: Ray Bellis Thread-Topic: DNS-AS RRTYPE PARAMETER ALLOCATION Thread-Index: AQHRY/5NTWKudmU6QEKjV5II8zU5uZ8q2Q6A Date: Sat, 13 Feb 2016 20:36:38 +0000 Message-ID: References: <56BB2C7E.2000206@bellis.me.uk> In-Reply-To: <56BB2C7E.2000206@bellis.me.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.215.77] Content-Type: multipart/signed; boundary="Apple-Mail=_F8EDD7BC-C6D6-410A-8E5F-90BE60FCDC47"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 13 Feb 2016 13:42:04 -0800 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] DNS-AS RRTYPE PARAMETER ALLOCATION 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: Sat, 13 Feb 2016 20:36:44 -0000 --Apple-Mail=_F8EDD7BC-C6D6-410A-8E5F-90BE60FCDC47 Content-Type: multipart/alternative; boundary="Apple-Mail=_59723724-6638-4E1C-B3B2-8BCC265C5D0B" --Apple-Mail=_59723724-6638-4E1C-B3B2-8BCC265C5D0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ray, may thanks for your reply. I consultant with some colleagues and were good with filing a new = request and replace the mnemonic =3D DNSAS with mnemonic =3D AVC as you = suggested. Also some answer to your question inline. For all other on list, if you=E2=80=99re looking for more details on = DNS-AS please have look at http://dns.as.org Thank you, Wolfgang > On 10 Feb 2016, at 13:26PM, Ray Bellis wrote: >=20 > Wolfgang, >=20 > I've been appointed as the designated expert to review your RRTYPE > application per RFC 6895. >=20 > In principle the application is OK, and it's highly desirable that you > avoid use of TXT. >=20 > Within my remit however I do have some concerns over the name of the = RRTYPE: >=20 > - the term "authoritative" has a particular meaning in the DNS > protocol, and "authoritative source" is a commonly used term > too. Typing "dns authoritative source" into Google already > produces 75,000 results, none that I could see relating to > your project. yes I agree and we have chosen the wording by intension to outline that = we leverage the authoritative name server as a sigle source of truth for = application metadata. > - using "DNS" within the RRTYPE name seems redundant - we=E2=80=99re = already in the DNS. agree > - the letters "AS" are also commonly used to refer to a BGP = "Autonomous System=E2=80=9D. agree > [FWIW, when I first saw your requested mnemonic in the subject of your > application I was expecting to see an application for an RRTYPE to > represent a BGP AS number!] it=E2=80=99s not so far off given that BGP expresses routing policy = intend and DNS-AS metadata for application policy intend > Also missing is any explicit statement that the intended wire and > presentation format are identical to that of a TXT record. > Consideration should also be given to what happens if the data does = not > fit within a single 255 octet "character-string" sub-field. OK will adress this > Incidentally, the "CISCO-CLS=3D" prefix in the RDATA would appear to = be > redundant when you get your own RRTYPE, and if it's expected that = other > vendors would use this then I suggest that you either omit it or use > something more neutral. yes good catch and I agree and will remove this > At a higher level I have concerns about the overall use case that > should be addressed if you plan to document "DNS Authoritative Source" > in an Internet Draft (although I don't expect these to be a factor in = my > decision as they're probably outside the scope of RFC 6895): at this time there are not plans to submit this as an Internet Draft > - why DNS? Readily available tool - already leveraged to identify an application by = DNS-NAME > How does the client know what domain names are supposed to be looked = up? it=E2=80=99s a function of an DNS-AS client which snoop DNS request as = an trigger and raises it=E2=80=99s own query for a DNS-AS Resource = Record to get the metadata to enforce policy later > - if the "Application Name" is the primary key, why not incorporate > that into the domain name? This =E2=80=98could be done=E2=80=99 - but most customers don=E2=80=99t = or won=E2=80=99t always identify what application is running on a server = via it=E2=80=99s FQDN. > - (corollary) is it expected that a client would want to (or even > be allowed to) obtain information about all known applications at > a domain with a single DNS query? there is nothing confidential inside a DNS-AS resource record. The key is that it it authoritative! > - what about DNS Security? What happens in your SDN if someone > manages to poison a record? what happens if I haven't done my homework and didn=E2=80=99t secure and = harden my DNS infrastructure ;-) If DNS is compromised you have bigger problems than how a network = element chooses mark and service (queue) for a given application... > The decision will be reached within two weeks of today, and before > approval the explicit linking to the TXT record format must be = resolved. >=20 > I urge you to reconsider your project name of "DNS Authoritative = Source" > as being a clash with existing terminology. I'm not currently inclined > to reject the application on that basis of the requested DNSAS = mnemonic, > but welcome community feedback on that issue. yes will file a new request for mnemonic =3D AVC >=20 > kind regards, >=20 > Ray Bellis --Apple-Mail=_59723724-6638-4E1C-B3B2-8BCC265C5D0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ray,

may= thanks for your reply.

I consultant with some colleagues and were good with filing a = new request and replace the mnemonic =3D DNSAS with mnemonic =3D AVC as = you suggested.
Also some answer to your question = inline.

For = all other on list, if you=E2=80=99re looking for more details on DNS-AS = please have look at http://dns.as.org

Thank = you,
Wolfgang

<= /span>
<= /div>

On 10 Feb 2016, at 13:26PM, Ray Bellis <ray@bellis.me.uk> = wrote:

Wolfgang,

I've been appointed as = the designated expert to review your RRTYPE
application = per RFC 6895.

In principle the application = is OK, and it's highly desirable that you
avoid use of = TXT.

Within my remit however I do have some = concerns over the name of the RRTYPE:

- the = term "authoritative" has a particular meaning in the DNS
=  protocol, and "authoritative source" is a commonly used term
 too.  Typing "dns authoritative source" into = Google already
 produces 75,000 results, none that I = could see relating to
 your project.

yes I = agree and we have chosen the wording by intension to outline that we = leverage the authoritative name server as a sigle source of truth for = application metadata.

- using "DNS" within the = RRTYPE name seems redundant - we=E2=80=99re already in the DNS.

agree

- the letters "AS" are also = commonly used to refer to a BGP "Autonomous System=E2=80=9D.

agree

[FWIW, when I first saw your = requested mnemonic in the subject of your
application I = was expecting to see an application for an RRTYPE to
represent a BGP AS number!]

it=E2=80= =99s not so far off given that BGP expresses routing policy intend and = DNS-AS metadata for application policy intend

Also missing is any explicit statement that the intended wire = and
presentation format are identical to that of a TXT = record.
Consideration should also be given to what happens = if the data does not
fit within a single 255 octet = "character-string" sub-field.

OK = will adress this

Incidentally, the = "CISCO-CLS=3D" prefix in the RDATA would appear to be
redundant when you get your own RRTYPE, and if it's expected = that other
vendors would use this then I suggest that you = either omit it or use
something more neutral.

yes = good catch and I agree and will remove this

At a higher level I have concerns about the overall use case =  that
should be addressed if you plan to document = "DNS Authoritative Source"
in an Internet Draft (although = I don't expect these to be a factor in my
decision as = they're probably outside the scope of RFC 6895):

at = this time there are not plans to submit this as an Internet = Draft

-  why DNS? =  

Readily = available tool - already leveraged to identify an application by = DNS-NAME

How does the client know what domain names = are supposed to be looked up?

it=E2=80= =99s a function of an DNS-AS client which snoop DNS request as an = trigger and raises it=E2=80=99s own query for a DNS-AS Resource Record = to get the metadata to enforce policy later

-  if the "Application Name" is the primary key, why not = incorporate
  that into the domain name?

This = =E2=80=98could be done=E2=80=99 - but most customers don=E2=80=99t or = won=E2=80=99t always identify what application is running on a server = via it=E2=80=99s FQDN. 

 - (corollary) is it = expected that a client would want to (or even
=    be allowed to) obtain information about all known = applications at
   a domain with a single = DNS query?

there is nothing confidential inside a DNS-AS = resource record. 
The key is that it it = authoritative!

-  what about DNS = Security?  What happens in your SDN if someone
=   manages to poison a record?

what = happens if I haven't done my homework and didn=E2=80=99t secure and = harden my DNS infrastructure ;-)
If DNS is compromised you = have bigger problems than how a network element chooses mark and service = (queue) for a given application...

The decision = will be reached within two weeks of today, and before
approval the explicit linking to the TXT record format must = be resolved.

I urge you to reconsider your = project name of "DNS Authoritative Source"
as being a = clash with existing terminology. I'm not currently inclined
to reject the application on that basis of the requested = DNSAS mnemonic,
but welcome community feedback on that = issue.

yes will file a new request for mnemonic =3D = AVC


kind regards,

Ray Bellis

= --Apple-Mail=_59723724-6638-4E1C-B3B2-8BCC265C5D0B-- --Apple-Mail=_F8EDD7BC-C6D6-410A-8E5F-90BE60FCDC47 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----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJWv5PUAAoJECTe5TeQF2Aswi0QALQFMnHXGD2lf9FqxgT7FRSO OmKIwlDHDyBGVzEy8srywqO6uTfcIb2I3NFFl18sMkbXc7E7ZG6H4RGq8HIws+nh n0uDlBD01Eh3y4C80RF6cm3w+/goHWOLKJ4CoYswGhMvzNpiWXtUmPS2MrsFY4lA 7iszs+0uD8Pz98pHO6eqiq6X1fhYLu/5G2wH1+hNnqBQk8LGNg/a3BYqX3JWu8z3 CbIpmdIrd0LDSQUVOfr7ZPUsZTmzbXDHYMxhBWWw0XWfyr4Zf/g4BLZ3hySJ93NF lI5oQ3NcGdW/SeqTGWOHwU12F9Olvb4fHQGsupiTLiY1Dio9gDMOWBFHsykQYzRj lXWI+aIs5mCIJ6vtN4m6VZBuSCYeeczYm9H8OzzTPvYLvxr9GyHFpzPRaBIRI0pY eyGbMowRMalO1lSq3OFc2Rq6N7CrGxl/NTTtZLSgqLWWlfMgAazxB8tWkK73R1z9 h+kSjBC2/rtVa/aTKIHwwLaRKX3RIz14I328uc39eOEUOQw4x62zz9ADTG/FaH2F BSPZr4VXzGg0mO5/xB1Y5WXxi43nLLXKwgjAJlUTTiy3snRDiklZOrGaPpMznmFG 1H0d5hsDulpxhXaR2s7aZ7KFJpRFhxXwWcByVADwusIZ+f9pzEYJ84ZaGhlIFsE7 Rhc/e5fkqwx21RZ7b8eS =SbV/ -----END PGP SIGNATURE----- --Apple-Mail=_F8EDD7BC-C6D6-410A-8E5F-90BE60FCDC47-- From nobody Sat Feb 13 13:48:21 2016 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 D0C091A87DB for ; Sat, 13 Feb 2016 13:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 2v_JlpkCSJmc for ; Sat, 13 Feb 2016 13:48:20 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A011A87D1 for ; Sat, 13 Feb 2016 13:48:19 -0800 (PST) Received: (qmail 16743 invoked from network); 13 Feb 2016 21:48:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=4166.56bfa4a2.k1602; bh=88JMYo1jfPQwKahqh5trP2GyG3I9H5JAd0Hqi16VVII=; b=exWbvOJGXJ1+AF//ANXpanKlw/5fRnukn2RZ7ZkR0/LUMXn+vx+7XOV4xP7EK5mB/b0M3LSwQpCguJ1HKi0jvgCQ09VgXIrMxYPXsN3AJLUn8ADFsmV0GhIippjhEw5+Co9UF8RW2MH4kh+ikfKnPCj7NTn8PtLgB1fBU8k5KTz2qOjozKcO8bshPece7k3mDyzDAsHaLNVeba9RVzxeTk2P+CPvdvCKRdR5G2iXEO+0aUwdUC2djKpZV2kLlgsq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=4166.56bfa4a2.k1602; bh=88JMYo1jfPQwKahqh5trP2GyG3I9H5JAd0Hqi16VVII=; b=H1CPdbzX+ANIkVhENZXjkquUcl/cgdcd7dBVQyaZ2FrRKk6NR42yavyRkuKkOGZKxIAUiGI4xfay+GCiEhj3BDiuyo+mgAIKG2W8HWZDYUzvuVnWmm8AP+ukoA4PKNIDLiFhtheDOpUcTcAa64Zjc7XGyfxHKnLteOZY7PPAwqmxPjQ2Ur+gd5oFVgYHmgn/WbMPai2UMrOpiiblar1+necy8orcsgvYR3DdoCkPWUF0dEqG3cb5OYioaXrNSw/b Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 13 Feb 2016 21:48:18 -0000 Date: 13 Feb 2016 16:48:18 -0500 Message-ID: From: "John R Levine" To: dnsext@ietf.org User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: [dnsext] Any interest in draft-latour-dnsoperator-to-rrr-protocol ? 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: Sat, 13 Feb 2016 21:48:21 -0000 I noticed the -02 of this draft go by yesterday. It's a very rough version of a DNSSEC key record bootstrap design in which the operator of the delegated zone pokes the operator of the upper level zone using http, which tells the upper level zone to import keys from the delegated zone's CDS and CDNSKEY records. Is there much interest in this? On my tiny DNS server I have over 100 signed zones where I can't install the upper level DS records because I'm not the registrant, I'm just running their DNS. It would be nice to have a way to do that that scales better than walking each of the registrants through their registrars' DNSSEC update processes. R's, John From nobody Tue Feb 16 13:11:48 2016 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 8D4F91B2FD4 for ; Tue, 16 Feb 2016 13:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.006, 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 9LJVPC_NSPZG for ; Tue, 16 Feb 2016 13:11:46 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF931B2C4C for ; Tue, 16 Feb 2016 13:11:39 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 2E6D23F432; Tue, 16 Feb 2016 16:11:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22211.37002.133734.319655@gro.dd.org> Date: Tue, 16 Feb 2016 16:11:38 -0500 From: Dave Lawrence To: "John R Levine" In-Reply-To: References: Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] Any interest in draft-latour-dnsoperator-to-rrr-protocol ? 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, 16 Feb 2016 21:11:48 -0000 John R Levine writes: > I noticed the -02 of this draft go by yesterday. > > It's a very rough version of a DNSSEC key record bootstrap design in which > the operator of the delegated zone pokes the operator of the upper level > zone using http, which tells the upper level zone to import keys from the > delegated zone's CDS and CDNSKEY records. > > Is there much interest in this? I'm not sure how measure "much", but yes there is interest from third-party operators like Akamai and CloudFlare because we can't provide end-to-end DNSSEC services without currently involving a manual interaction between the customer and their registrar. From nobody Thu Feb 18 07:54:57 2016 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 0777B1A06E9 for ; Wed, 17 Feb 2016 17:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rIlLrgPYmOXB for ; Wed, 17 Feb 2016 17:36:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3DC1A0235 for ; Wed, 17 Feb 2016 17:36:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0ABC6180209; Wed, 17 Feb 2016 17:36:20 -0800 (PST) To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com, brian@innovationslab.net, terry.manderson@icann.org, ogud@ogud.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160218013620.0ABC6180209@rfc-editor.org> Date: Wed, 17 Feb 2016 17:36:20 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 07:54:56 -0800 Cc: edmonds@mycre.ws, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC5155 (4622) 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, 18 Feb 2016 01:36:41 -0000 The following errata report has been submitted for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622 -------------------------------------- Type: Technical Reported by: Robert Edmonds Section: 7.2.8 Original Text ------------- 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist. Corrected Text -------------- 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME besides NSEC3, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist. Notes ----- If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Thu Feb 18 09:46:48 2016 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 A6E891A003A for ; Thu, 18 Feb 2016 09:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 yHrd0NnCgvcr for ; Thu, 18 Feb 2016 09:46:44 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0320D1A1BF1 for ; Thu, 18 Feb 2016 09:46:43 -0800 (PST) Received: from [46.227.151.81] (port=54150 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1aWSf0-0006HX-QI (Exim 4.72) for dnsext@ietf.org (return-path ); Thu, 18 Feb 2016 17:46:38 +0000 References: <26590E02-7D2E-4720-8084-9133F4BE03BA@cisco.com> To: dnsext@ietf.org From: Ray Bellis X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <26590E02-7D2E-4720-8084-9133F4BE03BA@cisco.com> Message-ID: <56C60381.9090406@bellis.me.uk> Date: Thu, 18 Feb 2016 17:46:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <26590E02-7D2E-4720-8084-9133F4BE03BA@cisco.com> Content-Type: multipart/mixed; boundary="------------030909090305030200010408" Archived-At: Subject: [dnsext] Fwd: [dns-rrtype-applications] DNS-AS RRTYPE PARAMETER ALLOCATION 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, 18 Feb 2016 17:46:46 -0000 This is a multi-part message in MIME format. --------------030909090305030200010408 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Wolfgang Riedel has submitted an updated application (attached), addressing my previous comments by replacing the mnemonic with "AVC", and also now explicitly documenting that the RDATA format is identical to a "TXT" record. I see no reason to reject this application, and intend to approve it on Monday unless there's any vigorous objections. Ray Bellis -------- Forwarded Message -------- Subject: [dns-rrtype-applications] dns-rrtype-applications] DNS-AS RRTYPE PARAMETER ALLOCATION Date: Sun, 14 Feb 2016 09:05:14 +0000 From: Wolfgang Riedel (wriedel) To: iana-prot-param@iana.org , dns-rrtype-applications@ietf.org Hello, as requested attached our re-worked request for an assignment for a new DNS Resource Record for mnemonic=AVC. Please let me know if there is anything unclear or missing and what the next steps would be. --------------030909090305030200010408 Content-Type: text/plain; charset=UTF-8; name="DNS-AS-RR-AVC-apply.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DNS-AS-RR-AVC-apply.txt" ICAgICAgICAgICAgICAgICBETlMgUlJUWVBFIFBBUkFNRVRFUiBBTExPQ0FUSU9OIFRFTVBM QVRFDQoNCiAgIFdoZW4gcmVhZHkgZm9yIGZvcm1hbCBjb25zaWRlcmF0aW9uLCB0aGlzIHRl bXBsYXRlIGlzIHRvIGJlIHN1Ym1pdHRlZA0KICAgdG8gSUFOQSBmb3IgcHJvY2Vzc2luZyBi eSBlbWFpbGluZyB0aGUgdGVtcGxhdGUgdG8gZG5zLXJydHlwZS1hcHBsaWNhdGlvbnNAaWV0 Zi5vcmcuDQoNCiAgIEEuIFN1Ym1pc3Npb24gRGF0ZToNCg0KICAgQi4xIFN1Ym1pc3Npb24g VHlwZTogIFtYXSBOZXcgUlJUWVBFICBbIF0gTW9kaWZpY2F0aW9uIHRvIFJSVFlQRQ0KICAg Qi4yIEtpbmQgb2YgUlI6ICBbWF0gRGF0YSBSUiAgWyBdIE1ldGEtUlINCg0KICAgQy4gQ29u dGFjdCBJbmZvcm1hdGlvbiBmb3Igc3VibWl0dGVyICh3aWxsIGJlIHB1YmxpY2x5IHBvc3Rl ZCk6DQogICAgICBOYW1lOiBXb2xmZ2FuZyBSaWVkZWwgICAgICAgRW1haWwgQWRkcmVzczog d29sZmdhbmdAY2lzY28uY29tDQogICAgICBJbnRlcm5hdGlvbmFsIHRlbGVwaG9uZSBudW1i ZXI6ICs0OS04MTEtNTU5LTU0NTANCiAgICAgIE90aGVyIGNvbnRhY3QgaGFuZGxlczogDQoN CiAgIEQuIE1vdGl2YXRpb24gZm9yIHRoZSBuZXcgUlJUWVBFIGFwcGxpY2F0aW9uLg0KDQog ICAgICBDaXNjbyBoYXMgZGV2ZWxvcGVkIGEgbmV3IHVzZSBjYXNlIGZvciBETlMgY2FsbGVk ICJETlMgQXV0aG9yaXRhdGl2ZSBTb3VyY2UiIA0KICAgICAgaW4gc2hvcnQgRE5TLUFTLiBU aGlzIHVzZSBjYXNlIHVzZXMgdGhlIEROUyB0byBzdG9yZSBhbmQgcHJvdmlkZSAKICAgICAg bWV0YWRhdGEgYWJvdXQgYXBwbGljYXRpb25zLg0KICAgICAgVGhpcyBkYXRhIGlzIHByaW1h cmlseSBpbnRlbmRlZCB0byBiZSB1c2VkIGZvciBtZXRhZGF0YSBkcml2ZW4gDQogICAgICBB cHBsaWNhdGlvbiBWaXNpYmlsaXR5IGFuZCBDb250cm9sIGluIHNob3J0IEFWQy4NCiAgICAg IA0KICAgICAgT24gbmV0d29yayBlbGVtZW50cyBpdCBjYW4gYmUgdXNlZCBhcyBhIGtleSB0 byBsaW5rIGFwcGxpY2F0aW9uIHRvIHBvbGljeSANCiAgICAgIGluIHN1cHBvcnQgb2YgdGhv c2UgYXBwbGljYXRpb25zIGFzIGFsc28gZm9yIHZpc3VhbGl6YXRpb24gYWZ0ZXJ3YXJkcy4N CiAgICAgIEZvciBleGFtcGxlLCBhIG5ldHdvcmsgZWxlbWVudCBtaWdodCB1c2UgdGhlIGlu Zm9ybWF0aW9uDQogICAgICBvYnRhaW5lZCB0aHJvdWdoIHRoZSBBVkMgUlJUWVBFIHRvIHNl dCBRb1Mgb3IgYWNjZXNzIHBvbGljaWVzIGZvcg0KICAgICAgdHJhZmZpYyB0byBvciBmcm9t IGEgc3BlY2lmaWMgYXBwbGljYXRpb24uIA0KICAgICAgV2UgYXJlIGFwcGx5aW5nIGZvciBh IG5ldyBSUlRZUEUgdGhhdCBjYW4gaG9sZCB0aGUgYXBwbGljYXRpb24gbWV0YWRhdGEgYmVl biANCiAgICAgIHVzZWQgYnkgdGhlIEROUy1BUyB1c2UgY2FzZSBmb3IgZm9yIEFWQy4NCg0K ICAgRS4gRGVzY3JpcHRpb24gb2YgdGhlIHByb3Bvc2VkIFJSIHR5cGUuDQoNCiAgICAgIEdl bmVyYWwgQVZDIFJlc291cmNlIFJlY29yZCBzeW50YXg6DQogICAgICAiPG9wdGlvbj46PHZh bD57fDxvcHRpb24+Ojx2YWw+fSoiIA0KICAgICAgDQogICAgICBUaGUgUkRBVEEgaGFzIGV4 YWN0bHkgdGhlIHNhbWUgY29udGVudCBhcyBhIFRYVCByZWNvcmQuDQogICAgICBUaGUgb3B0 aW9uIGZpZWxkIGlzIGRlcml2ZWQgZnJvbSBSRkM2NzU5IE1ldGFkYXRhIENvbXBvbmVudHMg bG9uZyBuYW1lLg0KICAgICAgV2UgdHJ5IHRvIGtlZXAgdGhlIFJSIHNob3J0IHRvIG5vdCBl eGNlZWQgdGhlIDI1NSBjaGFyYWN0ZXJzIGFzIGFsc28gbWFrZSBpdA0KICAgICAgZWFzeSBw YXJzZWFibGUuIFRoZXJlZm9yZSB3ZSBzaG9ydGVuIHRoZSBSRkM2NzU5IG5hbWVzIGluc2lk ZSB0aGUgUlIgbGlrZSANCiAgICAgICJBcHBsaWNhdGlvbiBOYW1lIiB0byAiYXBwLW5hbWUi IG9yICJBcHBsaWNhdGlvbiBJRCIgdG8gImFwcC1pZCINCiAgICAgIEluIGNhc2UgYSBzaW5n bGUgcmVjb3JkIG1pZ2h0IGV4Y2VlZCAyNTUgY2hhcmFjdGVycyB3ZSBuZWVkIHRvIGFsbG93 IGZvciB0aGF0LCB0b28uDQogICAgICBUeXBpY2FsbHkgYW4gYXBwbGljYXRpb24gd291bGQg Y29uY2F0ZW5hdGUgdGhlIGluZGl2aWR1YWwgc3ViLXN0cmluZ3MgZGlyZWN0bHkNCiAgICAg ICp3aXRob3V0KiBhZGRpbmcgYW55IHNlcGFyYXRvci4NCg0KICAgICAgQW4gZXhhbXBsZSBm b3Igc3VjaCBhbiBBVkMgUkRBVEEgcmVjb3JkIHdpdGggYXBwIG1ldGFkYXRhIHdvdWxkIGJl Og0KICAgICAgImFwcC1uYW1lOldPTEZHQU5HfGFwcC1jbGFzczpPQU18YnVzaW5lc3M9eWVz IiANCg0KICAgICAgU2VlIGhlcmUgZm9yIG1vcmUgaW5mbzoNCiAgICAgIGh0dHA6Ly93d3cu ZG5zLWFzLm9yZy93aGF0LWlzL21ldGFkYXRhLw0KICAgICAgaHR0cDovL3d3dy5kbnMtYXMu b3JnL3N1cHBvcnQvZG5zLWFzLXJyLw0KDQogICBGLiBXaGF0IGV4aXN0aW5nIFJSVFlQRSBv ciBSUlRZUEVzIGNvbWUgY2xvc2VzdCB0byBmaWxsaW5nIHRoYXQgbmVlZA0KICAgICAgYW5k IHdoeSBhcmUgdGhleSB1bnNhdGlzZmFjdG9yeT8NCg0KICAgICAgTGlrZSBTUEYgd2UgYXJl IGN1cnJlbnRseSB1c2luZyB0aGUgVFhUIFJSIGZvciBETlMtQVMuIFRoZSBUWFQgUlJUWVBF IA0KICAgICAgY2FuIHN1cHBvcnQgYXJiaXRyYXJ5IFRMVnMgZW5jb2RlZCBhcyBhIHRleHQu IEluIGdlbmVyYWwgdGhpcyBraW5kIA0KICAgICAgb2YgKGFiKXVzZSBvZiBUWFQgUlIgaXMg ZGlzY291cmFnZWQgYXMgZGlzY3Vzc2VkIGluIFJGQzU1MDcgdGhlcmVmb3JlDQogICAgICB3 ZSBhcHBseSBmb3IgYSBkZWRpY2F0ZWQgcmVzb3VyY2UgcmVjb3JkLg0KDQogICBHLiBXaGF0 IG1uZW1vbmljIGlzIHJlcXVlc3RlZCBmb3IgdGhlIG5ldyBSUlRZUEUgKG9wdGlvbmFsKT8N CiAgICAgIG1uZW1vbmljPUFWQw0KDQogICBILiBEb2VzIHRoZSByZXF1ZXN0ZWQgUlJUWVBF IG1ha2UgdXNlIG9mIGFueSBleGlzdGluZyBJQU5BIHJlZ2lzdHJ5DQogICAgICBvciByZXF1 aXJlIHRoZSBjcmVhdGlvbiBvZiBhIG5ldyBJQU5BIHN1YnJlZ2lzdHJ5IGluIEROUw0KICAg ICAgUGFyYW1ldGVycz8gIElmIHNvLCBwbGVhc2UgaW5kaWNhdGUgd2hpY2ggcmVnaXN0cnkg aXMgdG8gYmUgdXNlZA0KICAgICAgb3IgY3JlYXRlZC4gIElmIGEgbmV3IHN1YnJlZ2lzdHJ5 IGlzIG5lZWRlZCwgc3BlY2lmeSB0aGUNCiAgICAgIGFsbG9jYXRpb24gcG9saWN5IGZvciBp dCBhbmQgaXRzIGluaXRpYWwgY29udGVudHMuICBBbHNvIGluY2x1ZGUNCiAgICAgIHdoYXQg dGhlIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmVzIHdpbGwgYmUuDQoNCiAgICAgIFRoZSBtbmVt b25pYyBzeW50YXggYXMgYWxzbyB0aGUgcG90ZW50aWFsIDxvcHRpb24+Ojx2YWw+IGZpZWxk cyBhcmUNCiAgICAgIGlubGluZSB3aXRoIFJGQzY3NTkgYW5kIHRoZSB1c2FnZSBpcyBkZXNj cmliZWQgaW4gZGV0YWlsIGhlcmU6DQogICAgICBodHRwOi8vd3d3LmRucy1hcy5vcmcvd2hh dC1pcy9tZXRhZGF0YS8NCiAgICAgIGh0dHA6Ly93d3cuZG5zLWFzLm9yZy9zdXBwb3J0L2F2 Yy1yZGF0YS8NCg0KICAgSS4gRG9lcyB0aGUgcHJvcG9zYWwgcmVxdWlyZS9leHBlY3QgYW55 IGNoYW5nZXMgaW4gRE5TDQogICAgICBzZXJ2ZXJzL3Jlc29sdmVycyB0aGF0IHByZXZlbnQg dGhlIG5ldyB0eXBlIGZyb20gYmVpbmcgcHJvY2Vzc2VkDQogICAgICBhcyBhbiB1bmtub3du IFJSVFlQRSAoc2VlIFtSRkMzNTk3XSk/DQoNCiAgICAgIE5vLg0KDQogICBKLiBDb21tZW50 czoNCg0KICAgICAgTm9uZS4K --------------030909090305030200010408-- From nobody Fri Feb 19 07:11:35 2016 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 1808D1A1B8E for ; Fri, 19 Feb 2016 07:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 KOOT9QmyYYUF for ; Fri, 19 Feb 2016 07:11:32 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9FD1ACDED for ; Fri, 19 Feb 2016 07:11:32 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 37335880C7; Fri, 19 Feb 2016 07:11:32 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 63D1A328081A; Fri, 19 Feb 2016 07:11:31 -0800 (PST) To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com References: <20160218013620.0ABC6180209@rfc-editor.org> From: Brian Haberman Message-ID: <56C7309D.8080603@innovationslab.net> Date: Fri, 19 Feb 2016 10:11:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160218013620.0ABC6180209@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG" Archived-At: Cc: dnsext@ietf.org, ogud@ogud.com Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (4622) 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, 19 Feb 2016 15:11:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Does anyone have an opinion on the validity of this erratum? It seems like a reasonable clarification in my reading. Brian On 2/17/16 8:36 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5155, > "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D4622 >=20 > -------------------------------------- > Type: Technical > Reported by: Robert Edmonds >=20 > Section: 7.2.8 >=20 > Original Text > ------------- > 7.2.8. Responding to Queries for NSEC3 Owner Names >=20 > The owner names of NSEC3 RRs are not represented in the NSEC3 RR > chain like other owner names. As a result, each NSEC3 owner name is= > covered by another NSEC3 RR, effectively negating the existence of > the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR= > can be proven by its RRSIG RRSet. >=20 > If the following conditions are all true: >=20 > o the QNAME equals the owner name of an existing NSEC3 RR, and >=20 > o no RR types exist at the QNAME, nor at any descendant of QNAME, >=20 > then the response MUST be constructed as a Name Error response > (Section 7.2.2). Or, in other words, the authoritative name server > will act as if the owner name of the NSEC3 RR did not exist. >=20 >=20 > Corrected Text > -------------- > 7.2.8. Responding to Queries for NSEC3 Owner Names >=20 > The owner names of NSEC3 RRs are not represented in the NSEC3 RR > chain like other owner names. As a result, each NSEC3 owner name is= > covered by another NSEC3 RR, effectively negating the existence of > the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR= > can be proven by its RRSIG RRSet. >=20 > If the following conditions are all true: >=20 > o the QNAME equals the owner name of an existing NSEC3 RR, and >=20 > o no RR types exist at the QNAME besides NSEC3, nor at any > descendant of QNAME, >=20 > then the response MUST be constructed as a Name Error response > (Section 7.2.2). Or, in other words, the authoritative name server > will act as if the owner name of the NSEC3 RR did not exist. >=20 >=20 > Notes > ----- > If the QNAME is equal to the owner name of an existing NSEC3 RR, then t= he NSEC3 RR type itself will exist at the QNAME, and the second condition= will always be false. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5155 (draft-ietf-dnsext-nsec3-13) > -------------------------------------- > Title : DNS Security (DNSSEC) Hashed Authenticated Denial= of Existence > Publication Date : March 2008 > Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG >=20 --sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWxzCiAAoJEBOZRqCi7goqn6kH/0Qs1MOkWJvDdGJSMLKoF8lv ItZV6ijIAHO/slVtqKaUBMe0mMPJhhRLtnP6OtnBqInJJXMHf54cVw2YdNiEJYfy S7gNifT2vwvprp/szpBNG/hubHNLdX4d1BrFc+CT9COYSfIKVfr7WupL8lNMBOsf S1pFQDGlODsvCjJFTFLFP5x8h4Fwr5fNzJm1ZmpN5EVyZrpqvKj/UQ1zvPYhM2yB Vi3dCIA1Zkpkwddxwk7XlR4JtM4bjqebPpNm6rxc70ZurkFSFOIrDXAuluszrlJ8 xIQ0YxPCNjEvwRreJkKHkSLmfzreP3jAA1Wju6vSOT4raB1IgYwfWmbtDKMaiOM= =rmA6 -----END PGP SIGNATURE----- --sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG-- From nobody Fri Feb 19 08:38:03 2016 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 59F381B3211 for ; Fri, 19 Feb 2016 08:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 HN8tIuNJ4NU0 for ; Fri, 19 Feb 2016 08:37:51 -0800 (PST) Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86721B31F5 for ; Fri, 19 Feb 2016 08:37:51 -0800 (PST) Received: by mail-qg0-x261.google.com with SMTP id b35so8736551qge.0 for ; Fri, 19 Feb 2016 08:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=zjScveNGCvi5o9xc5els8+6r0zO6JgoCOUw5Xj5gNM8=; b=qlADa+VP5IMlntFm3KcH3ozcVf+PunMw1mwbqg+U6XRB4VajWeW6FPAq9zvun0sn/t G6HnmiL9ouiDecbPntqG5a62GLQArGKG0S69IMUNz2UcWIKT3WMcsuTi4rBuYf3p4AzD Ctd8t6cbLoPb8z0ZBW+jrUCmHman/Yvp0764MOHVMLY91qtC+9/5C5jSMq3GnjOWh4SY eu+FMOJhL/tKtp5IoTQqbNAIuev69FuJ2xJbuN/8p1f4wdhYmj2wUioccapMifcHV6kf Bjuu6/KHYWlRNKsRncudiWE3xlYrgF9cJpJ/p7XLxQFlbtT+xt/hMfLdgV85dZexZGlj ZcuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=zjScveNGCvi5o9xc5els8+6r0zO6JgoCOUw5Xj5gNM8=; b=X/Y/u2AQ4iB+wFYtX7o0dhlXcM8ETX71xHbu4Zpa6Nlt2L0JYsO5NuzTPn++HMuRvz UNFFd3NWDhgm7QBPoHooKnafrmDLiWGPzlPBgeyEwdfB59oI6eTiwbNvqQ5V0lAEMkCP COfunNE3SoGhh1GN3c3maWGc+7MTzafTd8yragxztg4aj/nvPPpW2xui1m2flyl2pgPk pT/SSAyKIbnYILV7q35AlrcUSREtzYlokglKhHBY/mJmnj/z/bez+4s4q4DdBncDJOvY nUxR6nZCh9L6qlKL2RF4EGPwdAOhp9xv/+zriPMIZc3HjI7u4iuv6eUvmpKWLxHysHJF i2mg== X-Gm-Message-State: AG10YOSOPh/O7iq+rNlrvV3waM0rBcEo655xXLtENwYDx9F52rxng4IXXkSzsXw9mNfo0RoUAEYQrjbJGDWc2YFBqnVsVEU7 X-Received: by 10.140.93.166 with SMTP id d35mr16645320qge.29.1455899870479; Fri, 19 Feb 2016 08:37:50 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id u191sm1751770qka.2.2016.02.19.08.37.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 08:37:50 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u1JGbmCZ006693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 11:37:48 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 19 Feb 2016 11:37:48 -0500 From: "Blacka, David" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC5155 (4622) Thread-Index: AQHRaezQyDYX0XHghE+hgPNTkIPv7J8zz5GAgAAYK4A= Date: Fri, 19 Feb 2016 16:37:47 +0000 Message-ID: <354ECEF6-49FA-4819-8FA5-9F9AC9116B0A@verisign.com> References: <20160218013620.0ABC6180209@rfc-editor.org> <56C7309D.8080603@innovationslab.net> In-Reply-To: <56C7309D.8080603@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_7EB03420-E23C-47E9-B733-014C235EF8BA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "geoff-s@panix.com" , "dnsext@ietf.org" , =?utf-8?B?w5NsYWZ1ciBHdeKIgm11bmRzc29u?= Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (4622) 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, 19 Feb 2016 16:37:57 -0000 --Apple-Mail=_7EB03420-E23C-47E9-B733-014C235EF8BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 19, 2016, at 10:11 AM, Brian Haberman = wrote: >=20 > Does anyone have an opinion on the validity of this erratum? It seems > like a reasonable clarification in my reading. The clarification looks correct and reasonable to me. >=20 > Brian >=20 > On 2/17/16 8:36 PM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5155, >> "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D4622 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Robert Edmonds >>=20 >> Section: 7.2.8 >>=20 >> Original Text >> ------------- >> 7.2.8. Responding to Queries for NSEC3 Owner Names >>=20 >> The owner names of NSEC3 RRs are not represented in the NSEC3 RR >> chain like other owner names. As a result, each NSEC3 owner name = is >> covered by another NSEC3 RR, effectively negating the existence of >> the NSEC3 RR. This is a paradox, since the existence of an NSEC3 = RR >> can be proven by its RRSIG RRSet. >>=20 >> If the following conditions are all true: >>=20 >> o the QNAME equals the owner name of an existing NSEC3 RR, and >>=20 >> o no RR types exist at the QNAME, nor at any descendant of QNAME, >>=20 >> then the response MUST be constructed as a Name Error response >> (Section 7.2.2). Or, in other words, the authoritative name server >> will act as if the owner name of the NSEC3 RR did not exist. >>=20 >>=20 >> Corrected Text >> -------------- >> 7.2.8. Responding to Queries for NSEC3 Owner Names >>=20 >> The owner names of NSEC3 RRs are not represented in the NSEC3 RR >> chain like other owner names. As a result, each NSEC3 owner name = is >> covered by another NSEC3 RR, effectively negating the existence of >> the NSEC3 RR. This is a paradox, since the existence of an NSEC3 = RR >> can be proven by its RRSIG RRSet. >>=20 >> If the following conditions are all true: >>=20 >> o the QNAME equals the owner name of an existing NSEC3 RR, and >>=20 >> o no RR types exist at the QNAME besides NSEC3, nor at any >> descendant of QNAME, >>=20 >> then the response MUST be constructed as a Name Error response >> (Section 7.2.2). Or, in other words, the authoritative name server >> will act as if the owner name of the NSEC3 RR did not exist. >>=20 >>=20 >> Notes >> ----- >> If the QNAME is equal to the owner name of an existing NSEC3 RR, then = the NSEC3 RR type itself will exist at the QNAME, and the second = condition will always be false. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC5155 (draft-ietf-dnsext-nsec3-13) >> -------------------------------------- >> Title : DNS Security (DNSSEC) Hashed Authenticated = Denial of Existence >> Publication Date : March 2008 >> Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 -- David Blacka =20 Distinguished Engineer Verisign Product Engineering --Apple-Mail=_7EB03420-E23C-47E9-B733-014C235EF8BA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINtDCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggdMMIIGNKADAgECAhA5tGWhlt5X 22yZo/aBwRVEMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE1MDIxOTAwMDAwMFoXDTE2MDMwMjIzNTk1OVowbTEiMCAGCSqGSIb3DQEJARYTZGF2aWRi QHZlcmlzaWduLmNvbTEWMBQGA1UEAwwNQmxhY2thLCBEYXZpZDEWMBQGA1UECwwNRU5URVJQUklT RSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCs0UlNOAODGuwcpxB1HyTslCBsgR+KlIEGzyExqWCVdSJ39rW+moTPkY1zE2cVdljs5ssE EhhF1fzxYkpwYOborg+hI0ssqt9JqtlSbJsqprXXmGpilQ1E1MAl0hOCAhi7htqB/LmPhP5uRPKg VziUXuzASpqsZsL/o0KM9XwXXioZWB5Z4NUntOGbRY7zr2YOlRJdEcR42vYGpsIlzJACyrJgQri/ bD4otsta0j0csxd1v9oZup6TSi0fsqm53bIgAAbgZ++dd/fEBY423vfG5AJPBdduuDHwjfsiYCAA LgPJdkhXiwvVdGqG9sp1f/WqSE2GC19D01GmPmjeDBSfAgMBAAGjggOJMIIDhTAMBgNVHRMBAf8E AjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUVoVK aC1xEPB9EWKq3dWrwskIufkwHgYDVR0RBBcwFYETZGF2aWRiQHZlcmlzaWduLmNvbTAfBgNVHSME GDAWgBTYSCmoXyoXkuL6nnvvb2CD+Li43DCCAXEGCCsGAQUFBwEBBIIBYzCCAV8wJwYIKwYBBQUH MAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCCATIGCCsGAQUFBzAChoIBJGxkYXA6Ly9k aXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBT aGFyZWQlMjBJbnRlcm1lZGlhdGUlMjBDZXJ0aWZpY2F0ZSUyMEF1dGhvcml0eSUyQ09VJTIwJTNE JTIwQ2xhc3MlMjAyJTIwTWFuYWdlZCUyMFBLSSUyMEluZGl2aWR1YWwlMjBTdWJzY3JpYmVyJTIw Q0ElMkNPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3b3JrJTJDTyUyMCUzRCUyMFN5 bWFudGVjJTIwQ29ycG9yYXRpb24lMkNDJTIwJTNEJTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfMDdiYjdkNjQ3 N2NmNGY2YmU5NmFmMWIzNmNhYmQzMTYvTGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG +EUBBxcCMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUF BwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMEIGCSqGSIb3DQEJDwQ1MDMwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBFjALBglghkgBZQMEASowLAYKYIZIAYb4RQEQ AwQeMBwGEmCGSAGG+EUBEAECAgEBi/HGCRYGMjQ3NjY0MDkGCmCGSAGG+EUBEAUEKzApAgEAFiRh SFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZWFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALOq TUGAtFutNz1xdrgU+019PnljzpswtmGD1dK2s4sBq719Alxf8CYULlRgY5qNr4NZVnmYmRSobeKz OYGTYWm+KJzoTkIz6JfVTFk67KcowOZxWLNiYzVydkACuPDYS8sS7EIDXd+AyJNcvozVn5a91Mf8 gyPgqecm3pD0KDGvVAUxWuC1TSe0NBgRm3gKMrBW3qONpB7y9ilG+anVGK297q5g4QqwukPIIVAd t/v0BY/QhdQqrqTeKt4W6DT5tiGkAW3V59ztpNCWD1BDIr7h8QAYZowJxIuzrEc9lmBiSlxDGBhc Bvh3Uq2OfeNQmctYux/N+HvJWGx5MCkTtp8xggRNMIIESQIBATCB3jCByTELMAkGA1UEBhMCVVMx HTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBO ZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRp ZmljYXRlIEF1dGhvcml0eQIQObRloZbeV9tsmaP2gcEVRDAJBgUrDgMCGgUAoIICQzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTkxNjM3NTVaMCMGCSqGSIb3 DQEJBDEWBBRT3JQE1B8VCparkVXovChda0rIgTCB7wYJKwYBBAGCNxAEMYHhMIHeMIHJMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVj IFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlh dGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhA5tGWhlt5X22yZo/aBwRVEMIHxBgsqhkiG9w0BCRAC CzGB4aCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8w HQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQg UEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBT aGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQObRloZbeV9tsmaP2gcEV RDANBgkqhkiG9w0BAQEFAASCAQB1xNmKIXuSChTJvqPu+4pMukaFnNp+59JNix+b6Wfj81EjujAj mb7Q1hadYD5ThbvBYXai3cv/QhTZFX1fsyUKHttC2ZmPsKFSixwbp5t8bc7C5Sr+T8ufm0gVSK1d BMXumtX6SWCdgBgAvzJTowJiNxrLZq7/U+b8khbUhGaGl7Onuxti6YM6s4UKq+IOxqUh2ubo4ZA5 oRS06CwqKf1ear9eEFrti1mgHmi/3iGmhrYDXa7Wh03mPaPiT791ZixSS/NtDwd2tNhyluaBvsuw 3BNKBoT3zhAHFKfyOyjH8Ebbi5jXKIULjxLhnGnODD4RohrnS8Af2tAgbPkfY2s5AAAAAAAA --Apple-Mail=_7EB03420-E23C-47E9-B733-014C235EF8BA-- From nobody Fri Feb 19 08:49:05 2016 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 4B1031B3269; Fri, 19 Feb 2016 08:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Rgk_Uj6sKCId; Fri, 19 Feb 2016 08:49:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632761B3267; Fri, 19 Feb 2016 08:48:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0535118046E; Fri, 19 Feb 2016 08:48:37 -0800 (PST) To: edmonds@mycre.ws, ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160219164837.0535118046E@rfc-editor.org> Date: Fri, 19 Feb 2016 08:48:37 -0800 (PST) Archived-At: Cc: brian@innovationslab.net, rfc-editor@rfc-editor.org, iesg@ietf.org, dnsext@ietf.org Subject: [dnsext] [Errata Verified] RFC5155 (4622) 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, 19 Feb 2016 16:49:01 -0000 The following errata report has been verified for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622 -------------------------------------- Status: Verified Type: Technical Reported by: Robert Edmonds Date Reported: 2016-02-18 Verified by: Brian Haberman (IESG) Section: 7.2.8 Original Text ------------- 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist. Corrected Text -------------- 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME besides NSEC3, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist. Notes ----- If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Sat Feb 20 08:34:06 2016 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 4A6931B31DA for ; Fri, 19 Feb 2016 07:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 tjxA_KApYjWU for ; Fri, 19 Feb 2016 07:44:54 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B195A1B320A for ; Fri, 19 Feb 2016 07:44:54 -0800 (PST) Received: from [10.32.60.122] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u1JFilHF044976 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2016 08:44:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Brian Haberman" Date: Fri, 19 Feb 2016 07:44:47 -0800 Message-ID: In-Reply-To: <56C7309D.8080603@innovationslab.net> References: <20160218013620.0ABC6180209@rfc-editor.org> <56C7309D.8080603@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: X-Mailman-Approved-At: Sat, 20 Feb 2016 08:34:05 -0800 Cc: dnsext@ietf.org, geoff-s@panix.com, Roy Arends , ogud@ogud.com Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (4622) 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, 19 Feb 2016 15:44:55 -0000 On 19 Feb 2016, at 7:11, Brian Haberman wrote: > Does anyone have an opinion on the validity of this erratum? It seems > like a reasonable clarification in my reading. This was discussed on the DNSOP mailing list and folks agreed with the clarification. --Paul Hoffman From nobody Sat Feb 20 12:43:12 2016 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 220261ACE6E for ; Sat, 20 Feb 2016 12:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8PbfFFu-5Mvm for ; Sat, 20 Feb 2016 12:43:07 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE741ACE69 for ; Sat, 20 Feb 2016 12:43:06 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x4so64695039lbm.0 for ; Sat, 20 Feb 2016 12:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=otzgXNRG906BbIIVvwnZK9yw0BqJSOvRkou0qz9TGVQ=; b=tAYud1SVZZ/EM6LO62ffd/7hF/n8IR3CMy04qqptiJFcOktLT+2CA+devCEHWNkezX sbrSkUYyAlFVnCHWmDBm9/imQiMiVvyrvD89KWStJjmbjypMisAq0RzeCPgQJ2N15P36 z8TOEW9hd1Tcwqjr8ni2HWNYW+sqPpZRxx0njfpwjeueTkOeCQdD7qJbuDyBw9l6RIaW zQeHadck8iluQH8qm+fQ06ZDiOagQsksOpbthrwQRqakc7fuM+2q1DxWgfGWA1wXSi/d HHvNQunYcbFyFRHRZvusJqUIQ/7ti9nexxcFl366/j4wBouGfyRU38WlVoukMvkfR55b UBIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=otzgXNRG906BbIIVvwnZK9yw0BqJSOvRkou0qz9TGVQ=; b=gim/ZmAnr8K1qa+00w9Zr4r4Iune0/tUXQVT5Jp2x1X5f/qm17sKVEn4FKJ95SD5pN z6UqpQ19aPgljGYuUZLUNqERFTTKYV9nRs25Ll26a8+zawWeKniZluOfAkV1sr0NW/eV JphV9tyjdw+ln3URY6i8NEeXS2oz0XpZ8z3DG+rC+3gUbVuW2RhQk4inDWjMCf/q604S //OUXt3eWV1V2Rrt8Yew+sSR9gsQHRV+Wbad3xyUjHIwZuaVuLyQiF6YmOW+aHT8DqF5 Bv9HMNEyC+M8cWjd/C+kS5Q97lSUPaPeT1IJY4eMXWGLmahpbNYwoUthbo9Le9jyn3jj redw== X-Gm-Message-State: AG10YOSKIVmP2ydcu/PT7s/xuGJqHaBrUKJeMVL9dlWKUg5HVa5N3+e/pMPM5e+VM8yjF+MaP5sKXZRfh/eKjQ== MIME-Version: 1.0 X-Received: by 10.112.14.39 with SMTP id m7mr7668031lbc.20.1456000984824; Sat, 20 Feb 2016 12:43:04 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.112.20.226 with HTTP; Sat, 20 Feb 2016 12:43:04 -0800 (PST) In-Reply-To: <354ECEF6-49FA-4819-8FA5-9F9AC9116B0A@verisign.com> References: <20160218013620.0ABC6180209@rfc-editor.org> <56C7309D.8080603@innovationslab.net> <354ECEF6-49FA-4819-8FA5-9F9AC9116B0A@verisign.com> Date: Sat, 20 Feb 2016 20:43:04 +0000 X-Google-Sender-Auth: stSJqSgy3kJYvp0PwBi32_-Z-NE Message-ID: From: Ben Laurie To: "Blacka, David" Content-Type: multipart/alternative; boundary=001a11c3726a7e4545052c39a5af Archived-At: Cc: Brian Haberman , "geoff-s@panix.com" , "dnsext@ietf.org" , =?UTF-8?B?w5NsYWZ1ciBHdeKIgm11bmRzc29u?= Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (4622) 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: Sat, 20 Feb 2016 20:43:10 -0000 --001a11c3726a7e4545052c39a5af Content-Type: text/plain; charset=UTF-8 Me, too, though it could be more economically expressed as "no _other_ RR types exist...". On 19 February 2016 at 16:37, Blacka, David wrote: > > > On Feb 19, 2016, at 10:11 AM, Brian Haberman > wrote: > > > > Does anyone have an opinion on the validity of this erratum? It seems > > like a reasonable clarification in my reading. > > The clarification looks correct and reasonable to me. > > > > > Brian > > > > On 2/17/16 8:36 PM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5155, > >> "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Robert Edmonds > >> > >> Section: 7.2.8 > >> > >> Original Text > >> ------------- > >> 7.2.8. Responding to Queries for NSEC3 Owner Names > >> > >> The owner names of NSEC3 RRs are not represented in the NSEC3 RR > >> chain like other owner names. As a result, each NSEC3 owner name is > >> covered by another NSEC3 RR, effectively negating the existence of > >> the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR > >> can be proven by its RRSIG RRSet. > >> > >> If the following conditions are all true: > >> > >> o the QNAME equals the owner name of an existing NSEC3 RR, and > >> > >> o no RR types exist at the QNAME, nor at any descendant of QNAME, > >> > >> then the response MUST be constructed as a Name Error response > >> (Section 7.2.2). Or, in other words, the authoritative name server > >> will act as if the owner name of the NSEC3 RR did not exist. > >> > >> > >> Corrected Text > >> -------------- > >> 7.2.8. Responding to Queries for NSEC3 Owner Names > >> > >> The owner names of NSEC3 RRs are not represented in the NSEC3 RR > >> chain like other owner names. As a result, each NSEC3 owner name is > >> covered by another NSEC3 RR, effectively negating the existence of > >> the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR > >> can be proven by its RRSIG RRSet. > >> > >> If the following conditions are all true: > >> > >> o the QNAME equals the owner name of an existing NSEC3 RR, and > >> > >> o no RR types exist at the QNAME besides NSEC3, nor at any > >> descendant of QNAME, > >> > >> then the response MUST be constructed as a Name Error response > >> (Section 7.2.2). Or, in other words, the authoritative name server > >> will act as if the owner name of the NSEC3 RR did not exist. > >> > >> > >> Notes > >> ----- > >> If the QNAME is equal to the owner name of an existing NSEC3 RR, then > the NSEC3 RR type itself will exist at the QNAME, and the second condition > will always be false. > >> > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC5155 (draft-ietf-dnsext-nsec3-13) > >> -------------------------------------- > >> Title : DNS Security (DNSSEC) Hashed Authenticated Denial > of Existence > >> Publication Date : March 2008 > >> Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka > >> Category : PROPOSED STANDARD > >> Source : DNS Extensions > >> Area : Internet > >> Stream : IETF > >> Verifying Party : IESG > >> > > > > -- > David Blacka > Distinguished Engineer Verisign Product Engineering > > > > > > --001a11c3726a7e4545052c39a5af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Me, too, though it could be more economically expressed as= "no _other_ RR types exist...".
=
On 19 February 2016 at 16:37, Blacka, David = <davidb@verisign.com> wrote:

> On Feb 19, 2016, at 10:11 AM, Brian Haberman <brian@innovationslab.net> wrote:
>
> Does anyone have an opinion on the validity of this erratum? It seems<= br> > like a reasonable clarification in my reading.

The clarification looks correct and reasonable to me.

>
> Brian
>
> On 2/17/16 8:36 PM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5155,
>> "DNS Security (DNSSEC) Hashed Authenticated Denial of Existen= ce".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.= org/errata_search.php?rfc=3D5155&eid=3D4622
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Robert Edmonds <edmonds@mycre.ws>
>>
>> Section: 7.2.8
>>
>> Original Text
>> -------------
>> 7.2.8.=C2=A0 Responding to Queries for NSEC3 Owner Names
>>
>>=C2=A0 =C2=A0The owner names of NSEC3 RRs are not represented in th= e NSEC3 RR
>>=C2=A0 =C2=A0chain like other owner names.=C2=A0 As a result, each = NSEC3 owner name is
>>=C2=A0 =C2=A0covered by another NSEC3 RR, effectively negating the = existence of
>>=C2=A0 =C2=A0the NSEC3 RR.=C2=A0 This is a paradox, since the exist= ence of an NSEC3 RR
>>=C2=A0 =C2=A0can be proven by its RRSIG RRSet.
>>
>>=C2=A0 =C2=A0If the following conditions are all true:
>>
>>=C2=A0 =C2=A0o=C2=A0 the QNAME equals the owner name of an existing= NSEC3 RR, and
>>
>>=C2=A0 =C2=A0o=C2=A0 no RR types exist at the QNAME, nor at any des= cendant of QNAME,
>>
>>=C2=A0 =C2=A0then the response MUST be constructed as a Name Error = response
>>=C2=A0 =C2=A0(Section 7.2.2).=C2=A0 Or, in other words, the authori= tative name server
>>=C2=A0 =C2=A0will act as if the owner name of the NSEC3 RR did not = exist.
>>
>>
>> Corrected Text
>> --------------
>> 7.2.8.=C2=A0 Responding to Queries for NSEC3 Owner Names
>>
>>=C2=A0 =C2=A0The owner names of NSEC3 RRs are not represented in th= e NSEC3 RR
>>=C2=A0 =C2=A0chain like other owner names.=C2=A0 As a result, each = NSEC3 owner name is
>>=C2=A0 =C2=A0covered by another NSEC3 RR, effectively negating the = existence of
>>=C2=A0 =C2=A0the NSEC3 RR.=C2=A0 This is a paradox, since the exist= ence of an NSEC3 RR
>>=C2=A0 =C2=A0can be proven by its RRSIG RRSet.
>>
>>=C2=A0 =C2=A0If the following conditions are all true:
>>
>>=C2=A0 =C2=A0o=C2=A0 the QNAME equals the owner name of an existing= NSEC3 RR, and
>>
>>=C2=A0 =C2=A0o=C2=A0 no RR types exist at the QNAME besides NSEC3, = nor at any
>>=C2=A0 =C2=A0 =C2=A0 descendant of QNAME,
>>
>>=C2=A0 =C2=A0then the response MUST be constructed as a Name Error = response
>>=C2=A0 =C2=A0(Section 7.2.2).=C2=A0 Or, in other words, the authori= tative name server
>>=C2=A0 =C2=A0will act as if the owner name of the NSEC3 RR did not = exist.
>>
>>
>> Notes
>> -----
>> If the QNAME is equal to the owner name of an existing NSEC3 RR, t= hen the NSEC3 RR type itself will exist at the QNAME, and the second condit= ion will always be false.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If neces= sary, please
>> use "Reply All" to discuss whether it should be verified= or
>> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=
>>
>> --------------------------------------
>> RFC5155 (draft-ietf-dnsext-nsec3-13)
>> --------------------------------------
>> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: DNS = Security (DNSSEC) Hashed Authenticated Denial of Existence
>> Publication Date=C2=A0 =C2=A0 : March 2008
>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Laurie, G. = Sisson, R. Arends, D. Blacka
>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAND= ARD
>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : DNS Exten= sions
>> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Inte= rnet
>> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
>> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>>
>

--
David Blacka=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <davi= db@verisign.com>
Distinguished Engineer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Verisign Product Engineering






--001a11c3726a7e4545052c39a5af-- From nobody Tue Feb 23 05:18:29 2016 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 3C2BF1A1B1B; Tue, 23 Feb 2016 05:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 h3vATX256ydQ; Tue, 23 Feb 2016 05:18:23 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885AD1B2B69; Tue, 23 Feb 2016 05:18:23 -0800 (PST) Received: from [46.227.151.81] (port=54866 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1aYCr5-0002zq-VE (Exim 4.72) (return-path ); Tue, 23 Feb 2016 13:18:19 +0000 To: dns-rrtype-applications@ietf.org, wolfgang@cisco.com, dnsext@ietf.org References: <26590E02-7D2E-4720-8084-9133F4BE03BA@cisco.com> From: Ray Bellis Message-ID: <56CC5C1D.9050807@bellis.me.uk> Date: Tue, 23 Feb 2016 13:18:21 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <26590E02-7D2E-4720-8084-9133F4BE03BA@cisco.com> Content-Type: multipart/mixed; boundary="------------090700030907060300000102" Archived-At: Subject: Re: [dnsext] [dns-rrtype-applications] "AVC" RRTYPE PARAMETER ALLOCATION (was "DNSAS") 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, 23 Feb 2016 13:18:26 -0000 This is a multi-part message in MIME format. --------------090700030907060300000102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 14/02/2016 09:05, Wolfgang Riedel (wriedel) wrote: > Hello, > > as requested attached our re-worked request for an assignment for a > new DNS Resource Record for mnemonic=AVC. Please let me know if there > is anything unclear or missing and what the next steps would be. Having received no further comments, as the Designated Expert according to RFC 6895 I hereby approve the application for the "AVC" RRTYPE as described in the attached template. Ray Bellis --------------090700030907060300000102 Content-Type: text/plain; charset=UTF-8; name="DNS-AS-RR-AVC-apply.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DNS-AS-RR-AVC-apply.txt" ICAgICAgICAgICAgICAgICBETlMgUlJUWVBFIFBBUkFNRVRFUiBBTExPQ0FUSU9OIFRFTVBM QVRFDQoNCiAgIFdoZW4gcmVhZHkgZm9yIGZvcm1hbCBjb25zaWRlcmF0aW9uLCB0aGlzIHRl bXBsYXRlIGlzIHRvIGJlIHN1Ym1pdHRlZA0KICAgdG8gSUFOQSBmb3IgcHJvY2Vzc2luZyBi eSBlbWFpbGluZyB0aGUgdGVtcGxhdGUgdG8gZG5zLXJydHlwZS1hcHBsaWNhdGlvbnNAaWV0 Zi5vcmcuDQoNCiAgIEEuIFN1Ym1pc3Npb24gRGF0ZToNCg0KICAgQi4xIFN1Ym1pc3Npb24g VHlwZTogIFtYXSBOZXcgUlJUWVBFICBbIF0gTW9kaWZpY2F0aW9uIHRvIFJSVFlQRQ0KICAg Qi4yIEtpbmQgb2YgUlI6ICBbWF0gRGF0YSBSUiAgWyBdIE1ldGEtUlINCg0KICAgQy4gQ29u dGFjdCBJbmZvcm1hdGlvbiBmb3Igc3VibWl0dGVyICh3aWxsIGJlIHB1YmxpY2x5IHBvc3Rl ZCk6DQogICAgICBOYW1lOiBXb2xmZ2FuZyBSaWVkZWwgICAgICAgRW1haWwgQWRkcmVzczog d29sZmdhbmdAY2lzY28uY29tDQogICAgICBJbnRlcm5hdGlvbmFsIHRlbGVwaG9uZSBudW1i ZXI6ICs0OS04MTEtNTU5LTU0NTANCiAgICAgIE90aGVyIGNvbnRhY3QgaGFuZGxlczogDQoN CiAgIEQuIE1vdGl2YXRpb24gZm9yIHRoZSBuZXcgUlJUWVBFIGFwcGxpY2F0aW9uLg0KDQog ICAgICBDaXNjbyBoYXMgZGV2ZWxvcGVkIGEgbmV3IHVzZSBjYXNlIGZvciBETlMgY2FsbGVk ICJETlMgQXV0aG9yaXRhdGl2ZSBTb3VyY2UiIA0KICAgICAgaW4gc2hvcnQgRE5TLUFTLiBU aGlzIHVzZSBjYXNlIHVzZXMgdGhlIEROUyB0byBzdG9yZSBhbmQgcHJvdmlkZSAKICAgICAg bWV0YWRhdGEgYWJvdXQgYXBwbGljYXRpb25zLg0KICAgICAgVGhpcyBkYXRhIGlzIHByaW1h cmlseSBpbnRlbmRlZCB0byBiZSB1c2VkIGZvciBtZXRhZGF0YSBkcml2ZW4gDQogICAgICBB cHBsaWNhdGlvbiBWaXNpYmlsaXR5IGFuZCBDb250cm9sIGluIHNob3J0IEFWQy4NCiAgICAg IA0KICAgICAgT24gbmV0d29yayBlbGVtZW50cyBpdCBjYW4gYmUgdXNlZCBhcyBhIGtleSB0 byBsaW5rIGFwcGxpY2F0aW9uIHRvIHBvbGljeSANCiAgICAgIGluIHN1cHBvcnQgb2YgdGhv c2UgYXBwbGljYXRpb25zIGFzIGFsc28gZm9yIHZpc3VhbGl6YXRpb24gYWZ0ZXJ3YXJkcy4N CiAgICAgIEZvciBleGFtcGxlLCBhIG5ldHdvcmsgZWxlbWVudCBtaWdodCB1c2UgdGhlIGlu Zm9ybWF0aW9uDQogICAgICBvYnRhaW5lZCB0aHJvdWdoIHRoZSBBVkMgUlJUWVBFIHRvIHNl dCBRb1Mgb3IgYWNjZXNzIHBvbGljaWVzIGZvcg0KICAgICAgdHJhZmZpYyB0byBvciBmcm9t IGEgc3BlY2lmaWMgYXBwbGljYXRpb24uIA0KICAgICAgV2UgYXJlIGFwcGx5aW5nIGZvciBh IG5ldyBSUlRZUEUgdGhhdCBjYW4gaG9sZCB0aGUgYXBwbGljYXRpb24gbWV0YWRhdGEgYmVl biANCiAgICAgIHVzZWQgYnkgdGhlIEROUy1BUyB1c2UgY2FzZSBmb3IgZm9yIEFWQy4NCg0K ICAgRS4gRGVzY3JpcHRpb24gb2YgdGhlIHByb3Bvc2VkIFJSIHR5cGUuDQoNCiAgICAgIEdl bmVyYWwgQVZDIFJlc291cmNlIFJlY29yZCBzeW50YXg6DQogICAgICAiPG9wdGlvbj46PHZh bD57fDxvcHRpb24+Ojx2YWw+fSoiIA0KICAgICAgDQogICAgICBUaGUgUkRBVEEgaGFzIGV4 YWN0bHkgdGhlIHNhbWUgY29udGVudCBhcyBhIFRYVCByZWNvcmQuDQogICAgICBUaGUgb3B0 aW9uIGZpZWxkIGlzIGRlcml2ZWQgZnJvbSBSRkM2NzU5IE1ldGFkYXRhIENvbXBvbmVudHMg bG9uZyBuYW1lLg0KICAgICAgV2UgdHJ5IHRvIGtlZXAgdGhlIFJSIHNob3J0IHRvIG5vdCBl eGNlZWQgdGhlIDI1NSBjaGFyYWN0ZXJzIGFzIGFsc28gbWFrZSBpdA0KICAgICAgZWFzeSBw YXJzZWFibGUuIFRoZXJlZm9yZSB3ZSBzaG9ydGVuIHRoZSBSRkM2NzU5IG5hbWVzIGluc2lk ZSB0aGUgUlIgbGlrZSANCiAgICAgICJBcHBsaWNhdGlvbiBOYW1lIiB0byAiYXBwLW5hbWUi IG9yICJBcHBsaWNhdGlvbiBJRCIgdG8gImFwcC1pZCINCiAgICAgIEluIGNhc2UgYSBzaW5n bGUgcmVjb3JkIG1pZ2h0IGV4Y2VlZCAyNTUgY2hhcmFjdGVycyB3ZSBuZWVkIHRvIGFsbG93 IGZvciB0aGF0LCB0b28uDQogICAgICBUeXBpY2FsbHkgYW4gYXBwbGljYXRpb24gd291bGQg Y29uY2F0ZW5hdGUgdGhlIGluZGl2aWR1YWwgc3ViLXN0cmluZ3MgZGlyZWN0bHkNCiAgICAg ICp3aXRob3V0KiBhZGRpbmcgYW55IHNlcGFyYXRvci4NCg0KICAgICAgQW4gZXhhbXBsZSBm b3Igc3VjaCBhbiBBVkMgUkRBVEEgcmVjb3JkIHdpdGggYXBwIG1ldGFkYXRhIHdvdWxkIGJl Og0KICAgICAgImFwcC1uYW1lOldPTEZHQU5HfGFwcC1jbGFzczpPQU18YnVzaW5lc3M9eWVz IiANCg0KICAgICAgU2VlIGhlcmUgZm9yIG1vcmUgaW5mbzoNCiAgICAgIGh0dHA6Ly93d3cu ZG5zLWFzLm9yZy93aGF0LWlzL21ldGFkYXRhLw0KICAgICAgaHR0cDovL3d3dy5kbnMtYXMu b3JnL3N1cHBvcnQvZG5zLWFzLXJyLw0KDQogICBGLiBXaGF0IGV4aXN0aW5nIFJSVFlQRSBv ciBSUlRZUEVzIGNvbWUgY2xvc2VzdCB0byBmaWxsaW5nIHRoYXQgbmVlZA0KICAgICAgYW5k IHdoeSBhcmUgdGhleSB1bnNhdGlzZmFjdG9yeT8NCg0KICAgICAgTGlrZSBTUEYgd2UgYXJl IGN1cnJlbnRseSB1c2luZyB0aGUgVFhUIFJSIGZvciBETlMtQVMuIFRoZSBUWFQgUlJUWVBF IA0KICAgICAgY2FuIHN1cHBvcnQgYXJiaXRyYXJ5IFRMVnMgZW5jb2RlZCBhcyBhIHRleHQu IEluIGdlbmVyYWwgdGhpcyBraW5kIA0KICAgICAgb2YgKGFiKXVzZSBvZiBUWFQgUlIgaXMg ZGlzY291cmFnZWQgYXMgZGlzY3Vzc2VkIGluIFJGQzU1MDcgdGhlcmVmb3JlDQogICAgICB3 ZSBhcHBseSBmb3IgYSBkZWRpY2F0ZWQgcmVzb3VyY2UgcmVjb3JkLg0KDQogICBHLiBXaGF0 IG1uZW1vbmljIGlzIHJlcXVlc3RlZCBmb3IgdGhlIG5ldyBSUlRZUEUgKG9wdGlvbmFsKT8N CiAgICAgIG1uZW1vbmljPUFWQw0KDQogICBILiBEb2VzIHRoZSByZXF1ZXN0ZWQgUlJUWVBF IG1ha2UgdXNlIG9mIGFueSBleGlzdGluZyBJQU5BIHJlZ2lzdHJ5DQogICAgICBvciByZXF1 aXJlIHRoZSBjcmVhdGlvbiBvZiBhIG5ldyBJQU5BIHN1YnJlZ2lzdHJ5IGluIEROUw0KICAg ICAgUGFyYW1ldGVycz8gIElmIHNvLCBwbGVhc2UgaW5kaWNhdGUgd2hpY2ggcmVnaXN0cnkg aXMgdG8gYmUgdXNlZA0KICAgICAgb3IgY3JlYXRlZC4gIElmIGEgbmV3IHN1YnJlZ2lzdHJ5 IGlzIG5lZWRlZCwgc3BlY2lmeSB0aGUNCiAgICAgIGFsbG9jYXRpb24gcG9saWN5IGZvciBp dCBhbmQgaXRzIGluaXRpYWwgY29udGVudHMuICBBbHNvIGluY2x1ZGUNCiAgICAgIHdoYXQg dGhlIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmVzIHdpbGwgYmUuDQoNCiAgICAgIFRoZSBtbmVt b25pYyBzeW50YXggYXMgYWxzbyB0aGUgcG90ZW50aWFsIDxvcHRpb24+Ojx2YWw+IGZpZWxk cyBhcmUNCiAgICAgIGlubGluZSB3aXRoIFJGQzY3NTkgYW5kIHRoZSB1c2FnZSBpcyBkZXNj cmliZWQgaW4gZGV0YWlsIGhlcmU6DQogICAgICBodHRwOi8vd3d3LmRucy1hcy5vcmcvd2hh dC1pcy9tZXRhZGF0YS8NCiAgICAgIGh0dHA6Ly93d3cuZG5zLWFzLm9yZy9zdXBwb3J0L2F2 Yy1yZGF0YS8NCg0KICAgSS4gRG9lcyB0aGUgcHJvcG9zYWwgcmVxdWlyZS9leHBlY3QgYW55 IGNoYW5nZXMgaW4gRE5TDQogICAgICBzZXJ2ZXJzL3Jlc29sdmVycyB0aGF0IHByZXZlbnQg dGhlIG5ldyB0eXBlIGZyb20gYmVpbmcgcHJvY2Vzc2VkDQogICAgICBhcyBhbiB1bmtub3du IFJSVFlQRSAoc2VlIFtSRkMzNTk3XSk/DQoNCiAgICAgIE5vLg0KDQogICBKLiBDb21tZW50 czoNCg0KICAgICAgTm9uZS4= --------------090700030907060300000102--