Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Eliot Lear]

On 23.10.22 05:40, John Levine wrote:

It appears that Eliot Lear   said:

As a matter of practicality, a registry surely will be form.  It is
simply a matter of whether the IANA will host it.  If the IANA does not
host it, then by shifting it elsewhere this group is actually weakening
the IANA function, and that would be sad.

But trying to turn IANA and .alt into a junior version of ICANN would
be much worse than sad.


Nobody is trying to do that.

Eliot


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Martin Schanzenbach]

On 21.10.22 18:48, Tim Wicinski wrote:
> >
> >
> > Rather than placing "alt" in the TLD position, I think it might be better
> > as a scheme modifier: https+alt://...  This is a common pattern  for
> > modifications to URI schemes (c.f. git+ssh://), and informs the software
> > that this URI is special without overloading the DNS namespace.
> >
> >
> Not putting any hat on, I do like Ben's https+alt:// URI suggestion.
> 
> As a chair, if we see enough interest in this, the WG should find consensus
> 

I am actually surprised by this as the primary concern reason for
a possible conflict was that the names in GNS and DNS can be conflated
by the user.
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?
It is as if we are chasing a moving target where the primary pont of
contention always seems to escape us. The goalpost seems to be moving.

BR


> 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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Suzanne Woolf]

Eliot,

On Oct 23, 2022, at 2:15 AM, Eliot Lear mailto:l...@lear.ch>> 
wrote:


On 23.10.22 05:40, John Levine wrote:
It appears that Eliot Lear  mailto:l...@lear.ch>> said:
As a matter of practicality, a registry surely will be form.  It is
simply a matter of whether the IANA will host it.  If the IANA does not
host it, then by shifting it elsewhere this group is actually weakening
the IANA function, and that would be sad.
But trying to turn IANA and .alt into a junior version of ICANN would
be much worse than sad.

Nobody is trying to do that.


I believe the point is that it would happen if the IETF ran such a registry, 
regardless of intent: if the IETF is deciding who gets to use names that look 
like domain names, it's at high risk of walking directly into the conditions 
that led to the creation of ICANN in the first place. The exception is names 
under .arpa, which is explicitly under the administration of the IETF.
Personally, I agree with the comment that several people have now made, that 
such an attempt is likely to be fraught with legal and reputation risk. But for 
the WG's purposes those comments are somewhat speculative.
We've been told repeatedly that no one wants to engage legal analysis or 
liaison communications on a document that doesn't have WG consensus. Any member 
of the IAB might be able to correct or add to this assessment, but it's 
currently the chairs' understanding that we or the responsible AD should 
request any liaison communications and presumably legal review after the WG 
process concludes. (I understand frustration with this, but I also understand 
the reasoning: if a draft doesn't have at least WG consensus, that 
administrative machinery is not necessary.)

The chairs would like to hear it if anyone has anything new to say about such a 
registry on its technical merits, including specific registry policy and 
operational challenges with administering it if the non-technical risks could 
be managed.


Thanks,
Suzanne

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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Martin Schanzenbach]

