end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds <del> owner but by another vendor, the vender who own the KeyPurposeIds may </del>  not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the 4. <del> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </del>  The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying <del> party software proresses each restriction on "Excluded </del>  KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId". When a single application has the capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling <del> (e.g.  text, pdf, etc). </del>  5.

Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".

end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds  <ins> owner but by another vendor, the vendor who own the KeyPurposeIds may </ins> not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the 4.  <ins> Our intended use case is people consuming the contents of signed documents.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying  <ins> party software processes each restriction on "Excluded </ins> KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId". When a single application has the capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling  <ins> (e.g., TEXT, PDF). </ins> 5.


signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than <del> processed by machines. </del>  3.1. This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds, instead of </del>  single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and

Addressing Erik's . Given that documents may be presented to people "by means of ... software" perhaps a slight tweak to the "rather than processed by machines", e.g.: "rather than processed primarily by machines", or "rather than processed principally by machines" s/instead of single/instead of a single/ s/proresses/processes/ I think?

signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than  <ins> primarily processed by machines. </ins> 3.1. This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can  <ins> permit or prohibit combinations of KeyPurposeIds, instead of a </ins> single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and


Abstract <del> RFC5280 specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key usage for X.509 public key certificates which specifies the usage of the certificates for document signing. </del>  1. RFC5280 specifies several extended key usages for X.509 certificates. <del> 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. </del>  In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of the certified public key is allowed to be used for verifying the signature on a document. </del>  <del> Term of "Document Sign" in this document is digitally signes contents </del>  that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by means of services or software, rather than processed by machines. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> Subject named in the certificate signed the document content, and the associated keys can be used by a document signing service or a software for authentication, message integrity, and non-repudiation of origin (using digital signatures, along with any usages allowed by other EKU values). </del>  4. The signed contents of Internet-Drafts are primarily intended to be consumed by human.  To be more precise, contents are intended to be shown to human in a printable or displayable form by means of <del> services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by humans, implementations MAY perform the steps below during certificate validation: </del>  The implementation MAY examine the Extended Key Usage value(s): If there are restrictions set for the replying party and relying party software, proceed as following. <del> Each Restriction on the EKUs can be "Excluded EKU" or "Permitted EKU" and handled. The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this document, but the relying party can permit or prohibit combinations of EKU.  A consideration on prohibiting combinations of EKUs is described in the security consideration section of this document. 2.1.  Excluded EKUs procedure "Excluded EKU" is an EKU which the relying party or the relying party software prohibits.  Examples of "Excluded EKU" are, presence of anyEKU or complete absence of EKU extension on a certificate.  If an EKU of the certificate meets the conditions set by the "Excluded EKU" restriction, the relying party or the relying party software rejects the certificate. 2.2.  Permitted EKU procedure "Permitted EKU" is an EKU which the relying party or the relying party software accepts.  Examples of "Permitted EKU" are, presence of this general document signing EKU and/or protocol specific document signing-type EKUs.  If an EKU of the certificate meets the condition set by a "Permitted EKU" restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. When a single software has the capability to process various data </del>  formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc). 6. <del> The usage of id-kp-documentSigning EKU is to provide an alternative to id-kp-emailProtection being used for non-email purposes and id-kp- codeSigning being used to sign objects other than binary code.  This </del>  EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. To reduce the risk of specific cross protocol attacks, the relying <del> party or relying party software may additionally prohibit use of </del>  specific combination of EKUs. While a specific protocol or signing scheme may choose to come up <del> with their own EKU, some may not have significant motive or resources to set up and manage their own EKU.  This general document signing </del>  EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would <del> like to distinguish document signing from other usages. </del>  Introduction of this id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.

This also made the references to RFCs 7229 and 8358 Informative references, as was approved by in PR. More importantly, neither of these refs are required for implementation. This also changes the line breaks in the .md hence it looks like a lot more changes than there really are. Done to aid readability. NAME please double check that the new formatting in s4 works. It seemed to the me that the paragraphs after "2." were part of the numbered item so I indented them. The .md will result in the following .txt: If there are restrictions set for the replying party and relying party software, proceed as following. Each Restriction on the EKUs can be "Excluded EKU" or "Permitted EKU" and handled. The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs. It is outside the scope of this document, but the relying party can permit or prohibit conbinations of EKU. A consideration on prohibiting combination of EKUs is described in the security consideration section of this document. Excluded EKUs procedure: "Excluded EKU" is an EKU which the relying party or the relying party software prohibits. Examples of "Excluded EKU" are, presence of anyEKU or complete absence of EKU extension on a certificate. If an EKU of the certificate meets the conditions set by the "Excluded EKU" restriction, the relying party or the relying party software rejects the certificate. Permitted EKU procedure: "Permitted EKU" is an EKU which the relying party or the relying party software accepts. Examples of "Permitted EKU" are, presence of this general document signing EKU and/or protocol specific document signing-type EKUs. If an EKU of the certificate meets the condition set by a "Permitted EKU" restriction, the certificate is acceptable. Otherwise, relying party or the relying party software rejects the certificate. When a single software has capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc).
Also
Section 4: s/prohibit conbinations/xxclude combinations/ Section 4: s/anyEKU/anyExtendedKeyUsage/ Section 6: s/none-email purposes/purposes other than email/ Note the comment about the abstract was addressed via .
I-D Nits complains about: one line being too long: the 2nd line of the ASN.1 module the abstract containing a reference: [RFC5280]
approved. after building into txt, it seems same in my environment also.

