Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-rfc8499bis-09: (with COMMENT)

[Murray S. Kucherawy]

On Sun, Sep 17, 2023 at 7:53 AM Tim Wicinski  wrote:

>
>
> On Sun, Sep 17, 2023 at 5:01 AM Joe Abley  wrote:
>
>> Hi Murray!
>>
>> Op 17 sep. 2023 om 08:07 heeft Murray Kucherawy via Datatracker <
>> nore...@ietf.org> het volgende geschreven:
>>
>> > I thought the IESG (though maybe not this particular one) had previously
>> > discouraged publishing "living documents" like this one in the RFC
>> series.  So
>> > why aren't we doing this as a wiki page or something?  Not a hill I
>> care to die
>> > on, but I'd like to understand.
>>
>> I find it handy when I write a document that includes DNS terms to cite
>> the current terminology document rather than make up my own definitions.
>>
>> The particular citation I use in a document matches the meaning of the
>> terms that were intended in my document. Definitions change from time to
>> time, but the intention of my document remains clear even if subsequent
>> terminology documents are published.
>>
>> How do I do that with a wiki page?
>>
>>
>>
> Murray
>
> I have to agree with Joe here.
>
> And I have never heard of this IESG mandate, but I am always impressed
> that they make such statements, and yet have no alternative ideas for such
> things.
> Perhaps if we focused on making the RFCs have release versions, "DNS
> Terminology 4.0" could have this definition.
>

First, I never said it was a mandate or, as Paul suggested, a policy.  It's
just come up before when processing other documents and this situation
seems similar to me, so I'm wondering where that thought process went.
I've seen comments and even ABSTAIN ballot positions that object to
publication of informational documents that "could've been a wiki", and
living documents are often candidates for such consideration.  So here we
are.

The reason I'm asking, though, is that we had 7719 in 2015, which was
replaced by 8499 in 2019, and now this revision.  Since we consider RFCs
expensive to produce, I thought it was a reasonable question to ask.

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

Re: [DNSOP] Murray Kucherawy's Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

[Murray S. Kucherawy]

On Tue, Feb 7, 2023 at 2:02 AM Willem Toorop  wrote:

> Op 28-12-2022 om 23:29 schreef Murray Kucherawy via Datatracker:
> > (1) It's expected (required?), with no actions for IANA, to expressly
> include a
> > section that says so.  It's conspicuously missing here.
>
> We've added the section.
>

Yay!


> > (2) Why is there no registry for custom properties?  I can see that
> Section 4.5
> > takes a run at dealing with the collision risk by SHOULDing a particular
> way of
> > naming custom properties, but it feels to me like a registry is the
> right way
> > to deal with this.  As a consumer of this work, I might not want to
> reveal (via
> > names) which DNS implementation I'm using, for example.
>
> We (the co-authors) discussed this and do recognize that a registry for
> *properties* is a good idea and have added that to the draft (with PR
> https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/67
> )
>

Nice.  The only thing I would say this needs now (per RFC 8126) is some
guidance for the Designated Expert around what to consider a valid
registration versus when to ask for changes.  This isn't mandatory to
provide, but it really is a good idea to put some advice here for future
DEs.

Since this isn't a strict requirement of RFC 8126, I'm going to clear my
DISCUSS, but I suggest you consider adding some guidance text here.  You
and Warren can decide when it's ready to move forward.


> > (3) I have a similar question about groups in Section 4.4.2; "nodnssec"
> is an
> > example of something that we might want to register with global
> semantics, or
> > more generally, that some values might be common in implementations and
> > therefore worth documenting.
>
> Those group values are not for implementations, but for operators to
> choose. We have done several modifications to clarify that:
> - The group values now have non-descriptive names as to not suggest
> that they have meanings in implementations (it's the operator that
> determines the "meaning" and not the implementation)
> - We have extended the lines about catalog producers publishing at
> two consumer operators and how mapping of group values is a matter of
> those producer/consumer relationships, so it now reads:
>
> "Implementations MAY facilitate mapping of a specific group
> value to specific configuration configurable on a per catalog zone basis
> to allow for producers that publish their catalog zone at multiple
> consumer operators. Consumer operators SHOULD namespace their group
> values to reduce the risk of having to resolve clashes."
>

