from:"Warren Kumari"

Re: [homenet] [dnsdir] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26

2023-01-31 Thread Warren Kumari

[ Top-post ]

Just a very quick note to say "Thank you very much!" to Anthony for this
review. This document is relatively long, contains lots of DNS related
content, and has had significant number of sizable update — all of which
leads to this being a much much larger than normal DNSDIR review load.

Thank you!
W



On Tue, Jan 31, 2023 at 12:30 PM, Anthony Somerset  wrote:

> Reviewer: Anthony Somerset
> Review result: Ready with Issues
>
> Hello
>
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as they pass
> through IETF last call and IESG review, and sometimes on special request.
> The purpose of the review is to provide assistance to the ADs. For more
> information about the DNS Directorate, please see https://wiki.ietf.org/
> en/group/dnsdir
>
> There are are clear and direct references to various DNS RFC's and this
> draft is not in any major conflict with the wider DNS space but the
> following specific suggestions relating to DNS are made.
>
> I previously Reviewed Version 18 of this draft and am re-rereviewing in
> line with the comments I made in that review -
> https://datatracker.ietf.org/doc/
> review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/
>
> Having re-read the new version a few times, and keeping track of the
> various reviews as not to duplicate reports for same issues i will try not
> say the same things again.
>
> I specifically note that Geoff has done a very definitive review of
> version 25 of the document and i won't repeat those comments in this review
> but suffice to say i do concur with the assessment of the situation in his
> review and agree with the position of Ready with Issues as well
>
> I am happy with the large effort to reflow the document - it does now read
> in a more sensible order and helps with clarity.
>
> I am also happy with the additional security considerations that make
> sense.
>
> Major Issues: None
>
> Minor Issues:
>
> Section 2 - Public Authoritative Servers - my original NIT was dealt with
> but I note that anycast is now referenced here which is still extraneous,
> we are not attempting to deal with the standard of how Public Authoritative
> Servers be managed operationally
>
> Section 3 - now Section 5 - i note specifically the comment about:
>
> "In the case the HNA is a CPE, outsourcing to the DOI protects the home
> network against DDoS for example."
>
> I personally would consider this a dangerously inaccurate statement.
>
> This offers NO protection against a DDoS, at best it (only) slightly
> reduces the attack surface exposed but it provides no meaningful additional
> protection.
>
> I specifically repeat this and recommend the statement be removed or
> re-worded appropriately
>
> Section 3.2 - Original NIT dealt with
>
> 1.1 - now 3 - NIT dealt with
>
> 3.1 now 5.1 - Typo fixed
>
> 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the
> reflowing of the document definitely helps here.
>
> Thanks
>
> --
> dnsdir mailing list
> dns...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsdir
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

2022-10-17 Thread Warren Kumari via Datatracker

Warren Kumari has entered the following ballot position for
draft-ietf-homenet-front-end-naming-delegation-18: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/



--
DISCUSS:
--

Please see:
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I am (reluctantly) balloting DISCUSS on the following criteria:
* The specification is impossible to implement due to technical or clarity
issues. * The protocol has technical flaws that will prevent it from working
properly, or the description is unclear in such a way that the reader cannot
understand it without ambiguity. * It is unlikely that multiple implementations
of the specification would interoperate, usually due to vagueness or incomplete
specification.

I apologize for doing this, as I know that this will be a difficult set of
comments to address. This isn't just a few "here are the DISCUSS points", but
rather "there are a sufficient number of lack of clarity issues (and
readability issues) that I don't think it can be understood and implemented
without ambiguity."

I have reviewed most of the document, but have only transcribed my comments up
to page 13. Because there are both nits and substantive comments on the same
bits of text (and to stop this gettign even longer) I have not separated them
into separate sections like I normally would.

I wanted to send this out now, so that the authors, WG and AD can start
reviewing and we can discuss some way to resolve this...


--
COMMENT:
--


Section 1:
1:
O: The remaining of the document is as follows.
P: The remainder of the document is as follows:
C: Nit - Grammar

2:
O: Section 3 provides an architectural view of the HNA, DM and DOI as well as
its different communication channels P: Section 3 provides an architectural
view of the HNA, DM and DOI as well as their different communication channels
C: Nit - Plural.

