> On 2 Jul 2021, at 17:00, Dick Franks <[email protected]> wrote:
>
> Feedback on SVCB draft 06 as requested.
>
> On Mon, 28 Jun 2021 at 02:39, Tim Wicinski <[email protected]> wrote:
>> 8
>>
>> The chairs would like the WG to review these changes, and give us some
>> feedback.
>
>
> 6.1. "alpn" and "no-default-alpn"
>
> The presentation "value" SHALL be a comma-separated list
> (Appendix A.1) of one or more "alpn-id"s. Zone file implementations
> MAY disallow the "," and "\" characters instead of implementing the
> "value-list" escaping procedure, relying on the opaque key format
> (e.g. "key1=\002h2") in the event that these characters are needed.
>
> If implementations MAY ignore the escape mechanism Appendix A.1 completely,
> there is little incentive to do otherwise.
>
> However, implementations that do not exercise that option expose themselves
> to a litany of potential security weaknesses:
Not really, opaque form is easily recognised and has its own processing
rules.
> These range from argument strings which produce corrupt content:
>
> example.com. SVCB 1 example.com. ipv6hint="2001:db8:5c:5c5c::1"
>
> not ok 29 - SVCB ipv6hint shrinkage
> # Failed test 'SVCB ipv6hint shrinkage'
> # at test.pl line 149.
> # got: 'example.com. IN SVCB ( \# 33 0001
> 076578616d706c6503636f6d00 ; example.com.
> # 0006 000e 20010db8005c0000000000000001 )'
> # expected: 'example.com. IN SVCB ( \# 35 0001
> 076578616d706c6503636f6d00 ; example.com.
> # 0006 0010 20010db8005c5c5c0000000000000001 )’
Opaque key form isn’t subject to double parsing despite the hint6 having
commas in the presentation form. That’s about the only way you could be
seeing that difference. The opaque key form knows nothing about the
internal structure, you don’t double parse opaque key form. It’s
ipv6hint="2001:db8:5c:5c5c::1”
or
ipv6hint=2001:db8:5c:5c5c::1
or
key6=“ \001\012\139\000\\\\\\\000\000\000\000\000\000\000\001”
If you get keyXXXX or keyXXX=“value” you don’t do any second steps.
> to crafted RRs which silently subvert the parsing process in undesirable ways:
>
> example.com. SVCB 1 example.com.
> ipv4hint="92.48.55.48,92.48.56.53,92.48.54.54,92.48.56.50"
>
> not ok 30 - SVCB ipv4hint subversion
> # Failed test 'SVCB ipv4hint subversion'
> # at test.pl line 149.
> # got: 'example.com. IN SVCB ( \# 23 0001
> 076578616d706c6503636f6d00 ; example.com.
> # 0004 0004 46554252 )'
> # expected: 'example.com. IN SVCB ( \# 35 0001
> 076578616d706c6503636f6d00 ; example.com.
> # 0004 0010 5c3037305c3038355c3036365c303832 )'
Again opaque key form is just that.
> D.3. Failure cases
>
> The following additional test vectors are listed below the
> corresponding requirement.
>
> [9, para 1]
> In presentation format, the value is a [SINGLE] ECHConfigList encoded
> in Base64.
>
> example.com. SVCB 1 foo.example.com. ech ; missing argument
> example.com. SVCB 1 foo.example.com. ech=b25l,dHdv ; multiple arguments
>
> [6.2, para 2]
> The presentation "value" of the SvcParamValue is a [SINGLE] decimal
> integer between 0 and 65535 in ASCII.
>
> Note: Character set cannot be specified here; it is whatever the
> platform or zone file uses (EBCDIC for example).
>
> example.com. SVCB 1 foo.example.com. port=1234,4678 ; multiple arguments
>
> [6.1, para 6]
> When "no-default-alpn" is specified in an RR, "alpn" must also be
> specified in order for the RR to be "self-consistent" (Section 2.4.3).
>
> example.com. SVCB 1 foo.example.com. (
> no-default-alpn ; without expected alpn
> )
>
> D.2. Service form
>
> The test vector for unsorted SvcParams would be better expressed using
> numerical keys and disentangled from extraneous clutter.
>
> example.com. SVCB 1 foo.example.org. ( ; unsorted SvcParam
> keys
> key23609 key23600 mandatory=key23609,key23600
> )
>
> --rwf
>
>
>
>>
>> ---------- Forwarded message ---------
>> From: <[email protected]>
>> Date: Wed, Jun 16, 2021 at 10:29 AM
>> Subject: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
>> To: Tim Wicinski <[email protected]>
>>
>>
>>
>> A new version (-06) has been submitted for draft-ietf-dnsop-svcb-https:
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.txt
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.html
>>
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>>
>> Diff from previous version:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06
>>
>> IETF Secretariat.
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
