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

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote:

> On Thu, Sep 8, 2022, at 13:29, Brian Dickson 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.)
> 
> (FWIW, I had trouble parsing this last bit.)
> 
> Can the AliasMode record reference a name that includes attrleaf
> labels, such that this could be as non-functional as using the
> attrleaf-laden original $QNAME?

It can, but that would be a bad idea in general, unless one was
absolutely sure that there's a ServiceMode record at the target,
and that's all that the AliasMode record is for.  And if A/
records for the qname fail to be discovered should a fallback
be attempted, all's well, since none were expected.

This touches on the RFC1123 question, which I think the WG did not want
to tackle (as too late for a substantive change) at this time.

But in any case, wheh there were no AliasMode records, and we're
using SVCB attrleaf prefixes for the original $QNAME, there really
was no intention to try that $QNAME as a fallback, as confirmed by
Ben (IIRC upthread at some point).

-- 
Viktor.

___
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)

[Brian Dickson]

On Wed, Sep 7, 2022 at 9:09 PM Martin Thomson  wrote:

>
>
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson 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.)
>
> (FWIW, I had trouble parsing this last bit.)
>
> Can the AliasMode record reference a name that includes attrleaf labels,
> such that this could be as non-functional as using the attrleaf-laden
> original $QNAME?
>

It can, but that's a different case than the original thing (which will
always have them). Changing the text to handle that would be more
words/sentences than what Warren wants.

Brian
___
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)

[Martin Thomson]

On Thu, Sep 8, 2022, at 13:29, Brian Dickson 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.)

(FWIW, I had trouble parsing this last bit.)

Can the AliasMode record reference a name that includes attrleaf labels, such 
that this could be as non-functional as using the attrleaf-laden original 
$QNAME?

___
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)

[Brian Dickson]

On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman  wrote:

> On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni 
> 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 instead of the initial $QNAME, the origin name (and port) are added to
the end of the list, that is literally the exact same thing as non-SVCB
connection mode, so adding that to the list would be moot.

Brian
___
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 5:48 PM, Viktor Dukhovni  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"?

--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]

> Yes, and catching COVID on Friday didn't help.  Will attempt to send a
> pull request for just the $QNAME fix shortly.

Making a pull request does not preclude also Cc'ing the list.  Which
is what I'm doing now and was planning to do in any case:

https://github.com/MikeBishop/dns-alt-svc/pull/399/files

--- a/draft-ietf-dnsop-svcb-https.md
+++ b/draft-ietf-dnsop-svcb-https.md
@@ -532,12 +532,13 @@ noted in {{client-failures}} and {{ech-client-behavior}}).

 SVCB-optional clients SHOULD issue in parallel any other DNS queries that might
 be needed for connection establishment if the SVCB record is absent, in order 
to minimize delay
 in that case and enable the optimizations discussed in {{optimizations}}.

 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.)

-- 
VIktor.

___
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 Wed, Sep 07, 2022 at 03:36:16PM -0700, Warren Kumari wrote:

> I chatted with Viktor Dukhovni late last week, and he promised us a
> sentence to solve all that ails us… or, at least, a simple, clear, concise
> sentence which only clarifies what appears to have been intended.
> 
> I suspect that US Labor day vacation got in the way, but I hope to
> have it soon.  If not, I think we just stick with the original - 'tis
> not perfect, but all can be fixed in a -bis[0].

Yes, and catching COVID on Friday didn't help.  Will attempt to send a
pull request for just the $QNAME fix shortly.

-- 
Viktor.

___
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)

[Warren Kumari]

I chatted with Viktor Dukhovni late last week, and he promised us a
sentence to solve all that ails us… or, at least, a simple, clear, concise
sentence which only clarifies what appears to have been intended.

I suspect that US Labor day vacation got in the way, but I hope to have it
soon.
If not, I think we just stick with the original - 'tis not perfect, but all
can be fixed in a -bis[0].

W
[0]: Quick, someone put that on a t-shirt…



On Wed, Sep 07, 2022 at 5:20 PM, Ben Schwartz  wrote:

> As I noted earlier, changing the non-SVCB fallback recommendation to "MAY"
> would nominally make HTTPS-record deployment riskier.  I'm inclined to take
> the current approach (encouraging fallback when it is safe) for now, and
> perhaps revisit this question in a few years if operational experience
> shows it to be unnecessary.
>
> On Wed, Aug 31, 2022 at 11:00 PM Tommy Pauly  wrote:
>
> I don’t personally find this proposal to be an improvement for clarity.
>
> The fact that a client is SVCB-optional means, somewhat by definition,
> that they allow not using the SVCB results. Saying that the client “MAY”
> doesn’t really help; it’s the very definition of what SVCB-optional is. If
> the client doesn’t use non-SVCB connection modes at that point, then it is
> SVCB-reliant.
>
> Listing out the details of what a non-SVCB connection does (not using the
> information from the SVCB record) also seems redundant. It is more accurate
> to just say “don’t use anything from SVCB if SVCB didn’t work” rather than
> trying to list out what all of those details might be.
>
> Tommy
>
> On Aug 31, 2022, at 4:13 PM, Brian Dickson 
> wrote:
>
> So, here is my suggestion, for "a sentence (or possibly two) which only
> clarify what is already written?":
>
> In section 3:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
> (The original didn't use RFC 2119 language, but the list of failure modes
> in 3.1 leads to "MAY" being the most appropriate choice.)
>
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis
> document? The day of RFC publication? I'd like to start that as soon as
> possible, while everything is still fresh.)
>
> Brian
>
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:
>
>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson  com> wrote:
>
> Here are some proposed text changes, per Warren's invitation to send text:
>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)
>
> In section 3, the following changes are proposed; they introduce a new
> term LASTNAME to be used to disambiguate the $QNAME reference so as to
> remove ATTRLEAF prefixes from the appended target:
>
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the

Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Ben Schwartz]

I believe the proposed change here is moot.  The point of the current "MUST
NOT" is just a reminder that this logic does not require doing anything
unsafe.  A DNSSEC signature on the HTTPS record would not enable any
substantial improvements to the pseudo-HSTS upgrade.

Also, HTTP specifications generally do not rely on DNSSEC.  If there is
appetite for exploring possible enhancements to HTTP that rely on DNSSEC, I
think this would be better addressed in a general "DNSSEC-Enhanced HTTP"
document.  (However, I think it would not be wise to publish such a
document until such time as end-to-end DNSSEC is reasonably prevalent in
the HTTP ecosystem.)

On Wed, Aug 31, 2022 at 6:40 PM Eric Orth  wrote:

> Does any HTTP client not follow 307 redirects if received over cleartext?
> This feels to me like a purely theoretical situation.  I'm not opposed to a
> bis making the trust in the HSTS feature be treated more similarly to
> receiving the 307 over HTTPS when DNS is protected, but I also wouldn't
> consider this important enough on its own to adopt a bis.
>
> On Wed, Aug 31, 2022 at 6:22 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Aug 31, 2022 at 10:43 AM Eric Orth > 40google@dmarc.ietf.org> wrote:
>>
>>> I'm not sure what exactly is being changed or clarified with this
>>> suggestion.  Section 9.5 already applies at SHOULD-level, whether
>>> cryptographically protected or not and whether the received records were
>>> AliasMode or ServiceMode.
>>>
>>
>> The text in 9.5 has some language that is actually NOT at the SHOULD
>> level:
>>
>>Because HTTPS RRs are received over an often-
>>insecure channel (DNS), clients MUST NOT place any more trust in this
>>signal than if they had received a 307 (Temporary Redirect) response
>>over cleartext HTTP.
>>
>>
>> That's what the suggestion is making an effort to strengthen, under
>> specific conditions (e.g. cryptographically protected HTTPS records
>> received).
>>
>> The current 9.5 text quoted above, is placing MUST NOT guidance,
>> independent of whether the records were cryptographically protected.
>>
>> I'm thinking it would be better to fix the quoted language above, in a
>> -bis document, if the suggested text isn't acceptable as an update to the
>> about-to-be-published draft.
>>
>> The logic used to reach that MUST NOT is suspect, IMHO.
>> The main non-requirements on DNSSEC (i.e. that HTTPS does not require it)
>> are then turned into an "assume all DNS responses are not cryptographically
>> protected" inferentially.
>>
>> It would be better guidance to instruct clients to use appropriate levels
>> of trust, on signed vs unsigned DNS, and/or DNS received over encrypted
>> transports.
>>
>> I also think the guidance would be more precise if the encrypted
>> transport were not lumped together with the signed content.
>> Also something for a potential -bis or best practice document.
>>
>> Brian
>>
>>
>>> On Wed, Aug 31, 2022 at 5:43 AM Martin Thomson 
>>> wrote:
>>>
 On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
 > One additional suggested addition to the end of section 3.1 is:
 >>If DNS responses are cryptographically protected, and at least
 >>one HTTPS AliasMode record has been received successfully,
 >>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
 >>even when reverting to non-SVCB connection modes. Clients
 >>also MAY treat resolution or connection failures subsequent
 >>to the initial cryptographically protected AliasMode record
 >>as fatal.
 > [Brian's note: this last would provide some guidance to implementers
 of
 > clients: a signed HTTPS AliasMode record is a strong signal that the
 > DNS operator is discouraging fallback, albeit at a "MAY" level.]
 >
 > NB: The 2.4.3 change could be removed as it is mostly independent, as
 > could the last addition to 3.1.
 > The 1.2 change is very minor, is not too important but presents a
 > succinct clarification on the hostname vs domain name thing.
 > The 2.4.2 change and section 3 changes together are fixes for the
 > prefix/no-prefix issue (which was basically a scrivener's error, and
 > does not change the semantics at all.) They should stay or go as one
 > unit.

 I somewhat like this change, but I would generalize to receiving any
 signed HTTPS record during resolution, rather than limiting it to 
 AliasMode.

 That said, it is somewhat gratuitous.  I'd want it standardized if that
 was what was expected, but I'd prefer to defer that to an
 extension/follow-up.

 (In case you hadn't guessed, I tend to agree with those arguing for no
 change to the spec.)

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

>>> ___
>>> DNSOP mailing 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Hugo Salgado]

On 20:55 05/09, Shumon Huque wrote:
> > > I'm thinking of a (broken) nameserver that responds to NSs queries with
> > > NXDOMAIN (but does answer to other types)[1]. Is that a positive
> > > response, which should be cached with an authoritative data ranking?
> >
> 
> We cover this case in the 3rd paragraph of section 3 with the following:
> 
>   " ... that there are
>   number of nameservers in the field that (incorrectly) fail to
>   answer explicit queries for NS records, and thus the revalidation
>   logic may need to be applied lazily and opportunistically to deal
>   with them."
> 
> Applying the logic "opportunistically" means that the resolver falls back to
> using the delegation information in the referral from the parent. We should
> make that clearer in the draft.
> 

Thanks Shumon.
I've just read the new sentence in the third bullet of section 3,
in the new -03 draft version, and it works perfectly for me!

Thanks again for the clarification.

Hugo



signature.asc
Description: PGP signature
___
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]

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