3:
O: Section 7 and Section 9 respectively details HNA security policies as well
as DNSSEC P: Section 7 and Section 9 respectively detail HNA security policies
as well as DNSSEC C: Nit - Grammar / plural

Section 1.1:
4:
O: Of these the link-local are never useful for the Public
Zone,
C: I don't really agree with the "never" - the document does discuss
failing back to the Public zone if needed, and so this may sometimes be
useful. I agree that it is much less common / useful, and this this is
probably a nit...

5:
O: "However, since communications
 are established with names which remains a global identifier, the
 communication can be protected by TLS the same way it is protected on
 the global Internet."
C: "However" implies that the sentence follows on from a previous point and
provides a refutation / comparison, and this sentence doesn't - it is more of a
fragment / new thought. C: s/remains/remain/ (grammar) C: More text is needed
here - I'm *assuming* that you are meaning that because the name is globally
resolvable to an address, that this can be used to obtain a certificate for
that name? If so, that's really not clear.

Section 1.2:
6:
O: "An alternative existing solution is to have a single zone, where a
 host uses a RESTful HTTP service to register a single name into a
 common public zone. "
P: "An alternative existing solution for residential customers is to..."
C: There are a number of alternative solutions, for example many companies use
DHCP to populate a zone (usually using RFC 2136), Windows Active Directory does
something similar, many cloud / hosting providers will add and remove entries,
etc.

7:
O: "This is often called "Dynamic DNS" [DDNS], and
 there are a number of commercial providers. While the IETF has
 defined Dynamic Update [RFC3007], in many - as far as the co-authors
 know in all cases - case commercial "Dynamic Update" solutions are
 implemented via a HTTPS RESTful API."
 C1: I think that you need to be much clearer that the "Dynamic DNS" you are
 talking about in the first sentence is different to Dynamic Updates. C2: I
 think that that is the wrong reference - RFC2136 is the Dynamic Updates RFC,
 RFC3007 wraps it in TSIG. C3: You have a repeated "case" (actually, "case"
 should move before the hyphen

Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS)

2017-09-02 Thread Warren Kumari

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

2017-09-02 Thread Warren Kumari

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

[homenet] Warren Kumari's No Objection on draft-ietf-homenet-dot-13: (with COMMENT)

2017-08-30 Thread Warren Kumari

Warren Kumari has entered the following ballot position for
draft-ietf-homenet-dot-13: No Objection

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/

--
COMMENT:
--

This was originally a DISCUSS, but Ted nicely (and quickly!) addressed my
concerns - clearing.

Major issues:

1: I think that this document could benefit from additional review in the DNSOP
WG - it got some
(https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that
was a: while it was still homenet. b: primarily focused in terms of RFC6761 and
not on the whole systems / interaction with existing behaviors, c: largely
devolved into "does this do go in the root zone or not"?, d: 9 revisions back.
The document feels vague about much of the details / expected behavior from all
of the different players, and I think more focused review from more DNS people
would help.

2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or
is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses
both terms makes me think that they are different, but I don't know how.

3: The document says: "Unless configured otherwise, recursive resolvers and DNS
proxies MUST behave as described in Locally Served Zones ([RFC6303] Section
3).", but I do not see this being added to the locally served zones registry.
This was raised in a previous review (Jon Mitchell, OpsDir (for v03)
https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/
), and not implemented. I'm assuming there is a reason, but I haven't found the
discussion.

4: The document describes what recursive servers should do with queries for
things in home.arpa, but seems to gloss over some detail -- I think that the
document would benefit from an overview showing the stub (and / or validating
stub), an internal recursive / proxy, an external recursive, the local
authoritative for home.arpa, and the .arpa servers, and clearly explain what
the expected behavior / role for each one under various scenarios is.

5: Even with the above answered, I remain confused by the "what does a
recursive resolver do" bit -- this discusses what a recursive server should do
with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC
validating stubs from believing that foo.home.arpa is bogus. It also means that
it is expected that queries from stubs will sometimes arrive at these recursive
resolvers (and they "MUST behave as described in Locally Served Zones" is not
simply to prevent pollution). If a query for printer.bedroom.home.arpa does
arrive at a recursive, and it is configured as a locally served zone, it will
return NXDOMAIN. This (obviously) breaks the lookup for
printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Nothing
Underneath ") also says that this means that nothing exists in
bedroom.home.arpa - I think that there needs to be some more text describing
the deployment, and which set of queries go where.

6: Section 7. Delegation of ’home.arpa.’
This delegation MUST NOT include a DS record, and MUST point to one or more
black hole servers, for example ’blackhole-1.iana.org.’ and ’blackhole-
2.iana.org.’. I fully agree with the DS bit, but the "blackhole" bit feels VERY
hand-wavey. Currently a lookup for home.arpa to these returns REFUSED instead
of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; Got
answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; flags: qr
rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion
requested but not available

;; QUESTION SECTION:
;home.arpa. IN A

The document just delegates this to ’blackhole-1.iana.org.’ and ’blackhole-
2.iana.org.’ - they're are not authoritative for home.arpa (and nothing in the
doc makes them so), and so this does not return NXDOMAIN and instead amplifies
the query load. Delegating them to RFC7535 servers *may* help, but I'm not sure.

7: "In addition to the behavior specified above, recursive resolvers that can
be used in a homenet MUST be configurable with a delegation to an
authoritative server for that particular homenet’s instance of the domain
’home.arpa.’." -- Ok, but how does this interact with the requirements on
local-zones? I'm *guessing* it overrides it, and if I get a query for
printer.livingroom.home.arpa

Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

2017-08-30 Thread Warren Kumari

Ok, I'm surprised - I spent much time with this review, and felt bad
submitting a number of DISCUSS points close to the telechat. I thought
that addressing them might end up in this going back to the WG -- but,
your (really quick) responses more than adequately addresses my
DISCUSS (and major concerns).

Thank you, I'm clearing my discuss position -- more inline, but I'm a
happy camper.



On Wed, Aug 30, 2017 at 3:54 PM, Ted Lemon <mel...@fugue.com> wrote:
> On Aug 30, 2017, at 3:10 PM, Warren Kumari <war...@kumari.net> wrote:
>> 1: Section 4.  Domain Name Reservation Considerations, Subsection 4
>> If I'm a recursive server and I am configured "with a delegation to an
>> authoritative server for that particular homenet’s instance of the domain
>> ’home.arpa.’." then I have a local zone containing "home.arpa   IN   NS
>> ". Unless I'm really confused, this means
>> that I have to make myself authoritative for .arpa, which will a: break
>> everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to
>> validating stubs. (See also #5). Perhaps you mean that there should be
>> something like (BINDism): zone "home.arpa" {
>>type forward;
>>forwarders { 192.0.2.1; 192.0.2.2; };
>> };
>> This possibility only came to me after much thought, and I do not think that 
>> it
>> could be described as "a delegation". I also do not think that this is a
>> standard / well defined behavior.
>
> Yup, that's bogus.   Is this better?
>
> In addition to the behavior specified above, recursive 
> resolvers that can be used in
> a homenet MUST be configurable to forward queries for 
> 'home.arpa.' and subdomains of
> 'home.arpa.' to an authoritative server for 'home.arpa.'.   
> This server will provide
> authoritative data for 'home.arpa.' within a particular 
> homenet.   The special
> handling for DS records for the 'home.arpa.' delegation is 
> still required.

Much better, thanks.


>
>
>> 2: Section 4.  Domain Name Reservation Considerations, Subsection 4
>> "Caching resolvers conforming to this specification MUST support DNSSEC
>> queries." This is a MUST, so it's important to understand, but I don't
>> understand what it actually means.  What is a "DNSSEC query"? It is just one
>> with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I
>> don't know what this means, so I don't know if it applies to me / what I 
>> should
>> do.
>
> I think this is clarified in the -13 version of the document.   Is this 
> review based on that version, or on -12?   Here is the new text:
>
> Recursive resolvers at sites using 'home.arpa.' MUST 
> transparently support
> DNSSEC queries: queries for DNSSEC records and queries with 
> the DO bit set
> ( 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.

WFM.

>
>> 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST
>> behave as described in Locally Served Zones ([RFC6303] Section 3).  That is,
>> queries for domains that are subdomains of ’home.arpa.’ MUST NOT be 
>> forwarded,
>> with one important exception: ..." This says that I must not forward for
>> *domains* that are *subdomains* of home.arpa. The example shows a lookup for 
>> NS
>> for 'home.arpa', so presumably this is actually talking about subdomains of
>> home.arpa.  So, I have no idea what to do for lookups within home.arpa itself
>> -- what do I do with query for the A record for printer.home.arpa? It is 
>> simply
>> a name within home.arpa; I have no way of knowing if it is a subdomain of
>> home.arpa but it certainly isn't a domain that is a subdomain of home.arpa
>> (because there are only three label, not four).
>
> Yes, the other text had the same problem.   How about "queries for 
> 'home.arpa.' and subdomains of 'home.arpa.'"?

WFM. Thanks.

>
>> --
>> COMMENT:
>> --
>>
>> Major issues:
>>
>> 1: I think that this document could benefit from additional review in the 
>> DNSOP
>> WG - it got some
>> (https://www.ietf.org/ma

[homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

2017-08-30 Thread Warren Kumari

Warren Kumari 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:
--

1: Section 4. Domain Name Reservation Considerations, Subsection 4
If I'm a recursive server and I am configured "with a delegation to an
authoritative server for that particular homenet’s instance of the domain
’home.arpa.’." then I have a local zone containing "home.arpa IN NS
". Unless I'm really confused, this means
that I have to make myself authoritative for .arpa, which will a: break
everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to
validating stubs. (See also #5). Perhaps you mean that there should be
something like (BINDism): zone "home.arpa" {
type forward;
forwarders { 192.0.2.1; 192.0.2.2; };
};
This possibility only came to me after much thought, and I do not think that it
could be described as "a delegation". I also do not think that this is a
standard / well defined behavior.

2: Section 4. Domain Name Reservation Considerations, Subsection 4
"Caching resolvers conforming to this specification MUST support DNSSEC
queries." This is a MUST, so it's important to understand, but I don't
understand what it actually means. What is a "DNSSEC query"? It is just one
with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I
don't know what this means, so I don't know if it applies to me / what I should
do.

3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST
behave as described in Locally Served Zones ([RFC6303] Section 3). That is,
queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded,
with one important exception: ..." This says that I must not forward for
*domains* that are *subdomains* of home.arpa. The example shows a lookup for NS
for 'home.arpa', so presumably this is actually talking about subdomains of
home.arpa. So, I have no idea what to do for lookups within home.arpa itself
-- what do I do with query for the A record for printer.home.arpa? It is simply
a name within home.arpa; I have no way of knowing if it is a subdomain of
home.arpa but it certainly isn't a domain that is a subdomain of home.arpa
(because there are only three label, not four).

--
COMMENT:
--

Major issues:

5: Even with the above answered, I remain confused by the "what does a
recursive resolver do" bit -- this discusses what a recursive server shou

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Warren Kumari

On Mon, Jul 31, 2017 at 5:36 AM, Ted Lemon  wrote:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
>
> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> here is *important*.
>
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five?   The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?

Having recently had exactly this discussion with someone, this area is
fraught with opportunities for misunderstandings.

Let's take example.com as an example[0]. The .com zone is signed.
Example Corp hired a DNS geek, who signed the example.com zone, but
never quite got around to publishing a DS record in the parent.

There is now a signed, insecure delegation to a signed zone; the
delegation itself is signed (.com is a signed zone and so there there
is an RRSIG for the NS for example.com), but there is no DS record, so
it is insecure.

It really is an insecure delegation, not an unsigned delegation --
calling it unsigned would be confusing to many people. The person I
was discussing it with wasn't aware of the term "insecure delegation"
and assumed that it meant an "unsigned delegation", which is, um,
difficult to achieve in a non-NSEC3 OO zone...

I spend an almost infinite amount of time[1] trying to explain this
very point (to someone who understands DNSEEC) over the phone - it's
tricky to communicate without a whiteboard and / or diagram.
I ended up opening an issue on the terminology-bis document to get it
added: 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/26#issuecomment-314275871

W
[0]: For the purpose of discussion, let's pretend that .COM uses NSEC,
not NSEC3 with Opt-Out.
[1]: Ok, perhaps it wasn't almost infinite, but it sure felt like it...

>
>
> ___
> 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] [dnsdir] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26

[homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS)

Re: [homenet] I-D Action: draft-ietf-homenet-dot-14.txt

[homenet] Warren Kumari's No Objection on draft-ietf-homenet-dot-13: (with COMMENT)

Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

[homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

8 matches

Site Navigation

Mail list logo

Footer information