Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Erik Nygren]

There seem to be two topics:

1) Victor's clarification makes sense, although the wording is a little
awkward and perhaps we can improve that sentence.
The section was already implying that meaning (ie, that the fallback
addition of the QNAME was for the AliasMode case)
but clarifying this in a more normative way seems worthwhile and not a
technical change.
I'd propose we refine this PR and incorporate it as the "clarifying
sentence" that Warren was willing to accept.

2) There is the issue of whether attrleaf labels are valid owner names for
A/ records.
This document does not seem like the place to land that, and it seems
like it may be open for interpretation
as different implementations may have interpreted it differently.  If
anything, we might add a non-normative sentence like:

   "Some implementations may not allow A or  records on names
starting with an underscore
due to various interpretations of RFCs. This could be an
operational issue when the TargetName contains an attrleaf label,
as well as using an TargetName of "." when the owner name contains
an attrleaf label."

   This wouldn't be a normative change but just an operational warning ---
would this be acceptable to include at this stage?
   Further clarification of this seems worth a draft in its own right since
the existing RFCs are inconsistent
   on this topic and there is room for multiple interpretations, as shown
in some implementations.



On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman  wrote:

> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 
> wrote:
> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
> > is the unaltered (attrleaf prefixed) starting point.  The current
> > meaning was not intended.  If the edit can be made without any
> > major process, just a note to the RFC editor, it'll save errata,
> > and possible confusion later.
>
> A technical change made after the IESG review requires, at a minimum,
> another IESG review. The IESG could ask for another IETF review, if they
> want. It's up to Warren, the responsible AD, to decide if that's "major
> process".
>
> --Paul Hoffman
>
> ___
> 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] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni  wrote:
> This is a bug fix, the proposed behaviour makes no sense when $QNAME
> is the unaltered (attrleaf prefixed) starting point.  The current
> meaning was not intended.  If the edit can be made without any
> major process, just a note to the RFC editor, it'll save errata,
> and possible confusion later.

A technical change made after the IESG review requires, at a minimum, another 
IESG review. The IESG could ask for another IETF review, if they want. It's up 
to Warren, the responsible AD, to decide if that's "major process". 

--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] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote:

> > If no AliasMode record was processed, then $QNAME would be the
> > origin name PLUS the prefix(es) of type attrleaf ( underscore
> > thingies). Those won't be legitimate A/ owner names (and
> > shouldn't exist), and if a client did that it would be harmful (to
> > the client), at least a little bit harmful (trying something that
> > won't work.)
> 
> If this proposed change is only for something that is a bit harmful to
> the client (trying something that won't work), then I don't think this
> reaches the bar for making a change after IETF and IESG evaluation.
> The amount of process work that is necessary to make this technical
> change far outweighs the advantage to clients who are unaware of the
> problem that this thread has exposed.

This is a bug fix, the proposed behaviour makes no sense when $QNAME
is the unaltered (attrleaf prefixed) starting point.  The current
meaning was not intended.  If the edit can be made without any
major process, just a note to the RFC editor, it'll save errata,
and possible confusion later.

The document is on hold anyway, the fix is elementary and obvious.  I am
not a process wonk, I'm happy to let those who are go at it.  With the
suggested change made, I'm done.

-- 
Viktor.

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

[DNSOP] Announcing the ICANN DNS Symposium 2022 and solicitation of presentation proposals

[Matt Larson]

[cid:8771DFF1-513C-40BC-B5C7-093C04815944]

(With apologies for the duplicate message, sending again without line-break 
issues.)

Dear colleagues,

ICANN’s Office of the Chief Technology Officer is pleased to announce that the 
fifth ICANN DNS Symposium (IDS 2022) will be held on 15-16 November 2022 in 
Brussels, Belgium. IDS 2022 will be co-located with the first ever IANA 
Community Day on 17 November 2022. A workshop coordinated by eco on DNS abuse 
topics will also be held on 17-18 November 2022 with further information 
forthcoming.

The theme for IDS 2022 is “Examining the effects of both centralization and 
diversification in the DNS”.

There has been a move toward centralization in the Domain Name System (DNS): 
the devices of more than 20% of Internet users are configured to use public 
resolvers, according to some studies; a small set of registry service providers 
are responsible for a large set of top-level domains; an attack against a 
single service provider’s infrastructure can affect a large percentage of 
Internet users. At the same time, there are more public resolver services and 
more top-level domains than ever. This prompts the question, “Is the DNS overly 
centralized or adequately diversified?” ICANN invites speakers to present 
topics on centralization and diversification in the DNS. Presentations could 
include measurements and fact-based predictions, discussions about risk 
mitigation and scalability in relation to either greater or lesser 
centralization, greater or lesser diversity, or both.

We are soliciting proposals for presentations. Please send a one-paragraph 
description of your proposed topic to 
ids-propos...@icann.org by 14 October 2022. We 
will publish a preliminary agenda by 1 November 2022.

IANA Community Day is a half-day workshop focused on key technical evolution 
projects within IANA relating to the DNS. Topics will include a discussion of 
how to perform a DNSSEC algorithm rollover for the DNS root zone, and reviewing 
and updating the TLD technical requirements for root zone changes. TLD 
managers, DNS experts, and other interested parties are encouraged to attend.

For more information on both IDS and IANA Community Day, including schedule, 
venue and registration information, please visit https://www.icann.org/ids.

Thank you and we hope to see you there!

Matt Larson
VP of Research
ICANN Office of the CTO

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Sep 7, 2022, at 8:29 PM, Brian Dickson  wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the authority
> > endpoint's port number, and no SvcParams.  (This endpoint will be
> > attempted before falling back to non-SVCB connection modes.  This ensures 
> > that
> > SVCB-optional clients will make use of an AliasMode record whose TargetName 
> > has
> > A and/or  records but no SVCB records.)
> 
>> What happens under the current wording, before the addition above? That is, 
>> if no AliasMode record was processed, is the addition along the lines of 
>> "you can only add this if you have it, and if no AliasMode record was 
>> processed, you don't have it"? Or does the addition solve the problem "if no 
>> AliasMode record was processed, the thing you append will be harmful"?
>> 
> Yes.
> 
> If no AliasMode record was processed, then $QNAME would be the origin name 
> PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be 
> legitimate A/ owner names (and shouldn't exist), and if a client did that 
> it would be harmful (to the client), at least a little bit harmful (trying 
> something that won't work.)

If this proposed change is only for something that is a bit harmful to the 
client (trying something that won't work), then I don't think this reaches the 
bar for making a change after IETF and IESG evaluation. The amount of process 
work that is necessary to make this technical change far outweighs the 
advantage to clients who are unaware of the problem that this thread has 
exposed.

A draft with a discussion of this one problem would go a long way to alerting 
client authors of this problem. The same draft could also talk about the other 
issues that sparked this larger thread. Such a draft is not limited to "change 
this sentence to that": it could have a discussion of the various things that 
client developers are discovering.

--Paul Hoffman

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

Re: [DNSOP] Doodle poll for DNSOP WG interim week 26-30 September 2022

[Benno Overeinder]

Hi all!

Gentle reminder to fill in the Doodle poll.

We will close the poll today, end-of-business day.

Best,

Suzanne, Tim and Benno

On 31/08/2022 19:56, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting for 2022 in the week 
of 26-30 September.


The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim 
meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/e9QDWqBe

The options for the time slots are a compromise for CEST/EDT/PDT/JST.

We will close the Doodle poll at the end of Tuesday 6 September.


Best regards,

Suzanne, Tim and Benno

___
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