Re: [Add] DNR's SvcParams encoding

[Erik Nygren <[e-mail]>]

I was also assuming this would be the wire format and am surprised that it
is presentation format (which was meant to just be in human-edited zone
files or other serializations).  I also suspect it was missed due to
referencing the section number without a description of which section so
readers jumped to the conclusion of which seemed obvious to them.  (eg,
wire format as being the obvious encoding for something on the wire.)

Much of the presentation format encoding is also specific to
representations in DNS zone files.  It took enough iterations to handle all
of the corner-cases around escaping and encoding, with some of that
referencing how DNS zone files assume things will be in presentation
format, that using presentation format on the wire is going to open up a
ton of opportunities for interop issues and bugs.  Even the section now
covering this ("Decoding text in zone files") is about zone files.

Lots of ambiguity issues start showing up if we include the presentation
format, as well as interop issues which are primarily addressed through the
wire format but not as clearly in the presentation format.  Some of these
also open up potentials for security vulnerabilities.

If we were to expect clients to interop by sending messages in presentation
format there are likely sets of design and security considerations which
we'd need to address which aren't addressed in the draft(s).

As an example, that "key1=\1522" and "alpn=h2" are the same thing and both
valid seems like a horrible thing to have to put into DHCP clients.

I'd be strongly in-favor of clarifying/fixing this to use wire format even
if it means delay in getting the cluster out.  (We should probably have the
drafts be clear that this is "wire format" in their text as well, not just
give a section reference.)

     Erik



On Sat, Sep 30, 2023 at 10:08 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

> My impression is that the blob should be a binary-encoded blob. The DHCP
> server can be provisioned with the same data as a DDR server for these
> properties, and doesn’t require the router understanding the specific
> values contained within the blob.
>
> Regarding implementations, my impression is that we don’t yet have
> deployments of clients using this, so it’s not like this is too late. It
> also seems from this list that the majority of people assumed this was wire
> format, not string format. This does look like a bug in the spec.
>
> Tommy P
>
> On Sep 30, 2023, at 1:01 AM, [e-mail] wrote:
>
> 
>
> Hi Tommy,
>
>
>
> I have no problem to make a change if there is a bug, but it isn’t for
> this specific case.
>
>
>
> The rationale why we had 2.1 is to avoid requiring updating DHCP servers
> (or routers for RA) when new service parameters are defined. With the
> current approach, there is no need for server implementation to map a
> configured service parameter to an assigned IANA integer value in order to
> send it on the wire. The server just supplies the blob to clients (modulo
> validation in 2.1) which pass it to a DNS library.
>
> I also have a concern that we will be breaking existing implems such as
> the one I already cited.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Add <[e-mail]> *De la part de* Tommy Jensen
> *Envoyé :* vendredi 29 septembre 2023 20:58
> *À :* Tommy Pauly <tpauly=[e-mail]>; Ben Schwartz
> <bemasc=[e-mail]>; ADD Mailing list <[e-mail]>
> *Cc :* Chris Box <[e-mail]>
> *Objet :* Re: [Add] [EXTERNAL] Re: DNR's SvcParams encoding
>
>
>
> Merging forks.
>
>
>
> Med, I did the archaeology and also saw this was here since -01. I’m going
> to admit my part in this as a supporter of the wire format, both as a
> co-author and as a client implementor. I did not read carefully enough and
> assumed the reference to SVCB enabled the wire format, not the presentation
> format, given the reuse of parsers between DNR and DDR, along with the
> concerns Ben is likely referring to with presentation format on the wire.
>
>
>
> Anyway, the point isn’t that this is a new objection, just a failure on us
> collectively in determining that we ended up addressing what we thought was
> there. I’m as big a fan of DNR as the next person, though I now wish we had
> gotten to our prototype sooner.
>
>
>
> I don’t know what the process is for making this change, but even if it
> means pulling it back to the WG, I think we need to fix this before we are
> all stuck with 1) using text format on the wire, 2) all violating RFC, 3)
> doing an immediate -bis. I say that with all the pain of a co-author of two
> docs in this AUTH48 cluster, which I know others share. Silver lining: at
> least we do have time to discuss this, even if at the 11.99th hour.
>
>
>
> Thanks,
>
> Tommy
>
>
>
>
>
> *From:* Add [e-mail] *On Behalf Of *
> [e-mail]
> *Sent:* Friday, September 29, 2023 10:53 AM
> *To:* Ben Schwartz bemasc=[e-mail]; Chris Box
> [e-mail]; ADD Mailing list [e-mail]
> *Subject:* [EXTERNAL] Re: [Add] DNR's SvcParams encoding
>
>
>
> Hi all,
>
>
>
> It is surprising to raise this objection now given that text was there
> since -01: https://datatracker.ietf.org/doc/draft-ietf-add-dnr/01/ (May
> 2021) and the intent was clarified during the AD review. The rationale was
> to supply a blob in DHCP, not inherit DNS wire format.
>
>
>
> I even had a thread with Chris with that section explicitly mentioned:
> https://mailarchive.ietf.org/arch/msg/add/05eABH5YubZPoqj3wBMMdsdhTrg/.
>
>
>
> FWIW, I know that at least
> https://reports.kea.isc.org/dev_guide/d7/dee/classisc_1_1dhcp_1_1DnrInstance.html#a7f272a5323080bcf23228dc66c4069d5
> followed that encoding.
>
>
>
> Cheers
>
> *From:* Add <[e-mail]> *On Behalf Of *Tommy Pauly
> *Sent:* Friday, September 29, 2023 11:23 AM
> *To:* Ben Schwartz <bemasc=[e-mail]>; ADD Mailing list <
> [e-mail]>
> *Cc:* Chris Box <[e-mail]>
> *Subject:* [EXTERNAL] Re: [Add] DNR's SvcParams encoding
>
>
>
> I would also expect interpretation A. Agreed with Ben about concerns for B.
>
>
>
> I expect that this wasn’t caught since it is easy to not follow the
> Section 2.1 reference and assume it is applying to the wire format.
>
>
>
> Thanks,
>
> Tommy
>
>
>
> On Sep 29, 2023, at 10:33 AM, Ben Schwartz <
> bemasc=[e-mail]> wrote:
>
>
>
> I expected interpretation A, and would correct the reference to point to
> Section 2.2.  I would have serious concerns about publication under
> interpretation B.
>
>
>
> --Ben Schwartz
> ------------------------------
>
> *From:* Add <[e-mail]> on behalf of Chris Box <
> [e-mail]>
> *Sent:* Friday, September 29, 2023 1:27 PM
> *To:* ADD Mailing list <[e-mail]>
> *Subject:* [Add] DNR's SvcParams encoding
>
>
>
> *This Message Is From an Untrusted Sender *
>
> You have not previously corresponded with this sender.
>
> Hi everyone
>
>
>
> DNR is currently in the RFC queue, as part of a cluster in AUTH48 (
> https://www.rfc-editor.org/cluster_info.php?cid=C461).
>
> As part of recent implementation work, it's become apparent to me that
> there are two possible interpretations of DNR's description of the wire
> encoding of SvcParams.
>
>
> DNR draft 16 says this.
>
>
>
>    Service Parameters (SvcParams) (variable length):  Specifies a set of
>       service parameters that are encoded following the rules in
>       Section 2.1 of [I-D.ietf-dnsop-svcb-https].  Service parameters
>       may include, for example, a list of ALPN protocol identifiers or
>       alternate port numbers.  This field SHOULD include at least "alpn"
>       SvcParam.  The "alpn" SvcParam may not be required in contexts
>       such as a variant of DNS over CoAP where messages are encrypted
>       using OSCORE.  The service parameters MUST NOT include "ipv4hint"
>       or "ipv6hint" SvcParams as they are superseded by the included IP
>       addresses.
>
>
>
> I'll describe the two different ways to understand that.
>
>
>
> *Human interpretation A*
>
> Section 2.1
> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.1>
>  is "Zone file presentation format". This interpretation considers that
> this section is simply a description of how such information would appear
> if it was in a zone file, and does not define a wire format. In the case of
> DNR, this implies that the wire format of the SvcParams field of the DHCP
> option ought to follow Section 2.2
> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2>
>  which is "RDATA wire format".
>
> An example DNR option response could be:
>
> Tag (0xA2)
>
> Length
>
> DNR Instance Data Length
>
> Service Priority (0x0001)
>
> ADN Length
>
> ADN (0x04 "doh1" 0x07 "example" 0x03 "com" 0x00)
>
> Addr Length
>
> Address (0xC0 0x0 0x2 0x1)
>
> SvcParams (0x0001 0x0002 "h2" 0x0007 0x0010 "/dns-query{?dns}")
>
>
> This is a format where the last part is similar to what a DDR client would
> receive in the answer to its SVCB request. So in that sense, DNR is similar
> to DDR.
>
>
> *Human interpretation B*
>
> Section 2.1
> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.1>
>  is followed literally, and therefore the wire format of the SvcParams is
> in zone file format.
>
> Tag (0xA2)
>
> Length
>
> DNR Instance Data Length
>
> Service Priority (0x0001)
>
> ADN Length
>
> ADN (0x04 "doh1" 0x07 "example" 0x03 "com" 0x00)
>
> Addr Length
>
> Address (0xC0 0x0 0x2 0x1)
>
> SvcParams ("alpn=h2 dohpath=/dns-query{?dns}")
>
>
> This obviously requires textual parsing by the recipient, which is
> different to DDR.
>
>
> My question to you all is: when you considered DNR during WGLC, which
> interpretation did you have? Rough concensus was declared, but I wonder
> whether we all had the same interpretation of the meaning of the text when
> we did so.
>
> Looking back, I see Eric did pick up on this ambiguity in his AD review:
> https://mailarchive.ietf.org/arch/msg/add/SFIpMWvnhzTkMDWKQkrl_jGMC6E/ He
> expressed doubt about interpretation B, but did not block. Unfortunately I
> did not see this exchange at the time.
>
>
>
> Which interpretation did you consider at the time?
>
>
>
> Chris
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>