Re: [DNSOP] Looking for IANA registry for --xn

[Phillip Hallam-Baker]

No it is not a pedantic difference.

If it isn't in a registry it didn't happen.

It is like when someone decided to do an April Fools RFC which used a code
point in PKIX space that wasn't actually registered with IANA. That caused
some real chaos.

Protocol matters. And just because IANA does 'assignments' that are not
'registrations' doesn't mean that is right or should continue.


On Thu, Oct 6, 2016 at 9:56 PM, Paul Hoffman  wrote:

> On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:
>
> On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  wrote:
>>
>>> RFC 3490 does say something about the ACE prefix.
>>>
>>> ​It says it has been registered but not where and there is no IANA
>>>
>> registry that references RFC3490​
>>
>
> It does not say it was "registered", it says that it was "assigned":
>
>11. IANA Considerations
>
>   IANA has assigned the ACE prefix in consultation with the IESG.
>
> This is not a pedantic difference: IANA keeps registries for things it has
> registered. This prefix was assigned by IANA as a neutral body that helped
> determine a prefix that was unlikely to have been used in public domain
> labels; you can read the mailing list for why that came about that way.
> There was no registry for prefixes because it was a one-off for this RFC
> only. That can change in the future, of course.
>
> --Paul Hoffman
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Looking for IANA registry for --xn

[Paul Hoffman]

On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:

On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  
wrote:

RFC 3490 does say something about the ACE prefix.

​It says it has been registered but not where and there is no IANA

registry that references RFC3490​


It does not say it was "registered", it says that it was "assigned":

   11. IANA Considerations

  IANA has assigned the ACE prefix in consultation with the IESG.

This is not a pedantic difference: IANA keeps registries for things it 
has registered. This prefix was assigned by IANA as a neutral body that 
helped determine a prefix that was unlikely to have been used in public 
domain labels; you can read the mailing list for why that came about 
that way. There was no registry for prefixes because it was a one-off 
for this RFC only. That can change in the future, of course.


--Paul Hoffman

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

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[Tim Wicinski]

On 10/6/16 3:58 PM, Stephane Bortzmeyer wrote:

On Thu, Oct 06, 2016 at 01:47:28PM -0400,
 John R Levine  wrote
 a message of 34 lines which said:


It still seems to me that the time to add the wildcards back in
would be less than the time to do two separate documents.  Unless
there's some reason that this needs to be published in a hurry,


Not for me, I'm fine with a delay (there have been many important
changes between -02 and -03, during the WGLC, so, some time to digest
and study them may be worth it).



I agree. There is no need to hurry this along. I'd rather get this right.

tim

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[John Levine]

> If someone can just start using a name and thus make it too hard
> to delegate we have a much a bigger problem.

That's been true approximately forever, viz. .onion, .belkin, .corp,
.local, .mail, and probably still .uucp that are too poisoned to allow
reliable delegation and new use.  That's why we're here.

The fundamental and I hope obvious problem, is that the IETF and ICANN
have no control over software that people write and the hardware they
embed it in.  If someone creates popular software leaking requests for
.PICKLE, we can grouse all we want but since we're not the Network
Police, there's not much we can do about it.

R's,
John

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

Re: [DNSOP] Looking for IANA registry for --xn

[Phillip Hallam-Baker]

On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  wrote:

>  Robert Edmonds writes:
>
>  > Donald Eastlake wrote:
>  > > Sure, you can consider the root zone to be the registry for TLDs but
> the
>  > > point is the xn-- labels are recommended to be interpreted specially
> at the
>  > > user interface at all levels...
>  >
>  > Nor would this say anything about "CCHH" prefixed labels in general.
>  >
>
> RFC 3490 does say something about the ACE prefix.
>
> ​It says it has been registered but not where and there is no IANA
registry that references RFC3490​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[George Michaelson]

If you can come up with an efficient, "fair" and trusted process for a
unitary name space on domain principles (domains of scope. trees.)
that doesn't confront collisions over desires for labels at arbitrary
points in the tree, and of essential 'centrality' in decision making
logic over things especially the apex of the tree, computer science
would like to know.

