Question:
Added tag for updates: Removed Observe references scattered throughout the draft Added appendix to collect clarifications to RFC7641 in one place
Captured from : There needs to be a section on how resources can be observed over TCP/TLS. Questions include: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?
URL In a conference call with Klaus, Simon, Bill and myself we discussed the issue and the raised questions. QUESTION 1: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? The text from the CoAP over Websockets could be re-used. Here is what it could say: Since the TCP provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. The Observe Option still has to be sent since it contains other information as well. QUESTION 2: Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up? We believe it is enough to send keep-alive message for the CoAP over TCP draft (as opposed to send a re-registration message when used over UDP). QUESTION 3: How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? TCP offers a flow control mechanism as a means for the receiver to govern the amount of data sent by the sender. This is functionality that can be re-used.
URL (1) -- I agree with the proposed solution. (2) -- we need text that empty messages are no-ops and can be used as a keep-alive mechanism. (3) -- this is a problem that most applications that start using reliable streams run into. Early implementations sometimes ignore the need for proper flow control. That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?

RFC2119. This document assumes that readers are familiar with the terms and <del> concepts that are used in RFC6455 and RFC7252. </del> <ins> concepts that are used in RFC6455, RFC7252, and RFC7641. </ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP.


Question:
Added tag for updates: Removed Observe references scattered throughout the draft Added appendix to collect clarifications to RFC7641 in one place
Captured from : There needs to be a section on how resources can be observed over TCP/TLS. Questions include: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?
URL In a conference call with Klaus, Simon, Bill and myself we discussed the issue and the raised questions. QUESTION 1: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? The text from the CoAP over Websockets could be re-used. Here is what it could say: Since the TCP provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. The Observe Option still has to be sent since it contains other information as well. QUESTION 2: Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up? We believe it is enough to send keep-alive message for the CoAP over TCP draft (as opposed to send a re-registration message when used over UDP). QUESTION 3: How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? TCP offers a flow control mechanism as a means for the receiver to govern the amount of data sent by the sender. This is functionality that can be re-used.
URL (1) -- I agree with the proposed solution. (2) -- we need text that empty messages are no-ops and can be used as a keep-alive mechanism. (3) -- this is a problem that most applications that start using reliable streams run into. Early implementations sometimes ignore the need for proper flow control. That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?

Retransmission and deduplication of messages is provided by the TCP/ TLS protocol. <del> Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed.  The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception. </del> 3. CoAP over WebSockets can be used in a number of configurations.  The


Question:
Added tag for updates: Removed Observe references scattered throughout the draft Added appendix to collect clarifications to RFC7641 in one place
Captured from : There needs to be a section on how resources can be observed over TCP/TLS. Questions include: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?
URL In a conference call with Klaus, Simon, Bill and myself we discussed the issue and the raised questions. QUESTION 1: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? The text from the CoAP over Websockets could be re-used. Here is what it could say: Since the TCP provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. The Observe Option still has to be sent since it contains other information as well. QUESTION 2: Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up? We believe it is enough to send keep-alive message for the CoAP over TCP draft (as opposed to send a re-registration message when used over UDP). QUESTION 3: How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? TCP offers a flow control mechanism as a means for the receiver to govern the amount of data sent by the sender. This is functionality that can be re-used.
URL (1) -- I agree with the proposed solution. (2) -- we need text that empty messages are no-ops and can be used as a keep-alive mechanism. (3) -- this is a problem that most applications that start using reliable streams run into. Early implementations sometimes ignore the need for proper flow control. That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?

distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. <del> Since the WebSocket protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception. </del> 3.4. When a client does not receive any response for some time after


Question:
Added tag for updates: Removed Observe references scattered throughout the draft Added appendix to collect clarifications to RFC7641 in one place
Captured from : There needs to be a section on how resources can be observed over TCP/TLS. Questions include: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?
URL In a conference call with Klaus, Simon, Bill and myself we discussed the issue and the raised questions. QUESTION 1: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? The text from the CoAP over Websockets could be re-used. Here is what it could say: Since the TCP provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. The Observe Option still has to be sent since it contains other information as well. QUESTION 2: Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up? We believe it is enough to send keep-alive message for the CoAP over TCP draft (as opposed to send a re-registration message when used over UDP). QUESTION 3: How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? TCP offers a flow control mechanism as a means for the receiver to govern the amount of data sent by the sender. This is functionality that can be re-used.
URL (1) -- I agree with the proposed solution. (2) -- we need text that empty messages are no-ops and can be used as a keep-alive mechanism. (3) -- this is a problem that most applications that start using reliable streams run into. Early implementations sometimes ignore the need for proper flow control. That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?