On 23.10.22 10:50, Suzanne Woolf wrote:
> Eliot,
> 
> On Oct 23, 2022, at 2:15 AM, Eliot Lear mailto:l...@lear.ch>> 
> wrote:
> 
> 
> On 23.10.22 05:40, John Levine wrote:
> It appears that Eliot Lear  mailto:l...@lear.ch>> said:
> As a matter of practicality, a registry surely will be form.  It is
> simply a matter of whether the IANA will host it.  If the IANA does not
> host it, then by shifting it elsewhere this group is actually weakening
> the IANA function, and that would be sad.
> But trying to turn IANA and .alt into a junior version of ICANN would
> be much worse than sad.
> 
> Nobody is trying to do that.
> 
> 
> I believe the point is that it would happen if the IETF ran such a registry, 
> regardless of intent: if the IETF is deciding who gets to use names that look 
> like domain names, it's at high risk of walking directly into the conditions 
> that led to the creation of ICANN in the first place. The exception is names 
> under .arpa, which is explicitly under the administration of the IETF.
> Personally, I agree with the comment that several people have now made, that 
> such an attempt is likely to be fraught with legal and reputation risk. But 
> for the WG's purposes those comments are somewhat speculative.
> We've been told repeatedly that no one wants to engage legal analysis or 
> liaison communications on a document that doesn't have WG consensus. Any 
> member of the IAB might be able to correct or add to this assessment, but 
> it's currently the chairs' understanding that we or the responsible AD should 
> request any liaison communications and presumably legal review after the WG 
> process concludes. (I understand frustration with this, but I also understand 
> the reasoning: if a draft doesn't have at least WG consensus, that 
> administrative machinery is not necessary.)
> 
> The chairs would like to hear it if anyone has anything new to say about such 
> a registry on its technical merits, including specific registry policy and 
> operational challenges with administering it if the non-technical risks could 
> be managed.
> 

In my opinion lots of technical justifications were given in the various
threads and those were not really addressed or refuted in any way but the
mentioned "non-technical risks" and "out of scope for dnsop" highlighted.
At the same time it appears to me that those risks do not (?) seem to manifest
themselves for .arpa. Is there an explanation or an indication why this would be
the case for .alt?

BR
Martin

> 
> Thanks,
> Suzanne
> 

> ___
> 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] [Ext] Possible alt-tld last call?

[Paul Vixie]

Martin Schanzenbach wrote on 2022-10-23 04:34:

...
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?


yes.


It is as if we are chasing a moving target where the primary point of
contention always seems to escape us. The goalpost seems to be moving.


building a standards and innovation community out of humans has 
predictable downsides.


--
P Vixie

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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Paul Vixie]

Martin Schanzenbach wrote on 2022-10-23 04:38:

On 23.10.22 10:50, Suzanne Woolf wrote:

...

The chairs would like to hear it if anyone has anything new to say about such a 
registry on its technical merits, including specific registry policy and 
operational challenges with administering it if the non-technical risks could 
be managed.


i think everything has been both said and challenged. my own position 
hasn't evolved, and it's short so i'll summarize it here:


* first come first served
* same character set rules as DNS
* IDN is not disallowed
* short RFC to name the codepoint and refer to the carve-out's naming system
* administered by IETF not ICANN
* IANA to maintain a registry
* allocation cannot be denied

but, read on:

Martin Schanzenbach wrote on 2022-10-23 04:38:

In my opinion lots of technical justifications were given in the various
threads and those were not really addressed or refuted in any way but the
mentioned "non-technical risks" and "out of scope for dnsop" highlighted.
At the same time it appears to me that those risks do not (?) seem to manifest
themselves for .arpa. Is there an explanation or an indication why this would be
the case for .alt?


quoting suzanne's message to which the above text is a reply: >


those were bad times. green papers, lawyers, oh my. noone who lived 
through the years of contention over who would control the root zone and 
how is going to be easily dragged back into it. in today's equilibrium 
the decision to allocate TLD codepoints rests with ICANN. so to get 
".ALT" it will be nec'y to assert IETF's authority on the basis that 
this is a reservation not a delegation. it can be done (in my opinion) 
but nobody wants to bell that cat. getting ICANN to create and adopt a 
policy for reservation would be much harder. putting this under ".ARPA" 
would be much easier.


--
P Vixie

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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[David Conrad]

Suzanne,

On Oct 23, 2022, at 3:50 AM, Suzanne Woolf  wrote:
> We've been told repeatedly that no one wants to engage legal analysis or 
> liaison communications on a document that doesn't have WG consensus.

This appears broken.