Meantime, we have this tree, and we have a lot of documentation around
this tree, and we have a current bilateral view between two agencies
on this tree, and we're discussing this tree, in the context of one of
those agencies: we're using IETF infrastructure, IETF processes, IETF
methodologies, to discuss that tree.

I agree pejorative language doesn't help, and I share responsibility
for its over-use. I apologize for intemperate use of language.

Peer to peer, hash based, location-id separator,  all
discuss concepts which collide in this model.

It might surprise you to know, that outside of this conversation I
hold different views about social equity, and who should or should not
be vested with authority in names. I try to draw distinctions between
what I think as a consumer, and a user, and what I observe from my
training and praxis.

I hold a unitary name space as a public good in very high regard. I
think p2p models, and models of probabalistic or hash naming are
interesting, but they wind up needing to map coherently to DNS names.
What I depart from, in the conversation, is how high in the DNS tree
that coherence has to vest.

A lot of your commentary goes to procedural fairness. I won't pretend
we don't have a problem there. I think you, and others in development
of novel systems have a right to feel severely disadvantaged by
process as it stands.

-G

On Thu, Oct 6, 2016 at 7:48 PM, hellekin  wrote:
> On 10/06/2016 09:22 AM, avri doria wrote:
>>
>> As for the so-called toxic waste names (i really find that terminology
>> problematic)
>>
>
> I agree it's a problem to use that kind of vocabulary to convey a
> technical context.
>
>> the so called waste pile of usurped names
>>
>
> Therefore this is also a problem to call names-used-in-the-wild
> "usurped" or "squatted", because it says that there's a central body
> that assigns names, and it defines who can use them, with the
> exclusivity of any other approach.  I know this idea may sound funny to
> a lot of people given the missions of IANA and ICANN, and the existence
> of trademarks and so-called 'intellectual property', but to me, having
> an authority over who can use what names *in general*--as opposed to
> particular, specific cases (e.g., trademarks)--is akin to the Novlang
> Committee.
>
> Names in the DNS are sanctioned by IANA/ICANN, and those names are
> 'legitimate' in the context of Internet names.  That doesn't mean at all
> that names not sanctioned by ICANN are illegitimate, or that names
> covered by trademarks are more 'legitimate' than 'unprotected' names.
> This is all a matter of transactions and legal-firepower.  But from
> there to legitimate this transactional-belligerent perspective over any
> other (historical, cultural, incidental, ontogenetic, etc.) seems to me
> problematic and abusive.
>
> ==
> hk
>
> ___
> 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

Re: [DNSOP] Looking for IANA registry for --xn

[Jaap Akkerhuis]

 Robert Edmonds writes:

 > Donald Eastlake wrote:
 > > Sure, you can consider the root zone to be the registry for TLDs but the
 > > point is the xn-- labels are recommended to be interpreted specially at the
 > > user interface at all levels...
 > 
 > Nor would this say anything about "CCHH" prefixed labels in general.
 > 

RFC 3490 does say something about the ACE prefix.

jaap

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

Re: [DNSOP] Looking for IANA registry for --xn

[Robert Edmonds]

Donald Eastlake wrote:
> Sure, you can consider the root zone to be the registry for TLDs but the
> point is the xn-- labels are recommended to be interpreted specially at the
> user interface at all levels...

Nor would this say anything about "CCHH" prefixed labels in general.

At the TLD level there seems to be an agreement at least(?) for new
gTLDs to reserve all "CCHH" prefixes in delegated names other than
xn--:

SPECIFICATION 6

REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS

1. Standards Compliance

1.1. DNS.  Registry Operator shall comply with relevant existing
RFCs and those published in the future by the Internet Engineering
Task Force (IETF), including all successor standards, modifications
or additions thereto relating to the DNS and name server operations
including without limitation RFCs 1034, 1035, 1123, 1982, 2181,
2182, 2671, 3226, 3596, 3597, 4343, and 5966.   DNS labels may only
include hyphens in the third and fourth position if they represent
valid IDNs (as specified above) in their ASCII encoding (e.g.,
“xn--ndk061n”).