OK.


> > (4) Do we need a registry of names that are special in the context of
> catalog
> > zones, e.g., "zones", "ext", "group", "version", "coo", "invalid"?
>
> We have added a registry for catalog zones properties, already
> provisioned with "zones", "ext", "group", "version" and "coo".
> The latest version of the IANA registry (including "zones") can be seen
> here:
>
>
> https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/blob/master/draft-ietf-dnsop-dns-catalog-zones.md#iana-considerations-iana
>
> "invalid" is already part of the "Special use domain names" registry:
>
>
> https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml


OK.


> > Separately: What action should be taken if a nameserver is already
> > authoritative for a zone (say, is a primary), yet it receives a catalog
> update
> > that now contains that same zone?  This seems like a possible attack that
> > should be discussed.  I guess the second-last paragraph of Section 7
> covers
> > this, though indirectly.
>
> There is text for this in section 5.2:
>
>  "If there is a clash between an existing zone's name (either from
> an existing member zone or otherwise configured zone) and an incoming
> member zone's name (via transfer or update), the new instance of the
> zone MUST be ignored and an error SHOULD be logged."
>

Ah, you're right.  Thanks for the pointer.

> Could I trouble you for an example of a complete sample catalog zone,
> perhaps
> > in BIND format, in an appendix?  I can see each individual concept
> illustrated,
> > but it would be helpful to see them assembled someplace.
>
> Ack. We've added a sample zone:
>
>
> https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/blob/master/draft-ietf-dnsop-dns-catalog-zones.md#catalog-zone-example


Thanks for this.  You might consider adding some prose following the
example that walks the reader through it, but this isn't strictly necessary.


> We thought it couldn't harm to repeat this for clarity. Some reviewers
> "stumbled" over the word "meaningless" so we rephrased this to:
>
>   "Catalog consumers MUST ignore any RRs in the catalog zone for
> which no processing is specified or which are otherwise not supported by
> the implementation."
>

Fair enough.