Abstract  <ins> RFC 5280 specifies several extended key usages for X.509 certificates.  This document defines a general purpose document signing extended key usage for X.509 public key certificates which restricts the usage of the certificates for document signing. </ins> 1. RFC5280 specifies several extended key usages for X.509 certificates.  <ins> In addition, several extended key usage had been added RFC7299 as public Object Identifier (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 OID 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 This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the  <ins> use of any Subject names in the certificate is restricted to use by a document signing. </ins>  <ins> Term of "Document Sign" in this document is digitally sign contents </ins> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by means of services or software, rather than processed by machines. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the  <ins> use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values). </ins> 4. The signed contents of Internet-Drafts are primarily intended to be consumed by human.  To be more precise, contents are intended to be shown to human in a printable or displayable form by means of  <ins> services or software, rather than processed by machines.  To validate the digital signature which is signed to contents intended to be consumed by human, implementations MAY perform the steps below as a certificate validation. </ins> The implementation MAY examine the Extended Key Usage value(s): If there are restrictions set for the replying party and relying party software, proceed as following.  <ins> Each Restriction on the EKUs can be "Excluded EKU" or "Permitted EKU" and handled. The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this document, but the relying party can permit or exclude combinations of EKU.  A consideration on prohibiting combination of EKUs is described in the security consideration section of this document. "Excluded EKU" is an EKU which the relying party or the relying party software prohibits.  Examples of "Excluded EKU" are, presence of anyExtendedKeyUsage or complete absence of EKU extension on a certificate.  If an EKU of the certificate meets the conditions set by the "Excluded EKU" restriction, the relying party or the relying party software rejects the certificate. "Permitted EKU" is an EKU which the relying party or the relying party software accepts.  Examples of "Permitted EKU" are, presence of this general document signing EKU and/or protocol specific document signing-type EKUs.  If an EKU of the certificate meets the condition set by a "Permitted EKU" restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. When a single software has capability to process various data </ins> formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc). 6.  <ins> The usage of id-kp-documentSigning EKU intends to prevent id-kp- emailProtection from being used for purposes other than email and id- kp-codeSigning used to sign objects other than binary codes.  This </ins> EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. To reduce the risk of specific cross protocol attacks, the relying  <ins> party or relying party software may additionaly prohibit use of </ins> specific combination of EKUs. While a specific protocol or signing scheme may choose to come up  <ins> with their own EKU, some may not have significant motive or resource to set up and manage thier own EKU.  This general document signing </ins> EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would  <ins> like to distinguish from other usage. </ins> Introduction of this id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.


Abstract <del> During the process of creating a peer-to-peer connection, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed.  However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature.  This document discusses when these situations can occur and proposes a way to avoid premature failure. </del>  1.

LGTM with the tweak I added
Where: Abstract What: s/peer-to-peer connection/connectivity Why: We talk about establishing connectivity elsewhere
peer-to-peer seems important to retain here, not sure I agree with this change
Then we could at least use "peer-to-peer connectivity", because that seems to be used once in the Introduction of 8445.
I can get behind that.
Something happened. I forked the ICE WG repo, but when I created the PR it ended up in my private repo.
You used the wrong repo for the base repo. I fixed it in URL
I think I understand why that happened, ice-wg still thinks cdh4u is upstream, need to think about how to fix that.
Shouldn't it be possible to create a pull request to a fork? I guess my repo isn't needed anymore, so in worse case we can just remove it.
Fixed in
Looks good.

Abstract  <ins> During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and proposes a way to avoid premature failure. </ins> 1.


(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

Ok.
Looks good.
Where: Introduction What: s/candidate addresses/ICE candidates Why: An address is just one part of a candidate
I tend to think this is implicit, and won't confuse anyone.
We use "candidates" everywhere else, and it is not only the addresses that are exchanged.
8445 also uses 'candidate transport addresses' in Section 2. But open to some other text here, 'ICE candidates' feels like it doesn't explain enough to the reader.
The paragraph says: "Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established. If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed." If people don't understand what an "ICE candidate" is they won't understand the rest of the text either :) My point is that endpoints are exchanging candidates. The candidate transport addresses are then used for sending connectivity checks. So, if you want to include it, perhaps something like: "and then test each candidate pair, by sending connectivity checks using the candidate transport addresses, to see if...."
Implemented in
Reworded, PTAL.

(ICE), for Network Address Translator (NAT) traversal for UDP-based communication.  <ins> When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote


Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned <del> above; note that receipt of an ICE candidate is not required. </del>  The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all

I committed both changes.
WHERE: Update to RFC 8445 WHAT: Modify... "; note that receipt of an ICE candidate is not required." URL that it also indicates that no candidate needs to be SENT before the timer is started. WHY: The text in unclear on whether a candidate needs to be sent or not before the timer is started. The text only says that a candidate does not need to be received.
ok
Implemented in
LG with two minor wording changes

Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned  <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all


