On 12/14/2016 12:34 PM, Steve Crocker wrote:
Mike,
A query to the root for .homenet results in a *signed* answer that
.homenet does not exist. This should suffice for the purpose you have
in mind.
Yup - that's my comment:
The third way is to do no delegation from the root for .homenet and
just ensure that that name never gets registered and published.
Ralph,
Re moving to the homenet list, I will try to send the same info there
once I have time to sign up for that list.
Actually, I think Ray was probably more right on where this -
specifically - should be discussed. Once done, then Homenet needs to
consider what to do about the guidance.
Mike
Steve
On Dec 14, 2016, at 12:23 PM, Michael StJohns <m...@nthpermutation.com
<mailto:m...@nthpermutation.com>> wrote:
On 12/14/2016 12:07 PM, Ted Lemon wrote:
I hope it was obvious that I was pretty confident that you actually
had a reason. :)
The issue what what you are saying is that sometimes it is
technically correct for a name to not be validatable. The reason
we want an unsecured delegation for .homenet is that .homenet can't
be validated using the root trust anchor, because the name is has no
globally unique meaning. So the reason that you've given doesn't
apply to this case, although I completely agree with your reason as
it applies to the case of names that are globally unique.
I went back and forth on this three times in 3 minutes "Steve's
right, no Ted's right, no, Steve's right" before settling on "I think
Steve is mostly right, but there may be an alternative third approach".
Here's the reasoning: Either your home router understands .homenet
or it doesn't. If it doesn't, then your homenet shouldn't be using
.homenet and any .homenet lookups to the real world should fail. If
it does, then it should trap .homenet queries and do with it what it
will.
Doing it Steve's way removes one attack surface for non-compliant
routers on home networks and for all the rest of the networks (e.g.
feeding a user a URL with a .homenet name on a fake webpage).
However, I think doing it Steve's way requires a *real* TLD zone for
.homenet, if for no other reason than to include NSEC and NSEC3
records indicating an empty domain.
The third way is to do no delegation from the root for .homenet and
just ensure that that name never gets registered and published.
"If it's stupid and it works, it's not stupid".
Mike
On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker <st...@shinkuro.com
<mailto:st...@shinkuro.com>> wrote:
The latter. All DNS answers at all levels should be signed to
assure the querier of the integrity of the answer. This has
been the goal and best practice for a very long time. For
example, it was the explicit objective of the quote substantial
DNSSEC effort funded by the US Dept of Homeland Security
starting in 2004.
Within ICANN, in 2009 we made it a formal requirement of all new
gTLDs must be signed. The ccTLDs are not subject to ICANN rules
but they have been gradually moving toward signed status. Most
of the major ccTLDs are signed and many of the others are too.
Detailed maps are created every week by ISOC.
I will also try to contribute to the homenet mailing list.
Steve
Sent from my iPhone
On Dec 14, 2016, at 11:36 AM, Ted Lemon <mel...@fugue.com
<mailto:mel...@fugue.com>> wrote:
Is this a matter of religious conviction, or is there some
issue with unsecured delegations in the root that you are
assuming is so obvious that you don't need to tell us about it?
:)
On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker
<st...@shinkuro.com <mailto:st...@shinkuro.com>> wrote:
I am strongly opposed to unsecured delegations in the root
zone. No matter what the problem is, an unsecured
delegation is not the answer.
Steve
On Dec 14, 2016, at 11:11 AM, Suzanne Woolf
<suzworldw...@gmail.com <mailto:suzworldw...@gmail.com>>
wrote:
Hi all,
DNSOP participants who are interested in the special use
names problem might want to review
draft-ietf-homenet-redact
(https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/
<https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/>)
and draft-ietf-homenet-dot
(https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/
<https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/>)
for the WGLC on them in the HOMENET wg.
WGLC comments should go to the WG list, home...@ietf.org
<mailto:home...@ietf.org>.
If you do, it will also be helpful to look at RFC 7788,
which specifies the Home Networking Control Protocol for
homenets.
The redact draft is intended to remove the inadvertent
reservation of “.home” as the default namespace for
homenets in RFC 7788.
The homenet-dot draft is intended to provide a request
under RFC 6761 for “.homenet” as a special use name to
serve as a default namespace for homenets. It also asks
IANA for an unsecured delegation in the root zone to avoid
DNSSEC validation failures for local names under
“.homenet”. The root zone request to IANA has caused some
discussion within the WG, as there’s no precedent for such
a request.
Terry Manderson mentioned the homenet-dot draft briefly at
the mic in Seoul.
The WGLC ends this week.
Suzanne
Begin forwarded message:
*From: *Ray Bellis <r...@bellis.me.uk
<mailto:r...@bellis.me.uk>>
*Subject: **[homenet] WGLC on "redact" and "homenet-dot"*
*Date: *November 17, 2016 at 11:27:08 PM EST
*To: *HOMENET <home...@ietf.org <mailto:home...@ietf.org>>
This email commences a four week WGLC comment period on
draft-ietf-homenet-redact and draft-ietf-homenet-dot
Please send any comments to the WG list as soon as possible.
Whilst there was a very strong hum in favour of
".homenet" vs anything
else during the meeting, and there's some discussion of
that ongoing
here on the list - I'd like us to please keep the
discussion of the
choice of domain separate from other substantive comment
about the
drafts' contents.
thanks,
Ray
_______________________________________________
homenet mailing list
home...@ietf.org <mailto:home...@ietf.org>
https://www.ietf.org/mailman/listinfo/homenet
<https://www.ietf.org/mailman/listinfo/homenet>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
