Hi Ondřej, Without digging into the technical merits of OLD vs NEW, the text you flagged reflects the intended behavior as further confirmed in Section 10:
Section 5.4 recommends logging these as errors and continuing to wait for a signed response until the request times out. I don't think filling an errata is appropriate here. This errata falls under the following case [1]: "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should generally be Rejected. Significant clarifications should not be handled as errata reports and need to be discussed by the relevant technical community." My current take is to reject it. Cheers, Med [1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : mercredi 24 juin 2026 22:55 > À : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected]; > [email protected]; [email protected] > Cc : [email protected]; [email protected]; [email protected] > Objet : [Technical Errata Reported] RFC8945 (9014) > > > The following errata report has been submitted for RFC8945, > "Secret Key Transaction Authentication for DNS (TSIG)" > > -------------------------------------- > Type: Technical > Reported by: Ondřej Surý <[email protected]> > > Section 5.4 says: > > Original Text > ------------- > Instead, the client SHOULD log an error and continue to wait for a > signed response until the request times out. > > Corrected Text > -------------- > Instead, the client SHOULD log an error and MUST regard the > message as corrupt and discard it. > > Notes > ----- > The previous sentence says that the response might have been > spoofed or manipulated. > > > Regardless of the RCODE, a message containing a TSIG RR that is > unsigned as specified in Section 5.3.2 or that fails verification > SHOULD NOT be considered an acceptable response, as it may have > been spoofed or manipulated. > > If the connection between client and server is under attack than > waiting for more spoofed or manipulated responses is the worst > thing that the client can do is to wait for more spoofed responses > to come. > > There are basically two scenarios: > - off-path attacker guessed port+id -> and we certainly don't want > to wait for more spoofed responses to come > - on-path attacker -> all is lost anyway, waiting will not help > > Instructions: > ------------- > This erratum is currently posted as "Reported". Please use "Reply > All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party will log in to change the > status and edit the report, if necessary. > > -------------------------------------- > RFC8945 (draft-ietf-dnsop-rfc2845bis) > -------------------------------------- > Title : Secret Key Transaction Authentication for > DNS (TSIG) > Publication Date : November 2020 > Author(s) : F. Dupont, S. Morris, P. Vixie, D. Eastlake > 3rd, O. Gudmundsson, B. Wellington > Category : Internet Standard > Source : dnsop (ops) > Stream : IETF > Verifying Party : IESG ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
