Re: [DNSOP] HTTPS SVCB no service available signal.

[Mark Andrews]

> On 11 Jul 2020, at 02:41, Brian Dickson  wrote:
> 
> (Apologies for any weird quoting-style/depth issues, mail user agents aren't 
> terribly consistent.)
> 
> On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews  wrote:
> 
> 
> > On 10 Jul 2020, at 11:53, Joe Abley  wrote:
> > 
> > On 9 Jul 2020, at 18:48, Mark Andrews  wrote:
> > 
> 
> > By that logic, DNS UPDATE changed the original purpose of MNAME to be the 
> > target for a DNS UPDATE.
> 
> No. DNS UPDATE says any listed nameserver is a target for DNS UPDATE.  If the 
> SOA MNAME matches a NS name then you try that nameserver FIRST.
> 
> That's an IF conditional which is only applicable if the IF condition is 
> matched. It says nothing about what to do if the SOA MNAME doesn't match an 
> NS name.

UPDATE says to send the update requests to the servers listed in the NS RRset.  
The SOA MNAME provides a sorting criteria for those names.

> I'm also confused about the objection. Are you saying you want to allow 
> UPDATEs, or that you want a mechanism that programmatically blocks UPDATEs 
> without changing your use of MNAME?
> See below (next block of text from me) if it is the latter case.
>  
> 
> >> When you change the purpose of a field you have to consider the existing 
> >> users of that field.
> > 
> > The only purpose of MNAME today that I am aware of is to identify the 
> > target for a DNS UPDATE. If you know of another way that the field is 
> > interpreted I'd be interested to hear it. Even without DNS UPDATE being a 
> > primary concern, there are many zones whose provisioning means that 
> > "primary master" has no real meaning; there's no reachable server that is 
> > more master or more primary than any other; the concept of a single, 
> > primary master server or service is a legacy that no longer applies to many 
> > high-use zones.
> 
> So you discard everyone that has to diagnose DNS issues.  You discard anyones 
> self configuring provisioning system.  The field is in use for purposes other 
> than DNS UPDATE.
> 
> 
> This illustrates the importance and value in documenting dependencies/uses in 
> RFCs, even if they are Informational or even ISE.
> The uses you are referring to aren't in any RFCs, are they?

The use of MNAME to point to the primary server IS documented in STD13.  You 
don’t have to document every possible use that falls out of that specification. 
 So no there isn’t any RFC documenting them but there is no expectation that 
there would be either.  Where is it documented that EVERY use you make of the 
existing specifications needs to be documented in a RFC.  The same way as there 
is no documentation on millions of uses that naturally fall out of all the 
existing RFCs.  Joe is trying to CHANGE the specification of MNAME and I’m 
pointing out some of the potential uses of the existing specification.

> I could overload the TTL field of a DNS record to be a DSCP thing, but if I 
> didn't tell anyone about it, I shouldn't be surprised if future changes to 
> standards broke it.

Now you are just throwing stupid straw man arguments about.

