On Mon, 5 Jul 2021 at 03:11, Mark Andrews <[email protected]> wrote:
>8
>
> 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
>
My current analysis model certainly does not rely upon double-parsing
of the opaque form.
Whatever else we might disagree about, there is one feature we can depend upon.
The devout double-escapologist believes that "standard string
processing" occurs before any SVCB-specific code is reached.
This introduces plenty of weaknesses to be exploited.
1) Chuck in an extra digit
example.com. SVCB 1 foo.example.com. port=1234\053
produces
example.com. IN SVCB ( \# 25 0001 ; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0003 0002 3039 )
instead of the expected error message.
2) Break number parsing
example.com. SVCB 1 foo.example.com. port=1234\078
Argument "1234N" isn't numeric in pack at
blib/lib/Net/DNS/RR/SVCB.pm line 192, <DATA> line 2.
file GLOB(0x556193c89ea0) line 2
at test.pl line 23.
3) Break argument parsing
example.com. SVCB 1 foo.example.com. port=12\04434
SVCB: unexpected number of values for "key3" at
blib/lib/Net/DNS/ZoneFile.pm line 531.
file GLOB(0x559fdbb90d80) line 2
at test.pl line 23.
--rwf
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
