Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

[Francesca Palombini <[e-mail]>]

Hi Ben,

 

Thanks for your reply. Some additional thoughts inline.

 

Francesca

 

From: iesg <[e-mail]> on behalf of Ben Schwartz <bemasc=[e-mail]>
Date: Thursday, 3 March 2022 at 19:27
To: Francesca Palombini <[e-mail]>
Cc: Tim Wicinski <[e-mail]>om>, dnsop <[e-mail]>rg>, dnsop-chairs <[e-mail]>rg>, The IESG <[e-mail]>rg>, [e-mail] <[e-mail]>
Subject: Re: Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

On Wed, Mar 2, 2022 at 5:13 PM Francesca Palombini via Datatracker <[e-mail]> wrote:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/" rel="nofollow">https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

I am concerned by the use of SHOULD in this document. In several places (see 1.
below for what I identified as problematic SHOULDs) the document lacks text
about why these are SHOULD and not MUST or MAY.

 

OK.  I've noted the instances you've identified at https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-56943dbe0fa4a18b&q=1&e=c8014498-d388-4b44-8b9a-7bfb9ad4de3e&u=https%3A%2F%2Fgithub.com%2FMikeBishop%2Fdns-alt-svc%2Fissues%2F355" rel="nofollow">https://github.com/MikeBishop/dns-alt-svc/issues/355

 

FP: Thank you.

...

I also have a number of non blocking comments and questions. I will appreciate
answers to my questions, to improve my understanding. If any clarification
comes out of it, I hope it will help improve the document.

 

I've attempted to answer questions inline, and tracked the other comments at https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7d57d98c29e2247&q=1&e=c8014498-d388-4b44-8b9a-7bfb9ad4de3e&u=https%3A%2F%2Fgithub.com%2FMikeBishop%2Fdns-alt-svc%2Fissues%2F372" rel="nofollow">https://github.com/MikeBishop/dns-alt-svc/issues/372.

 

... 

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


2. -----

   This subsection briefly describes the SVCB RR in a non-normative
   manner.  (As mentioned above, this all applies equally to the HTTPS
   RR which shares the same encoding, format, and high-level semantics.)

FP: I am not sure about why this section is described as non-normative but does
define requirements etc. Maybe it is normatively described somewhere else?

 

Yes, this section highlights some requirements but does not include any normative language.  Any normative requirements mentioned in this section are defined normatively elsewhere in the document.

 

Then
a pointer to that makes sense.

 

OK, we can add more forward references to this section.  (Tracked at https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-180b2252a2932e94&q=1&e=c8014498-d388-4b44-8b9a-7bfb9ad4de3e&u=https%3A%2F%2Fgithub.com%2FMikeBishop%2Fdns-alt-svc%2Fissues%2F371" rel="nofollow">https://github.com/MikeBishop/dns-alt-svc/issues/371.)

 

Also why does this mention encoding and format
but there is no encoding specified.

 

This section of the introduction is just an overview, for a reader who is not familiar with SVCB.  The detailed specification of encodings, formats, and other requirements is later in the document.

 

FP: Thanks, I added a note in the github with a suggestion on text – basically removing “non-normative manner”.

 

5. -----

   SvcParams in presentation format MAY appear in any order, but keys
   MUST NOT be repeated.

FP: Seems to contradict

   SvcParamKeys SHALL appear in increasing numeric order.

 

Ordering is unspecified in presentation format, but must be sorted in wire format.

 

6. -----

   If the client has an in-progress TCP connection to
   [2001:db8::2]:1234, it MAY proceed with TLS on that connection using
   ech="222...", even though the other record in the RRSet has higher
   priority.

FP: I believe this is descriptive of the example and should not use BCP 14 MAY.

 

This "MAY" is intended as an exception to "Clients SHOULD try higher-priority alternatives first" in Section 3.

 

FP: You don’t need to add this as a BCP 14 “MAY”, as “SHOULD” already allows for exceptions, and again this text is only describing an example, so in my opinion should not be adding requirements but just describe behavior.

 

7. -----

   For example, the following is a valid list of SvcParams:

   ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech

FP: I expected this to be a comma separated list.

 

Section 2.1 notes that "SvcParams are a whitespace-separated list".  The SvcParamValue for "mandatory" is a comma-separated list ("key65444,ech").

 

FP: Thanks, I missed it.

 

12. -----

   All protocols employing "http://" or "https://" URLs SHOULD respect
   HTTPS RRs.  For example, clients that support HTTPS RRs and implement

FP: I am not sure how the first sentence is supposed to be implemented, hence
why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be
the clearest wording.

 

There are many protocols that are "layered on top" of HTTP in some fashion, e.g. generating an HTTP URL and performing an HTTP connection as part of some process.  This text was originally written for WebSocket (wss://), but it could also potentially apply to something like MTA-STS, which generates an HTTP URL to fetch information about a mail server.

 

The SHOULD applies primarily to implementers of such protocols, who may need to configure their HTTP implementations appropriately.

 

I think the word "respected" was used because HTTPS-record support is optional for HTTP in general.  The point here is that HTTPS records are applicable to such "embedded" instances of HTTP, and should not be ignored merely because HTTP is not the "top layer" protocol.

 

FP: I see, thank you for the clarification – it makes sense. I’ll leave it up to you if you think some wording (such as the one you just wrote above) might help the reader, or leave it as is.