Subject: Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

From: "libor.peltan" <[email-masked]>
Date: Mon, 1 Nov 2021 11:57:06 +0100

Hi,

I'm just not sure if this requested SHOULD->MUST change would actually 
have any consequences.

It still doesn't say anything about what authoritative, and recursive 
servers should do.

The draft's sections about authoritative server behavior are somewhat 
brief, but that may be OK.

In general, they tend to expect that the authoritative server passes 
through any SVCB/HTTPS records without too much verification. Just check 
syntax in order to be able to translate zonefile <--> wire format.

The semantic consistency seems to be expected only between the record 
author and the client, which seems to be OK.

Libor

Dne 31. 10. 21 v 2:03 Mark Andrews napsal(a):
> In AliasMode, records SHOULD NOT include any SvcParams, and
>     recipients MUST ignore any SvcParams that are present.
>
>
> Today we had the following record like this
>
> example.com IN HTTPS 0 . alpn=h2 ipv4hint=192.0.2.1 ipv6hint=2001:DB8:
>
> interpreting this as described leads to “0 .” which indicates
> NO SERVICE OFFERED.  Rejecting this at load time would be much
> safer but the weasel wording of "SHOULD NOT” makes this difficult.
>
> Please make this MUST NOT.
>
> Mark
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Nov 2021 00:30:11 +1100

> On 1 Nov 2021, at 21:57, libor.peltan <[email-masked]> wrote:
> 
> Hi,
> 
> I'm just not sure if this requested SHOULD->MUST change would actually have any consequences.

The primary would refuse to load the record and it would have been corrected.  The primary would refuse to accept in as part of an UPDATE message and return FORMERR.

> It still doesn't say anything about what authoritative, and recursive servers should do.
> 
> The draft's sections about authoritative server behavior are somewhat brief, but that may be OK.
> 
> In general, they tend to expect that the authoritative server passes through any SVCB/HTTPS records without too much verification. Just check syntax in order to be able to translate zonefile <--> wire format.

If priority == 0 && service params != empty then reject the zone.  This is what you are supposed to do on load error according to STD13.  

> The semantic consistency seems to be expected only between the record author and the client, which seems to be OK.

Authoritative servers have been rejecting broken records at load time since RFC 1034 and RFC 1035 where published.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Nov 2021 11:35:29 -0400

This text is a "SHOULD NOT" because there has been some discussion of
potential future uses for SvcParams in AliasMode.  If implementations
follow the current text, this kind of extension can be backwards-compatible.

I agree that the resulting behavior creates a typo hazard for zone
administrators.  Perhaps we could keep the "SHOULD NOT", but add a line
like "Zone file parsers MAY emit a warning"?

---

From: Eric Orth <[email-masked]>
Date: Mon, 1 Nov 2021 11:58:59 -0400

The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present" part.

I don't understand what would be different if the record sender SHOULD
became a MUST.  Recipients wouldn't be able to behave any differently
because they would still need to ignore rather than reject params in order
to preserve compatibility with future supported alias params.  Am I missing
something?

If there's not a big difference either way that I'm missing, I would lean
towards preferring SHOULD because I don't think strong MUST-level rules
should be set when it isn't necessary for the protocol.  The reason to not
set params in an alias record is that they'll be ignored and thus just a
waste of bandwidth, but nothing else bad would happen and it wouldn't limit
the capabilities of the protocol.  Sounds like a SHOULD situation to me.

On Mon, Nov 1, 2021 at 11:36 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 1 Nov 2021 13:29:22 -0400

On 11/1/2021 11:58 AM, Eric Orth wrote:
> because they would still need to ignore rather than reject params in 
> order to preserve compatibility with future supported alias params.  
> Am I missing something?
>
> If there's not a big difference either way that I'm missing, I would 
> lean towards preferring SHOULD because I don't think strong MUST-level 
> rules should be set when it isn't necessary for the protocol.  The 
> reason to not set params in an alias record is that they'll be ignored 
> and thus just a waste of bandwidth, but nothing else bad would happen 
> and it wouldn't limit the capabilities of the protocol. Sounds like a 
> SHOULD situation to me.
>
> On Mon, Nov 1, 2021 at 11:36 AM Ben Schwartz 
> <bemasc=[email-masked]> wrote:
>
>     This text is a "SHOULD NOT" because there has been some discussion
>     of potential future uses for SvcParams in AliasMode.  If
>     implementations follow the current text, this kind of extension
>     can be backwards-compatible.
>
>     administrators.  Perhaps we could keep the "SHOULD NOT", but add a
>     line like "Zone file parsers MAY emit a warning"?

Eric et al -

"SHOULD" and "should" are inherently dangerous as they lead to ambiguity 
and different conclusions from the same data.  Mark's note made me go 
and take a look at this document and simply searching for "should" shows 
a number of problems.

Section 2 - "their definition should specify..." - this is obviously a 
must and is guidance to the IANA for interpreting registrations.  E.g. 
lack of this data has to result in a rejected registration request.

Section 2.1 - "Key names should contain..."  - drop the should as it 
introduces ambiguity.  The BNF is clear this is a MUST and is normative.

Section 2.1 - "...formats for such keys SHOULD use a comma-separated 
list".  This is a semi-reasonable SHOULD, but begs the question of what 
you do if you don't use a comma separated list and adds to the later 
parser complexity if someone chooses something else in a later 
definition.   Guidance such as "Requests for registration of  lists or 
set SvcParamKeys that propose a different format must justify any 
deviation and are subject to rejection." may be appropriate here.

2.4.1 - "all RRs SHOULD have the same mode" - this is satisfactory as 
the next sentence describes what to do if this is not the case.

2.4.1 - " ... SHOULD be given preference..." and "SHOULD apply a random 
shuffle" are not satisfactory as they lead to ambiguity between the 
publisher and the client.  There appears to be no good reason not to 
make both of theses MUST.

2.4.2 - "SHOULD only have a single...." and "SHOULD pick one at 
random".  The first is satisfactory as it's covered by guidance on the 
following sentence.  The second is not as it leads to ambiguity and 
there appears to be no good reason not to make it a MUST.  Among other 
things, you really don't want someone to come along later and decide 
that because 75% of the clients pick the first one, they can game the 
system by manipulating the RRSet.

2.4.2 "TargetName SHOULD NOT..." - this is unsatisfactory as it doesn't 
explain what a client should do if it receives such a beast.  This needs 
client guidance and the client MUST ignore such a record.  Also are 
there other pathological cases where you might end up with loops 
indirectly?  If so, guidance for the client on how to detect such cases 
needs to be given.

2.4.2. "...records SHOULD NOT..." is satisfactory as it describes how a 
client resolves receiving such records.

2.4.2 "....zone owners SHOULD NOT ... " should be lower case as humans 
are not protocol elements.  This is operational guidance rather than 
protocol guidance.

2.4.3 "...implementations SHOULD enforce..." - this one is iffy as I 
don't think "zone file implementations" is a consistent term of art.  
You could place the enforcement with the server - e.g. "SHOULD refuse to 
serve inconsistent ServiceMode RRs"? Or perhaps with the DNSSEC signing 
tool?

3 - "SVCB-optional clients SHOULD issue in parallel..." - is 
satisfactory because it describes client behavior and refers to a 
section the describes the reasoning.  However, is "in parallel" here a 
term of art?   "in conjunction" may be a better phrasing.

3 - "Clients SHOULD try higher-priority..." is mostly satisfactory, but 
needs to at least explain the implications of not going in strict 
priority mode.   However, there appears to be no good reason not to make 
this a MUST - see back to the comment 2.4.1 - "SHOULD be given 
preference" with respect to ambiguity.

3. "...client SHOULD attempt..." - is not satisfactory as it doesn't 
describe why you should or shouldn't do this and leaves the implementer 
guessing.

3.1 - "...client SHOULD abandon..." is not satisfactory as the text 
really describes a MUST.  E.g. security errors are either permanent 
failure, or transient with a retry, they are never to be ignored.  
Reading this suggests that ignoring is sufficient.  If you leave 
"SHOULD", then clarify what not abandoning the connection means - e.g. 
retrying it for some amount of times, but never accepting falsified data.

3.1. "...it SHOULD apply..." - not satisfactory as the text describes a 
MUST.  There is no good reason and every reason not to treat the SVCB 
validation differently than an A/AAAA response.

3.1. "....client SHOULD fall back..." - not satisfactory as the text 
fails to describe what happens if you don't fall back.  At the least 
this needs a discussion of why falling back makes sense and its impact 
on security.

3.2  "...proxies SHOULD arrange..." is not satisfactory because of the 
"or" clause ambiguity and a lack of implementer guidance on which 
choices make sense in which situations.

___________________   pausing here to do other work 
________________________________

In general, the document substantially overuses SHOULD clauses. I'd 
recommend the authors and participants take a harder look at each 
SHOULD, and, if they want to leave a SHOULD in place, ensure they've 
described the options sufficiently for an implementer to make an 
informed decision.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 1 Nov 2021 13:46:12 -0400

Eric et al -

Mike

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 3 Nov 2021 14:54:35 +0100

On 01/11/2021 18.29, Michael StJohns wrote:
> list".  This is a semi-reasonable SHOULD, but begs the question of 
> what you do if you don't use a comma separated list and adds to the 
> later parser complexity if someone chooses something else in a later 
I agree with what you write about these occurrences.  Generally I hope 
that it's not too late to make similar changes.

> 2.4.1 - " ... SHOULD be given preference..." and "SHOULD apply a 
> random shuffle" are not satisfactory as they lead to ambiguity between 
> the publisher and the client.  There appears to be no good reason not 
> to make both of theses MUST.
>
In these two points it should (heh) remain clear that there are 
situations where the clients won't exactly do this - e.g. if some 
protocol is not supported by the client or if it can assume that some of 
the RRs probably would not lead to success (based on recent connections 
attempts).  In some later parts there is text for these fallbacks, so it 
probably will remain clear, though I think would be better to reflect it 
in the above formulations *if* they get strengthened to MUST.

> 2.4.2 "TargetName SHOULD NOT..." - this is unsatisfactory as it 
> doesn't explain what a client should do if it receives such a beast.  
> This needs client guidance and the client MUST ignore such a record.  
> Also are there other pathological cases where you might end up with 
> loops indirectly?  If so, guidance for the client on how to detect 
> such cases needs to be given.
>
> 2.4.2. "...records SHOULD NOT..." is satisfactory as it describes how 
> a client resolves receiving such records.
>
I think I agree with these two points, too.

I don't have a strong opinion on the following comments about section 
3.  I don't feel qualified for such details around HTTPS and similar 
clients.

On the other hand, I carefully re-read all resolver-related bits (mainly 
sections 4.x, 5.2, 13, 14), and there the requirements language seems 
good to me.

Perhaps I'd like to note just this paragraph from 13. security 
considerations:

> Clients MUST ensure that their DNS cache is partitioned for each local 
> network, or flushed on network changes, to prevent a local adversary 
> in one network from implanting a forged DNS record that allows them to 
> track users or hinder their connections after they leave that network.
Does this imply that if a DNS *resolver* is running on a device capable 
of "switching networks" (e.g. laptop), it MUST ensure this DNS cache 
handling?  I'm not aware of such standards-track RFC requirements so 
far, and it's reaching a bit further than just these new RR types.  Note 
that the actual client (like web browser) most likely won't be able to 
control this (optional) layer of local DNS cache, though there are 
always options like attempting some DNS bypass (e.g. via DoH, most 
popularly).

--Vladimir | knot-resolver.cz