https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm

-- 
Robert Edmonds

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

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[Stephane Bortzmeyer]

On Thu, Oct 06, 2016 at 01:47:28PM -0400,
 John R Levine  wrote 
 a message of 34 lines which said:

> It still seems to me that the time to add the wildcards back in
> would be less than the time to do two separate documents.  Unless
> there's some reason that this needs to be published in a hurry,

Not for me, I'm fine with a delay (there have been many important
changes between -02 and -03, during the WGLC, so, some time to digest
and study them may be worth it).

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

Re: [DNSOP] Looking for IANA registry for --xn

[Donald Eastlake]

Hi,

On Thu, Oct 6, 2016 at 3:14 PM, Jim Reid  wrote:

> > On 6 Oct 2016, at 18:59, Donald Eastlake  wrote:
> > I don't believe there is a registry.
>
> Actually there is. Sort of:

% whois -h whois.iana.org テスト
> % IANA WHOIS server
> % for more information on IANA, visit http://www.iana.org
> % This query returned 1 object
>
> domain:   テスト
> domain-ace:   XN--ZCKZAH
> ...
>

Sure, you can consider the root zone to be the registry for TLDs but the
point is the xn-- labels are recommended to be interpreted specially at the
user interface at all levels...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


> It should be a no-brainer for IANA to publish and maintain a list of these
> IDN encodings for delegated TLDs.
>
> ISTR IANA's Root Zone Database web page used to contain the punycode
> representation for the non-ASCII TLDs. Though I could well have imagined
> that.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Looking for IANA registry for --xn

[Jim Reid]

> On 6 Oct 2016, at 18:59, Donald Eastlake  wrote:
> 
> I don't believe there is a registry.

Actually there is. Sort of:

% whois -h whois.iana.org テスト
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:   テスト
domain-ace:   XN--ZCKZAH
...

It should be a no-brainer for IANA to publish and maintain a list of these IDN 
encodings for delegated TLDs.

ISTR IANA's Root Zone Database web page used to contain the punycode 
representation for the non-ASCII TLDs. Though I could well have imagined that.

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

Re: [DNSOP] Looking for IANA registry for --xn

[Paul Hoffman]

On 6 Oct 2016, at 10:08, Phillip Hallam-Baker wrote:

I have been looking for the IANA registry in which the IDNA prefix 
xn-- is

allocated and have not been able to find it. I can see the following
possibilities

1) There isn't such a registry. The allocation is purely ad hoc

2) There is a registry but none of the IDNA RFCs bother to list it as 
a

normative reference.


It is #1. It is defined in the IDNA RFCs as a single value. If you want 
to change IDNA, you need to update the RFC.


--Paul Hoffman

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

Re: [DNSOP] Looking for IANA registry for --xn

[Donald Eastlake]

I don't believe there is a registry. It would seem reasonable to reserve
labels starting with all other [a-z][a-z]-- besides xn-- and establish a
registry. (To avoid people trying to squat on names in advance, the "xn"
was selected by the same sort of publicly verifiable random process as
nomcom voter selection.) Especially if there are any other DNS parameter
registration things that need to be tweaked, I think the best thing might
be an update of RFC 6895.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Thu, Oct 6, 2016 at 1:51 PM, Phillip Hallam-Baker 
wrote:

> ​​
>
>
> On Thu, Oct 6, 2016 at 1:24 PM,  wrote:
>
>>
>> >I have been looking for the IANA registry in which the IDNA prefix xn--
>> is allocated and have not been able to find it. I can see the following
>> possibilities
>>
>> >1) There isn't such a registry. The allocation is purely ad hoc
>>
>> >2) There is a registry but none of the IDNA RFCs bother to list it as a
>> normative reference.
>>
>> >Either one would be bad. The existence or non existence of a registry,
>> the allocation or non allocation of a code point is not going to cause me
>> to decide whether or not to use functionality. All that the registry
>> achieves is to avoid collisions.
>>
>> Phil, this is very interesting.
>>
>> The 'xn--', of course, is the prefix for punycode used for International
>> Domain Names.   I have seen it used for DNS resolution quite a bit in the
>> last couple of months.   So, it is certainly used.   In fact, that appears
>> to be the only way one can do DNS resolution (at least in my experience).
>> That is, do the translation from IDN to punycode.   Then, it seems to work
>> like a charm.
>>
>>
> ​I am not looking to extend the xn-- system, I have another parallel
> application.​
>
> Imagine for the sake of argument that someone who was a VIP (VERY VIP)
> needed a secure email system and imagine that they wanted something that
> was completely compatible with the existing email infrastructure. ​
>
>
> ​A UDF fingerprint MAY be encoded as a DNS label by prefixing the Base32
> text representation with the string ‘zz--‘.
>
> A DNS name that includes a UDF fingerprint as a DNS label carries the
> implicit assertion that the interpretation of the address MUST be
> authorized by a security policy that is validated under a key that matches
> the corresponding fingerprint.
>
>
> Placing such a DNS label as the top level (rightmost) label in a DNS
> address creates an address that is not legal and thus cannot be resolved by
> the Internet DNS infrastructure. Thus ensuring that the address is rejected
> by applications that are not capable of performing the associated
> validation steps.
>
>
> For example, Alice has the email security key with fingerprint
> MB2GK-6DUF5-YGYYL-JNY5E. She uses the following email addresses:
>
> ​* ​
> al...@example.com
>
> Alice publishes this email address when she does not want the other party
> to use the secure email system.
>
> ​* ​
> al...@zz--mb2gk-6duf5-ygyyl-jny5e.example.com
>
> Alice publishes this email address when she wants to give the other party
> the option of using secure email if their system supports it.
>
> The DNS server for example.com has been configured to redirect requests
> to resolve zz--mb2gk-6duf5-ygyyl-jny5e.example.com to the mail server
> example.com.
>
> ​* ​
> al...@example.com.zz--mb2gk-6duf5-ygyyl-jny5e
>
> Alice uses this email address when she wants the other party to be able to
> send her email if and only if their client supports use of the secure
> messaging system.
>
> While there should never be a DNS label of the form zz--* in the
> authoritative DNS root, such labels MAY be introduced by a trusted local
> resolver. This would allow attempts at making an untrusted communication
> request to be transparently redirected through a locally trusted security
> enhancing proxy.​
>
>
> ___
> 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

Re: [DNSOP] Looking for IANA registry for --xn

[Phillip Hallam-Baker]

​​


On Thu, Oct 6, 2016 at 1:24 PM,  wrote:

>
> >I have been looking for the IANA registry in which the IDNA prefix xn--
> is allocated and have not been able to find it. I can see the following
> possibilities
>
> >1) There isn't such a registry. The allocation is purely ad hoc
>
> >2) There is a registry but none of the IDNA RFCs bother to list it as a
> normative reference.
>
> >Either one would be bad. The existence or non existence of a registry,
> the allocation or non allocation of a code point is not going to cause me
> to decide whether or not to use functionality. All that the registry
> achieves is to avoid collisions.
>
> Phil, this is very interesting.
>
> The 'xn--', of course, is the prefix for punycode used for International
> Domain Names.   I have seen it used for DNS resolution quite a bit in the
> last couple of months.   So, it is certainly used.   In fact, that appears
> to be the only way one can do DNS resolution (at least in my experience).
> That is, do the translation from IDN to punycode.   Then, it seems to work
> like a charm.
>
>
​I am not looking to extend the xn-- system, I have another parallel
application.​

Imagine for the sake of argument that someone who was a VIP (VERY VIP)
needed a secure email system and imagine that they wanted something that
was completely compatible with the existing email infrastructure. ​


​A UDF fingerprint MAY be encoded as a DNS label by prefixing the Base32
text representation with the string ‘zz--‘.

A DNS name that includes a UDF fingerprint as a DNS label carries the
implicit assertion that the interpretation of the address MUST be
authorized by a security policy that is validated under a key that matches
the corresponding fingerprint.


