[Adding dnsop WG in the loop] From: Olafur Gudmundsson <[email protected]> Date: Wednesday, 25 March 2026 at 14:40 To: RFC Errata System <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Eric Vyncke (evyncke) <[email protected]>, Andrew Sullivan <[email protected]>, Ondřej Surý <[email protected]>, [email protected] <[email protected]> Subject: Re: [dnsext] [Technical Errata Reported] RFC3645 (8773)
This is a blast from the past. After re-reading RFC3645 a few times, I think this errata is valid My question to those who understand GSS-API better is if a warning should be added to section 4.x? as well but that may be an overkill. Other than the typo fix below I think it should be accepted. Olafur (DNSEXT chair when this RFC as worked on) > On Feb 20, 2026, at 04:30, RFC Errata System <[email protected]> > wrote: > > The following errata report has been submitted for RFC3645, > "Generic Security Service Algorithm for Secret Key Transaction Authentication > for DNS (GSS-TSIG)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8773 > > -------------------------------------- > Type: Technical > Reported by: Ondřej Surý <[email protected]> > > Section: 7 > > Original Text > ------------- > This document describes a protocol for DNS security using GSS-API. > The security provided by this protocol is only as effective as the > security provided by the underlying GSS mechanisms. > > All the security considerations from RFC 2845, RFC 2930 and RFC 2743 > apply to the protocol described in this document. > > Corrected Text > -------------- > This document describes a protocol for DNS security using GSS-API. > The security provided by this protocol is only as effective as the > security provided by the underlying GSS mechanisms. > > All the security considerations from RFC 2845, RFC 2930 and RFC 2743 > apply to the protocol described in this document. > > The mechanism in Section 4.1.1 effectively allows pre-authentication > oracle. This allow a pre-authentication information disclosure in s/allow/allows/ > GSS-API TKEY negotiation. An unauthenticated attacker can determine > which GSSAPI session keynames are currently active in the server's > dynamic keyring by observing differential error codes in TKEY responses. > > Notes > ----- > The other angle would be to change the section 4.1.1 to disallow reporting > the BADNAME error and handle everything uniformly. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) 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. > > -------------------------------------- > RFC3645 (draft-ietf-dnsext-gss-tsig-06) > -------------------------------------- > Title : Generic Security Service Algorithm for Secret Key > Transaction Authentication for DNS (GSS-TSIG) > Publication Date : October 2003 > Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. > Hall > Category : PROPOSED STANDARD > Source : DNS Extensions > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > dnsext mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