In this specific case, the way forward appears to be predicated on the response 
to the analysis/communication.  That is, if ICANN is asked “would ‘reserving’ 
.alt (or any other TLD) represent an intrusion into ICANN’s bailiwick” and the 
answer from ICANN is yes, then moving forward with .alt would be precluded, 
regardless of WG consensus, no?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Use of GOST 2012 Signature Algorithms in DNSKEY and 
RRSIG Resource Records for DNSSEC
Authors : Dmitry Belyavskiy
  Vasily Dolmatov
  Boris Makarenko
  Filename: draft-ietf-dnsop-rfc5933-bis-12.txt
  Pages   : 11
  Date: 2022-10-23

Abstract:
   This document describes how to produce digital signatures and hash
   functions using the GOST R 34.10-2012 and GOST R 34.11-2012
   algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
   Domain Name System Security Extensions (DNSSEC).

   This document obsoletes RFC 5933 and updates RFC 8624.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-12


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

David Conrad wrote on 2022-10-23 12:00:

Rob,


not rod, but i have three comments.

On this mailing list, I think there is a pretty good understanding of 
the intent of .alt and I don’t think there is much in the way of 
disagreement on that intent. As far as I can tell, the points of 
contention are:


1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name 
resolution systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those 
issues.


first, +1 to the above and to the elided text formerly below.

second, it's worth a bit of puttering to figure out how to prevent more 
pollution (queries of non-DNS namespaces or non-global-DNS namespaces) 
from hitting the root. delegating .ALT the same way 10.in-addr.arpa is 
delegated (prisoner.iana.org and so on) may be a fine idea.


third, in recognition of this concern:

... 

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS 
name resolution protocol is specified to not be plain text (presumably 
any new protocol would be encrypted), then users of that protocol have 
an expectation that their queries are protected.  ...


implementation guidance contained in the .ALT "specification" should 
include the need to detect ".ALT" from the right hand side before 
deciding whether or not to do special non-DNS processing on the 
remaining left hand side. this is because the non-DNS syntax on the left 
hand side might include .ALT for other reasons, or may use "." 
differently than DNS would do. this is messy but inevitable given that 
DNS camped on to the entire domain namespace in its earliest days.


--
P Vixie

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

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Warren Kumari]

On Fri, Oct 21, 2022 at 2:54 PM, Warren Kumari  wrote:

> On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari  wrote:
>
>> On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman 
>> wrote:
>>
>>> On Oct 18, 2022, at 7:58 AM, Ron Even  wrote:
>>>
>>> 1. whis is this an informational RFC and not a standard track RFC.
>>>
>>> That's a reasonable question with a simple answer: because the WG
>>> changed its mind on what the status of this protocol should be. RFC 5933
>>> describes a national standard that is thinly deployed. At the time, it was
>>> necessary to have the protocol on standards track; now it no longer is
>>> required.
>>>
>>> 2. What is requested from IANA. ths text you wrote and I copied is not a
>>> directive to IANA that is clear
>>>
>>> You are correct that the IANA Considerations section is quite unclear,
>>> and needs to be clarified before the IESG considers it.
>>>
>>
>>
>> That is a good point.
>>
>> The document says:
>> ---
>> This document updates the RFC IANA registry "Delegation Signer
>> (DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for
>> the GOST R 34.11-2012 algorithm:
>>
>>   Value   Algorithm
>>   TBA2GOST R 34.11-2012
>>
>>The entry for Value 3, GOST R 34.11-94 should be updated to have its
>> Status changed to '-'.
>> 
>>
>> The IANA registry being referenced "DNSSEC Delegation Signer (DS)
>> Resource Record (RR) Type Digest Algorithms" is here: https://www.iana.
>> org/assignments/ds-rr-types/ds-rr-types.xhtml
>>
>> Setting this to '-' does seem incorrect, and from the text I think that
>> it should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" .
>>
>> In addition, the IANA has a question:
>> --
>> "Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type
>> Digest Algorithms registry located at:
>>
>> https://www.iana.org/assignments/ds-rr-types/
>>
>> a new registration will be made as follows:
>>
>> Value: [ TBD-at-Registration ]
>> Description: GOST R 34.11-2012
>> Status:
>> Reference: [ RFC-to-be ]
>>
>> IANA Question --> What should the entry for "Status" be for this new
>> registration?"
>> 
>>
>>
>>
>>
>> I believe that it is clear (e.g: "6.  Implementation Considerations
>>The support of this cryptographic suite in DNSSEC-aware systems is
>>OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state
>> that.
>>
>> So, I think a new version should be submitted saying:
>> 
>> This document updates the RFC IANA registry "Delegation Signer (DS)
>>Resource Record (RR) Type Digest Algorithms" by adding an entry for
>>the GOST R 34.11-2012 algorithm:
>>
>>   Value:   TBA2
>>   Description: GOST R 34.11-2012
>>   Status: OPTIONAL
>>   Reference: [ RFC-to-be ]
>>
>>The entry for Value 3, GOST R 34.11-94 should be updated to have its
>>Status changed to 'DEPRECATED'.
>>
>
> A new version was submitted (-11), but still says:
> "   The entry for Value 3, GOST R 34.11-94 should be updated to have its
>Status changed to '-'."
>
> The registry is here: https://www.iana.org/assignments/ds-rr-types/
> ds-rr-types.xhtml
>
> '-' to me implies that the codepoint hasn't  been used, but I don't
> actually know if that's true. I think "DEPRECATED" is better, but perhaps
> I'm wrong (anyone seeing '-' will presumably do read the referenced RFC,
> so…_)
>
> I will ask the IANA which they think is best / clearest…
>

Closing the loop:

I reached out to the IANA, and this was their reply:
"Hi Warren,

It makes sense to us to list "DEPRECATED" in the status column. When we're
asked to deprecate a codepoint, the label "deprecated" is usually added to
the registration in some way.

"-" is a bit of a cipher, and doesn't indicate that there's been a change.

thanks,
Amanda
"

If the authors post a new version before the draft cut-off (Monday) with
this addressed I should be able to move it along.

Thank you all,
W




> W
>
>
>
>> W
>>
>>
>>> --Paul Hoffman
>>>
>>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Boris Makarenko]

Hello, Warren

Just uploaded the 12th version. The only change is status of GOST R 
34.11-94 -- DEPRECATED.


--

Boris

23.10.2022 18:20, Warren Kumari пишет:





On Fri, Oct 21, 2022 at 2:54 PM, Warren Kumari  wrote:

On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari mailto:war...@kumari.net>> wrote:

On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman
mailto:paul.hoff...@icann.org>> wrote:

On Oct 18, 2022, at 7:58 AM, Ron Even
mailto:ron.even@gmail.com>>
wrote:

1. whis is this an informational RFC and not a
standard track RFC.

That's a reasonable question with a simple answer: because
the WG changed its mind on what the status of this
protocol should be. RFC 5933 describes a national standard
that is thinly deployed. At the time, it was necessary to
have the protocol on standards track; now it no longer is
required.

2. What is requested from IANA. ths text you wrote and
I copied is not a directive to IANA that is clear

You are correct that the IANA Considerations section is
quite unclear, and needs to be clarified before the IESG
considers it.



That is a good point.

The document says:
---
This document updates the RFC IANA registry "Delegation Signer
(DS) Resource Record (RR) Type Digest Algorithms" by adding an
entry for the GOST R 34.11-2012 algorithm:

Value   Algorithm
TBA2    GOST R 34.11-2012

   The entry for Value 3, GOST R 34.11-94 should be updated to
have its Status changed to '-'.


The IANA registry being referenced "DNSSEC Delegation Signer
(DS) Resource Record (RR) Type Digest Algorithms" is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml


Setting this to '-' does seem incorrect, and from the text I
think that it should be either "MUST NOT" or, better yet (for
clarity) "DEPRECATED" .

In addition, the IANA has a question:
--
"Third, in the DNSSEC Delegation Signer (DS) Resource Record
(RR) Type Digest Algorithms registry located at:

https://www.iana.org/assignments/ds-rr-types/