Placing such a DNS label as the top level (rightmost) label in a DNS
address creates an address that is not legal and thus cannot be resolved by
the Internet DNS infrastructure. Thus ensuring that the address is rejected
by applications that are not capable of performing the associated
validation steps.


For example, Alice has the email security key with fingerprint
MB2GK-6DUF5-YGYYL-JNY5E. She uses the following email addresses:

​* ​
al...@example.com

Alice publishes this email address when she does not want the other party
to use the secure email system.

​* ​
al...@zz--mb2gk-6duf5-ygyyl-jny5e.example.com

Alice publishes this email address when she wants to give the other party
the option of using secure email if their system supports it.

The DNS server for example.com has been configured to redirect requests to
resolve zz--mb2gk-6duf5-ygyyl-jny5e.example.com to the mail server
example.com.

​* ​
al...@example.com.zz--mb2gk-6duf5-ygyyl-jny5e

Alice uses this email address when she wants the other party to be able to
send her email if and only if their client supports use of the secure
messaging system.

While there should never be a DNS label of the form zz--* in the
authoritative DNS root, such labels MAY be introduced by a trusted local
resolver. This would allow attempts at making an untrusted communication
request to be transparently redirected through a locally trusted security
enhancing proxy.​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[John R Levine]

I'd rather you keep it [positive answers]

+1

Keep the positive, rather than writing a separate RFC for that later.


Why not but, in that case, this would send back the document for
several weeks, since the text about positive answers in -02 was very
limited and unclear (dropping it, like -03 did, is easier.)

It is not just a matter of "keeping positive answers", it is a matter
of "seriously studying the case of positive answers, which was
neglected in the previous discussions".


It still seems to me that the time to add the wildcards back in would be 
less than the time to do two separate documents.  Unless there's some 
reason that this needs to be published in a hurry, I'd rather get to a 
point where we agree that wildcard synthesis is OK.


Having looked at this probably more than most people, there are some 
points worth clarifying.  Most notably, due to the closest encloser rule, 
it is not possible in general to synthesize every wildcard result but I 
it's possible to synthesize many useful ones.


For example, let's say you query a.foo.example, and get back an answer 
saying it was synthesized from *.foo.example and the NSEC says the next 
name is c.foo.example. Then you can synthesize b.foo.example, but you 
can't synthesize d.foo.example.  That's a limitation, but that's OK.  It 
looks to me like most of the wildcards where this would be useful have no 
exceptions, such as the ones to put all of a IPv6 /64 into a DNS whitelist 
or blacklist.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Looking for IANA registry for --xn

[nalini.elkins]

>I have been looking for the IANA registry in which the IDNA prefix xn-- is 
>allocated and have not been able to find it. I can see the following 
>possibilities

>1) There isn't such a registry. The allocation is purely ad hoc

>2) There is a registry but none of the IDNA RFCs bother to list it as a 
>normative reference.

>Either one would be bad. The existence or non existence of a registry, the 
>allocation or non allocation of a code point is not going to cause me to 
>decide whether or not to use functionality. All that the registry achieves is 
>to avoid collisions.


Phil, this is very interesting.   
The 'xn--', of course, is the prefix for punycode used for International Domain 
Names.   I have seen it used for DNS resolution quite a bit in the last couple 
of months.   So, it is certainly used.   In fact, that appears to be the only 
way one can do DNS resolution (at least in my experience).  That is, do the 
translation from IDN to punycode.   Then, it seems to work like a charm.
Certainly sounds like an update somewhere is needed.
People may be interested in a draft that Harish and I have just posted:

https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy

>From our section 1.1 which explains punycode:

"Languages not based on the Latin script (A, B, C, etc) use unicode to 
represent the letters in their alphabet rather than ASCII. Punycode is used to 
show unicode characters in ASCII format. It is used in the transport of email. 

For example: 
English: NehruHindi: नेहरूPunycode: xn--l2bq0a0bw 