> > Section 4.1:
> >
> > Given the text in Section 3 (specifically that a catalog zone follows
> the same
> > rules

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

[Murray S. Kucherawy]

On Wed, Jan 4, 2023 at 8:50 AM Peter Thomassen  wrote:

> Hi Éric,
>
> Thank you for your review!
>
> On 1/2/23 14:59, Éric Vyncke via Datatracker wrote:
> > --
> > COMMENT:
> > --
> >
> >
> > # Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-catalog-zones-08
> > CC @evyncke
> >
> > Thank you for the work put into this document. I really like the ideas
> behind
> > this IETF draft (OTOH, DNS is now used as a control/transport protocol
> pretty
> > much BGP nowadays...). But, I second Murray's DISCUSS point about IANA
> (and his
> > ask to get an example because the whole document is not really easy to
> read for
> > a non expert).
>
> We will add both a IANA section and an appendix with a full example.
>
> They can be previewed in this PR, where we are collecting changes
> triggered by the current round of feedback:
> https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/55
> [...]
>

I can see you've added the "no actions" IANA section, which solves part of
my DISCUSS.  But I'd also like to understand why it is that handling names
via IANA was rejected.  Was this discussed in the WG?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-06.txt

[Murray S. Kucherawy]

Howdy,

On Thu, Aug 25, 2022 at 8:08 AM  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   : DNS Glue Requirements in Referral Responses
> Authors : M. Andrews
>   Shumon Huque
>   Paul Wouters
>   Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-06.txt
>   Pages   : 12
>   Date: 2022-08-25
>
> Abstract:
>The DNS uses glue records to allow iterative clients to find the
>addresses of name servers that are contained within a delegated zone.
>Authoritative Servers are expected to return all available glue
>records for in-domain name servers in a referral response.  If
>message size constraints prevent the inclusion of all glue records
>for in-domain name servers, the server MUST set the TC flag to inform
>the client that the response is incomplete, and that the client
>SHOULD use another transport to retrieve the full response.  This
>document updates RFC 1034 to clarify correct server behavior.
>
> [...]
>

Section 1.1 needs to use the updated BCP 14 boilerplate.  See RFC 8174.

Section 3.2 uses "NOT REQUIRED", but this isn't BCP 14 language.  I'm not
sure what the fix is here.  Should that be a SHOULD or MAY?

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

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

[Murray S. Kucherawy]

On Mon, May 9, 2022 at 3:12 PM Ben Schwartz  wrote:

> Yes, that's covered in the description:
>
> The designated expert MUST ensure that the Format Reference is stable and
> publicly available, and that it specifies how to convert the
> SvcParamValue's presentation format to wire format. The Format Reference
> MAY be any individual's Internet-Draft, or a document from any other source
> with similar assurances of stability and availability.
>

Yes, I saw that text, but that sentence doesn't make it clear to me why an
auto-expiring document is acceptable as a possibly-permanent format
reference, so I thought I'd double check.

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

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

[Murray S. Kucherawy]

On Fri, May 6, 2022 at 12:09 PM  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   : Service binding and parameter specification via
> the DNS (DNS SVCB and HTTPS RRs)
> Authors : Ben Schwartz
>   Mike Bishop
>   Erik Nygren
> Filename: draft-ietf-dnsop-svcb-https-09.txt
> Pages   : 62
> Date: 2022-05-06
>
> Abstract:
>This document specifies the "SVCB" and "HTTPS" DNS resource record
>(RR) types to facilitate the lookup of information needed to make
>connections to network services, such as for HTTP origins.  SVCB
>records allow a service to be provided from multiple alternative
>endpoints, each with associated parameters (such as transport
>protocol configuration and keys for encrypting the TLS ClientHello).
>They also enable aliasing of apex domains, which is not possible with
>CNAME.  The HTTPS RR is a variation of SVCB for use with HTTP [HTTP].
>By providing more information to the client before it attempts to
>establish a connection, these records offer potential benefits to
>both performance and privacy.
>

I see the change to Expert Review, which looks good.  Are we going with the
idea of allowing an I-D to be a valid format reference, even though they
expire, to enable things that are in development or experimental?

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

Re: [DNSOP] IANA Policy for SVCB

[Murray S. Kucherawy]

On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  wrote:

> I am concerned that the set of Expert Reviewers necessary to handle SVCB
> needs to have both expert DNS experience *and* detailed knowledge of the
> SVCB model for this to work.
>
> I am not sure there's anybody who fits that criteria.
>

Specification Required also assumes a community that can produce them,
which presumably contains the right experts.

Are we actually moving toward IETF Review here?

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

Re: [DNSOP] IANA Policy for SVCB

[Murray S. Kucherawy]

On Tue, Mar 22, 2022 at 8:48 AM Martin Thomson  wrote:

> On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> > On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> >  wrote:
> >> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
> >
> > Do you have a reference that asserts this?  An I-D that isn't published
> > will expire, which would appear to contradict "permanent and readily
> > available".
>
> There is precedent (TLS docs), but I don't know if there is a reference.
>

Interesting.

In my role as a media type reviewer, for example, it's unlikely I'd accept
an I-D as a stable reference in a registration request except maybe for a
provisional registration.  I could be wrong, but my understanding of the
intent of "Specification Required" is roughly "permanently published,
though not necessarily by the IETF", so I think the bar is a little higher
than just the existence of an I-D.

As to the options proposed, I agree that Expert Review can introduce delay,
but given the above, so too can Specification Required (maybe worse, in
aggregate).  So I recommend Expert Review.

Finally, I just realized my DISCUSS on this document about the IANA
Considerations is redundant to Ben's, so I'm going to go clear it and just
support Ben's.

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

Re: [DNSOP] IANA Policy for SVCB

[Murray S. Kucherawy]

On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz  wrote:

> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>

Do you have a reference that asserts this?  An I-D that isn't published
will expire, which would appear to contradict "permanent and readily
available".

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

Re: [DNSOP] [Ext] Murray Kucherawy's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)

[Murray S. Kucherawy]

On Sun, Oct 3, 2021 at 9:39 AM Paul Hoffman  wrote:

> > In Security Considerations, it says:
> >
> >   Security decisions about
> >   which algorithms are safe and not safe should be made by reading the
> >   security literature, not by looking in IANA registries.
> >
> > Should this document request addition of a note to this effect on the
> registry page itself?
>
> I don't think so, because it is true of every IANA registry page that
> lists crypto algorithms. Or, if you feel such a notice should be this
> registry, it should probably be in every similar registry, and that could
> be enacted by a separate Internet Draft that lists the myriad crypto
> algorthms.
>

I'm just trying to suggest a way to put this advice where it will be seen.
That is, it seems to me the people you're seeking to address -- those that
rely on IANA registries for implementation guidance, rather than documents
-- aren't going to read this document either, and will continue finding
that advice in registries and elsewhere.  Seems to me the way to reach them
is via a note in the registry.

Your call though.  If indeed this admonition would need to appear in many
places to be useful, I wouldn't expect this document to take care of all of
that.

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

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Murray S. Kucherawy]