a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: GOST R 34.11-2012
Status:
Reference: [ RFC-to-be ]

IANA Question --> What should the entry for "Status" be for
this new registration?"





I believe that it is clear (e.g: "6.  Implementation
Considerations
   The support of this cryptographic suite in DNSSEC-aware
systems is
OPTIONAL.") that it can only be OPTIONAL, but we need to
clearly state that.

So, I think a new version should be submitted saying:

This document updates the RFC IANA registry "Delegation Signer
(DS)
   Resource Record (RR) Type Digest Algorithms" by adding an
entry for
   the GOST R 34.11-2012 algorithm:

Value:   TBA2
Description: GOST R 34.11-2012
Status: OPTIONAL
  Reference: [ RFC-to-be ]

   The entry for Value 3, GOST R 34.11-94 should be updated to
have its
   Status changed to 'DEPRECATED'.


A new version was submitted (-11), but still says:
"   The entry for Value 3, GOST R 34.11-94 should be updated to
have its
   Status changed to '-'."

The registry is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml


'-' to me implies that the codepoint hasn't  been used, but I
don't actually know if that's true. I think "DEPRECATED" is
better, but perhaps I'm wrong (anyone seeing '-' will presumably
do read the referenced RFC, so…_)

I will ask the IANA which they think is best / clearest…


Closing the loop:

I reached out to the IANA, and this was their reply:
"Hi Warren,

It makes sense to us to list "DEPRECATED" in the status column. When 
we're asked to deprecate a codepoint, the label "deprecated" is 
usually added to the registration in some way.


"-" is a bit of a cipher, and doesn't indicate that there's been a change.

thanks,
Amanda
"

If the authors post a new version before the draft cut-off (Monday) 
with this addressed I should be able to move it along.


Thank you all,
W




W



W


--Paul Hoffman

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton)  wrote:
> As I read it, the partitioning of the domain name namespace is really to 
> achieve two aims:


On this mailing list, I think there is a pretty good understanding of the 
intent of .alt and I don’t think there is much in the way of disagreement on 
that intent. As far as I can tell, the points of contention are:

1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name resolution 
systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues.

FWIW, my views:

1) Ask the stupid question.
2) A voluntary, lightweight registry operated by IANA can help developers avoid 
collision.
3) Identifying leakage to the DNS as a protocol violation can, over time, help 
reduce that leakage.

> This is outside my area of expertise, but I'm not convinced that the global 
> DNS would see any significant increase in load, because the stub resolver 
> would generally not be sending the requests to the DNS assuming that they are 
> valid domains, and if they are not valid domains then that would seem to be 
> the same as what DNS already handles today.

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

If you look at the ICANN OCTO web page Paul referenced earlier 
(https://magnitude.research.icann.org ) 
and filter for “special use” TLDs, you’ll see data related to the number of 
queries received.  Some of those (e.g., .local) are non-trivial and, in my 
opinion, are indications of brokenness that should be fixed — the root 
shouldn’t be seeing those queries. My suggestion of using RFC 2119 “MUST NOT” 
language (i.e., queries for names in .alt MUST NOT be sent to the root server 
system supported by IANA) is in an effort to discourage an increase in that 
query volume over time.

It seems obvious to me that if a namespace is explicitly defined to not be in 
the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
actually surprised that this would be controversial.

> And as for the eavesdropping concern, doesn't this equally apply for all 
> domain lookups, particularly invalid ones?

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
resolution protocol is specified to not be plain text (presumably any new 
protocol would be encrypted), then users of that protocol have an expectation 
that their queries are protected.  By falling back to DNS, that expectation is 
silently violated.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 23, 2022, at 12:00 PM, David Conrad  wrote:
> On this mailing list, I think there is a pretty good understanding of the 
> intent of .alt and I don’t think there is much in the way of disagreement on 
> that intent. As far as I can tell, the points of contention are:
> 
> 1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> 2) whether there will be a registry of .alt uses (i.e., non-DNS name 
> resolution systems) and if so, who will operate that registry.
> 3) whether the inevitable leakage of .alt queries to the DNS represent 
> potential issues, and if so, should there be an effort to address those 
> issues.
> 
> FWIW, my views:
> 
> 1) Ask the stupid question. 