Punycode will start with the prefix: "xn--". An application handling IDN 
domains has to reference an IDN repository to know how to display them. Emails 
add to the complication since many email systems pre-date the introduction of 
IDNs. These systems often simply reject emails that don't work within the old 
domain name model. 
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Looking for IANA registry for --xn

[Phillip Hallam-Baker]

I have been looking for the IANA registry in which the IDNA prefix xn-- is
allocated and have not been able to find it. I can see the following
possibilities

1) There isn't such a registry. The allocation is purely ad hoc

2) There is a registry but none of the IDNA RFCs bother to list it as a
normative reference.

Either one would be bad. The existence or non existence of a registry, the
allocation or non allocation of a code point is not going to cause me to
decide whether or not to use functionality. All that the registry achieves
is to avoid collisions.


Phill
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[Stephane Bortzmeyer]

On Wed, Oct 05, 2016 at 03:04:25PM -0400,
 Bob Harold  wrote 
 a message of 68 lines which said:

> > I'd rather you keep it [positive answers]
> >
> > +1
> Keep the positive, rather than writing a separate RFC for that later.

Why not but, in that case, this would send back the document for
several weeks, since the text about positive answers in -02 was very
limited and unclear (dropping it, like -03 did, is easier.)

It is not just a matter of "keeping positive answers", it is a matter
of "seriously studying the case of positive answers, which was
neglected in the previous discussions".

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

Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Stephane Bortzmeyer]

On Thu, Oct 06, 2016 at 02:53:38AM -0400,
 Tim Wicinski  wrote 
 a message of 17 lines which said:

> Just a reminder that the WGLC for
> draft-ietf-dnsop-nsec-aggressiveuse will end later today (barring
> any stuck issues).  The authors appear to have addressed all open
> issues

The way I understand it, in -03, there is no more *positive* answers
(NOERROR synthetized from a wildcard in the cache), only negative ones
(NXDOMAIN). Am I correct? (If so, I agree with the change.)

If this is true, then I would suggest some work on rewriting section 7
new text for updating RFC 4035. True, the cache needs to look at
wildcards to see if it can synthetize NXDOMAINs or not but the way it
is written, it is confusing, since a wildcard would *prevent*
synthesis. May be:

   Once the records are validated, DNSSEC enabled validating
   resolvers MAY use NSEC/NSEC3 resource records
   to generate negative responses until their effective TTLs   
   or signatures for those records expire. (This requires to also
   check there is no wildcard applicable for the QNAME.)

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

Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Tony Finch]

I have read through the draft and sent a pull request with some minor
editorial fixes.

Here are some more substantial suggestions / questions. Sorry for being so
late in the process.


Would it make sense to be more specific about how to match queries to
cached NSEC/NSEC3 records? By cross-referencing to the relevant part of
the NSEC and NSEC3 specs, rather than repeating.

The draft seems to imply that only one NSEC record is needed for denial of
existence, and that wildcards are only problematic for NSEC3 - but
wildcards can also trip up NSEC, if the covering NSEC does not also cover
a relevant wildcard.

eg (modified text) ...

5.1.  NSEC

   Implementations which support aggressive use of NSEC SHOULD enable
   this by default.  Implementations MAY provide a configuration switch
   to disable aggressive use of NSEC and allow it to be enabled or
   disabled per domain.

   The validating resolver needs to check the existence of an NSEC RR
   matching/covering the source of synthesis and an NSEC RR covering the
   query name.

   If denial of existance can be determined according to the rules set out
   in RFC 4035 section 5.4, using NSEC records in the cache, then the
   resolver can immediately return an NXDOMAIN or NODATA response.

5.2.  NSEC3

   A validating resolver implementation MAY support aggressive use of
   NSEC3.  If it does aggressive use of NSEC3, it MAY provide a
   configuration switch to disable aggressive use of NSEC3 and allow it
   to be enabled or disabled for specific zones.

   NSEC3 aggressive negative caching is more difficult.  If the zone is
   signed with NSEC3, the validating resolver needs to check the
   existence of non-terminals and wildcards which derive from query
   names.

   If denial of existance can be determined according to the rules set out
   in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the
   cache, then the resolver can immediately return an NXDOMAIN or NODATA
   response.


