Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Wouters]

On Fri, 19 Jun 2020, Olafur Gudmundsson wrote:


It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the 
DS registry "RFC required", like the other DNSSEC-related registries.

You are proposing a bureaucratic solution without thinking about the 
operational implications of it.
The hardest part to update in DNS tree right now is uploading DS records to the 
parents, keeping the list of algorithms down helps avoid operational problems



On the contrary, lets make that list change every month, so registrars
and registries stop doing weird requirements on DS.

Or advocate for ICANN contractual updates for mandatory CDS support :P

Anyway, nothing of this is related to new algortihms and should not be
conflated with it.

Paul

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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Olafur Gudmundsson]

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman  wrote:
> 
> On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:
>> The 2nd registry
>> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
>> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
>>  
>> )
>> has the "Standards Action" update policy
> 
> I had forgotten that the DS registry is "standards action". This document 
> shows why that was a bad idea.

Why ? 

> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.
You are proposing a bureaucratic solution without thinking about the 
operational implications of it. 
The hardest part to update in DNS tree right now is uploading DS records to the 
parents, keeping the list of algorithms down helps avoid operational problems 

Olafur


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

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

[Libor . peltan]

Hi Tommy,
My point in more detail: DNS itself Is a key-(multi)value database. 
Embedding another key-value list into RR data seems misconceptual. 
Moreover, this embeeded stuff od somewhat Complex, with different 
requirements on the keys, their order, and values.