> However, this doesn't mean this use case isn't valid.
> The fundamental question is whether there are ways to support that use (XFR 
> topology discovery) while also supporting Joe's concept(s) for making useless 
> UPDATE things stop.
>  (And more generally have ways to signal anything that might be a host name 
> from being used for something when that something isn't supported by policy.)
> 
> Rather than the NAME of the thing (FQDN, e.g. MNAME field or MX target), what 
> about using the VALUE or STATUS (e.g. presence/absence of A/ RRSETs, or 
> NXDOMAIN results)?
> 
> The corner case for XFR topology could be accomplished with DNS "views" for 
> the FQDN in the MNAME field (only permitted XFR clients would get the "real" 
> value).

Which kind of defeats the diagnostic use.

> The logic path for clients would be relatively simple: 
>   • Check if the name resolves and has A/ records
>   • Use it for the field's purpose only if BOTH things are satisfied.
> That seems like a simple and pragmatic compromise.
> I think it would be easy to implement, and would be mostly an optimization 
> (to not send UPDATEs that will be ignored).
> Interoperability would be dead easy to confirm.
> 
> 
> > I still think it'd be a service at this point to codify the use of an empty 
> > string in a field that is intended for use as a hostname to indicate that 
> > no host is available to do whatever the client was hoping to do. The only 
> > identified harm from such a definition, even after the fact, is the 
> > potential for a few client libraries that are unfamiliar with the concept 
> > of a hostname sending a few queries that will quickly be cached at multiple 
> > levels.
> > 
> > Making this assertion for all RDATA fields that might contain hostnames 
> > seems more beneficial than poking about in particular RRSet definitions, 
> > since it opens the door for efficient suppress

[DNSOP] Protocol Action: 'Secret Key Transaction Authentication for DNS (TSIG)' to Internet Standard (draft-ietf-dnsop-rfc2845bis-09.txt)

[The IESG]

The IESG has approved the following document:
- 'Secret Key Transaction Authentication for DNS (TSIG)'
  (draft-ietf-dnsop-rfc2845bis-09.txt) as Internet Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/





Technical Summary

This document describes a protocol for DNS for transaction level
authentication using shared secrets and one way hashing.  It can be
used to authenticate dynamic DNS updates as coming from an approved
client, or to authenticate responses as coming from an approved DNS
name server.

No recommendation is made here for distributing the shared secrets: it
is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism.

The draft obsoletes RFC2845 and RFC4635.

Working Group Summary

The draft updates RFC2845, because due to some ambiguity in the
wording of the document, different implementations made decisions that
caused operational problems, see also Section 1.3.  The draft was
swiftly adopted to become a DNSOP WG document.  After WG adoption, the
authors of the original RFC2845 have also been added to the author
list.  The WG stated that the document was not just an errata, but a
bis, so the document could improve the readability and wording of the
protocol specification.

Document Quality

A recent implementation of RFC2845 used the rfc2845bis draft to
implement TSIG.  The new draft document is much clearer and offers
better implementation guidance than the original.  RFC2845 is
implemented by all known open source DNS name servers and, as far as
the shepherd knows, all commercial DNS name servers (not knowing for
proprietary name servers).

The implementer (Martin Hoffmann, NLnet Labs) has provided good
feedback to improve the text of the rfc2845bis draft and to reorganize
some sections.  Other feedback from the working group has also been
processed.

Personnel


Document Shepherd: Benno Overeinder
Responsible Area Director: Warren Kumari

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

Re: [DNSOP] HTTPS SVCB no service available signal.

[Dick Franks]

On Thu, 9 Jul 2020 at 23:18, Joe Abley  wrote:

> On Jul 9, 2020, at 17:18, Ben Schwartz 
> wrote:
>
> This seems like a reasonable idea to me.  We should be able to incorporate
> this for the next draft revision.
>
>
> I guess I'll mention that when I suggested MNAME=. to indicate that a zone
> did not accept dynamic updates, the proposal was roundly shot down as a
> disgusting idea that would cause junk to be sent to root servers.i
>

The idea is respectable enough.
There is also a precedent to be found in RFC1035 (3.3.7) no less.

--Dick


> ___
> 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] HTTPS SVCB no service available signal.

[Joe Abley]

On 9 Jul 2020, at 23:02, Mark Andrews  wrote:

>>> When you change the purpose of a field you have to consider the existing 
>>> users of that field.
>> 
>> The only purpose of MNAME today that I am aware of is to identify the target 
>> for a DNS UPDATE. If you know of another way that the field is interpreted 
>> I'd be interested to hear it. Even without DNS UPDATE being a primary 
>> concern, there are many zones whose provisioning means that "primary master" 
>> has no real meaning; there's no reachable server that is more master or more 
>> primary than any other; the concept of a single, primary master server or 
>> service is a legacy that no longer applies to many high-use zones.
> 
> So you discard everyone that has to diagnose DNS issues.

Nope. I'm saying that in many cases there is no useful information to put in 
the MNAME field, so even if it was common practice to diagnose DNS problems 
with reference to the contents of that field (which I think is not true) the 
contents of the field have no particular relevance.