the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del>  In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> fail, e.g., where both sides provide candidates with unresolvable FQDNs ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </del>  Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That

I committed the change.
WHERE: All Candidates Discarded WHAT: Remove/rewrite the following: "(e.g., a candidate that contains a FQDN that fails to resolve)." WHY: It is unclear whether how/if FQDNs can be used in candidates. I think the text saying that the candidate cannot be used for some other reason is enough.
Implemented in One issue, though: The text says: "One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families ICE will no longer fail immediately, and only fail when the aforementioned timer expires." ('unsupported address families' used to be 'unresolvable FQDNs', but the issue is the same) Q: If both endpoints provide candidates that can't be used, how is the timer going to help? No endpoint will send any connectivity checks, so there will be no peer-reflexive candidates.
LG with one minor text change

the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a  <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should  <ins> fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </ins> Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That


(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del>  In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE needs to wait enough time to allow peer-reflexive candidates to be discovered.  Accordingly, when a full ICE implementation begins its ICE processing, as described in RFC8445, Section 6.1, it MUST set a <del> timer to ensure ICE will run for a minimum amount of time before determining failure. </del>  Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting.  This occurs when the agent has Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned <del> above; note that receipt of an ICE candidate is not required. </del>  The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> fail, e.g., where both sides provide candidates with unresolvable FQDNs ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios </del>  require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. <del> Note also that the timer is potentially relevant to the ICE </del>  nomination procedure described in RFC8445, Section 8.1.1.  That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the allow peer-reflexive candidates to be discovered and checked, as noted above.  Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it <del> MAY use the timer described above to do so.  As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the timer elapsing. </del>  5.

You are right, eventhoug 8445 in some places do say "whenever Ta fires". I'll update the PR. I think it is much easier to talk about "timer Tpac" than "the timer that does this and that". For example, during the ICEbis work, we often talked about "timer Ta". It may not sound like a big differnce at this point, when we are still working on the draft, but I think it will make a difference in the future when/if people start referring to the timer.
NAME NAME wdyt?
I don't think we need this, but if we want to name the timer, I would suggest: Call it "Tpac" and not "Timer Tpac" Not change so much of the existing text. Maybe put in the name (for future conversations) and just replace the once place where we say "the aforementioned timer".
I initially did that, but Justin pointed out that, when comparing to Ta, Ta is just the interval used by a timer. I think that, when we talk about about a timer, we should use the name of the timer.
The first mentions of timers in 8445 says "The gathering process is controlled using a timer, Ta. Every time Ta expires" but then later is says "The generation of ordinary and triggered connectivity checks is governed by timer Ta". So it looks like 8445 isn't self consistent. Meanwhile, we call the RTO timer "timer RTO", so we don't need the "Tfoo" model. How about we just call it "timer PAC", or better yet "the PAC timer"?
I left that part out on purpose :) The Terminology section uses "Timer Ta", though. I want to have a timer name. As I indicated to Justin when we discussed this, it will make future discussions much easier, when we refer to the timer. It will also make life easier for implementers. What about using "timer Tpac" in the first occurrence, and then "Tpac"? BTW, if you are concerned about the number of changes in the PR, note that we have already merged a set of PRs, so the new version of the draft will contain changes from the current version no matter what.
I don't see any reason to use the T prefix when always say "timer" along with it. It's redundant. I'd prefer "PAC timer or "timer PAC". But I don't care enough to keep talking about it. I'd rather just pick something and move on.
I have no problem with "timer PAC" if you prefer that. All I want is a timer name that people can be refer to.
I think it's very useful to have a name for the timer and both Tpac and PAC timer work for me.
I will merge the pull request. There will still be time (during WGLC, IESG review) to fine tune the timer name, if there is a need to.
There’s still more to do on the PR, but sounds like we have a path forward.
Ok, so I will not merge yet.
Updated the PR to use 'PAC timer', and only where necessary. I'm happy with this if you are.
Looks good.
I think we should give the timer a name. Other ICE timers have names, and it also makes it easier to refer to it in future discussions, drafts, and implementations. I previously suggested Tpac. Tupac would also be cool :)
I created a pull request for this,
Note that 'Ta' in 8445 is the interval, not the timer. It uses 'timer Ta' to refer to the actual timer. I'm not sure this change is an improvement, but open to considering it.LGTM

(ICE), for Network Address Translator (NAT) traversal for UDP-based communication.  <ins> When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a  <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE needs to wait enough time to allow peer-reflexive candidates to be discovered.  Accordingly, when a full ICE implementation begins its ICE processing, as described in RFC8445, Section 6.1, it MUST set a  <ins> timer, henceforth known as the PAC timer, to ensure ICE will run for a minimum amount of time before determining failure. </ins> Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting.  This occurs when the agent has Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned  <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should  <ins> fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the PAC timer expires.  However, because most ICE scenarios </ins> require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any.  <ins> Note also that the PAC timer is potentially relevant to the ICE </ins> nomination procedure described in RFC8445, Section 8.1.1.  That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the allow peer-reflexive candidates to be discovered and checked, as noted above.  Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it  <ins> MAY use the PAC timer to do so.  As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the timer elapsing. </ins> 5.


form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the <del> overall ICE process is considered to have failed. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

