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

[Willem Toorop <[e-mail]>]

Op 22-03-2021 om 15:50 schreef Ben Schwartz:
> On Mon, Mar 22, 2021 at 5:41 AM Willem Toorop <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     But what about the keys in the "mandatory" SvcParam? Should they be
>     sorted automatically? Or should the parser produce an error if they are
>     not sorted? Currently both both Net::DNS and ldns sort them for you.
> 
> 
> The draft says:
> 
>    The presentation "value" SHALL be a comma-separated list
>    (Appendix A.1) of one or more valid SvcParamKeys, either by their
>    registered name or in the unknown-key format (Section 2.1).  Keys MAY
>    appear in any order, but MUST NOT appear more than once.
> 
> and
> 
>    In wire format, the keys are represented by their numeric values in
>    network byte order, concatenated in ascending order.
> 
> Hopefully that's clear enough.

Sure, so this:

x8.example.     3600    IN      SVCB    16 foo.example.org. (
        key853="test" key123="some other text"
        ipv4hint=192.0.2.1 mandatory=ipv4hint,alpn,key853,key123
        alpn=h2,h3-19 ipv6hint=2001:db8::1.2.3.4,2001:db8::
	)

is equivalent with

x8.example.	3600	IN	SVCB	( \# 115 0010
	03666f6f076578616d706c65036f7267 00	; foo.example.org.
	0000 0008 00010004007b0355
	0001 0009 0268320568332d3139
	0004 0004 c0000201
	0006 0020 20010db8000000000000000001020304
	          20010db8000000000000000000000000
	; key123=...
	007b 000f 736f6d65206f746865722074657874
	; key853=...
	0355 0004 74657374
	)

Would be good to have that in a test vector ;).

>     What if keys appear double in the "mandatory" SvcParam? Should the
>     parser produce an error or remove the doubles? Currently ldns removes
>     them, but Net::DNS produces and error.
> 
> 
> I think authoritative servers "SHOULD" enforce the zone file
> requirements to the extent possible, but responsibility ultimately lies
> with the zone owner.

Excellent! How SHOULD it enforce? By failing to load or by fixing.
Most here tilt to *failing to load*, so these should fail to load:

; Forbidden key in mandatory
x9.example.	3600	IN	SVCB	0 . mandatory=key0
x10.example.	3600	IN	SVCB	( \# 9 0000 00
	0000 0002 0000
	)

; Double key in mandatory
x11.example.	3600	IN	SVCB	0 . (
	ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv4hint,alpn,key4
	)
x12.example.	3600	IN	SVCB	( \# 28 0000 00
	0000 0006 000100040004
	0001 0003 026832
	0004 0004 c0000201
	)

; Key without SvcParam in mandatory
x13.example.	3600	IN	SVCB	0 . (
	ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv6hint,alpn,key4
	)
x14.example.	3600	IN	SVCB	( \# 28 0000 00
	0000 0006 000100040006
	0001 0003 026832
	0004 0004 c0000201
	)

I think it would be good to have this added to the test-vectors appendix.

Should this fail to load too?

; Wireformat has SvcParams unordered
x15.example.	3600	IN	SVCB	( \# 26 0000 00
	0004 0004 c0000201
	0001 0003 026832
	0000 0004 00010004
	)

or am I stretching it now...

Cheers,
-- Willem

> 
>     What if keys that may not appear in "mandatory" (like key0 or mandatory
>     itself) appear in the "mandatory" SvcParam? Should they be removed
>     automatically or should they produce and error.
> 
>     What if keys that are listed in "mandatory" do not appear in the RR.
> 
> 
> The draft says:
> 
>    For self-
>    consistency (Section 2.4.3), listed keys MUST also appear in the
>    SvcParams.
> 
> and (in Section 2.4.3)
> 
>    Zone-file implementations
>    SHOULD enforce self-consistency.  Clients MUST reject any RR whose
>    recognized SvcParams are not self-consistent, and MAY reject the
>    entire RRSet.
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>