If I generate a zone that is distributed by means other than zone transfer, 
there is no common meaning of "primary master".

If I publish a zone from a private, non-world-reachable single master but then 
distribute it through a graph of distribution masters, why is the name of that 
private origin master useful to anybody trying to diagnose a problem?

>  You discard anyones self configuring provisioning system.  The field is in 
> use for purposes other than DNS UPDATE.

Just because you say it doesn't make it universally true, Mark. You're going to 
have to show your working if you want to make a point.

>>> Given that there is a registered SRV prefix for UPDATE (_dns-update._tcp) 
>>> you already have a signal.
>> 
>> That is certainly an option for clients that use SRV lookups to identify 
>> targets for a DNS UPDATE. I'm not aware of any, but I believe your inference 
>> that they exist. I think it's fair to say that there are other clients that 
>> don't support that mechanism, though. It wasn't mentioned in RFC 2136.
> 
> You local MacOS machine will lookup _dns-update._tcp SRV as do some CPE 
> routers.

And so your argument is that there are no other UPDATE clients that use the 
MNAME? Or are you agreeing with me?


Joe

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

Re: [DNSOP] HTTPS SVCB no service available signal.

[Brian Dickson]

(Apologies for any weird quoting-style/depth issues, mail user agents
aren't terribly consistent.)

On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews  wrote:

>
>
> > On 10 Jul 2020, at 11:53, Joe Abley  wrote:
> >
> > On 9 Jul 2020, at 18:48, Mark Andrews  wrote:
> >
>
> > By that logic, DNS UPDATE changed the original purpose of MNAME to be
> the target for a DNS UPDATE.
>
> No. DNS UPDATE says any listed nameserver is a target for DNS UPDATE.  If
> the SOA MNAME matches a NS name then you try that nameserver FIRST.
>

That's an IF conditional which is only applicable if the IF condition is
matched. It says nothing about what to do if the SOA MNAME doesn't match an
NS name.

I'm also confused about the objection. Are you saying you want to allow
UPDATEs, or that you want a mechanism that programmatically blocks UPDATEs
without changing your use of MNAME?
See below (next block of text from me) if it is the latter case.


>
> >> When you change the purpose of a field you have to consider the
> existing users of that field.
> >
> > The only purpose of MNAME today that I am aware of is to identify the
> target for a DNS UPDATE. If you know of another way that the field is
> interpreted I'd be interested to hear it. Even without DNS UPDATE being a
> primary concern, there are many zones whose provisioning means that
> "primary master" has no real meaning; there's no reachable server that is
> more master or more primary than any other; the concept of a single,
> primary master server or service is a legacy that no longer applies to many
> high-use zones.
>
> So you discard everyone that has to diagnose DNS issues.  You discard
> anyones self configuring provisioning system.  The field is in use for
> purposes other than DNS UPDATE.
>
>
This illustrates the importance and value in documenting dependencies/uses
in RFCs, even if they are Informational or even ISE.
The uses you are referring to aren't in any RFCs, are they?
I could overload the TTL field of a DNS record to be a DSCP thing, but if I
didn't tell anyone about it, I shouldn't be surprised if future changes to
standards broke it.

However, this doesn't mean this use case isn't valid.
The fundamental question is whether there are ways to support that use (XFR
topology discovery) while also supporting Joe's concept(s) for making
useless UPDATE things stop.
 (And more generally have ways to signal anything that might be a host name
from being used for something when that something isn't supported by
policy.)

Rather than the NAME of the thing (FQDN, e.g. MNAME field or MX target),
what about using the VALUE or STATUS (e.g. presence/absence of A/
RRSETs, or NXDOMAIN results)?

The corner case for XFR topology could be accomplished with DNS "views" for
the FQDN in the MNAME field (only permitted XFR clients would get the
"real" value).

The logic path for clients would be relatively simple:

   - Check if the name resolves and has A/ records
   - Use it for the field's purpose only if BOTH things are satisfied.

That seems like a simple and pragmatic compromise.
I think it would be easy to implement, and would be mostly an optimization
(to not send UPDATEs that will be ignored).
Interoperability would be dead easy to confirm.


> > I still think it'd be a service at this point to codify the use of an
> empty string in a field that is intended for use as a hostname to indicate
> that no host is available to do whatever the client was hoping to do. The
> only identified harm from such a definition, even after the fact, is the
> potential for a few client libraries that are unfamiliar with the concept
> of a hostname sending a few queries that will quickly be cached at multiple
> levels.
> >
> > Making this assertion for all RDATA fields that might contain hostnames
> seems more beneficial than poking about in particular RRSet definitions,
> since it opens the door for efficient suppression of traffic in client
> libraries.
> >
> > Having clients inadvertently send DNS UPDATEs to servers that are not
> prepared to accept the is at least an inefficiency; at worst it's a
> systematic leak of local topology information.
>

I agree with this concept.
See above for an idea on how to implement this that doesn't rely on the
FQDN being the empty string per se, but which would be satisfied IF the
FQDN were the empty string (or something under empty.as112.arpa, for
example.)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-09.txt

[Stephen Morris]

This is a minor update of the draft, changing the usage of hmac-sha224 from 
"NOT RECOMMENDED" to "MAY", in line with discussions on the list back in May.

Stephen

> On 10 Jul 2020, at 15:52, internet-dra...@ietf.org wrote:
> 
> 
> 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   : Secret Key Transaction Authentication for DNS (TSIG)
>Authors : Francis Dupont
>  Stephen Morris
>  Paul Vixie
>  Donald E. Eastlake 3rd
>  Olafur Gudmundsson
>  Brian Wellington
>   Filename: draft-ietf-dnsop-rfc2845bis-09.txt
>   Pages   : 29
>   Date: 2020-07-10
> 
> Abstract:
>   This document describes a protocol for transaction level
>   authentication using shared secrets and one way hashing.  It can be
>   used to authenticate dynamic updates to a DNS zone as coming from an
>   approved client, or to authenticate responses as coming from an
>   approved name server.
> 
>   No recommendation is made here for distributing the shared secrets:
>   it is expected that a network administrator will statically configure
>   name servers and clients using some out of band mechanism.
> 
>   This document obsoletes RFC2845 and RFC4635.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-09
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc2845bis-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> 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] I-D Action: draft-ietf-dnsop-rfc2845bis-09.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   : Secret Key Transaction Authentication for DNS (TSIG)
Authors : Francis Dupont
  Stephen Morris
  Paul Vixie
  Donald E. Eastlake 3rd
  Olafur Gudmundsson
  Brian Wellington