Again? It has already been answered many times in the negative. There are even 
RFCs about it. Asking it again is a waste of people's time. 

> 2) A voluntary, lightweight registry operated by IANA can help developers 
> avoid collision.

True, if we care about collision in namespaces we don't control. I certainly 
don't care about those namespaces.

> 3) Identifying leakage to the DNS as a protocol violation can, over time, 
> help reduce that leakage.

True, but so what? It is leakage from namespaces we don't control, and 
many/most of us don't care about them.

> 
>> This is outside my area of expertise, but I'm not convinced that the global 
>> DNS would see any significant increase in load, because the stub resolver 
>> would generally not be sending the requests to the DNS assuming that they 
>> are valid domains, and if they are not valid domains then that would seem to 
>> be the same as what DNS already handles today.
> 
> The root of the DNS is a commons, supported by volunteers who are paying out 
> of their own pocket to provision a global infrastructure. I’m personally not 
> comfortable recommending techniques that can add undefined (could be minimal, 
> might not be: no one knows for sure) load to that infrastructure.

I'm personally happy to defer this to those volunteers instead of speaking for 
them. In the past, they have said that the amount of leakage is not of concern 
to them, and there is no indication that .alt will increase it perceptibly.

> If you look at the ICANN OCTO web page Paul referenced earlier 
> (https://magnitude.research.icann.org) and filter for “special use” TLDs, 
> you’ll see data related to the number of queries received.  Some of those 
> (e.g., .local) are non-trivial and, in my opinion, are indications of 
> brokenness that should be fixed — the root shouldn’t be seeing those queries. 
> My suggestion of using RFC 2119 “MUST NOT” language (i.e., queries for names 
> in .alt MUST NOT be sent to the root server system supported by IANA) is in 
> an effort to discourage an increase in that query volume over time. 

I can't tell from this paragraph if you realize that the example you gave 
(.local) already has a SHOULD NOT for resolvers. Are you saying that updating 
RFC 6762 to make it a MUST NOT would have any noticeable effect?

> It seems obvious to me that if a namespace is explicitly defined to not be in 
> the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
> actually surprised that this would be controversial.

Can you say what you mean by "reliance on the DNS"? Defining .alt as a name 
that won't appear in the root zone does not have any reliance on the DNS. 

>> And as for the eavesdropping concern, doesn't this equally apply for all 
>> domain lookups, particularly invalid ones?
> 
> As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
> resolution protocol is specified to not be plain text (presumably any new 
> protocol would be encrypted), then users of that protocol have an expectation 
> that their queries are protected.  

Why on earth would those users think that? If the proponents of the non-DNS 
name resolution protocol suggest that to them, then those proponents are simply 
lying.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Ben and Wes,

On 21.10.22 20:45, Ben Schwartz wrote:


Rather than placing "alt" in the TLD position, I think it might be 
better as a scheme modifier: https+alt://...  This is a common 
pattern  for modifications to URI schemes (c.f. git+ssh://), and 
informs the software that this URI is special without overloading the 
DNS namespace.


How would this work in practice?

 * Would this require a re-registering of each and every URI scheme
   with +alt, and monitoring the URI scheme registry for new ones? 
   (I'll note that git+ssh isn't registered.)
 * What is the value of +alt at this point?  Why not use +gns or +onion
   or +eliotsfavoritenamespace?
 * How might or should this be reflected in the browser bar?

That last question probably has no pat answer, which is okay so long as 
we are clear that it does not.


Eliot



OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 23, 2022, at 1:27 PM, Paul Hoffman  wrote:
>> 1) Ask the stupid question.
> Again? It has already been answered many times in the negative. There are 
> even RFCs about it. Asking it again is a waste of people's time.

I’m unaware. Could you point me to the ICANN Board resolution, statement from 
the GNSO, and/or a position from the ICANN CEO on the issue?

>> 2) A voluntary, lightweight registry operated by IANA can help developers 
>> avoid collision.
> True, if we care about collision in namespaces we don't control. I certainly 
> don't care about those namespaces.

