Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS)
On Sat, Sep 2, 2017 at 6:38 PM, Warren Kumari wrote: > On Fri, Sep 1, 2017 at 10:41 AM, Eric Rescorla wrote: > > > > > > On Thu, Aug 31, 2017 at 8:39 PM, Mark Andrews wrote: > >> > >> > >> In message > >> <150413520708.16860.14531912464478386147.idtrac...@ietfa.amsl.com>, > >> Eric Rescorla writes: > >> > Eric Rescorla has entered the following ballot position for > >> > draft-ietf-homenet-dot-13: Discuss > >> > > >> > When responding, please keep the subject line intact and reply to all > >> > email addresses included in the To and CC lines. (Feel free to cut > this > >> > introductory paragraph, however.) > >> > > >> > > >> > Please refer to > >> > https://www.ietf.org/iesg/statement/discuss-criteria.html > >> > for more information about IESG DISCUSS and COMMENT positions. > >> > > >> > > >> > The document, along with other ballot positions, can be found here: > >> > https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ > >> > > >> > > >> > > >> > > -- > >> > DISCUSS: > >> > > -- > >> > > >> >A. Recursive resolvers at sites using 'home.arpa.' MUST > >> >transparently support DNSSEC queries: queries for DNSSEC > >> >records and queries with the DO bit set ([RFC4035] section > >> >3.2.1). While validation is not required, it is strongly > >> >encouraged: a caching recursive resolver that does not > >> >validate answers that can be validated may cache invalid > >> >data. This in turn will prevent validating stub resolvers > >> >from successfully validating answers. > >> > > >> > I don't understand the rationale for this requirement. As I understand > >> > it > >> > from this document, stuff ending in home.arpa cannot be DNSSEC > >> > validated, > >> > so what's it the business of this document to levy the requirement on > >> > sites which support home.arpa that they do anything with DNSSEC at > all. > >> > >> Wrong the responses can be validated. The output of the validation > >> step is one of secure, insecure, or bogus. With the exception of > >> home.arpa/DS and without private trust anchors being installed the > >> output of that validation should be insecure for all answers from > >> home.arpa. home.arpa/DS should validate as secure NODATA. > >> > >> In particular validation of the home.arpa/DS is important as it > >> prevents the cache being poisoned with answers which prevent the > >> stub proving that the home.arpa is supposed to exist and that it > >> doesn't have a chain of trust from the root. > > > > > > I don't see how this is different from any other kind of resolution. > > Jumpin' in the middle here. > > The root proves that .arpa exists. .arpa proves that home.arpa exists, > but, as there is no DS record, it also proves that names under > home.arpa are insecure, and so we can create foo.home.arpa, > bar.home.arpa, etc. > > If recursive resolvers at sites using 'home.arpa.' DID NOT > transparently support DNSSEC queries, then validating stubs would not > be able to query the .arpa servers, and get back the proof showing > that home.arpa is insecure, and so we would not make foo.home.arpa > exist. Of course, if recursive resolvers at sites using 'home.arpa.' > DID NOT transparently support DNSSEC queries they would break ALL > validation, and validating stubs wouldn't be able to resolve anything > at all... > Yes, I think this is consistent with the point I am making. Regardless, I've removed my Discuss, so I don't think there's a lot of point in continuing to debate this. -Ekr > > W > > > > > > -Ekr > > > >> > >> Mark > >> > >> > ___ > >> > homenet mailing list > >> > homenet@ietf.org > >> > https://www.ietf.org/mailman/listinfo/homenet > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > > > ___ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS)
On Fri, Sep 1, 2017 at 10:41 AM, Eric Rescorla wrote: > > > On Thu, Aug 31, 2017 at 8:39 PM, Mark Andrews wrote: >> >> >> In message >> <150413520708.16860.14531912464478386147.idtrac...@ietfa.amsl.com>, >> Eric Rescorla writes: >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-homenet-dot-13: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> > https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ >> > >> > >> > >> > -- >> > DISCUSS: >> > -- >> > >> >A. Recursive resolvers at sites using 'home.arpa.' MUST >> >transparently support DNSSEC queries: queries for DNSSEC >> >records and queries with the DO bit set ([RFC4035] section >> >3.2.1). While validation is not required, it is strongly >> >encouraged: a caching recursive resolver that does not >> >validate answers that can be validated may cache invalid >> >data. This in turn will prevent validating stub resolvers >> >from successfully validating answers. >> > >> > I don't understand the rationale for this requirement. As I understand >> > it >> > from this document, stuff ending in home.arpa cannot be DNSSEC >> > validated, >> > so what's it the business of this document to levy the requirement on >> > sites which support home.arpa that they do anything with DNSSEC at all. >> >> Wrong the responses can be validated. The output of the validation >> step is one of secure, insecure, or bogus. With the exception of >> home.arpa/DS and without private trust anchors being installed the >> output of that validation should be insecure for all answers from >> home.arpa. home.arpa/DS should validate as secure NODATA. >> >> In particular validation of the home.arpa/DS is important as it >> prevents the cache being poisoned with answers which prevent the >> stub proving that the home.arpa is supposed to exist and that it >> doesn't have a chain of trust from the root. > > > I don't see how this is different from any other kind of resolution. Jumpin' in the middle here. The root proves that .arpa exists. .arpa proves that home.arpa exists, but, as there is no DS record, it also proves that names under home.arpa are insecure, and so we can create foo.home.arpa, bar.home.arpa, etc. If recursive resolvers at sites using 'home.arpa.' DID NOT transparently support DNSSEC queries, then validating stubs would not be able to query the .arpa servers, and get back the proof showing that home.arpa is insecure, and so we would not make foo.home.arpa exist. Of course, if recursive resolvers at sites using 'home.arpa.' DID NOT transparently support DNSSEC queries they would break ALL validation, and validating stubs wouldn't be able to resolve anything at all... W > > -Ekr > >> >> Mark >> >> > ___ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-dot-14.txt
On Fri, Sep 1, 2017 at 2:46 PM, Walter H. wrote: > Hello, > > just one question for some better understanding ... > > I read this line > > "The domain name 'home.arpa.' is to be used for naming within > residential homenets." > > when this draft becomes an RFC - hopefully this year 2017 - then there > exists > an RFC, which gives you a domain name you can use in a home network/LAN > without conflicting to other things ..., the domain name 'home.arpa' > > but there still doesn't exist any for company networks, they most commonly > use > the domain name 'local', which I already noticed, that this conflicts to RFC > 6762 ... Around 2 months ago (AKA, *just* before the draft cutoff) I wrote https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00 -- this is specifically designed to be a reservation for a companies / organizations / test networks / disconnected networks, etc to be able to use. So far it has generated basically no discussion -- some of the purpose was simply to more fully discuss the issues, etc surrounding this sort of issue. Note that the document is not very well written, it was written on a plane and submitted in a rush. W > > Thanks, > Walter > > > On 01.09.2017 19:47, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Home Networking WG of the IETF. >> >> Title : Special Use Domain 'home.arpa.' >> Authors : Pierre Pfister >>Ted Lemon >> Filename: draft-ietf-homenet-dot-14.txt >> Pages : 11 >> Date: 2017-09-01 >> > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet