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

[Vladimír Čunát <[e-mail]>]

On 01/11/2021 18.29, Michael StJohns wrote:
>
> 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.
>
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.
>
> 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.
>
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