RFC6455. All requests for which the CoAP client has not received a response <del> yet are cancelled when the connection is closed.  If the client observes one or more resources over the WebSocket connection, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client from the lists of observers when the connection is closed. </del> <ins> yet are cancelled when the connection is closed. </ins> 4.


Question: Correct descriptions of Direct and Key Agreement Direct Change examples in the back to have "real" examples - they are JSON rather than CBOR, but that makes them shorter and easier to read.

method allowed for doing MAC-ed messages.  In COSE, all of the key management methods can be used for MAC-ed messages. <ins> The COSE_encrypt structure for the recipient is organized as follows: The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields MUST be null. The plain text to be encrypted is the key from next layer down (usually the content layer). At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the shared secret. </ins> 5.2.2. In key wrapping mode, the CEK is randomly generated and that key is


Question: Correct descriptions of Direct and Key Agreement Direct Change examples in the back to have "real" examples - they are JSON rather than CBOR, but that makes them shorter and easier to read.

The COSE_encrypt structure for the recipient is organized as follows: <ins> The 'protected', 'aad', 'iv', and 'tag' fields all use the 'null' value. At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key. The 'unprotected' field MUST contain the 'epk' parameter. </ins> 5.2.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The


Question: This was inspired by the IV computation for TLS. It may or may not make things more secure. The old behavior is easy to get by making the context IV have trailing zeros.

This parameter holds a part of the IV value.  When using the COSE_Encrypted structure, frequently a portion of the IV is part of the context associated with the key value.  This field is used <del> to carry the portion of the IV that changes for each message.  As the IV is authenticated by the encryption process, this value can be placed in the unprotected header bucket.  The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT be present in the same security layer. The final IV is generated by concatenating the fixed portion of the IV, a zero string and the changing portion of the IV.  The length of the zero string is computed by taking the required IV length and subtracting the lengths of the fixed and changing IV portions. </del> <ins> to carry a value that causes the IV to be changed for each message.  As the IV is authenticated by the encryption process, this value can be placed in the unprotected header bucket.  The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT be present in the same security layer. The message IV is generated by the following steps: Left pad the partial IV with zeros to the length of IV. XOR the padded partial IV with the context IV. </ins> This parameter holds a counter signature value.  Counter signatures provide a method of having a second party sign some


Question:
Create MAC as separate key operations per issue
Should we attempt to add the MACverify and MACcreate elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature/verify tags that are currently used in the JWK document?

If the 'alg' field present, it MUST match the HMAC algorithm being used. <del> If the 'key_ops' field is present, it MUST include 'sign' when creating an HMAC authentication tag. </del> <ins> If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag. </ins> <del> If the 'key_ops' field is present, it MUST include 'verify' when verifying an HMAC authentication tag. </del> <ins> If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag. </ins> Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate


Question:
Create MAC as separate key operations per issue
Should we attempt to add the MACverify and MACcreate elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature/verify tags that are currently used in the JWK document?

If the 'alg' field present, it MUST match the AES-MAC algorithm being used. <del> If the 'key_ops' field is present, it MUST include 'sign' when creating an AES-MAC authentication tag. </del> <ins> If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag. </ins> <del> If the 'key_ops' field is present, it MUST include 'verify' when verifying an AES-MAC authentication tag. </del> <ins> If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag. </ins> 9.2.1.


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items. <ins> 1.5. One of the standard issues that is specified in IETF cryptographic algorithms is a requirement that a standard specify a set of minimal algorithms that are required to be implemented.  This is done to promote interoperability as it provides a minimal set of algorithms that all devices can be sure will exist at both ends.  However, we have elected not to specify a set of mandatory algorithms in this document. It is expected that COSE is going to be used in a wide variety of applications and on a wide variety of devices.  Many of the constrained devices are going to be setup to used a small fixed set of algorithms, and this set of algorithms may not match those available on a device.  We therefore have deferred to the application protocols the decision of what to specify for mandatory algorithms. Since the set of algorithms in an environment of constrained devices may depend on what the set of devices are and how long they have been in operation, we want to highlight that application protocols will need to specify some type of discovery method of algorithm capabilities.  The discovery method may be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol.  S/MIME provided a number of different ways to approach the problem: Advertising in the message (S/MIME capabilities) Advertising in the certificate (capabilities extension) Minimum requirements for the S/MIME which have been updated over time </ins> 2. The COSE_MSG structure is a top level CBOR object that corresponds to


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