Filename: draft-ietf-dnsop-rfc2845bis-09.txt
Pages   : 29
Date: 2020-07-10

Abstract:
   This document describes a protocol for transaction level
   authentication using shared secrets and one way hashing.  It can be
   used to authenticate dynamic updates to a DNS zone as coming from an
   approved client, or to authenticate responses as coming from an
   approved name server.

   No recommendation is made here for distributing the shared secrets:
   it is expected that a network administrator will statically configure
   name servers and clients using some out of band mechanism.

   This document obsoletes RFC2845 and RFC4635.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-09
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [DNSOP] [Ext] [Technical Errata Reported] RFC8624 (6227)

[Paul Hoffman]

This errata should be rejected because it changes the decision of the IETF 
about the IANA registries. In specific:

> Notes
> -
> The document clearly has the intention to update the IANA registers, which is 
> also stated in the document, but not in section 6 ("IANA Considerations").

This is not true. There is literally no wording in the text that shows such 
intention.

If the author of this incorrect "errata" wants the IANA registries to reflect 
the values in RFC 8624, they should create a new Internet Draft saying such. I 
believe there will be both support and opposition, but it is a good discussion 
to have now that we have consensus on what the implementation guidance is.

--Paul Hoffman

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

Re: [DNSOP] [Technical Errata Reported] RFC8624 (6227)

[Paul Wouters]

On Fri, 10 Jul 2020, RFC Errata System wrote:


Subject: [DNSOP] [Technical Errata Reported] RFC8624 (6227)

The following errata report has been submitted for RFC8624,
"Algorithm Implementation Requirements and Usage Guidance for DNSSEC".



Type: Technical
Reported by: Mats Dufberg 



Original Text
-
  This document has no IANA actions.


Corrected Text
--
  This document updates the IANA registry "Delegation Signer (DS) Resource
  Record (RR) Type Digest Algorithms". The registry has been updated by
  the following table from section 3.3:


[...]



Notes
-
The document clearly has the intention to update the IANA registers, which is also stated 
in the document, but not in section 6 ("IANA Considerations").



The document did NOT add any columns to the IANA registry. Whether a
successor of this document should do that or not is up to the working
group. Some WG's prefer that recommendations stay in RFC's and IANA
just stays numbers. Other WGs add a column for deprecated/obsoleted

So I think technically, this errata is not correct.

I do agree that a future RFC should add a Notes column where we can
mark an entry as deprecated/obsolete. I do not think we should add
recommended, not recommended here, as the iANA registry itself does
not allow us to explain and clarify why we come to such recommendations
and an implementor cannot really decide on whether to implement a
MAY or NOT REOMMENDED or RECOMMENDED without having more context.

Paul

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

[DNSOP] [Technical Errata Reported] RFC8624 (6227)

[RFC Errata System]

The following errata report has been submitted for RFC8624,
"Algorithm Implementation Requirements and Usage Guidance for DNSSEC".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6227

--
Type: Technical
Reported by: Mats Dufberg 

Section: 6

Original Text
-
   This document has no IANA actions.


Corrected Text
--
   This document updates the IANA registry "Delegation Signer (DS) Resource 
   Record (RR) Type Digest Algorithms". The registry has been updated by
   the following table from section 3.3:

   ++-+---+---+
   | Number | Mnemonics   | DNSSEC Delegation | DNSSEC Validation |
   ++-+---+---+
   | 0  | NULL (CDS only) | MUST NOT [*]  | MUST NOT [*]  |
   | 1  | SHA-1   | MUST NOT  | MUST  |
   | 2  | SHA-256 | MUST  | MUST  |
   | 3  | GOST R 34.11-94 | MUST NOT  | MAY   |
   | 4  | SHA-384 | MAY   | RECOMMENDED   |
   ++-+---+---+

   [*] - This is a special type of CDS record signaling removal of DS at
 the parent in [RFC8078].


   This document updates the IANA registry "DNS Security Algorithm Numbers". 
   The registry has been updated by the following table from section 3.1:

   +++-+---+
   | Number | Mnemonics  | DNSSEC Signing  | DNSSEC Validation |
   +++-+---+
   | 1  | RSAMD5 | MUST NOT| MUST NOT  |
   | 3  | DSA| MUST NOT| MUST NOT  |
   | 5  | RSASHA1| NOT RECOMMENDED | MUST  |
   | 6  | DSA-NSEC3-SHA1 | MUST NOT| MUST NOT  |
   | 7  | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST  |
   | 8  | RSASHA256  | MUST| MUST  |
   | 10 | RSASHA512  | NOT RECOMMENDED | MUST  |
   | 12 | ECC-GOST   | MUST NOT| MAY   |
   | 13 | ECDSAP256SHA256| MUST| MUST  |
   | 14 | ECDSAP384SHA384| MAY | RECOMMENDED   |
   | 15 | ED25519| RECOMMENDED | RECOMMENDED   |
   | 16 | ED448  | MAY | RECOMMENDED   |
   +++-+---+



Notes
-
The document clearly has the intention to update the IANA registers, which is 
also stated in the document, but not in section 6 ("IANA Considerations").

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8624 (draft-ietf-dnsop-algorithm-update-10)
--
Title   : Algorithm Implementation Requirements and Usage Guidance 
for DNSSEC
Publication Date: June 2019
Author(s)   : P. Wouters, O. Sury
Category: PROPOSED STANDARD
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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