Subject: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 28 Aug 2017 15:07:31 -0700

Adam Roach has entered the following ballot position for
draft-ietf-homenet-dot-12: 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:
----------------------------------------------------------------------

Section 4 contains a list that it describes as defining "the behavior of [DNS]
systems". Item number 7 seems to be something else: I don't know what code or
configuration would result from this statement. Maybe move this item to section
3?

I'm having a hard time reconciling the normative requirement in section 4:

       Name resolution APIs and libraries MUST NOT recognize names that
       end in '.home.arpa.' as special and MUST NOT treat them
       differently.

With the explanation in section 6:

   it may be useful for the resolver to identify different
   homenets on which it has resolved names

Doesn't this mitigation in the security section require name resolution
libraries to recognize names that end in ".home.arpa." as special so that it
can treat them differently?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Aug 2017 18:29:08 -0400

> configuration would result from this statement. Maybe move this item to section

This is the format that RFC 6761 requires us to follow, which is why it's being done this way.   I think the text makes sense if you read it with the RFC 6761 list of criteria in section 5 in mind.   So I don't think it makes sense to move it, although I agree it scans a bit strangely. :)

> can treat them differently?

Section 6 is talking about future work.   If we come up with a way to do this, then it would update this document, changing the normative requirement.

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Aug 2017 22:18:56 -0500

On 8/28/17 5:29 PM, Ted Lemon wrote:
> El Aug 28, 2017, a les 6:07 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> va escriure:
> This is the format that RFC 6761 requires us to follow, which is why 
> it's being done this way.   I think the text makes sense if you read 
> it with the RFC 6761 list of criteria in section 5 in mind.   So I 
> don't think it makes sense to move it, although I agree it scans a bit 
> strangely. :)

Oh! That makes a lot more sense -- I should have chased down that 
section in 6761. I think what's tripping me up is the introduction in 
the homenet-dot draft: "This section defines the behavior of systems 
involved in domain name resolution when resolving queries for names 
ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if 
it said something more like "This section reserves the '.home.arpa.' 
subdomain according to the procedures outlined in [RFC6761] section 4."

(I'll also note that 6761 appears to require this to be "a subsection of 
the 'IANA Considerations' section", so you might consider moving it 
accordingly -- this would have been somewhat less confusing if it were 
clearer that it's part of the registration process, which putting it in 
the 'IANA Considerations' section would have done.)
> Section 6 is talking about future work.   If we come up with a way to 
> do this, then it would update this document, changing the normative 
> requirement.

To me, this reads as something that could be done unilaterally by the 
local resolver according to their own reasonable notion of what the 
proper mitigations might be here. I would suggest rephrasing to make it 
clearer that this suggestion pertains to _future_ work; e.g., "To 
prevent this from happening, future documents may define behavior that 
allows resolvers to identify and distinguish among different homenets on 
which they have resolved names, and take appropriate measures to avoid 
such confusion."

/a

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Aug 2017 09:52:36 -0400

OK, these both sound like worthwhile updates to the doc.   I will add them to my working copy and send proposed diffs later today (I'm in the middle of processing the gen-art review).

> El Aug 28, 2017, a les 11:18 PM, Adam Roach <[email-masked]> va escriure:
> 
>> El Aug 28, 2017, a les 6:07 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> va escriure:
> Oh! That makes a lot more sense -- I should have chased down that section in 6761. I think what's tripping me up is the introduction in the homenet-dot draft: "This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said something more like "This section reserves the '.home.arpa.' subdomain according to the procedures outlined in [RFC6761] section 4."
> 
> (I'll also note that 6761 appears to require this to be "a subsection of the 'IANA Considerations' section", so you might consider moving it accordingly -- this would have been somewhat less confusing if it were clearer that it's part of the registration process, which putting it in the 'IANA Considerations' section would have done.)
>> 
> To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasing to make it clearer that this suggestion pertains to _future_ work; e.g., "To prevent this from happening, future documents may define behavior that allows resolvers to identify and distinguish among different homenets on which they have resolved names, and take appropriate measures to avoid such confusion."
> 
> 
> 
> /a
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2017 12:25:58 -0400

Argh, I spaced out on doing these changes because the security review was so extensive.   Sorry about that.   I'm making changes to my version of the document, but I will refrain from further confusing the datatracker—assuming that this document is approved tomorrow, I can submit an update with these changes and any others that come up on the telechat.

> On Aug 28, 2017, at 11:18 PM, Adam Roach <[email-masked]> wrote:

The requirement to put this in the IANA considerations section is actually probably a bad idea, because it would create a lot of irrelevant chaff for the IANA to parse through.   I think it was well-intended, but I've never actually seen it done this way in previous RFC 6761 allocations.   That said, your basic point is correct—there should be a better explanation of what's going on in this section.   I've updated the introductory text for this section as follows:

	This section specifies considerations for systems involved in domain name resolution
	when resolving queries for names ending with '.home.arpa.'.  Each items in this section
	addresses some aspect of the DNS or the process of resolving domain names that would be
	affected by this special use allocation.  Detailed explanations of these items can be
	found in <xref target="RFC6761"/>, Section 5.

> To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasin…
Yup, that makes sense.   Proposed update:

	  To prevent this from happening, it could be useful for the resolver to securely
	  differentiate between different homenets, and between identical names on different
	  homenets.  However, a mechanism for doing this has not yet been standardized, and
	  doing so is out of scope for this document.  It is expected that this will be explored in
	  future work.

OK?

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Aug 2017 11:59:15 -0500

Thanks. Both changes look good to me.

/a

On 8/30/17 11:25, Ted Lemon wrote:
> Argh, I spaced out on doing these changes because the security review 
> was so extensive.   Sorry about that.   I'm making changes to my 
> version of the document, but I will refrain from further confusing the 
> datatracker—assuming that this document is approved tomorrow, I can 
> submit an update with these changes and any others that come up on the 
> telechat.
>
>> On Aug 28, 2017, at 11:18 PM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer 
>> if it said something more like "This section reserves the 
>> '.home.arpa.' subdomain according to the procedures outlined in 
>> [RFC6761] section 4."
>
> The requirement to put this in the IANA considerations section is 
> actually probably a bad idea, because it would create a lot of 
> irrelevant chaff for the IANA to parse through.   I think it was 
> well-intended, but I've never actually seen it done this way in 
> previous RFC 6761 allocations.   That said, your basic point is 
> correct—there should be a better explanation of what's going on in 
> this section.   I've updated the introductory text for this section as 
> follows:
>
>> proper mitigations might be here. I would suggest rephrasing to make 
>> it clearer that this suggestion pertains to _future_ work; e.g., "To 
>> prevent this from happening, future documents may define behavior 
>> that allows resolvers to identify and distinguish among different 
>> homenets on which they have resolved names, and take appropriate 
>> measures to avoid such confusion."
>>
>>