TTLs

Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA
MINIMUM field. This is not quite the same as RFC 2308 negative cache entry
TTL, which is the minimum of the SOA MINIMUM and SOA TTL.

Should there be text along the lines of:

5.3.  Consideration on TTL

   The TTL value of negative information is especially important,
   because newly added domain names cannot be used while the negative
   information is effective.

   Section 5 of RFC 2308 states that the maximum number of negative cache
   TTL value is 3 hours (10800).  It is RECOMMENDED that validating
   resolvers limit the maximum effective TTL value of negative responses
   (NSEC/NSEC3 RRs) to this same value.

   Section 5 of RFC 2308 also states that a negative cache entry TTL
   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
   This can be less than the TTL of an NSEC or NSEC3 record, since their
   TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and
   RFC 5155 section 3.)

   A resolver that supports aggressive use of NSEC and NSEC3 should reduce
   the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in
   the authority section of a negative response, if the SOA TTL is
   smaller.


Wildcards

Should the box in section 7 say "positive responses" instead of "negative
responses"?

If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
and RFC 5155 section 8.8 which both discuss validating positive wildcard
responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
text if you want.


Security Considerations

This should mention the impact of replay attacks. Something like,

Although the TTL of NSEC/NSEC3 records is typically fairly short
(minutes or hours), their RRSIG expiration time can be much
further in the future (weeks). An attacker who is able to
successfully spoof responses might poison a cache with old
NSEC/NSEC3 records. If the resolver is NOT making aggressive use
of NSEC/NSEC3, the attacker has to repeat the attack for every
query. If the resolver IS making aggressive use of
NSEC/NSEC3, one successful attack would be able to suppress many
queries for new names, up to the negative TTL.


Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or
rough. Showers later. Good.

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[hellekin]

On 10/06/2016 09:22 AM, avri doria wrote:
> 
> As for the so-called toxic waste names (i really find that terminology
> problematic)
>

I agree it's a problem to use that kind of vocabulary to convey a
technical context.

> the so called waste pile of usurped names
>

Therefore this is also a problem to call names-used-in-the-wild
"usurped" or "squatted", because it says that there's a central body
that assigns names, and it defines who can use them, with the
exclusivity of any other approach.  I know this idea may sound funny to
a lot of people given the missions of IANA and ICANN, and the existence
of trademarks and so-called 'intellectual property', but to me, having
an authority over who can use what names *in general*--as opposed to
particular, specific cases (e.g., trademarks)--is akin to the Novlang
Committee.

Names in the DNS are sanctioned by IANA/ICANN, and those names are
'legitimate' in the context of Internet names.  That doesn't mean at all
that names not sanctioned by ICANN are illegitimate, or that names
covered by trademarks are more 'legitimate' than 'unprotected' names.
This is all a matter of transactions and legal-firepower.  But from
there to legitimate this transactional-belligerent perspective over any
other (historical, cultural, incidental, ontogenetic, etc.) seems to me
problematic and abusive.

==
hk

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[avri doria]

On 04-Oct-16 09:19, David Conrad wrote:
> As far as I know, neither ICANN (the organization) nor anyone within
> ICANN (the organization) is asking whether they should delegate such
> names. Forward motion of those names is currently "indefinitely
> deferred" pending _somebody_ (not ICANN staff) figuring out what to do
> with them. I believe the hope had been that the IETF might provide
> some technical guidance, but that didn't work. Now, some members of
> the ICANN community are asking the board that those names be delegated
> and that results in (re)opening the question of what to do with
> "indefinitely deferred" strings.

Actually I thought they were asking that work that had been promised on
further researching the problem and mitigation techniques be done as
opposed to just prohibiting things because the first thoughts turned out
to be inadequate.

As for the so-called toxic waste names (i really find that terminology
problematic) someone needs to find a solution otherwise the possibility
of adding more and more names to the so called waste pile of usurped
names over time becomes an increasing possibility.  If someone can just
start using a name and thus make it too hard to delegate we have a much
bigger problem.