The title page (top left) says this updates RFC 3658, and that RFC is
mentioned in the Introduction and listed in the References section, but
this document doesn't explain what in that document is being updated.

-MSK

On Wed, Aug 4, 2021 at 8:29 AM Tim Wicinski  wrote:

>
> All
>
> This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/
>
> The Current Intended Status of this document is: Standards Track
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> 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:  18
> August 2021
>
> 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

Re: [DNSOP] NXDOMAIN and RFC 8020

[Murray S. Kucherawy]

On Tue, Apr 6, 2021 at 2:41 PM John Levine  wrote:

> In this application, no, because it's not doing a strict tree walk:
>
> _dmarc.newjersey.sales.bigcorp.wtf
> _dmarc.sales.bigcorp.wtf
> _dmarc.bigcorp.wtf
>
> The _dmarc tag means that none of the names is an ancestor of any of
> the others. It could also look at, e.g., sales.bigcorp.wtf and see if
> it has an NXDOMAIN and prune names below that, but I don't think that
> approach is likely to win overall.


Sure, but if I query "_dmarc.newjersey.sales.bigcorp.wtf" and I get back an
NXDOMAIN for "sales.bigcorp.wtf", I can eliminate at least one query,
because I know right away that the second one in your list isn't there
either.  Extend that out to a name with a dozen or more labels in it and
you're getting somewhere.

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

Re: [DNSOP] NXDOMAIN and RFC 8020

[Murray S. Kucherawy]

On Tue, Apr 6, 2021 at 12:56 PM Brian Dickson 
wrote:

> I think this is another point in favor of doing QNAME minimization.
> RFC7816 (technically experimental, but recommended.)
>
> It kind of makes the query order moot; the resolver looks up the shorter
> name first even while resolving the longer name.
>

Is there any data or even a hint of how widely that experiment has been
deployed or implemented?

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

Re: [DNSOP] NXDOMAIN and RFC 8020

[Murray S. Kucherawy]

On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque  wrote:

> Without DNSSEC, there is no current way to provide an indication about the
> longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3
> records in the response can do this (as well as providing cryptographic
> proof of this assertion with their signatures).
>

Thanks, this (and the others) is helpful.

Focusing on "no current way", could the process described in RFC 8020
theoretically be amended to do so?  It's fine if the answer is "no", but
I'd love to understand why if that's the case.

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

[DNSOP] NXDOMAIN and RFC 8020

[Murray S. Kucherawy]

I'm wondering something about tree walks, which John Levine asked about in
November, as it's a topic of interest to the evolution of DMARC.

I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also
covers later queries for "bar.foo.example".  Makes sense.

Can this be used (or maybe amended) to cover the queries if they come in
the reverse order?  For instance, if "bar.foo.example" arrives first, but
the authoritative server can determine that the entire "foo.example" tree
doesn't exist, could it reply with an NXDOMAIN for the question plus a
cacheable indication about the entire tree instead of just the name that
was in the question?

This would make an ascending tree walk even for something crazy like
"a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for
"foo.example" covers the entire subtree, for a caching nameserver
implementing RFC 8020.

Maybe this is discussed somewhere that I missed in the references.  I'm
happy to take a "go read this for the answer" if that's the case.

Thanks,

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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09

[Murray S. Kucherawy]

On Sat, Sep 12, 2020 at 3:09 PM Elwyn Davies via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Elwyn Davies
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-dnsop-dns-zone-digest-09
> Reviewer: Elwyn Davies
> Review Date: 2020-09-12
> IETF LC End Date: 2020-09-14
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Ready with  few nits.
>
> Major issues:
> None
>
> Minor issues:
> s3.3:  The
> Nits/editorial comments:
>

Did something get truncated here?

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

[Murray S. Kucherawy]

On Wed, Jul 18, 2018 at 12:50 PM, Dave Crocker  wrote:

>
>
>> I imagine myself as a SECDIR reviewer, and believe this would be the
>> first section I would read for any document to which I'm assigned.
>> Discovering there a sentence that basically says "None" would get my back
>> up ("We'll see about that!").
>>
>> More generally, I have had success with my proposed tactic in the past,
>> so I thought I'd suggest it here.
>>
>
> I've gotten decreasingly tolerant of using gambits in a specification
> document, in order to maneuver through the process. I think the document
> should say what it needs to to do its job and not have material that is
> primarily for appeasement those in charge.  Gambits add cruft, and often
> mislead the reader into thinking there is substance when there isn't.
>
> (I think I hit my limit when we appeased an AD for KIM and added the
> requirement for the DKIM signature cover the From: field, thereby aiding in
> community misunderstanding of what DKIM does.)
>
> If the suggested change had any actual substance with respect to security
> issues, that would be quite a different matter.  But it doesn't.
>
> Obviously if the wg would prefer different language, we'll use it...
>

It's not a major issue (to me).  Just a suggestion.


> Reading the document, I got the impression that in your research you
>> discovered some underscore names that don't quite follow the proposed
>> placement.  If my inference is wrong, then so is that clause.
>>
>
> sorry, but apparently something is getting in the way of my understanding
> this issue.  Now I'm confused about the 'placement' reference.
>

I'm willing to accept that I'm inventing a problem here that doesn't
actually exist, and you're advocating more generally for keeping this
section as terse as possible, so let's skip it.

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

[Murray S. Kucherawy]

On Wed, Jul 18, 2018 at 12:33 PM, Dave Crocker  wrote:

> On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
>
>> Section 3.2 replaces text in Section 4.1 of something, but I don't know
>> what; the prior paragraph refers to multiple other documents.  I suggest:
>> (a) clarify which document's 4.1 is being replaced, and (b) don't bother
>> including the original (replaced) text.
>>
>
> I'll add reference to the RFC being modified, closer to the modification
> text, but I'd rather keep the old language in there, to reduce the
> likelihood that someone will replace too-much/not-enough of the existing
> text.


My concern here is based on past ART efforts where direct citation was said
to risk inaccurate copying, and thus semantic drift.  Naturally in each
instance it's easy to argue "This is a correct copy of the text being
replaced" but it's still a generally discouraged practice.

Over in DCRUP, we faced the same problem and instead produced Section 3 of
RFC8301 with this in mind, for example.

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

[Murray S. Kucherawy]

On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker  wrote:

> Folks,
>
> I'm responding to Murray's impressive proofreading details offlist, but
> there are some points he raises that might need wg discussion:


Aw shucks.


> COMMENT:
>>
>> The text specifically calls for a stable reference. Do we have guidance
>> about what constitutes such a thing? I believe IANA has its own guidelines
>> to that end; are they available to the Designated Expert?
>>
>
> I'm inclined to let IANA raise this if they see and issue and then let
> them drive the resolution of this point.


Yeah, I don't have the right answer either, but I'm concerned that we're
asking the DE to make a decision with guidelines she doesn't have (or
worse, come up with some that are not consistent with what IANA usually
does).


> Section 6:
>>
>> COMMENT:
>>
>> I have doubts that SECDIR would accept this one-sentence comment. I
>> suggest saying something more specific, like:
>>
>> "This document establishes a registry, and encourages a slight
>> reorganization of attributes stored in the DNS. It establishes no new
>> security issues."
>>
>
> The first clause is redundant and makes sense to have here only either if
> the readers of this section haven't read the rest of the document, or if
> the clause is useful to what follows.  I believe neither applies here.
>

I imagine myself as a SECDIR reviewer, and believe this would be the first
section I would read for any document to which I'm assigned.  Discovering
there a sentence that basically says "None" would get my back up ("We'll
see about that!").

More generally, I have had success with my proposed tactic in the past, so
I thought I'd suggest it here.

I don't understand the 'encourages' statement but suspect I don't agree.
>

Reading the document, I got the impression that in your research you
discovered some underscore names that don't quite follow the proposed
placement.  If my inference is wrong, then so is that clause.


> Section 6.1:
>>
>> COMMENT:
>>
>> This seems to me to be content that belongs in its own section outside of
>> Section 6 since it doesn't seem to me to be a security issue, but it's
>> worth saying. Maybe give it its own section between what's now Sections 3
>> and 4?
>>
>
> Well, I agree it's awkward where it is, but gosh.  An entire major
> section?  For such a small and explanatory -- rather than
> specification/normative bit of text? Mumble.
>
> If no one minds, I would rather make it Section 1.4, just after the
> sub-section tht describes the construct.  I think it actually works well
> there.


That works too.

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

[DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

[Murray S. Kucherawy]

I've reviewed this document and it also looks like it's pretty much ready.
My suggestions here are also pretty minor:

As the other document, this one uses MUST without the RFC2119 boilerplate.

Section 3.2 replaces text in Section 4.1 of something, but I don't know
what; the prior paragraph refers to multiple other documents.  I suggest:
(a) clarify which document's 4.1 is being replaced, and (b) don't bother
including the original (replaced) text.

I believe Section 4 can include a note to the RFC Editor to remove it prior
to publication.

Section 5, as in the other document, is too terse.  I suggest summarizing
the fact that the only thing going on here is creating of IANA requirements
on future work, and updating old documents to reference those requirements.

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

[DNSOP] Review of draft-ietf-dnsop-attrleaf

[Murray S. Kucherawy]

I've reviewed this document and I think it's in pretty good shape, and is
just about ready to be sent up for publication.  I have some editorial
comments that are mostly minor in nature, as follows:

Section 1.1:

OLD:

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" [RFC1035
],
   [RFC2782 ], [RFC6335
], [RFC7553
].

NEW (formatting):

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" (see
[RFC1035 ],
   [RFC2782 ], [RFC6335
], and [RFC7553
]).

OLD:

   when they are the underscored name closest to the DNS root; they are
   considered 'global'.  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

NEW (consistent quoting; this is the first of several instances):

   when they are the underscored name closest to the DNS root; they are
   considered "global".  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

Section 1.3:

OLD:

   presentation convention described in Section 3.1

or [RFC1034 ] this is

NEW (typo, comma):

   presentation convention described in Section 3.1

of [RFC1034 ], this is

Section 2:

COMMENT:

   o  If a public specification calls for use of an underscore-prefixed
  domain node name, the 'global' underscored name -- the underscored
  name that is closest to the DNS root -- MUST be entered into this
  registry.


Use of "MUST" in the RFC2119 sense needs the RFC2119 boilerplate,
which isn't included in the document. This also appears in several
spots in Section 4.

I'm also not sure it applies here; there's no obvious threat to
interoperability if someone does this but doesn't register it.

(More generally, I've frequently been told that MUSTard in IANA
Considerations is a no-no.)


OLD:

   An underscored name define scope of use for specific resource record


NEW:

   An underscored name defines the scope of use for specific resource record

Section 4.1:

OLD:

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character (_) and is the underscored

NEW (include the ASCII value):

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character ("_", ASCII 0x5F) and is
the underscored

OLD:

   o  The required Reference for an entry MUST have a stable resolution
  to the organization controlling that registry entry


NEW (missing trailing period):

   o  The required Reference for an entry MUST have a stable resolution
  to the organization controlling that registry entry.

COMMENT:

The DNS is case-insensitive so this is a minor point, but would there
be any benefit to specifying that the registry only records the
all-lowercase version of an underscore name?

COMMENT:

The text specifically calls for a stable reference.  Do we have
guidance about what constitutes such a thing?  I believe IANA has its
own guidelines to that end; are they available to the Designated
Expert?

Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence comment.  I
suggest saying something more specific, like:

"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS.  It establishes no new
security issues."

Section 6.1:

COMMENT:

This seems to me to be content that belongs in its own section outside
of Section 6 since it doesn't seem to me to be a security issue, but
it's worth saying.  Maybe give it its own section between what's now
Sections 3 and 4?

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

Re: [DNSOP] Registry of non-service _prefix names?

[Murray S. Kucherawy]

On Sat, Nov 14, 2015 at 8:14 PM, John Levine  wrote:

> >I would sign up as chair if there is enough interest to resurrect this.
>
> I brought it up, I'm willing to work on it.
>

Likewise.  Also willing to help DISPATCH it via another route if DNSOP
doesn't take it up.  :-)

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

[DNSOP] Proposed charter for DBOUND WG

[Murray S. Kucherawy]

Colleagues,

Below is a proposed charter for a working group we're calling DBOUND, which
is seeking to solve the problem of finding a way to identify
administrative/organizational boundaries in the domain namespace.  We'd
like to get some feedback from outside the team of people that's been
working on it.

For the sake of tracking the feedback, please reply only to
apps-disc...@ietf.org with any comments you may have.

-MSK, APPSAWG co-chair

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related.  A popular example is
the need to determine whether example.com and foo.example.com, or
evenexample.net, are subject to the same administrative control.  To
humans,
the answer to this may be obvious.  However, the Domain Name System (DNS),
which is the service that handles domain name queries, does not provide
the ability to mark these sorts of relationships.  This makes it
impossible to discern relationships algorithmically.  For example, the
right answer is not always "compare the rightmost two labels".

The particular issue is that applications and organizations impose
policies and procedures that create additional structure in their use of
domain names.  This creates many possible relationships that are not
evident in the names themselves or in the operational, public
representation of the names.

Prior solutions for identifying relationships between domain names
have sought to use the DNS namespace and protocol to extract that
information when it isn't actually there; the concept of an administrative
boundary is by definition not present in the DNS.  Relying on the DNS to
divine administrative structure thus renders such solutions unreliable and
unnecessarily constrained.  For example, confirming or dismissing a
relationship between two domain names based on the existence of a zone
cut or common ancestry is often unfounded, and the notion of an upward
"tree walk" as a search mechanism is considered unacceptable.

For the purposes of this work, domain names are approached as identifiers
used by organizations and services, independent of underlying protocols
or mechanisms.  Specifically, the work will not propose any changes to
DNS protocols except the possible creation of new resource record types
(RRTYPES).  Furthermore, we define an "organizational domain" to be a
name that is at the top of an administrative hierarchy, defining transition
from one "outside" administrative authority to another that is "inside" the
organization.

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the hierarchical namespace at which registrations take place, and is
used to identify the boundary between so-called "public" names (below which
registrations can occur) and the private names (i.e., organizational names)
below them.  When this list is inaccurate, it exposes a deviation from
reality that degrades service to some and can be exploited by others.  Being
the de facto resource, and lacking a more comprehensive, alternative solution
for relationship identification, the functionality of the PSL has often been
misused to accomplish means beyond its capabilities.  For example, there
is no way to confirm the relationship between two domain names, only
signal that there is or is not a public boundary between the two.
Additionally, there are questions about the scalability, central management,
and third-party management of the PSL as it currently exists.

In terms of specific use cases: Within the realm of email, there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (at some point in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that FQDN can be found.  With respect to the
web, there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the namespace tree.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, equivalence, and
possibly other problems require independent solutions, in which case the
working group will follow that path.  The solutions may or may not involve
changes to the DNS, such as creation of new resource record types; in any
case, all such changes will be incremental only.

This working group will not seek to amend the consuming protocols t

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Murray S. Kucherawy]

On Thu, Jul 17, 2014 at 10:39 AM, John C Klensin  wrote:

> (d) It seems to me that the cases this proposal addresses are
> special enough that a dedicated Extended Status Code would be in
> order.  Instead, the document specifies the highly generic 5.1.2
> (even those the RFC 3463 definition of X.1.2 includes "incapable
> of accepting mail" and "invalid for mail" (which don't mean
> quite the same thing).   Especially since there is not an
> easily-located WG discussion, the document should at least
> explain its choice.
>

If consensus is to register a new code as suggested, one could certainly
help himself to a cloning of the useful parts of
draft-ietf-appsawg-email-auth-codes, now in Last Call.

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

Re: [DNSOP] on "Negative Trust Anchors"

[Murray S. Kucherawy]

> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of 
> Warren Kumari
> Sent: Monday, April 16, 2012 11:55 PM
> To: Livingood, Jason
> Cc: Joe Abley; Nick Weaver; Tony Finch; dnsop; Paul Vixie; Evan Hunt
> Subject: Re: [DNSOP] on "Negative Trust Anchors"
> 
> I think that this is a useful document and is *really* needed to help
> with DNSSEC deployment, and fully support it's publication (especially
> if it comes with examples!)...
> 
> The IETF publishing an RFC on this doesn't mean that folk will be
> forced to use it (and not publishing it doesn't mean that folk won't) -
> - if this were not true, we would have universal adoption of BCP 38,
> everyone would be running v6 and all packets involved in SPAM / DoS
> would have the Evil bit set...

Some of this conversation reminds me of the "X-" debate just wrapping up in 
apps, in that things that are supposed to be temporary often become permanent 
even if we tag them very explicitly as temporary.  In that sense, I'm more 
sympathetic to the "no" side so far, but not enough to object.

Also, a lot of things in apps space like to call out "MUST/SHOULD except if 
local policy says otherwise", and this strikes me as, basically, a kind of a 
local policy tool.  I presume the idea is to describe a mechanism that works 
and is minimally destructive to encourage people away from more broken methods. 
 In that sense, this is the right thing to do.

So if this is going to go forward to publication, I would urge ample 
explanation of why we think this is necessary to document, but also advocate 
strongly in the document that the technique is meant to be a short-term 
solution for a problem that exists during gradual and un-coordinated DNSSEC 
rollout, and that support for it be dropped once DNSSEC has reached critical 
mass.  Or something like that.

-MSK

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