9. <del> 9.1. </del> <ins> M00TODO: Put in generalities about sigature algorithms and parameters. </ins> <del> 9.2. </del> <ins> 9.1. </ins> ECDSA DSS defines a signature algorithm using ECC.


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) <del> 9.2.1. </del> <ins> 9.1.1. </ins> On of the issues that needs to be discussed is substitution attacks. There are two different things that can potentially be substituted in


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

including the signature algorithm identifier in the data to be signed. <ins> 9.2. The RSASSA-PSS signature algorithm is defined in RFC3447. The RSASSA-PSS signature algorithm is parametized with a hash function, a mask generation function and a salt length (sLen).  For this specification, the mask generation function is fixed to be MGF1 as defined in RFC3447.  It has been recommended that the same hash function be used for hashing the data as well as in the mask generation function, for this specification we following this recommendation.  The salt length is the same length as the hash function output. Three algorithms are defined in this document.  These algorithms are: This uses the hash algorithm SHA-256 for signature processing. The value used for this algorithm is -10.  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-384 for signature processing. The value used for this algorithm is "PS384".  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-512 for signature processing. The value used for this algorithm is -11.  The key type used for this algorithm is 'RSA'. There are no algorithm parameters defined for these signature algorithms.  A summary of the algorithm definitions can be found in table-rsa-algs. 9.2.1. Key size.  is there a MUST for 2048? or do we need to specify a minimum here? </ins> 10. Message Authentication Codes (MACs) provide data authentication and


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

the future and private curves can be used as well. contains the x coordinate for the EC point.  The integer is <del> converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  [CREF21] contains either the sign bit or the value of y coordinate for the EC point.  For the value, the integer is converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  For the sign bit, the value is true if the value of y is positive. </del> <ins> converted to an octet string use ???.  Note that the octet string represents a little-endian encoding of x.  [CREF21] </ins> contains the private key.


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

This contains a pointer to the public specification for the field if one exists <del> This registry will be initially populated by the values in COSE_KEY_PARAM_KEYS.  The specification column for all of these entries will be this document. </del> <ins> This registry will be initially populated by the values in --Multiple Tables--.  The specification column for all of these entries will be this document. </ins> 15.8.


Question: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

[CREF20] JLS: Do we create a registry for curves?  Is is the same registry for both EC1 and EC2? <del> [CREF21] JLS: Should we use the integer encoding for x, y and d instead of bstr? </del> <ins> [CREF21] JLS: Should we use the integer encoding for x and d instead of bstr? </ins> [CREF22] JLS: Should we use the integer encoding for x, y and d instead of bstr?


Question: Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

bounded end-to-end delivery latency.  General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  The </del> <ins> The purpose of this document is to describe the use of the MPLS data plane to establish and support DetNet flows.  The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  At the DetNet data plane a new set of functions (PREOF) provide the service sub-layer specific tasks.  The </ins> forwarding sub-layer is used to provide forwarding assurance (low <del> loss, assured latency, and limited out-of-order delivery). </del> <ins> loss, assured latency, and limited out-of-order delivery) via already existing Traffic Engineering and queuing tools.  The use of the functionalities of the DetNet service sub-layer and the DetNet forwarding sub-layer require careful design and control by the controller plane in addition to the DetNet specific use of MPLS encapsulation as specified by this document. </ins> This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched


Question: Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

encapsulations for consistency but there is no hard requirement in this regard. <ins> Implementation details of PREOF functions is out of scope for this document.  IEEE802.1CB-2017 specifies replication and elimination specific aspects, which can be applied to PRF and PEF. </ins> 4.2.2.1. The Packet Replication Function (PRF) function MAY be supported by an


Question: Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

basis.  The number of out of order packets that can be processed also impacts the latency of a flow. <ins> The latency impact on the system resources needed to support a specific DetNet flow will need to be evaluated by the controller plane based on that flow's traffic specification.  An example traffic specification that can be used with MPLS with Traffic Engineering (MPLS-TE) can be found in RFC2212. DetNet uses flow-specific requirements (e.g., maximum number of out- of-order packets, maximum latency of the flow) for configuration of POF-related buffers.  POF implementation details are out-of-scope for this document and POF configuration parameters are implementation specific.  The Controller Plane determines and sets the POF configuration parameters.  If PEF is combined with POF, then their configurations need to be coordinated to ensure the combined functionality. </ins> 4.2.3. F-Labels support the DetNet forwarding sub-layer.  F-Labels are used