It's a lot of words, makes the sentence harder to read, and given that this is introductory text, doesn't really clarify the document. I also think we'd have to similarly rewrite several other paragraphs in the intro if we did this, so I'm not in favor of adding the suggested text.
Perhaps, there are a few places that talks about "all pairs", without clarifying that it is for a checklist. So, at the moment, one could read the Introduction saying that ICE failure is typically declared once all pairs associated with the whole session have failed, which is not true. I assume you agree with that? As you have indicated yourself, ICE failure can be declared when all pairs associated with ONE checklist have failed, even if there are other checklists in the Completed state. Anyway, I think my issue is clarified in the "Update to RFC8445" section, so in order to move the draft forward, I am willing to accept ( ) and then leave the Introduction text as it is. I guess one has to assume that the reader of the draft knows ICE well enough to understand when ICE failure etc takes place.
Right, this is non-normative text, so I think we can keep it simple here and be specific (as we already have done) in the 8445 update section.

form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the  <ins> overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote


5.  The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. <del> 6. </del>  This specification makes no requests to IANA.

See URL for details.
Looks good. It's probably good to also add a note, asking the RFC Editor to replace XXX with the Trickle RFC number, once published. Something like: [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of once it has been published.]

5. <ins> [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published.] Trickle ICE I-D.ietf-ice-trickle considers a similar problem, namely whether an ICE agent should allow a checklist to enter the Failed state if more candidates might still be provided by the remote peer. The solution, specified in I-D.ietf-ice-trickle, Section 8, is to wait until an end-of-candidates indication has been received before determining ICE failure. However, for the same reasons described above, the ICE agent may discover peer-reflexive candidates after it has received the end-of- candidates indication, and so the solution proposed by this document MUST still be used even when the ICE agent is using Trickle ICE. Note also that sending an end-of-candidates indication is only a SHOULD-strength requirement, which means that ICE agents will need to implement an backup mechanism to decide when all candidates have been received, typically a timer.  Accordingly, ICE agents MAY use the PAC timer to also serve as an end-of-candidates fallback. 6. </ins> The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations.  <ins> 7. </ins> This specification makes no requests to IANA.


RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions. <del> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </del>  5.

…tion
Section 4.2, verified, calls out the entire cert check for validation, but section 4.3, opportunistic, only talks about skipping the IP validation. It has gone without saying that these are equivalent because the IP is the only thing about the cert being validated, but for implementors, does this mean they can skip the entire cert validation process (meaning the connection will be used even if other errors occur, such as the cert being expired)? I assume yes (no cert checking of any kind), but we should be specific.
I think it's up to implementations. If I look at the opportunistic profile in RFC 7858, it say: I think we should point to that and explain that it's open to the client to determine how opportunistic it wants to be
LGTM

RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions.  <ins> An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  This Opportunistic Privacy Profile similarly applies to DoQ RFC9250.  For this profile, Section 4.1 of RFC7858 explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. A client MAY use information from the SVCB record for "resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5.


connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST <del> use the IP address as the URI host for DoH requests. </del>  Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to

In 6.3 we say: "When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests." There are multiple IP addresses that may be in-play here. We should clarify which is "the IP address" in the case where the Designated Resolver and the Unencrypted Resolver do NOT share an IP. (I take it that this is the IP of the Unencrypted Resolver ?)
Good point!
LGTM

connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST  <ins> use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests. </ins> Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to


