date:20170830

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

2017-08-30 Thread Ted Lemon

Yup, Adam Roach caught that as well and the document will be updated with
some new text:

This section specifies considerations for systems involved in domain
name resolution
when resolving queries for names ending with '.home.arpa.'.  Each
item 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 , Section 5.

On Wed, Aug 30, 2017 at 10:34 PM, Dale R. Worley  wrote:

> Ted Lemon  writes:
> > I've updated the document to separate this out into three lettered
> > subheads.   We can't change the numbering, because that's required by
> > RFC 6761, but I agree that it's clearer if the three separate topics
> > are split out.
>
> I hadn't realized from the draft that the items in section 4 are meant
> to parallel the items in section 5 of RFC 6761, since the connecting
> text is only "(as per [RFC 6761])".  Perhaps it would help to amplify
> that to "(per the template in [RFC 6761] section 5)".
>
> Dale
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

2017-08-30 Thread Dale R. Worley

Ted Lemon  writes:
> I've updated the document to separate this out into three lettered
> subheads.   We can't change the numbering, because that's required by
> RFC 6761, but I agree that it's clearer if the three separate topics
> are split out.

I hadn't realized from the draft that the items in section 4 are meant
to parallel the items in section 5 of RFC 6761, since the connecting
text is only "(as per [RFC 6761])".  Perhaps it would help to amplify
that to "(per the template in [RFC 6761] section 5)".

Dale

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2017-08-30 Thread Eric Rescorla

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.




___
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 I should "forward" it to the authoritative
servers? The document also seems

Minor issues / nits:
1: Section 1.

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  wrote:
> On Aug 30, 2017, at 3:10 PM, Warren Kumari  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/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.

Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

2017-08-30 Thread Ted Lemon

On Aug 29, 2017, at 10:03 PM, Ted Lemon  wrote:
> Yes.   As far as I know the text gives IANA the information they need to do; 
> I do not know how they operate their black hole servers, so I am trusting 
> that these instructions are sufficient.   They have been reviewed by people 
> who understand this problem better than I do, like Andrew Sullivan, Paul 
> Hoffman and Mark Andrews.   I was specifically advised not to overspecify 
> this.   I would rather take their word on this than yours, if you will 
> forgive my saying so. :)

Argh.   Warren made me look more closely, and you were right.   Sorry for 
doubting.   :]   Here is the new text for the IANA considerations section:

IANA is further requested to create a new subregistry within the 
"Locally-Served DNS
Zones" registry , titled "Transport-Independent 
Locally-Served DNS
Zones", with the same format as the other subregistries.  IANA is 
requested to add an
entry in this new registry for 'home.arpa.' with the description 
"Homenet Special-Use
Domain", listing this document as the reference.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2017-08-30 Thread Ted Lemon

On Aug 30, 2017, at 3:10 PM, Warren Kumari  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.

> 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.

> 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.'"?

> --
> 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/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.

I disagree.   The document has had substantial review from DNSOP people, 
including recently.   They are mentioned in the acknowledgments.   I think that 
I've fixed a couple of the things in -13 that triggered this reaction.   In 
particular:

> 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.

The term "caching resolver" was carried over from 6761.   What is meant here is 
"recursive resolver" or "full service resolver," which I think are

[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:

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

2017-08-30 Thread Adam Roach


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 > wrote:
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."


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 , Section 5.



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?


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."




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?



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2017-08-30 Thread Ted Lemon

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  wrote:
> 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."

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 , Section 5.

>>> 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?
>> 
>> 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."
> 
> 
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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2017-08-30 Thread Kathleen Moriarty

Kathleen Moriarty 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:
--

Thanks for queuing up changes from the SecDir review and adding mention of
privacy implications into the security considerations section.  I read through
the responses on the SecDir list and agree with the statements and changes made.

https://mailarchive.ietf.org/arch/msg/secdir/E7fjRdo94abFW5nqjVBbLspvkww


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

2017-08-30 Thread Mark Andrews


In message <4b072264-2824-4433-a24d-df5d2fd5a...@fugue.com>, Ted Lemon writes:
> El Aug 24, 2017, a les 7:20 AM, Dale Worley  va
> escriure:
> > 4.  Domain Name Reservation Considerations
> >
> >   3.  Name resolution APIs MUST send queries for such
> >   names to a recursive DNS server that is configured to be
> >   authoritative for the 'home.arpa.' zone appropriate to the
> >   homenet.
> >
> > If I understand the terminology correctly, this rules out sending the
> > query to a DNS server that recursively sends the query to a server
> > that is authoritative for home.arpa.  If that is intended and there
> > are technical reasons for making this prescription, that's OK, but I
> > want to check that that is intended, as this rule is stricter than the
> > similar rule in the second paragraph of item 4, which is qualified
> > "Unless configured otherwise".
>
> Wow.   The text here is just flat wrong: recursive name servers aren't
> authoritative.   You can of course combine them, but this text doesn't
> agree with some other text later in the document.   What the text is
> supposed to be saying is that the stub resolver has to use the recursive
> resolver that was provided by the network; if it uses a manually
> configured resolver, it may get the wrong answer.   I will have to rework
> this textâthanks so much for calling this to my attention, even though
> what you noticed isn't exactly what's wrong!   :)
>
> As for the discrepancy itself, the reason for this is that recursive
> resolvers are supposed to stop home.arpa queries leaking to the root,
> whereas stub resolvers can (must!) fob that responsibility off on the
> recursive resolver.   If they are configured to send these queries to,
> e.g., 8.8.8.8, we just have to hope that google doesn't forward them to
> the root (as would be consistent with the text in item 4).

Or the recursive server has learnt that 8.8.8.8 is "special" and
is the equivalent of the root servers in terms of keeping local
traffic local.  Maintaining the list of don't leak too recursive
servers is a "interesting" problem.

Mark
-- 
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

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

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

[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)

Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

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] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

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

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

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

12 matches

Site Navigation

Mail list logo

Footer information