On Tue, May 11, 2021 at 9:41 AM Dick Franks <rwfra...@gmail.com> wrote:
> All, > > As part of a side discussion, I was admonished for my rather flippant > approach to a significant security issue and failure to explain > clearly how it manifests itself.. > > On Sun, 9 May 2021 at 13:01, Dick Franks <rwfra...@gmail.com> wrote: > >8 > > > > Pre-processing of '\\,' into the RFC1035 standard '\,' is > > superficially attractive, but also fraught with danger. > > > > A parser could have some fun with this one: > > > > $ORIGIN example.com > > @ SVCB 1 foo > > key6="\032\001\013\184\000\000\000\000\000\000\000\000\\\\,\000" > > ; a.k.a. ipv6hint=2001:db8::5c5c:2c00 > > > > Although a few sharp-eyed people recognised the security implications > immediately, I realise that I should have included the broken result > to illustrate the problem more clearly. > > example.com. IN SVCB ( \# 38 0001 ; 1 > 03666f6f076578616d706c6503636f6d 00 ; foo.example.com. > 0006 000f 20010db800000000000000005c2c00 ) > > instead of the expected: > > example.com. IN SVCB ( \# 39 0001 ; 1 > 03666f6f076578616d706c6503636f6d 00 ; foo.example.com. > 0006 0010 20010db800000000000000005c5c2c00 ) > > Observe that the IPv6 address is shortened to 15 octets. > I'm not sure what the concern is here, but Section 2.1 of the current draft [1], which specifies the parsing behavior in this case, simply says that the value in this form is a char-string. There is no mention of commas anywhere in that section, so any special handling of commas is clearly incorrect. (Previous versions of the draft have long specified the same behavior, with only editorial adjustments.) [1] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-zone-file-presentation-form
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