However, i havent found any better solution w/o different drawbacks :(
BR,
Libor


On 2020-06-17 15:50, Tommy Pauly wrote:

On Jun 17, 2020, at 5:10 AM, .peltan  wrote:

Hi all,

i'm a developer of Knot DNS authoritative server. I have some comments 
on the SVCB draft and some suggestions for improvements. Just consider 
my thoughts and then do whatever is best.


(1) The format of SVCB (and HTTPS) RR is too complicated, especially 
for parsing presentation format to wireformat and back, including 
consistency checks. Perhaps instead of


www 3600 IN HTTPS 1 . alpn=h2 port=8443

It could be

www 3600 IN HTTPS 1 . alpn h2
  1 . port 8443

Which gives slightly bigger RRSet wireformat, but not by much.


I find this format suggestion to be far more confusing to read, since
these really are key-value pairs, and the SvcDomainName and the
SvcDomainPriority fields are shared across the different key-value
pairs.

What specifically is too hard to parse in the draft’s format? Is that
something that more clarifying examples can help with instead?

Tommy



(2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
compressed. Is there a reason? Especially when the response packets 
are large (and I expect that for SVCB they will), any compression 
helps.


(3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name 
of a domain that has SVCB, , or A records" versus "SvcDomainName 
MAY be the owner of a CNAME record". What is the meaning here?


(4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 
4.1 is too vague and I don't see what an authoritative (not 
recursive!) server shall answer in situation SVCB->CNAME->A (all 
in-bailiwick). Shall the CNAME and A be added to additional section? 
For comparison, in situation MX->CNAME->A we don't bother since this 
situation is forbidden (see RFC 2181).


(5) Wouldn't one octet for priority field be enough?

(6) There are not enough examples in the document. There are many 
variants of SVCB records, the formal ABNF description is difficult to 
read, and it would also illustrate what kind of services those records 
are designed to handle.


Best regards and thanks for your effort,

Libor Peltan
CZ.NIC

___
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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 11:39 AM John Levine  wrote:

> In article  01gd...@mail.gmail.com> you write:
> >> Yes. Leveraging the fact that the IETF community is in fact a community
> >> seems worth the effort to have the references in registries be useful
> to a
> >> new developer a decade in the future.
> >
> >OK. In that case you and I disagree.
> >
> >My reasoning is that (as above) these algorithms are generally of low
> >interest and that requiring community review for code point registration
> >has the result of consuming quite scarce resources in the service of
> making
> >the algorithms which are being registered marginally clearer. ...
>
> Sounds like expert review would be more appropriate, so only one
> person has to spend cycles deciding whether the spec looks plausible.
>

As I said, even that turns out to be quite a bit of work, depending on what
you think "plausible" means. If you review for "there appears to be
something vaguely formatted like a spec at this location", then sure. If
you mean "is this implementable", let alone secure, then it's pretty far
from easy.

-Ekr

>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[John Levine]

In article  
you write:
>> Yes. Leveraging the fact that the IETF community is in fact a community
>> seems worth the effort to have the references in registries be useful to a
>> new developer a decade in the future.
>
>OK. In that case you and I disagree.
>
>My reasoning is that (as above) these algorithms are generally of low
>interest and that requiring community review for code point registration
>has the result of consuming quite scarce resources in the service of making
>the algorithms which are being registered marginally clearer. ...

Sounds like expert review would be more appropriate, so only one
person has to spend cycles deciding whether the spec looks plausible.

R's,
John

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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dick Franks]

On Fri, 19 Jun 2020 at 18:12, Paul Hoffman  wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>

How does any of that apply?
The algorithm in this case is specified by another standards organisation
and is what it is.
Community review did not find the incorrect test parameters in RFC5832 /
GOST R34.10-2001.

--Dick Franks



> ___
> 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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman 
wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>
> > Would that still apply if the space were larger?
>
> Yes. Leveraging the fact that the IETF community is in fact a community
> seems worth the effort to have the references in registries be useful to a
> new developer a decade in the future.
>

OK. In that case you and I disagree.

My reasoning is that (as above) these algorithms are generally of low
interest and that requiring community review for code point registration
has the result of consuming quite scarce resources in the service of making
the algorithms which are being registered marginally clearer. This opinion
is based on my extensive experience in reviewing code point assignments for
TLS (largely for things like exporters) where one was presented with a long
specification which was embedded in the context of some other protocol and
then one had to make sense of it and determine whether it was
implementable. And because you were actually holding up other people's work
based on that review, there was pressure to complete it. This kind of
experience is why we changed to the current system.

More generally, it seems like there are two primary purposes for code point
registration here:

1. To promote interoperability of the code points
2. To avoid code point collisions

My perspective here is that while interoperability is good, the primary
value here is to avoid collisions. People who wish to have interoperability
will still have the IETF process available to them, but given the large
number of uses of our protocols, I do not believe that it is productive to
make it harder for people to extend them in order to require
interoperability for those who do not believe they need it (or at least do
not believe they need the IETF enforcing it).

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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> What's your reasoning for why there needs to be community review before there 
> is a code point assigned?

Historically, the quality of algorithm descriptions in early drafts has been 
variable. What the author considers sufficient and obvious, another might not. 
Also, review gives folks a chance to say things like "your test vectors appear 
wrong", "having test vectors would be really useful", and so on. 

> Would that still apply if the space were larger?

Yes. Leveraging the fact that the IETF community is in fact a community seems 
worth the effort to have the references in registries be useful to a new 
developer a decade in the future.

--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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman  wrote:

> On Jun 18, 2020, at 9:20 PM, Martin Thomson  wrote:
> >
> > On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> >> It might be better, and faster, for this WG to adopt a one-paragraph
> >> draft that makes the DS registry "RFC required", like the other
> >> DNSSEC-related registries.
> >
> > I think you mean "Specification Required".
>
> I do not.
>
> >  RFC required has the same net effect, but the side effect being that
> you burden the ISE with these requests.
>
> "RFC required" forces the specification to be stable enough for the ISE
> (or the IESG, for individual submissions) to approve publication. Using
> "specification required" means that someone can write an Internet Draft,
> get the code point, then realize that their draft was wrong due to lack of
> community review. The result is either:
> - Two code points for similarly-named algorithms
>

Sure. This seems not that desirable, but given that these algorithms are
more or less by definition ones in which there is not that wide interest,
not that big a deal.


- A code point whose definition is a moving target
>

I agree that this is undesirable. The registrations should be tied to a
single fixed draft version.



> Using "RFC required" is not perfect (due to errata and RFC updates), but
> it does mean that there is at least some community review before the code
> point is allocated.
>

What's your reasoning for why there needs to be community review before
there is a code point assigned? Would that still apply if the space were
larger?


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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jun 18, 2020, at 9:20 PM, Martin Thomson  wrote:
> 
> On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
>> It might be better, and faster, for this WG to adopt a one-paragraph 
>> draft that makes the DS registry "RFC required", like the other 
>> DNSSEC-related registries.
> 
> I think you mean "Specification Required".

I do not.

>  RFC required has the same net effect, but the side effect being that you 
> burden the ISE with these requests.

"RFC required" forces the specification to be stable enough for the ISE (or the 
IESG, for individual submissions) to approve publication. Using "specification 
required" means that someone can write an Internet Draft, get the code point, 
then realize that their draft was wrong due to lack of community review. The 
result is either:
- Two code points for similarly-named algorithms
- A code point whose definition is a moving target
Using "RFC required" is not perfect (due to errata and RFC updates), but it 
does mean that there is at least some community review before the code point is 
allocated.

--Paul Hoffman

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

Re: [DNSOP] Hybird Resolver/ DNS invariants

[Paul Vixie]

On Friday, 19 June 2020 01:50:13 UTC Davey Song wrote:
> Dear Paul,
> 
> On Wed, 17 Jun 2020 at 00:03, Paul Vixie  wrote:
> > as you know, synchronizing the root zone (RFC 7706) solves almost
> > none of the problem of occasional connectivity, since so many other
> > NS, DS, glue, key, and signature data are needed in-cache to continue
> > retrieving other answers during times of disconnectivity. we (you) 
> > should do this.
> 
> I guess you mean providing an alternative resolution path for occasional
> disconnectivity on the path between the authority server and the resolver,
> #2 is one approach, right?

i don't think so. what i'm interested in is the situation where a host 
desiring to discover and reach some service, and that service, and the DNS 
content needed to discover that service, are all on the same side of a 
discontinuity. discoverability and reachability should be continuous.

this would naturally fall into two units of protocol development. first, the 
DNS metadata (NS, DS, DNSKEY, A/ glue for NS) discovered during times when 
the whole DNS infrastructure (roots, TLD servers, SLD servers if any, and so 
on) are reachable, should be retained in a form very similar to IXFR/NOTIFY. 
think of this as a "hidden secondary" at the RRset level rather than at the 
zone level. this method relies on normal operations to help discover normally 
needed DNS metadata, and then keep it in cache.

i should be able to reach the servers in my house even when the fiber has been 
cut, and i should not have to use LLMNR or similar protocols to make that 
possible. similarly, an island nation should be able to reach its entire 
electronic economy even if a shark has eaten the last undersea cable. this 
should not require that copies of all relevant DNS infrastructure be served 
inside that economy -- for example some new zealand web services are in .COM 
or .NET or elsewhere, and while it's possible to have a hidden secondary for 
NZ and CO.NZ, it's not possible to have hidden secondaries for all possible 
zones. the system must be able to opportunistically discover the "necessary" 
DNS infrastructure, and keep this data in-cache at an RRset granularity, and 
to make sure that this "leased RRset" can be invalidated by a secure 
transaction from the containing authority zone. so, that's a lot of data, and 
a lot of traffic. it wasn't practical until recently but it _is_ practical.

second, we should employ IP multicast or similar announcement technology so 
that zone authorities whether primary or secondary, and whether published or 
hidden, can become known by local validating recursive iterative DNS servers. 
this is a harder problem than the early opportunistic discovery approach, 
because we don't know how to define "local" properly. however, i'd like to be 
able to reboot my entire network during times of upstream discontinuity, and 
still be able to discover and reach all services on my side of the fiber cut. 
also, i'd like to be able to operate a fully disconnected network without 
having to create my own fake "root zone" to delegate my own names to my own 
servers inside my disconnected network. this wasn't practical without DNSSEC, 
but it _is_ practical.

> > it's long been known that ECS is a privacy nightmare; we must obsolete it
> > and also
> > erase set-associativity currently available by non-anycasted RDNS servers.
> 
> What do you mean by  set-associativity of   non-anycasted RDNS servers?

set-associativity means the authority server's opportunity to guess the 
topologic location of the stub resolver by examining the recursive server's 
uplink address. that's the original sin that led to ECS when RDNS anycast 
first became popular. authority servers should answer the questions they're 
asked, without topological favoritism. the 1.1.1.1 service does not speak ECS, 
yet the CDN world has not melted down. we can now move beyond not just ECS, 
but the privacy-violating original presumptions that ECS was based on.

see also: https://queue.acm.org/detail.cfm?id=1647302

> Again, thank you for your comments and support.

i hope this work continues. i'd like to see these problems solved, correctly 
and scalably, within my lifetime.

-- 
Paul


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