Question: Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

protect against DOS attacks, excess traffic due to malicious or malfunctioning devices is prevented or mitigated through the use of existing mechanisms, for example by policing and shaping incoming <del> traffic.  To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of on-path attackers, for example through use of authentication and authorization of devices within the DetNet domain. </del> <ins> traffic.  To prevent DetNet packets having their delay manipulated by an external entity, precautions need to be taken to ensure that all devices on an LSP are those intended to be there by the network operator and that they are well behaved.  In addition to physical security, technical methods such as authentication and authorization of network equipment and the instrumentation and monitoring of the LSP packet delay may be used.  If a delay attack is suspected, traffic may be moved to an alternate path, for example through changing the LSP or management of the PREOF configuration. </ins> 7.


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </del> <ins> RFC8939 specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </ins> The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and <del> limited reordering).  As described in I-D.ietf-detnet-ip no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </del> <ins> limited reordering).  As described in RFC8939 no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </ins> 2.


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. <del> I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </del> <ins> RFC8939 describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </ins> DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

configure DetNet IP over TSN: DetNet IP related configuration information according to the <del> DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip. </del> <ins> DetNet role of the DetNet IP node, as per RFC8939. </ins> TSN related configuration information according to the TSN role of the DetNet IP node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet IP flow(s) (as flow identification defined <del> in I-D.ietf-detnet-ip, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. </del> <ins> in RFC8939, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. </ins> This information must be provisioned per DetNet flow.


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet IP data plane specific considerations <del> are summarized in I-D.ietf-detnet-ip.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </del> <ins> are summarized in RFC8939.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </ins> The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Time-Sensitive Network. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The basic approach defined in I-D.ietf-detnet-mpls supports the


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

2.1. This document uses the terminology and concepts established in the <del> DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </del> <ins> DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls. The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study. <del> A MPLS DetNet flow is configured to carry any number of TSN flows. The DetNet flow specific bandwidth profile SHOULD match the required bandwidth of the App-flow aggregate. </del> 5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the


Question: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

(DetNet) Edge node terminates all related information elements encoded in the MPLS labels. <del> The LSP used to forward the DetNet packet may be of any type (MPLS- LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR RFC8660).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters. </del> When a PE receives a packet from the Service Proxy function it MUST <del> add to the packet the DetNet flow-ID specific S-label and create a d-CW.  The PE MUST forward the packet according to the configured DetNet Service and Forwarding sub-layer rules to other PE nodes. </del> <ins> handle the packet as defined in I-D.ietf-detnet-mpls. </ins> When a PE receives an MPLS packet from a remote PE, then, after processing the MPLS label stack, if the top MPLS label ends up being


Question:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

3. This document builds on the specification of MPLS over UDP and IP <del> defined in RFC7510.  It replaces the F-Label(s) used in I-D.ietf- detnet-mpls with UDP and IP headers.  The UDP and IP header information is used to identify DetNet flows, including member flows, per I-D.ietf-detnet-ip.  The resulting encapsulation is shown in IP- encap-dn. </del> <ins> defined in RFC7510.  It may replace partly or entirely the F-Label(s) used in I-D.ietf-detnet-mpls with UDP and IP headers.  The UDP and IP header information is used to identify DetNet flows, including member flows, per I-D.ietf-detnet-ip.  The resulting encapsulation is shown in IP-encap-dn.  There may be zero or more F-label(s) between the S-label and the UDP header. </ins> Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header.


Question:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it is not modified as well. <del> To support outgoing DetNet MPLS over IP, an implementation MUST support the provisioning of IP/UDP header information in place of sets of F-Labels.  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet flows and therefore, when PRF is supported, multiple IP/UDP headers MAY be provisioned. When multiple IP/UDP headers are provisioned for a particular </del> <ins> 4. To support outgoing DetNet MPLS over UDP/IP, an implementation MUST support the provisioning of UDP/IP header information in addition or in place of sets of F-Label(s).  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet MPLS flows and therefore, when PRF is supported, multiple UDP/IP headers MAY be provisioned. [Note: PRF is an MPLS function.  It produces member flows.  Member flows have 1to1 mapping to UDP/IP headers.  So why are multiple headers provisioned?  Delete next sentence?] When multiple UDP/IP headers are provisioned for a particular </ins> outgoing DetNet IP flow, a copy of the outgoing packet, including the <del> pushed S-Label, MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. </del> <ins> pushed S-Label (and optional F-label(s)), MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. [Note: What about IPv4 Type of Service and IPv6 Traffic Class Fields? Do we intend to set them?] </ins> To support receive processing an implementation MUST also support the <del> provisioning of received IP/UDP header information.  When S-Labels are taken from platform label space, all that is required is to provision that receiving IP/UDP encapsulated DetNet MPLS packets is permitted.  Once the IP/UDP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, IP/UDP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app- flows based on the combination of S-Label and incoming IP/UDP header. Normal receive processing, including PEOF can then take place. </del> <ins> provisioning of received UDP/IP header information. </ins> <del> 4. </del> <ins> [Note: Are the receiving nodes T-PE nodes?  Why?] When S-Labels are taken from platform label space, all that is required is to provision that receiving UDP/IP encapsulated DetNet MPLS packets is permitted.  Once the UDP/IP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, UDP/IP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app-flows based on the combination of S-Label and incoming IP/UDP header.  Normal receive processing, including PEOF can then take place. 5. The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows: IPv4 and IPv6 source address field. IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored. IPv4 and IPv6 destination address field. IPv4 and IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored. IPv4 protocol field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv6 next header field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv4 Type of Service and IPv6 Traffic Class Fields. IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a zero (0) effectively means that theses fields are ignored. UDP Source Port.  Exact and wildcard matching is required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. 6. </ins> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP


Question:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

mpls and I-D.ietf-detnet-ip.  This draft does not have additional security considerations. <del> 5. </del> <ins> 7. </ins> This document makes no IANA requests.


Question: Remove statement that the document describes the data structure in sufficient detail for implementers and describe more clearly how individual RRsets and the successive RRSig record set are identified by referencing the relevant sections in RFC's; and remove the in response to Eric Rescorla's DISCUSS point: IMPORTANT: I'm not sure that this is actually sufficient to allow an independent implementation without referring to the other documents. I mean, I think I pretty clearly can't validate this chain from the above. Similarly, although I think this is enough to break apart the RRSETs into RRs, it doesn't tell me how to separate the RRSETs from each other. I think you need to either make this a lot more complete or alternately stop saying it's sufficient.

This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on client by means of existing DNS library <del> functions.  However this document describes the data structure in sufficient detail that implementers if they desire can write their own code to do this. </del> <ins> functions. </ins> Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1. <ins> The resource records that make up a RRset all have the same owner, type and class, but different RDATA as specified RFC2181, Section 5. </ins> Each RRset in the sequence is followed by its associated RRsig record <del> set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> set.  This RRset has the same owner and class as the preceding RRset, but has type RRSIG.  The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in RFC4034, Section 3.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field


Question:
I reviewed and approved this pull request.
Upon further reflection it seems like RFC 7299 and 8358 are informative instead of normative references.

1. <del> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </del> <ins> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes


Question:
Changed 2 instances of DEER to DDR
I was so focused on finding "equivalent" that I missed a couple deer apparently. Thank you!

5. A DNS client that already knows the name of an Encrypted Resolver can <del> use DEER to discover details about all supported encrypted DNS </del> <ins> use DDR to discover details about all supported encrypted DNS </ins> protocols.  This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name


Question:
Changed 2 instances of DEER to DDR
I was so focused on finding "equivalent" that I missed a couple deer apparently. Thank you!

6. <del> Resolver deployments that support DEER are advised to consider the </del> <ins> Resolver deployments that support DDR are advised to consider the </ins> following points. 6.1.


Question:
Addressing issues and to make the SUDN forwarding a SHOULD NOT unless the operator understands and accepts the implications to authenticated discovery.
This is exactly what was intended, so we're on the same page.
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.
Migrated from original DEER issue: URL
The text says This is not true of any reasonable forwarder. RRsets are atomic collections, and cannot be mixed from multiple sources. Doing so would entirely break DNSSEC, for example. Unless you know of a forwarder that exhibits this seriously broken behavior, I don't think it bears mentioning.
Addressed with PR 14
Typo, but this seems like a reasonable tweak. The description on list was a bit worrying regarding IP address, but this just says don't forward unless it is deliberate. And by deliberate, I mean that the forwarder knows it will work or that clients might not care. That seems ok.

6.1. <del> If a caching forwarder consults multiple resolvers, it may be possible for it to cache records for the "resolver.arpa" Special Use Domain Name (SUDN) for multiple resolvers.  This may result in clients sending queries intended to discover Designated Resolvers for resolver "foo" and receiving answers for resolvers "foo" and "bar". A client will successfully reject unintended connections because the authenticated discovery will fail or the resolver addresses do not match.  Clients that attempt unauthenticated connections to resolvers discovered through SVCB queries run the risk of connecting to the wrong server in this scenario. To prevent unnecessary traffic from clients to incorrect resolvers, DNS caching resolvers SHOULD NOT cache results for the "resolver.arpa" SUDN other than for Designated Resolvers under their control. </del> <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.  This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be authenticated. </ins> 6.2.


Question: Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a <del> resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. </del> <ins> resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. </ins> 1.


Question: Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

7. <del> Since client can receive DNS SVCB answers over unencrypted DNS, on- </del> <ins> Since clients can receive DNS SVCB answers over unencrypted DNS, on- </ins> path attackers can prevent successful discovery by dropping SVCB packets.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated


Question: Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. <del> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this documents, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </del> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted


Question: Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins> 8. 8.1.


Question:
NAME does this work for you?
OK, so I said LGTM, but how does a server know that it is such a server? Can't I just publish a random DDR record for 1.1.1.1?
As I mentioned in the session, this is partly covered in SVCB-DNS, but perhaps we need a tighter rule. I've opened an issue to discuss it: URL I'm not entirely sure which draft this kind of text ought to go in. If you think this logic applies beyond DDR (e.g. in ADoT cases), then it probably should go in the SVCB-DNS draft. Otherwise, maybe DDR is the place.
NAME for security considerations, I'm OK with multiple drafts having warnings. I think this particular attack should be mentioned in DDR, since other uses of DNS SVCB could be over more trusted channels.
NAME if your resolver responds to URL, then we expect the address of the resolver I asked to be covered in the cert. So, if I send a packet to 1.1.1.1, 1.1.1.1 has to be covered. So, if you just provide a "random" DDR record in response to URL, you can only point to some resolver that has your IP address in its cert, which presumably is sufficient coordination for the resolver to "know" it has this set up.
Right. Good point.
As mentioned at the microphone, if we are to allow the query-path to be specified in the clear like this, we need to require that servers not have different responses with different query paths.
LGTM

queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. <ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections


Question:
I think that the answer here is that DDR resolution is SVCB-reliant as defined in the SVCB spec. Can you make that explicit please?
says It sounds like you're saying that DDR should adopt this without adjustments. That seems reasonable to me.
Right. I sort of assumed that it was SVCB-reliant, but it doesn't say that. Certainly, this is not a case where any deviation from spec is necessary. (The more of those we have, the better.)
DDR predates when the reliant and optional terms came about, which is why it wasn’t covered. I’m not clear on why anything would need to be said here. Reliant and optional seem to be modes for the client to block on getting SVCB records or falling back and ignoring them if they don’t arrive. Discovery based on IP addresses is done with an SVCB query for URL, and no other query types are allowed for URL By definition, this only works with SVCB. That doesn’t mean that a client can’t be SVCB optional for its general operation — it just means that if SVCB is blocked or fails, you don’t get to discover the encrypted resolver. What do we need to say here that would actually benefit things?
So SVCB-optional doesn't even make sense for this specification. I was just looking for a nudge in the form of: "The resolver/client uses SVCB in a SVCB-reliant mode." Just so that there is no confusion.
Yes, optional doesn’t make sense. But I still think that the entire reliant/optional choice is orthogonal to how DDR works. These are the two lines that mention reliant mode in the SVCB spec: Both of these seem to be about client behavior for connection establishment to a hostname. It’s specifically about connecting. It doesn’t make sense to connect to URL; this is a special purpose SVCB query used for discovery, which can lead to a connection. I don’t see any requirement from the SVCB spec that protocols that use SVCB need to define themselves as “reliant” or “optional”. Is there something I’m missing there?
How is this not about connecting from the point at which you feed the name into a SVCB query? A DDR client is trying to connect to a (secure) resolver. To that end, it is making a SVCB query. That it uses "URL" doesn't change the overall goal.
Until a client uses the SVCB query for discovery, it doesn’t know if an encrypted resolver exists that is designated. I’m not sure if saying a DDR-aware client is “SVCB-reliant” means that it will not use the unencrypted resolver for application queries until it discovers an encrypted resolver (which is not a requirement, obviously, since clients can be allowed to continue using unencrypted DNS if their local policy allows it), or it means that the connection to the discovered encrypted DNS server is SVCB-reliant, which is tautologically true since the existence of said server was only discovered via SVCB. If it’s the former, we shouldn’t say it because it’s really about client policy for allowing unencrypted DNS. If it’s the latter, I don’t see the value of adding anything, and I’m not sure it really fits the meaning of “reliant”.
I believe DDR clients' recommended behavior is exactly the behavior recommended in Section 8.2 of SVCB-DNS, quoted above. It is initially SVCB-optional, and becomes SVCB-reliant once SVCB resolution succeeds. Specifically: if you do discover an encrypted resolver, and you attempt connection, you SHOULD NOT fall back to unencrypted if that connection fails. Otherwise, you've added a downgrade vulnerability to attackers on the "transport path" (which may not be the same as the bootstrap-query path). As this is the default recommendation for SVCB-DNS, I don't think any additional normative language is strictly required. However, I think a reminder might be appropriate. This does not address the question of whether to wait for SVCB resolution before issuing any initial queries. As a practical matter, I don't think we can require that.
Okay, I agree with the behavior you describe there of being initially optional and then becoming reliant. I can try to find a place where it makes sense to reference that section.

Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB <del> queries or answers.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. </del> <ins> queries or answers, and thus prevent clients from switching to use encrypted DNS.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


Question:
I have committed all request changes. Thank you for the refinements.
The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, IANA understands that this document calls for the addition of "URL" to the Special-Use Domain Names (SUDN) registry established by RFC6761. RFC6761 specifically requires that any request for a Special-Use Domain Name needs to contain a subsection of the "IANA Considerations" section titled Domain Name Reservation Considerations. The current draft does not have such a section. IANA Question --> Could the authors either conform to the requirements of RFC6761 or provide explicit guidance as to why that section is not appropriate? Second, in the Transport-Independent Locally-Served DNS Zone Registry on the Locally-Served DNS Zones registry page located at: URL a new registration will be made as follows: Zone: URL Description: DNS Resolver Special-Use Domain Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: URL

Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. <ins> 8.2. In accordance with Section 5 of RFC6761, the answers to the following questions are provided relative to this document: Are human users expected to recognize these names as special and use them differently?  In what way? No.  This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. Are writers of application software expected to make their software recognize these names as special and treat them differently?  In what way? No.  There is no use case where a non-DNS application (covered by the next question) would need to use this name. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently?  If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself.  DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? No.  DDR is designed for use by recursive resolvers.  Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators?  If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid?  Do DNS server operators need to know about that and understand why?  Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query.  DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. How should DNS Registries/Registrars treat requests to register this reserved domain name?  Should such requests be denied? Should such requests be allowed, but only to a specially- designated entity? IANA should hold the registration for this name.  Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. </ins>


Question:
DISCUSS: CC NAME See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns Resolver without some sort of validation Why not? What is the alternative? Using unencrypted DNS to the party that told you how and where to contact these (unvalidated) Designated Resolvers. Resolver that does not use a private or local IP address and can be verified using the mechanism described in Section 4.2, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in Section 4.2. This seems to go against a lot of advise in the documents that networks must be treated independently. Also, the network wants you to use their designated resolver, so to say it is okay to use a totally different Designated Resolvers seems to violate the whole DNR/DDR architecture. This will also cause failure if there is split-DNS or internal-only data. Also, using "public IP" is not a good trustworthy method to prove that these IPs are truly the same Designated Resolver used by both networks. I can easily use an internal only zone with . IN A 8.8.8.8 and get a valid ACME'd certificate with SAN=. The user connecting to another network might now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS. address of the designating Unencrypted Resolver in a subjectAltName extension. How feasible is it to get a certificate with SAN=ip from one of the generally accepted root store CA's? Can you give me one example where I can get a certificate for with SAN=193.110.157.123 ? I do not think this is currently possible or easy. If I am right, that means all of Section 4.2 is wishful thinking and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it is possible, but I know of no ACME supported CA that issues these) discovered Designated Resolver. This creates a strange policy when compared to DNR where if you get a DHCP or RA for the Designated Resolver, which is also not validatable, that you do end up using it? And section 6.5 states DNR trumps DDR. address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). Why only when the IP is the same? Why not for when the IP is different? What's to lose, since the only fallback option is stick to using the unencrypted resolver? yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. How does the appearance of an (unsigned) Additional Answer entry convey any kind of real world trust/authentication? In other words, why should it not ALWAYS pass the same TLS certificate checks ? is to use unencrypted DNS, why not just use it anyway? use DDR to discover details about all supported encrypted DNS protocols. It's a little odd to mention this as the DNR draft really tries hard to say to only use the network's offered encrypted DNS servers, so this option is in conflict with the DNR draft. Unfortunately, all currently deployed software does not know this, so it will be very common that this happens. URL SHOULD treat URL as a locally served zone per [RFC6303] Why is this not a MUST ? queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. I don't see how this would improve security for the client. It also mixes up behaviour of proper DNS clients that have their own retransmit logic for if they get no answer. attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed. For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires I wonder which attacker can block encrypted DNS connections but not spoof (or block!) an unsigned SVCB record to the local client? And even if that is the case, this would be a denial of service attack if the DNS client cannot fallback to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few hours would be a very cheap 1 packet attack to keep the DNS client down for hours. This seems dangerous to implement. unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, [...] It seems likely that this advise will get ignored a lot, eg by people who have limited public IPs to use to spin up a DoH server, or who have to pay-per-IP. This advise seems more appropriate for local private IP DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason. Unencrypted Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. How would one obtain such a certificate via ACME? Since on the IP of the unencrypted resolver, there would be no HTTP server running? Additionally, if the client notices a failed verification of the Designated Resolver's TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now it may not? So this becomes a denial of service then ? to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. Based on earlier text, this should read "the same non-public IP address". you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you get anything back. It might be unauthenticated TLS but better than port 53? Special-Use Domain Names (SUDN) registry established by [RFC6761]. Why not pick URL As .local is already handled to not be forwarded by DNS forwarders. It would also not require an addition to SUDN. Even if someone was already using URL, it would not interfere with that usage because that usage would not be using SVCB records. To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of [RFC8484] regarding the avoidance of DNS- based references that block the completion of the TLS handshake. I find that reference to list more the issues than solutions that can be followed. The solution to use another DoH server is not really appropriate in most cases The client's other interface likely resides on other networks where its private DoH server cannot resolve the name of another network's private DoH server. It is also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general webpki root stores. And things like OCSP stapling doesn't help if the target is malicious - they just would omit the stapling that proves against its malicious use. The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve the encrypted resolver". Might as well say that and remove the 8484 reference. as the protocol is mentioned throughout the document as interacting with this protocol. when accessing web content on a dual-stack network: A, AAAA, and HTTPS queries. Discovering a Designated Resolver as part of one of these queries, without having to add yet another query, minimizes the total number of queries clients send. I don't understand this paragraph. Once clients can send SVCB queries for web content, they already have had to do all the DDR/DNR related queries, so I don't understand the argument of "saving queries" ? Also, it is adding queries for a specific target, eg URL, and this cannot be "saved" either? What am I misunderstanding here? provides provides -> provides
We should reference Security Considerations, because if you don't have any validation, an attacker can point you to any server they want (someone other than the server you were configured with by DHCP, etc).
We can probably just remove this, not using it in implementations right now.
It's already done by the major public resolvers, and there is an RFC to support this (RFC 8738). The IP address validation is clearly important and a matter of WG consensus. Hopefully, this will push adoption of RFC 8738 by more ACME services.
We can reference the DNR section. The MUST NOT should only apply to DDR, but doesn't invalidate other ways of using the resolver.
If they are different, it can be a random attacker (see security considerations). The client may also have other better options to fall back to.
Agree, this should be simplified to say "even if you connect over a different IP address for any reason, still validate the original IP address"
There are definitely cases where the client can have directly selected their own resolver name, etc. We don't have to use the network resolver.
Correct, and that's why we need this document, and it was added to the IANA section.
Sure, we can make this a MUST.
It makes the attacker's job harder by requiring them to be persistent. Normal retransmission logic is fine too.
This is a direct outcome of the svcb-dns document. Spoofing SVCB shouldn't be enough to cause a DoS here, because we should continue to use the previously used encrypted DNS server while on this network (even if you get a bad SVCB packet).
For the security reasons, I think this needs to stay as a MUST NOT. However, if you differentiate based on hostname + path, you can still differentiate, it just isn't a differentiation that can be discovered by IP address queries.
Yes, you'd fall back to unencrypted resolution if you can't have a secure trusted connection for encrypted resolution.
Yes, but that part is SHOULD. Will fix.
I think that's just opportunistic DoT / DoQ. That's already specified.
.local is the SUDN for multicast DNS, but it is also squatted on by some internal networks. Following the patterns for URL, etc, .arpa is a much more appropriate name. This is what the group had consensus on years ago and has been deployed widely already.
I think we can say "as explained in RFC 8484, don't loop on the resolver name."
Sure, that's fine.
Yeah, this paragraph is old and can be removed.
Looks good! Just silly editorial nits

should be able to use those records while safely ignoring the third record. <del> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-