(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover <del> designated resolvers using DNS server Service Binding (SVCB, I- D.ietf-dnsop-svcb-https) records: </del>  When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to

From Section 1 Introduction, it is not obvious if the two mechanisms mentioned in the section are alternative or complementary, and how they relate to the DoT, DoQ and DoH requirements introduced in the same section. Section 4 gets into details about DoT and DoQ using IP addresses - it would be good to explain a little more about it in the Intro section. In Section 5, the requirements seem to overlap with draft-ietf-add-svcb-dns. It would be good to further clarify the relationship between the two specifications. Finally, since multiple solutions are presented, some recommendations about when, how and why one mechanism should be used vs the other would be useful to the reader.
LGTM

(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover  <ins> designated resolvers that support these encrypted protocols using DNS server Service Binding (SVCB, I-D.ietf-dnsop-svcb-https) records: </ins> When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to


When DNS clients wish to use encrypted DNS protocols such as DNS- over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over- <del> HTTPS (DoH) RFC8484, they require additional information beyond the IP address of the DNS server, such as the resolver's hostname, non- standard ports, or URI templates.  However, common configuration mechanisms only provide the resolver's IP address during configuration.  Such mechanisms include network provisioning protocols like DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) options RFC8106, as well as manual configuration. </del>  This document defines two mechanisms for clients to discover designated resolvers that support these encrypted protocols using DNS If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a <del> Designated Resolver.  The client can still use other records in the same response if the client can understand all of their mandatory </del>  parameters.  This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols.  For example, if the Unencrypted DNS Resolver 4. When a DNS client is configured with an Unencrypted DNS Resolver IP <del> address, it SHOULD query the resolver for SVCB records for the name "resolver.arpa" before making other queries, in order to use </del>  Encrypted DNS for all other queries, if possible.  Specifically, the client issues a query for "_dns.resolver.arpa." with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. Because this query is for an SUDN, which no entity can claim ownership over, the ServiceMode SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT/DoQ <del> or used to construct the DoH template MUST be provided. </del>  The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" <del> SUDN, to provide a consistent and accurate signal to clients that it </del>  does not have a Designated Resolver. 4.1. suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that <del> will lead to further failed validations. </del>  If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. <del> A client MAY use information from the SVCB record for "resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </del>  5. 6.1. <del> 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 transparent forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows that 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 DNS resolver to use the SVCB information opportunistically. </del>  Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR that can block these connections can prevent clients from switching to use encrypted DNS. <del> 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.  For example, if a DoH resolver provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </del>  While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned

I think there are some interesting open questions about the structure of this document, and some details about how recommendations are described, but the technical components are sound. Section 1: (DoT) [RFC7858], DNS-over-QUIC (DoQ) [RFC9250], or DNS-over-HTTPS (DoH) [RFC8484], they require additional information beyond the IP address of the DNS server, such as the resolver's hostname, non-standard ports, or URI templates. This is arguably true, but none of these things are relevant in the simplest cases for DoT and DoQ using IP addresses (Section 4). In those cases, the purpose of this specification is simply to indicate whether the resolver supports DoT or DoQ. That probably bears mentioning here, ahead of the less common metadata like nonstandard ports. I think this is probably a mistake. The fact that there are two very different mechanisms defined here, both known as DDR, has already generated a fair bit of confusion. The second mechanism (Section 5) also seems largely to be repeating the recommendations in draft-ietf-svcb-dns. Given that these two drafts are entering review together, it might make sense to reconsider how material is split between them. Ideally, I think we would adjust the document so that "DDR" means "query URL", as that is what everyone seems to think it means. Section 3: Most of this text seems redundant with draft-ietf-svcb-dns. I understand the desire to avoid making readers read both documents, but some of the text seems especially duplicative, e.g. understand, it MUST NOT use that record to discover a Designated Resolver. This is repeating the normative definition of "mandatory" from draft-ietf-dnsop-svcb-https. If it must be repeated, the repetition could be flagged (e.g. 'As required by Section 8 of ...'). Section 4: SHOULD query the resolver for SVCB records for the name "URL" before making other queries. Specifically, the client issues a query for URL ... This seems contradictory at a glance. It might be more correct to say '... for SVCB records of a service with a scheme of "dns" and an Authority of "URL" ...'. Also, SVCB-DNS defines the term "Binding Authority" specifically to enable unambiguous specification of DDR, but DDR doesn't use this term. the ServiceMode SVCB response MUST NOT use the "." value for the TargetName. This rationale is mysterious to me. We've just told the resolver that they can place SVCB records on "URL", so it's not at all clear why they can't place AAAA records there as well, and this is all that TargetName means in SVCB. It also doesn't quite address the question of whether TargetName can be "URL", which would be more natural in SVCB. Personally, I don't see the need for this restriction, which I think is a holdover from previous drafts that imposed different semantics on TargetName. Placing AAAA records on "URL" seems like a fine way for the resolver to tell the client what it thinks its own public ingress IPs are. If the authors think this should be prohibited, perhaps they can clarify the rationale (e.g. 'To enable reliable identification of the Designated Resolver for debugging and future extensions, TargetName SHOULD NOT indicate a SUDN.'). Relatedly, if "URL" is not the expected TargetName, this section should probably have a sentence noting that the "speculative A and/or AAAA queries" recommended in Section 5 of draft-ietf-svcb-https are not applicable here. Resolvers, it SHOULD return NODATA for queries to the "URL" SUDN. I think this should say something like 'for queries to the "URL" zone'. Note that NXDOMAIN means there is nothing underneath (RFC 8020), but NODATA does not. Section 4.1: This recommendation is obscure. Perhaps an example of a plausible violation would help. Section 4.1.1: This seems a bit optimistic. For DoQ with resumption "no delay" might be possible, but for DoT a delay of at least 1 RTT is required. Perhaps 'no delay before establishing' would be more precise. Section 4.2: Perhaps cite RFC5280 for subjectAltName? Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). Why? I agree that the client shouldn't retry in a fast loop, but consider a passive attacker who can occasionally become active via some difficult mechanism (e.g. a Kaminsky-type attack). If this attacker can inject a single DDR record with a very long TTL, it can disable DDR passively monitor the DNS queries for a long time. It would be better for the client to retry SVCB resolution more frequently than the (potentially attacker-controlled) TTL, to force an active attacker to be more persistent. I think this should say 'TargetName'. (This is not "the name of a Designated Resolver" under the standard interpretation of TargetName.) 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. I find this confusing. There are potentially four classes of IP addresses involved here: A. The IP of the unencrypted resolver, provided out of band (e.g. via DHCP) B. ipv4hint/ipv6hint C. Additional Section records for TargetName D. Answer Section records for TargetName. This text makes it sound like A-C or B+C have something in common that D does not, but that is not true. In fact, only A is treated specially, and B-D are completely equivalent for DDR. Maybe this text is trying to warn against some implementation mistake? If so, better to make that explicit. Section 4.3: I find this confusing, since the SVCB record is at "URL", not "URL". (Really, it's the SVCB record for "URL", but "dns:" URIs are controversial at best.) Section 5: As discussed earlier, I think it might be better to shrink or eliminate this section. Section 6.1 '"URL" and subdomains'? Are we sure this advice applies to all future uses of the "URL" zone? the SVCB information opportunistically. This seems to contradict Section 4.3 (Opportunistic Discovery), which prohibits the use of the SVCB information in this configuration due to differing IPs of the local and upstream resolvers. Perhaps this should match Section 4.1's language about "implementation-specific policy" and "future mechanism", e.g. "... expects clients to validate the connection via some future mechanism". Section 7: Typo: "provides provides" unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. I think the caveat needs to be removed. Otherwise, an attacker on the transport path can cause verification to fail, in order to trigger unencrypted fallback. DNS MUST NOT provide differentiated behavior based on the HTTP path alone ... I think the language on this in draft-ietf-add-svcb-dns is more precise and complete. For example, this description does not cover alternate port numbers, and the use of "separate resolver IP addresses" is unclear (it means "separate unencrypted resolver IP addresses"). The language here should probably match, or be removed and rely on the other draft.
LGTM

When DNS clients wish to use encrypted DNS protocols such as DNS- over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over-  <ins> HTTPS (DoH) RFC8484, they can require additional information beyond the IP address of the DNS server, such as the resolver's hostname, alternate IP addresses, non-standard ports, or URI templates. However, common configuration mechanisms only provide the resolver's IP address during configuration.  Such mechanisms include network provisioning protocols like DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) options RFC8106, as well as manual configuration. </ins> This document defines two mechanisms for clients to discover designated resolvers that support these encrypted protocols using DNS If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a  <ins> Designated Resolver, in accordance with Section 8 of I-D.ietf-dnsop- svcb-https.  The client can still use other records in the same response if the client can understand all of their mandatory </ins> parameters.  This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols.  For example, if the Unencrypted DNS Resolver 4. When a DNS client is configured with an Unencrypted DNS Resolver IP  <ins> address, it SHOULD query the resolver for SVCB records of a service with a scheme of "dns" and an Authority of "resolver.arpa" before making other queries.  This allows the client to switch to using </ins> Encrypted DNS for all other queries, if possible.  Specifically, the client issues a query for "_dns.resolver.arpa." with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. Because this query is for an SUDN, which no entity can claim ownership over, the ServiceMode SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT/DoQ  <ins> or used to construct the DoH template MUST be provided.  This ensures that different designated resolver configurations can be correctly associated with IP addresses in A and AAAA records.  As such, clients MUST NOT perform A and AAAA queries for "resolver.arpa". </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"  <ins> zone, to provide a consistent and accurate signal to clients that it </ins> does not have a Designated Resolver. 4.1. suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that  <ins> will lead to further failed validations.  The client MAY issue new queries if the SVCB record's TTL is excessively long (as determined by client policy) to minimize the length of time an intermittent attacker can prevent use of encrypted DNS. </ins> If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses.  <ins> A client MAY use information from the SVCB record for "_dns.resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5. 6.1.  <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or any subdomains) 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 transparent forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows that the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients to validate the connection via some future mechanism. </ins> Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR that can block these connections can prevent clients from switching to use encrypted DNS.  <ins> Encrypted DNS Resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based solely on metadata in the SVCB record, such as the HTTP path or alternate port number, which are parameters that an attacker could modify.  For example, if a DoH resolver provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </ins> While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned


If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa", <del> the SVCB records SHOULD contain at least one "ipv4hint" and/or "ipv6hint" keys.  These address hints indicate the address on which the corresponding Encrypted Resolver can be reached and avoid additional DNS lookup for the A and AAAA records of the Encrypted Resolver name. </del>  4.1. address, clients MAY choose to opportunistically use the Encrypted Resolver even without this certificate check (opportunistic).  4.2. There are situations where authenticated discovery of encrypted DNS

Added some text to address and reference to SVCB draft with regards to hints explained why resolvers should provide hints clients MUST subject resolved IP addresses to the same security requirements as other IP address
I think we should invert this advice. We should recommend not including IP hints, and instead instruct recursive resolvers to append the relevant A and AAAA records in the Additional Section. The IP hints are strictly a performance hack when using a legacy non-SVCB-aware recursive resolver. This text is specifically applicable only to SVCB-aware recursive resolvers, so we can tell them to do it the right way instead.
NAME 's suggestion sounds good to me. Let's emphasize that the addresses should come in the same response as the SVCB record, with a preference for Additional Section.
I reviewed the draft on the git and came with a similar comment. preventing the use of ipv4hint My first comment is that we should favor IPv6 over IPv4 in our example. My second comment is that the first example uses a local target that is using a hint mentioned as SHOULD NOT in the svcb specification. The scenario I see that might be useful are: From the IP address of the unencrypted resolver: when the encrypted resolver has a different IP address than the one advertised. From the name of encrypted resolvers. Duplication of the IP address adds operational complexity and is a source of misconfiguration and makes updates harder. This may result in the resolver being unreachable and I do not think we should take that path even with a low probability. If I try to balance this with the potential outcomes, it at most reduces the connectivity of an additional round trip. Firstly, this does not sound - at least to me - as a big issue. Then it seems to me the same results can be achieved safely using additional data RRSets. If the additional round trip is performed, it is also likely that resolutions will prefetch the first connection performed by the end user. In any case, I do not see the benefit provided by the ip hint to compete with its disadvantages.
I have updated the text accordingly. The description of the need for an additional name resolution still mentions this will result if there are no A/AAAA or IP hints included because it's true, but the SHOULD is for the A/AAAA. I have also removed the IP hints from the examples altogether.
This PR also address the duplicate issue regarding adding ipv6 hints.
sure, thanks for the update.
We should make sure that any examples including an ipv4hint also include an ipv6hint or only include an ipv6hint. (per URL)
Address this then trivialized this by simply not including IP hint in the first place.
Migrated from original DEER issue: URL
From Ben: Strictly speaking, a compliant SVCB client is expected to perform the additional lookups anyway. The hints just avoid a delay while those queries complete. If you think it's important to "skip" those followup queries, we would have to make a deeper change. Otherwise, you could say "avoid waiting for DNS lookup...".
From Eliot Lear: The draft currently reads: When responding to these special queries for "URL", the SVCB records SHOULD contain at least one "ipv4hint" and/or "ipv6hint" keys. What happens when neither hint is present? The client should just query the local infrastructure, right? You almost say that, but not quite.
This is an interesting case. There are threat model implications to always querying the template name elsewhere. I will draft up something to address that includes a commentary on the implications for the client.

If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa",  <ins> the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section. This will allow the DNS client to make queries over an encrypted connection without waiting to resolve the Encrypted Resolver name per I-D.ietf-dnsop-svcb-https.  If no A/AAAA records or SVCB IP address hints are included, clients will be forced to delay use of the Encrypted Resolver until an additional DNS lookup for the A and AAAA records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use). </ins> 4.1. address, clients MAY choose to opportunistically use the Encrypted Resolver even without this certificate check (opportunistic). <ins> If resolving the name of an Encrypted Resolver from an SVCB record 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 Encrypted Resolver name. </ins> 4.2. There are situations where authenticated discovery of encrypted DNS


There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes <del> Unencrypted Resolvers on non-public IP addresses whose identity cannot be confirmed using TLS certificates. </del>  Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address <del> of the Unencrypted Resolver, and that IP address is a private address (such as those defined in RFC1918).  This approach can be used for DoT or DoH. If the IP addresses of the Encrypted and Unencrypted Resolvers are not the same, or the shared IP address is not a private IP address, the client MUST NOT use the Encrypted Resolver opportunistically. </del>  5.

The document was inconsistent, with the authenticated section saying same IP addresses MAY use opportunistic, but the opportunistic section saying the same IP address exception was for private IP addresses only.
Forgot to mention this is to address issue
From Eliot Lear: Can you explain the following statement? and that IP address is a private address (such as those defined in [RFC1918] I ask because it appears that you are using private addresses as some sort of security property. I recommend against that, not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans, and of course, private network addresses don’t really have any positive security properties to speak of. The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates. Of course, public trust anchors won’t allow it, but even private ones will have some difficulty. Your average bank might have multiple overlapping zones of trust - it’s a pretty hairy scene.
The intent of that section is to say that "if you were going to send this local IP address unencrypted traffic anyway, using encryption to that same IP address is a net improvement to the threat model." It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses. I can try to rephrase this section to be more accurate. Please comment again if I missed the point.
In reviewing the opportunistic section, I see what you mean Eliot. The need to use "private IP" as a feature is not necessary since same-IP opportunistic discovery is permitted whether the address is private or not. However, the draft conflicted on that point. I have a PR to remove the local IP address as a decision branch and make the draft consistent.
With the PR merged, I am closing this issue.

There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes  <ins> Unencrypted Resolvers on non-public IP addresses such as those defined in RFC1918 whose identity cannot be confirmed using TLS certificates. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address  <ins> of the Unencrypted Resolver.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.


records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use).  4.1. In order to be considered an authenticated Designated Resolver, the Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS <del> certficates.  If a deployment uses a different hostname for one </del>  protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client.

This addresses the remaining portions of not address by a prior PR
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.

records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use). <ins> If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" SUDN. </ins> 4.1. In order to be considered an authenticated Designated Resolver, the Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS  <ins> certificates.  If a deployment uses a different hostname for one </ins> protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. <ins> The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers.  The intent of the SUDN is to allow clients to communicate with the Unencrypted Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication.  For more context, see the rationale behind "ipv4only.arpa" in RFC8880. </ins>


Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. <del> The following is an example of an SVCB record describing a DoH server: </del>  <del> The following is an example of an SVCB record describing a DoT server: </del>  If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https.  This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https.  If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa",

This PR addresses issues and to ensure smoother implementation and deployment (avoid name resolution deadlock and clearly illustrate why "." cannot be used for target names when discovering Designated Resolvers using the URL SUDN).
The existing examples in the document all use the "." for the SvcDomainName. Per the SVCB draft section 2.5.2, this would mean that queries for the SUDN that contain this value (".") would mean that the DoH template should use the SUDN as the domain name. While the examples do not query the SUDN, meaning the examples themselves are not erroneous, there is no useful example of the SUDN case. We need to add some examples showing an SUDN query response that carries the DoH domain name in the SvcDomainName field instead of the ".".
RFC8484 section 10, para 3 talks about the need for servers to ensure client do not need DNS lookups to validate the server's certificate to avoid deadlocks. DDR should reference this and reaffirm the need to have resolvers help clients avoid this deadlock.
Thanks! These examples are very useful!

Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns.  <ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": </ins>  <ins> The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.example.net": </ins> If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> 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. </ins> This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. <ins> Because this query is for an SUDN, which no entity can claim ownership over, the SVCB response MUST NOT use the "." value for the SvcDomainName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.resolver.arpa": </ins> If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa",


This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from <del> unencrypted DNS to encrypted DNS when only the IP address of an encrypted resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </del>  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. When only an IP address of an Unencrypted Resolver is known, the client queries a special use domain name to discover DNS SVCB <del> records associated with the Unencrypted Resolver (bootstrapping). </del>  <del> When the hostname of an encrypted DNS server is known, the client </del>  requests details by sending a query for a DNS SVCB record.  This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver

I've made a few changes to terms used to correct some accidental lies: the starting IP address could be of an Encrypted Resolver, but does not have to be, discovery by SVCB may discover one or more resolver which may or may not be the original resolver, etc.

This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from  <ins> unencrypted DNS to encrypted DNS when only the IP address of a resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </ins> 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. When only an IP address of an Unencrypted Resolver is known, the client queries a special use domain name to discover DNS SVCB  <ins> records associated with one or more Encrypted Resolvers the Unencrypted Resolver has designated for use when support for DNS encryption is requested (bootstrapping). </ins>  <ins> When the hostname of an Encrypted Resolver is known, the client </ins> requests details by sending a query for a DNS SVCB record.  This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver


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 <del> Resolver and such an active attack. </del>  While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such

In the security considerations, we should note that the DDR query can be made repeatedly in case it got a negative answer before, to still detect cases where the record had been dropped or blocked before
For authentication to matter, it generally has to operate without fallback. Currently the text is not very clear on this point, but it sure seems like IP-authenticated mode is expected to fall back to cleartext if no upgrade is possible. I think we need to clarify the use case for an authenticated mode, or abandon the distinction between opportunistic and authenticated. In my view, authenticated mode only makes sense if (1) the resolver is identified by its IP address AND (2) the system knows a priori that this resolver supports encrypted DNS, so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker. This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names (Section 5) or opportunistic instead.
Currently, this is what we say (which I now see a grammatical error in, but there it is): We don't say anything else because that would be out of WG scope. The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS. The stub resolver's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business. Look at this through a common OS scenario: the OS stub resolver learns an IP address from DHCP, and it's a public IP address (my old ISP did this). It knows of no other resolvers because the user doesn't know what DNS is and that's the default configuration (use network recommendation). If I try to use DDR and I get no answer back, then I'm in the same position as I was before DDR: I know of no other resolver, so I either have to use this one or have no DNS resolutions. DDR did not introduce that conundrum; it offers clients a way out of it when DNR is not present and there is no plain-text DNS attack present. The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text. I do not agree this scenario is sufficiently narrow to drop. Is your concern over the usefulness of the scenario, or over naming it "authenticated"? I am open to suggestions on the latter; I strongly disagree with the former.
Both. How is this information useful to the client? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated, when the resolver is identified by IP address. As for the name, RFC 7435 is the reference. I find it a bit confusing, but here's some of the relevant text: The "authenticated" section does not seem to describe an "authenticated" protocol by this definition, because it does not provide a downgrade-resistant method to determine that authentication is expected to work.
Please suggest a more accurate name then please. I do agree behavior naming should be consistent with other documents. Your bar for useful is apparently different from mine. Before DDR, a client configured only with an IP address had only unencrypted DNS as an option. With DDR, the client can possibly encrypt that connection. A transient attacker would have to have been present for the initial SVCB discovery to prevent that; an attacker arriving after DDR has taken place will be kept out of the loop. In the worst case, a client is returned to square one. I do not agree that just because a mechanism can be prevented means the mechanism provides no value. It doesn't have to. In the common case, the client is forced by lack of knowledge to use unencrypted DNS. If it can from that default configuration divine encrypted DNS configuration, that's a net positive. Resolver selection is out of scope and has nothing to do with it.
I've updated to address this question by reformulating the concept of authentication, and being much more explicit about the threat model. Yes, that's a good step, but it doesn't rely on authentication. This is a very helpful observation. I've incorporated it in .
I believe this particular issue is largely overtaken by events. Particularly, I think we've added some clarity and escape hatches with , and protections with .
LGTM, one comment which is non-blocking.

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  <ins> 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. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such


When a client discovers Designated Resolvers, it learns information such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service <del> Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. </del>  The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- <del> D.schwartz-svcb-dns.  However, if any protocol does not involve some </del>  form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.

Addressing
Once it's published, we should reference the official draft for draft-schwartz-svcb-dns

When a client discovers Designated Resolvers, it learns information such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service  <ins> Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I-  <ins> D.ietf-add-svcb-dns.  However, if any protocol does not involve some </ins> form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.