avri

avri


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Matthijs Mekking]

Hi,

On 06-10-16 08:53, Tim Wicinski wrote:
> 
> Just a reminder that the WGLC for  draft-ietf-dnsop-nsec-aggressiveuse
> will end later today (barring any stuck issues).  The authors appear to
> have addressed all open issues (except JINMEI's last comments).  Please
> read the current version here:

I don't think my issues have been addressed in -03, except for the
bikeshedding Pull Request has been merged.

Best regards,
  Matthijs




> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
> 
> and speak up with any final questions, concerns, etc.
> 
> thanks
> tim
> 
> ___
> 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

[DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

[Tim Wicinski]

The authors for this document have addressed some lingering  outstanding 
issues, and it appears ready for Working Group Last Call.


This starts a Working Group Last Call for:
   draft-ietf-dnsop-edns-key-tag

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.


This starts a two week Working Group Last Call process, and ends on 20 
October 2016


thanks
tim

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

[DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Tim Wicinski]

Just a reminder that the WGLC for  draft-ietf-dnsop-nsec-aggressiveuse 
will end later today (barring any stuck issues).  The authors appear to 
have addressed all open issues (except JINMEI's last comments).  Please 
read the current version here:


https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

and speak up with any final questions, concerns, etc.

thanks
tim

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

Re: [DNSOP] Working Group Last Call

[Tim Wicinski]

On 10/5/16 2:30 PM, 神明達哉 wrote:

At Tue, 4 Oct 2016 17:39:55 -0400,
Warren Kumari  wrote:


- Section 3: this section also has an issue of "recursive resolver".
  Although it may not be as critical as other part of the draft since
  it's only used as an example scenario, it's probably better to not
  limit the role of resolver to avoid misleading.  Maybe "recursive
  resolver" is just changed to "validating resolver", and
  "authoritative server" is changed to, e.g., "external servers"
  (meaning either authoritative or or other recursive servers).


DONE.
I did some fix up - how do you like:
"If a validating resolver gets a query for cat.example.com, it will
query the example.com servers and will get back an NSEC (or NSEC3)
record starting that there are no records between apple and elephant.
The resolver then knows that cat.example.com does not exist; however,
it does not use the fact that the proof covers a range (apple to
elephant) to suppress queries for other labels that fall within this
range. This means that if the validating resolver gets a query for
ball.example.com (or dog.example.com) it will once again go off and
query the example.com servers for these names."

Does that cover it sufficiently? (and I think I now better understand
your concern).


To be perfectly generic, "it will query the example.com servers" is
not always the case.  It (= validating resolver) might query another
intermediate resolver (often called a "forwarder") that performs
recursion.  By "external server" I tried to generalize the concept.



Maybe this?

"If a validating resolver receives a query for cat.example.com, it 
contacts its resolver (which may be itself) to query the example.com 
servers and will get back an NSEC (or NSEC3) record starting that there 
are no records between apple and elephant."



I'm not sure how we address the subtlety without being overly
verbose.  Perhaps we can note in the terminology section that this
draft generally describes (validating) resolvers as those performing
recursive resolution, but the proposal will also work for resolvers
that rely on other recursive (or "full service" if you love to use
this term) resolvers.  And then we can keep Section 3 as is (as of ver
02).


I'm now understanding the distinction you're trying to make.  I've spent 
some time staring at 7719 and 4035 with no better suggestion.




How is:
"Aggressive use of NSEC / NSEC3 resource records without DNSSEC
validation may create serious security issues, and so this technique
requires DNSSEC validation."? I don't love it, additional suggestions
or text welcomed.


To me the main point isn't address with this text.  I might be able to
offer alternative text, but can't we perhaps just remove these 2
sentences?  In a sense these talk about the obvious, and in other
sense it could be even harmful as it can be misleading.



I think you could drop the "Aggressive" and discussing NSEC/NSEC3 
records w/out validation.  4035 is pretty clear on that


tim

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