OK, but others may. As a precedent: https://www.iana.org/time-zones 
.

>> 3) Identifying leakage to the DNS as a protocol violation can, over time, 
>> help reduce that leakage.
> True, but so what? It is leakage from namespaces we don't control, and 
> many/most of us don't care about them.

I would’ve thought we'd care about (and try to discourage) the leakage into the 
DNS as a result of IETF action.

>> The root of the DNS is a commons, supported by volunteers who are paying out 
>> of their own pocket to provision a global infrastructure. I’m personally not 
>> comfortable recommending techniques that can add undefined (could be 
>> minimal, might not be: no one knows for sure) load to that infrastructure.
> I'm personally happy to defer this to those volunteers instead of speaking 
> for them.

OK. Could you point me to the statement by the RSOs on the topic?

> In the past, they have said that the amount of leakage is not of concern to 
> them, and there is no indication that .alt will increase it perceptibly.

Given the root server infrastructure is shared across the entire Internet 
globally, in the past, the DNS operational community has gone to significant 
efforts in relation to proposed changes that could conceivably affect the load 
on the root servers, e.g., deploying IPv6 or DURZ, even when there was no 
assurance or even a common belief that there would be a perceptible negative 
impact.

But this is somewhat irrelevant: what we’re talking about here is specific 
wording that tries to more strongly discourage traffic going to the root, i.e., 
'MUST NOT’ instead of ‘should not’. I’m confused why such wording would be 
considered controversial.

> I can't tell from this paragraph if you realize that the example you gave 
> (.local) already has a SHOULD NOT for resolvers.

Yep, I’m aware.  I don’t think repeating mistakes is a good idea.

> Are you saying that updating RFC 6762 to make it a MUST NOT would have any 
> noticeable effect?

Are you saying you think it would hurt?  I’m hopeful in the long term, it would 
have a positive impact.

>> It seems obvious to me that if a namespace is explicitly defined to not be 
>> in the DNS, embedding a reliance on the DNS would be a protocol violation.  
>> I am actually surprised that this would be controversial.
> Can you say what you mean by "reliance on the DNS"? Defining .alt as a name 
> that won't appear in the root zone does not have any reliance on the DNS.

For applications that are misconfigured, instead of blocking at the resolver, 
you appear to be arguing queries should use the DNS protocol to query the root 
servers to (presumably) return an NXDOMAIN. I consider this a protocol 
violation, and as such, I think it appropriate to use language that suggests 
implementors must not do that.

>>> And as for the eavesdropping concern, doesn't this equally apply for all 
>>> domain lookups, particularly invalid ones?
>> As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
>> resolution protocol is specified to not be plain text (presumably any new 
>> protocol would be encrypted), then users of that protocol have an 
>> expectation that their queries are protected.
> Why on earth would those users think that?

E.g., "GNS is a decentralized and censorship-resistant domain name resolution 
protocol that provides a *privacy-enhancing* alternative to the Domain Name 
System (DNS) protocols.” (second sentence of the abstract of 
https://lsd.gnunet.org/lsd0001/ , emphasis 
added).  Now, what happens on a machine that is unaware of GNS responds to 
(say) an email from paul@secret_name.alt  (and if 
you don’t think that’s a privacy violation, then what’s the point of DoH/DoT)?

> If the proponents of the non-DNS name resolution protocol suggest that to 
> them, then those proponents are simply lying.


Or, more charitably, they are making an assumption about the environment in 
which the non-DNS name resolution protocol operates.  Pointing this out in the 
Security Considerations section seems like a no-brainer to me.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop