[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-session-signal-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/



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

Thank you for resolving most of my DISCUSS points (the additional
clarification about when the one-hour retry does (not) apply in particular
is helpful even if not strictly needed).  However, it seems that my point
about an "application protocol profile" for TLS 1.3 0-RTT was deferred
until the resolution of a different thread covering 0-RTT, but that
we never picked it back up.  I think this document's profile needs to
provide greater clarity about what specific messages are (or are not)
allowed in 0-RTT data, i.e., listing permitted TLVs and having a column in
the registry for whether a TLV is 0-RTT-safe.  For example, Retry Delay
simply cannot appear in a DSO message that is eligible for 0-RTT, so it
accordingly cannot appear in a 0-RTT message, while EncryptionPadding
should be safe to appear [as an additional TLV], provided there is a
suitable primary TLV to attach it to.  On first look [after long absence],
the keepalive TLV should be safe to use as a 0-RTT primary TLV, since it
elicits a response and only affects the current connection.  Anyway, my main
point here is that we need to place the burden of analysis on a TLV's
safety on the authors of the spec introducing that TLV, and not on
implementors or users of the protocol.


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

[COMMENT section unchanged from original ballot; contents may no longer apply]

Six authors exceeds five, so "there is likely to be discussion" about this
being too large a number of authors.  What is the justification for the
author count?

Do we need to specify some GREASE (per draft-ietf-tls-grease) for new TLV
types in order to ensure the proper handling of unknown types?

Section-by-section comments follow.

Section 1

A DoH reference seems timely/apt.  (But maybe then it is only "Some such
transports" that can offer persistent sessions.)

Maybe give some examples of advantages of server-initiated messages?  Are
we talking about letting the server push records with larger TTLs or
notifying when the response to a query is changing, or just more mundane
keepalive-type things?

Section 3

   The terms "initiator" and "responder" correspond respectively to the
   initial sender and subsequent receiver of a DSO request message or
   unacknowledged message, regardless of which was the "client" and
   "server" in the usual DNS sense.

We just defined "client" and "server" explictly (without reference to the
"usual DNS sense"), so probably it's best to have this definition refer to
the previous client/server definitions or clarify that the above
definitions match the "usual DNS sense".

   When an anycast service is configured on a particular IP address and
   port, it must be the case that although there is more than one
   physical server responding on that IP address, each such server can
   be treated as equivalent.  If a change in network topology causes
   packets in a particular TCP connection to be sent to an anycast
   server instance that does not know about the connection, the normal
   keepalive and TCP connection timeout process will allow for recovery.
   If after the connection is re-established, [...]

Perhaps clarifying that "recovery" means "detecting the broken session and
starting a new one" would be useful?  (I guess Spencer's DISCUSS takes this
a different direction.)

   DSO unacknowledged messages are unidirectional messages and do not
   generate any response.

"Do not generate any response" at the DNS layer; any reason to mention that
TCP will still ACK the bytes (or rather, that the "reliable" part of the
data stream will need to do so)?

Section 5.1

   DSO messages MUST be carried in only protocols and in environments
   where a session may be established according to the definition given
   above in the Terminology section (Section 3).

nit: is this "in only" or "only in"

   If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
   ([TBA2] tentatively 11), then the client MUST assume that the server
   does not implement DSO at all.  In this case the client is permitted
   to continue sending DNS messages on that connection, but the client
   SHOULD NOT issue further DSO messages on that connection.

I'm confused how the server would still have proper framing for subsequent
DNS messages, since the DSO TLVs would be "spurious extra data" after a
request header and potentially subject to misinterpretation as the start of
another DNS message header.

Section 5.1.3

It is probably worth explicitly noting that a middlebox MUST NOT
make/forward a DSO request with TLVs that it does not implement.

Section 5.2

   If a DSO message is received where any of the count fields are not
   zero, then a FORMERR MUST be returned, unless a future IETF Standard
   specifies otherwise.

This seems like ... not the conventional wording for this behavior, and
subject to large debates about the meaning of "IETF Standard".
(Similar language is used elsewhere, too.)

Section 5.2.2

The start of this section seems to duplicate a lot of Section 3 -- e.g.,
the specification of the "Primary TLV"; request/response/unacknowledged as
the types of messages; etc.  It's unclear to me that this duplication of
content is helpful to the reader.

   Unacknowledged messages MUST NOT be used "speculatively" in cases
   where the sender doesn't know if the receiver supports the Primary
   TLV in the message, because there is no way to receive any response
   to indicate success or failure of the request message (the request
   message does not contain a unique MESSAGE ID with which to associate
   a response with its corresponding request).  Unacknowledged messages
   are only appropriate in cases where the sender already knows that the
   receiver supports, and wishes to receive, these messages.

Having gone to the trouble to explicitly define (twice!) "request",
"response" and "unacknowledged", it's pretty confusing to then use the
English word "request" to refer to an "unacknowledged" message.

Section 5.2.2.1

   The specification for a TLV states whether that DSO-TYPE may be used
   in "Primary", "Additional", "Response Primary", or "Response
   Additional" TLVs.

Perhaps this could be wordsmithed to avoid accidental misreading as
exclusive-or?

Section 5.3.1

   When a DSO unacknowledged message is unsuccessful for some reason,
   the responder immediately aborts the connection.

Doesn't this kill the client/server pairing for an hour?  "For some reason"
is very vague to induce such behavior, and could include transient internal
errors.

Section 6.1

When would it be appropriate for the server to send responses out of order?

Section 6.6.1.1

nit: "RECONNECT DELAY" is used with inconsistent capitalization.

Section 7.1

The description of the two timeout fields is predicated on understanding
that it is only the response's incarnation of them that is authoritative;
as an editorial matter, it might be nice to introduce this fact earlier.

Section 7.1.1

It seems like we could consolidate the "equal to" and "greater than" cases
into "greater than or equal to".

Section 7.2.1

   A client MUST NOT send a Retry Delay DSO request message or DSO
   unacknowledged message to a server. [...]

nit: it must not send it as a response, either, so perhaps "MUST NOT send a
Retry Delay DSO message to a server" is shorter and better.

Section 9.3

I thought IANA liked to see a "registration template" for what subsequent
registrations in a registry being created will need to specify.  (That
said, the IANA state is "IANA OK - Actions Needed", and one might expect
that they know better than I do...)

Section 10

I'm a little surprised to not see some discussion that this mechanism
encourages the maintenance of persistent connections on DNS servers, which
encourages the maintenance of persistent connections on DNS servers, which
has impact on resource consumption/load, but is not expected to be
problematic because the server can tell the clients to go away if needed.