The incremental effort to implement SHA-224 if you are implementing SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use and you can use SHA-256 with truncation to 224 or even fewer bits.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Sat, May 9, 2020 at 9:52 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > To follow up on Stephen's comments, a table was added to 2845bis to > list all the algorithms that are currently in the IANA registry, > along with suggestions for implementation. This was the first version: > > Requirement Name > ----------- ------------------------ > Optional HMAC-MD5.SIG-ALG.REG.INT > Optional gss-tsig > Mandatory hmac-sha1 > Optional hmac-sha224 > Mandatory hmac-sha256 > Optional hmac-sha384 > Optional hmac-sha512 > > During the IESG review (I think it was the SECDIR review), there was > a meltdown over implementing SHA-1. But SHA-1 is in use currently. > My suggestion was to do a variation describing implementation use. > This is what I came up with(so blame me): > > Name Implementation Use > ------------------------ -------------- --------------- > HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT > gss-tsig MAY MAY > hmac-sha1 MUST NOT RECOMMENDED > hmac-sha224 MAY NOT RECOMMENDED > hmac-sha256 MUST RECOMMENDED > hmac-sha256-128 MAY MAY > hmac-sha384 MAY MAY > hmac-sha384-192 MAY MAY > hmac-sha512 MAY MAY > hmac-sha512-256 MAY MAY > > On the use side, these are mostly guesses. We would love to hear > what the WG has to say about this. > > thanks > tim > > > On Mon, May 4, 2020 at 2:07 PM Stephen Morris <sa.morr...@gmail.com> > wrote: > >> >> > On 4 May 2020, at 19:00, internet-dra...@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Domain Name System Operations WG of >> the IETF. >> > >> > Title : Secret Key Transaction Authentication for DNS >> (TSIG) >> > Authors : Francis Dupont >> > Stephen Morris >> > Paul Vixie >> > Donald E. Eastlake 3rd >> > Olafur Gudmundsson >> > Brian Wellington >> > Filename : draft-ietf-dnsop-rfc2845bis-08.txt >> > Pages : 29 >> > Date : 2020-05-04 >> >> >> The update addresses to the draft comments made during the IESG review. >> There were a fair number of these which led to a number of changes to the >> document. These are listed below. >> >> One significant change is that the list of acceptable algorithms has been >> extended, and WG approval for this is sought. >> >> Stephen >> >> >> >> >> Comments from Roman Danyliw >> --- >> > ** Section 1.3. Per “In 2017, two nameservers strictly following that >> document (and the related [RFC4635]) were discovered to have security >> problems related to this feature”, consider providing a reference to the >> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) >> >> I’ve added these (and one other related CVE) as informative references. >> Using just the CVE number as a reference seemed a bit spartan, so I’ve >> added a title to each incident. As the description of the CVEs in Mitre’s >> database don’t contain a title (only a description, which can be rather >> long), I’ve taken the title from ISC’s KnowledgeBase (for the BIND CVEs) >> and from the Knot release notes (for the Knot CVE). >> >> >> > ** Section 6. Per “SHA-1 collisions have been demonstrated so the MD5 >> security considerations apply to SHA-1 in a similar manner. Although >> support for hmac-sha1 in TSIG is still mandatory for compatibility reasons, >> existing uses should be replaced with hmac-sha256 or other SHA-2 digest >> algorithms [FIPS180-4], [RFC3874], [RFC6234]. >> > >> > -- It’s worth repeating those MD5 security considerations here >> >> I’m not really keen on doing this, since the security considerations in >> RFC 6151 cover two paragraphs and including them - or even a summary of >> them - would detract from the flow of the document. However, I have >> explicitly included a reference to RFC 6151 in the text. >> >> >> > -- (from Magnus Nystrom’s SECDIR review, thanks Magnus!) it’s worth >> including references to the recent SHA-1 cryptoanalysis provided in the >> SECDIR review >> >> Added references to just one of these papers (”SHA1 is a Shambles”). >> We’re not doing a general analysis of the algorithms, so a simple reference >> to a paper than describes a SHA1 collision is all that is needed. (As an >> aside, the paper doesn't give the date of publication, so I had to search >> the Web looking for references to it. I think I’ve got the date correct, >> but I’d be grateful for a double-check.) >> >> >> > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). >> >> Done - see Table 2 >> >> >> > ** Section 10. Per “For all of the message authentication code >> algorithms listed in this document, those producing longer values are >> believed to be stronger”, as noted in Magnus’s SECDIR review, this could be >> misconstrued as the algorithm choice not the digest length provides the >> security. Recommend rephrasing (or making some statement >> >> I’ve reworded this paragraph (in section 10). It now reads: >> >> "Although the strength of an algorithm determines its security, there >> have been some arguments that mild truncation can strengthen a MAC by >> reducing the information available to an attacker. However, excessive >> truncation clearly weakens authentication by reducing the number of >> bits an attacker has to try to break the authentication by brute >> force [RFC2104]." >> >> >> > ** Editorial >> > -- Section 4.3.2. Per “When verifying an incoming message, this is the >> message after the TSIG RR and been removed and the ARCOUNT field has been >> decremented.”, this sentence doesn’t parse (is missing a word). >> > >> > -- Section 4.3.2. Per “A whole and complete DNS message in wire >> format.”, this isn’t a sentence. >> >> Section 4.3.2 has been reworded to address these issues. >> >> >> >> Comments from Benjamin Kaduk >> >> > Thanks for putting together this update; it's good to see the security >> > issue getting closed off in the udpated spec, and progression to full >> > Internet Standard! I do have several substantive comments (as well as >> > some minor/nit-level ones), many of which are listed here at the top but >> > a few of which are interspersed in the per-section comments. >> > >> > >> > I considered making this a Discuss point, but it should be pretty >> > uncontroversial and I trust that the right thing will happen even if I >> > don't: there's a couple lingering remnants of SHA-1 being the >> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 and >> > 10 (further detailed in the per-section comments). >> >> The document now mentions SHA1 collisions and notes that the MD5 security >> considerations apply to SHA1. It also mentions that support for SHA1 is >> mandatory for compatibility reasons but in existing uses it should be >> replaced by a stronger one. >> >> >> > I also initially had made the following point a Discuss-level point, but >> > decided to not do so since I don't remember any BCP-level guidance >> > relating to cross-protocol attacks. Nevertheless, I strongly encourage >> > the authors to consider that cryptographic best practice is to use any >> > given key with exactly one cryptographic algorithm. The record format >> > listed in Section 4.2 has the key name and algorithm as separately >> > conveyed, which would allow for a given key to be used with all >> > implemented algorithms. We should include some discussion that it's >> > best to only use a single algorithm with any given key. >> >> The following text has been added to the Security Considerations section: >> >> "To prevent cross-algorithm attacks, there SHOULD only be one >> algorithm associated with any given key name." >> >> >> > We also have a 16-bit wide field for "Fudge", which (since it counts >> > seconds) corresponds to a maximum window of something like +/- 18 hours; >> > it's hard to believe that we really want to give people the rope to >> > allow for that much time skew. (Yes, I understand that implementations >> > will set something sane in practice but that doesn't necessarily mean >> > that the protocol still has to allow it.) >> >> That was set in the original RFC 2845. Although I agree with the >> comments, changing the size of that field would be a significant >> undertaking. However, section 10 does state that the RECOMMENDED fudge >> value in most circumstances is 300 seconds. >> >> >> > Our authoritative list of algorithm names (Table 1) is rather divorced >> > from the references to be consulted for the individual hash algorithms >> > to be used with the HMAC procedure. The ones used here are sufficiently >> > well-known that I'm not terribly concerned about it, though. >> >> The first paragraph of the IANA considerations section lists the >> algorithms and references to where they are described, and I didn’t want to >> duplicate the information. >> >> >> > Abstract >> > >> > The title says "DNS" but maybe the body of the abstract should as well? >> >> In the abstract, changed: >> >> "It can be used to authenticate dynamic updates as coming from an >> approved client" >> >> to >> >> "It can be used to authenticate dynamic updates to a DNS zone as coming >> from an approved client" >> >> >> > Section 1.1 >> > >> > Some of this language feels like it might not age terribly well, e.g., >> > "this can provide" or "[t]here was a need". >> > >> > addresses that need. The proposal is unsuitable for general server >> > to server authentication for servers which speak with many other >> > servers, since key management would become unwieldy with the number >> > of shared keys going up quadratically. But it is suitable for many >> > resolvers on hosts that only talk to a few recursive servers. >> >> Changed to: >> >> "The authentication mechanism proposed here provides a >> simple and efficient authentication between clients and local >> servers >> by using shared secret keys to establish a trust relationship >> between >> two entities. Such keys must be protected in a manner similar to >> private keys, lest a third party masquerade as one of the intended >> parties (by forging the MAC). The proposal is unsuitable for >> general >> server to server authentication for servers which speak with many >> other servers, since key management would become unwieldy with the >> number of shared keys going up quadratically. But it is suitable >> for >> many resolvers on hosts that only talk to a few recursive >> servers.” >> >> >> > Should zone transfers be mentioned here as well? >> >> Zone transfers are mentioned in the preceding paragraph. >> >> >> > Section 1.2 >> > >> > I don't understand the motivation for changing terminology from MACs to >> > "signatures"; they're still MACs even though they're transaction-based.. >> >> The mention of signatures in section 1.2 is intended as a link between >> the name of the RR (TSIG or Transaction Signature) and the term MAC used in >> the rest of the document. >> >> >> > MAC of the query as part of the calculation. Where a response >> > comprises multiple packets, the calculation of the MAC associated >> > with the second and subsequent packets includes in its inputs the MAC >> > for the preceding packet. In this way it is possible to detect any >> > interruption in the packet sequence. >> > >> > I suggest mentioning the lack of mechanism to detect truncation of the >> > packet sequence. >> >> That is a fair point. I’ve modified the last sentence to read: >> >> "In this way it is possible to detect any interruption in the packet >> sequence, >> although not its premature termination." >> >> >> > Section 4.2 >> > >> > NAME The name of the key used, in domain name syntax.. The name >> > should reflect the names of the hosts and uniquely identify the >> > key among a set of keys these two hosts may share at any given >> > time. For example, if hosts A.site.example and >> > B.example.net >> > >> > share a key, possibilities for the key name include >> > <id>.A.site.example, <id>..B.example.net, and >> > <id>.A.site.example.B..example.net >> <http://A.site.example.B.example.net>. It should be possible for >> > more than one key to be in simultaneous use among a set of >> > interacting hosts. >> > >> > I'd suggest adding a note along the lines of "This allows for periodic >> > key rotation per best operational practices, as well as algorithm >> > agility as indicated by [BCP201].” >> >> Added. >> >> >> > The name may be used as a local index to the key involved and >> > it is recommended that it be globally unique. Where a key is >> > >> > (nit?): this feels more like a "but" than an "and", to me. >> >> Well spotted. I also think it is more “but” than “and” >> >> >> > * MAC Size - an unsigned 16-bit integer giving the length of >> > MAC field in octets. Truncation is indicated by a MAC size >> > less than the size of the keyed hash produced by the >> > algorithm specified by the Algorithm Name. >> > >> > nit: I would suggest "output size", as there are potentially a few >> > different sizes involved (key size, block size, and output size, for >> > starters, though I think the possibility of confusion here is low). >> >> I disagree here. “MAC Size” is an unambiguous reference to this field, >> and the other size mentioned - that of the keyed hash is, I think, also >> unambiguous. >> >> >> > * Other Len - an unsigned 16-bit integer specifying the length >> > of the "Other Data" field in octets. >> > >> > * Other Data - this unsigned 48-bit integer field will be >> > empty unless the content of the Error field is BADTIME, in >> > which case it will contain the server's current time as the >> > number of seconds since 00:00 on 1970-01-01 UTC, ignoring >> > leap seconds (see Section 5.2..3). >> > >> > I'm slightly confused at the interplay between the explicit length field >> > and the "empty unless" directive. Does this mean that the only allowed >> > values in the "Other Len" are 0 and 6? Does "empty" mean "length-zero”? >> >> I’ve rewritten this slightly in a bid to make it clearer that “Other >> Data” being empty means that “Other Len” is zero.. >> >> >> > Section 4.3.1 >> > >> > Only included in the computation of a MAC for a response message (or >> > the first message in a multi-message response), the validated request >> > MAC MUST be included in the MAC computation. If the request MAC >> > failed to validate, an unsigned error message MUST be returned >> > instead. (Section 5.3.2). >> > >> > side note: while Section 5.3.2 specifies how to create an unsigned error >> > message, it looks like Section 5.2 (and subsections lists specific >> > RCODEs that are to be used. >> >> That is the case. Section 4 is a description of the TSIG RR and its >> fields. Section 5 describes the contents of the fields in various >> situations (client transmission, server reception, server transmission, >> client reception). >> >> >> > Section 4.3.2 >> > >> > When verifying an incoming message, this is the message after the >> > TSIG RR and been removed and the ARCOUNT field has been decremented. >> > If the message ID differs from the original message ID, the original >> > message ID is substituted for the message ID. (This could happen, >> > for example, when forwarding a dynamic update request.) >> > >> > I trust (based on this text having survived while going for full IS) >> > that there are no interesting record-keeping considerations with respect >> > to knowing the message ID(s) to substitute, in the "forwarding a >> > dynamic-update request" case, presumably since this is just the field >> > from the TSIG RDATA and not some externally retained state. >> >> That is correct - the original ID is stored in the TSIG record’s RDATA >> and it is from there that the original ID is retrieved when a substitution >> is made. >> >> >> > Section 4.3.3 >> > >> > The RR RDLEN and RDATA MAC Length are not included in the input to >> > MAC computation since they are not guaranteed to be knowable before >> > the MAC is generated. >> > >> > I appreciate that this is explicitly noted; there are some security >> > considerations regarding the non-inclusion of the (truncated) mac length >> > as input, though. The local truncation policy helps here, but not 100%. >> >> OK >> >> >> > For each label type, there must be a defined "Canonical wire format" >> > >> > Just to check my understanding: label types only come into play for the >> > two fields that are in domain name syntax, key name and algorithm name? >> >> There was actually an error in the text here: RFC 4034 section 6.1 is >> concerned with Canonical Name Order. It is section 6.2 that details the >> canonical wire format - I’ve changed the reference. >> >> Going back to the original point, yes, that is correct. Label type 00 is >> uncompressed name. (11 is a compressed name, and label types 01 and 10 are >> discouraged - see RFC 6891 section 5). >> >> >> > Section 5.1 >> > >> > the server. This TSIG record MUST be the only TSIG RR in the message >> > and MUST be last record in the Additional Data section. The client >> > >> > (Is there anything else that tries to insist on being the last record in >> > the additional data section? I guess it doesn't really make sense to >> > try to Update: 1035 just to note this requirement.) >> >> Not to our knowledge. >> >> >> > MUST store the MAC and the key name from the request while awaiting >> > an answer. >> > >> > [This is going to end up alongside the request-ID that it has to store >> > already, right?] >> >> Yes. The request MAC is included as one of the components used by the >> server to generate the response - which should be encoded using the same >> key as used in the request. >> >> >> > Note that some older name servers will not accept requests with a >> > nonempty additional data section. Clients SHOULD only attempt signed >> > transactions with servers who are known to support TSIG and share >> > some algorithm and secret key with the client -- so, this is not a >> > problem in practice. >> > >> > (The context in which this "SHOULD" appears makes it feel like it's >> > repeating an admontion from elsewhere and not the only instance of the >> > requirement, in which case a reference might be appropriate.) >> >> I’ve removed this paragraph. The reference to older name servers is now >> completely out of date (it was a carry-over from the original 20-year old >> text). The rest of the paragraph seems superfluous - rather like stating >> that TCP clients should only connect to servers that support TCP. >> >> >> > Section 5.2 >> > >> > If the TSIG RR cannot be understood, the server MUST regard the >> > message as corrupt and return a FORMERR to the server. Otherwise the >> > server is REQUIRED to return a TSIG RR in the response. >> > >> > As written, this could be read as an attempt to make a normative >> > requirement of servers that do not implement this spec. Presumably it's >> > just restating a requirement of the core protocol, though? >> >> It is the core protocol. >> >> I see your point though. However, by implication we are talking about a >> server that implements TSIG. >> >> >> > Section 5.2.2 >> > >> > Using the information in the TSIG, the server should verify the MAC >> > by doing its own calculation and comparing the result with the MAC >> > received. If the MAC fails to verify, the server MUST generate an >> > >> > Is there any other way to verify the MAC? (Should this be a "MUST >> > verify”?) >> >> Well spotted, it should be a “MUST” - changed. >> >> >> > Section 5.2.2.1 >> > >> > When space is at a premium and the strength of the full length of a >> > MAC is not needed, it is reasonable to truncate the keyed hash and >> > use the truncated value for authentication. HMAC SHA-1 truncated to >> > 96 bits is an option available in several IETF protocols, including >> > IPsec and TLS. >> > >> > Also Kerberos, where it was the strongest option for a while and we had >> > to define a new encryption type to provide a better option (RFC 8009). >> > >> > This text seems to be implying that HMAC SHA-1 truncated to 96 bits is a >> > recommendable option, which is ... far from clear. I'd prefer to have a >> > note that this specific truncation was appropriate when initially >> > specified but may not provide a security level appropriate for all cases >> > in the modern environment, or preferrably to just change the reference >> > to (e.g.) SHA-384-192 or SHA-256-128. >> >> Added the following an the end of the paragraph: >> >> However, while this option is kept for backwards compatibility, >> it may not provide a security level appropriate for all cases >> in the modern environment. In these cases, it is preferable to >> use a hashing algorithm such as SHA-256-128, SHA-384-192 >> or SHA-256-128 [RFC4868]. >> >> I’ve also added the algorithms “hmac-sha256-128”, “hmac-sha384-192” and >> “hmac-sha512-256” as optional algorithms to the algorithm table. >> >> >> > This is sent when the signer has truncated the keyed hash output >> > to an allowable length, as described in [RFC2104], taking initial >> > octets and discarding trailing octets. TSIG truncation can only >> > >> > (Or when an on-path attacker has performed truncation.) >> >> True, but an on-path attacker can manipulate the message in any way >> possible. I’m not sure whether adding this caveat will add anything to the >> document. >> >> >> > Section 5.2.3 >> > >> > (BADTIME). The server SHOULD also cache the most recent time signed >> > value in a message generated by a key, and SHOULD return BADTIME if a >> > message received later has an earlier time signed value. A response >> > >> > (But there's no fudge factor on this check, other than the inherent >> > limit of seconds granularity, as alluded to by the last paragraph of >> > this section?) >> >> The last paragraph in the section states that handling this issue should >> be left up to implementations and that the exact method (and by >> implication, the size of the fudge factor) be determined by the >> implementation themselves. >> >> >> > Section 5.3.1 >> > >> > A zone transfer over a DNS TCP session can include multiple DNS >> > messages. Using TSIG on such a connection can protect the connection >> > from hijacking and provide data integrity. The TSIG MUST be included >> > >> > (I assume that "hijacking TCP" means a sequence-number-guessing attack >> > that would require the attacker to be winning the race against the >> > legitimate sender to cause modified data to be introduced into the TCP >> > stream? This is maybe not the best word to use for such a case.) >> >> I’ve changed “hijack” to “attack”. >> >> >> > on all DNS messages in the response. For backward compatibility, a >> > client which receives DNS messages and verifies TSIG MUST accept up >> > to 99 intermediary messages without a TSIG. The first message is >> > >> > (side note: I'm kind of curious what such compatibility is needed with.. >> > Also, this gives an attacker some flexibility into which to incorporate >> > a collision, though given the near-real-time constraints and the >> > strength of the HMAC construction I don't expect any practical impact.) >> >> The original RFC 2845 did not require all packets in a message stream to >> contain a TSIG, it just stated that there be no more than 99 intermediary >> messages without a TSIG (presumably to cut down on the overhead required in >> message calculations - remember that RFC 2845 was published 20 years ago). >> Although many DNS implementations now add a TSIG to every message, it is by >> no means certain that all do. (In fact, less than three years ago, a bug >> was introduced into BIND, causing it to require that all packets in a zone >> transfer would contain a TSIG. A fix allowing BIND to accept up to 99 >> packets between signed ones was released shortly afterwards after reports >> were received of zone transfers failing.) >> >> >> > Section 5.3.2 >> > >> > Request MAC (if the request MAC validated) >> > DNS Message (response) >> > TSIG Variables (response) >> > >> > The reason that the request is not included in this MAC in some cases >> > is to make it possible for the client to verify the error. If the >> > error is not a TSIG error the response MUST be generated as specified >> > in Section 5.3. >> > >> > This makes it sound like the server excludes the request MAC from the >> > digest if it failed to validate (something the client cannot predict), >> > so that the client must perform trial verification of both versions in >> > order to validate the response. Is that correct? >> >> No. If the incoming MAC failed to validate, the server should send back >> an unsigned response (MAC size == 0 and empty MAC). >> >> >> > Also, I think that the "in some cases" is not properly placed: as-is, it >> > says that the request (not request MAC) is sometimes not included >> > (implying that sometimes it is), which does not match up with the >> > specification for the digest components. I presume that the intent is >> > to say that in some cases the client could not verify the error, if the >> > request itself was always included in the digest. >> >> Changed “request” to “request MAC”. >> >> If the MAC could not be verified, it is possible that it was corrupted, >> which would prevent the client verifying the response. But a major reason >> is that an incorrect MAC included in a signed response led to the CVEs that >> prompted this document update. >> >> >> > Section 5.4.1 >> > >> > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG >> > validates and the TSIG key recognised by the client but different >> > from that used on the request, then this is a Key Error. The client >> > >> > nits: missing words "key is recognized" and "but is different” >> >> It now reads “key is recognized but different" >> >> >> > Section 5.5 >> > >> > destination or the next forwarder. If no transaction security is >> > available to the destination and the message is a query then, if the >> > corresponding response has the AD flag (see [RFC4035]) set, the >> > forwarder MUST clear the AD flag before adding the TSIG to the >> > response and returning the result to the system from which it >> > received the query. >> > >> > Is there anything to say about the CD bit? (It's independent crypto, so >> > I don't expect so, but it seems worth checking.) >> >> No. CD is just a mechanism by which a client can request that the server >> not do DNSSEC signature validation on the data and so allow the client to >> receive the data instead of a SERVFAIL response. >> >> >> > Section 6 >> > >> > The only message digest algorithm specified in the first version of >> > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], >> > [RFC2104]). Although a review of its security [RFC6151] concluded >> > that "it may not be urgent to remove HMAC-MD5 from the existing >> > protocols", with the availability of more secure alternatives the >> > opportunity has been taken to make the implementation of this >> > algorithm optional. >> > >> > It seems worth noting that the advice from RFC 6151 is already nine >> > years old. >> >> I’ve use the phrasing "Although a review of its security some years ago”. >> >> >> > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], >> > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 >> > security considerations apply to SHA-1 in a similar manner.. Although >> > >> > I'd consider referencing (e.g.) >> > shattered.io >> > for the "collisions have >> > been demonstrated" claim, though it's pretty optional. >> >> A reference has been made to the “SHA1 is a Shambles” paper.. >> >> >> > support for hmac-sha1 in TSIG is still mandatory for compatibility >> > reasons, existing uses should be replaced with hmac-sha256 or other >> > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >> > >> > Is this "sha1 mandatory for compatibility" going to age well? If we >> > have two implementations that can operate with sha2 variants, is it >> > required to keep this as mandatory (vs. optional with a note about >> > deployed reality at time of publication) for progression to Internet >> > Standard? >> >> This has been addressed by splitting the “Mandatory/Optional” column in >> RFC4635 (from which Table 2 was derived) into “Implementation” and “Use”. >> SHA1 is required to be implemented (for backwards compatibility) but its >> use is not recommended. >> >> >> > Optional hmac-sha224 >> > >> > It's not clear there's much reason to keep this around, or if we do, it >> > could probably be "not recommended". (I assume that just dropping it >> > entirely makes things annoying w.r.t. the IANA registry.) >> >> It has been left in for compatibility reasons, but its use is not >> recommended. >> >> >> > Section 9 >> > >> > Previous specifications [RFC2845] and [RFC4635] defined values for >> > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >> > >> > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where >> > HMAC qualifies both hash algorithms is not terribly clear. >> >> Changed to >> >> Previous specifications [RFC2845] and [RFC4635] defined names for >> the HMAC-MD5 and the various HMAC-SHA algorithms. >> >> >> > Section 10 >> > >> > I suggest some discussion that the way truncation policy works, an >> > attackers ability to forge messages accepted as valid is limited by the >> > amount of truncation that the recipient is willing to accept, not the >> > amount of truncation used to generate messages by the legitimate sender. >> >> I think this is already taken care of by the reference to a local policy >> in the “Truncation Check and Error Handling” section (5.2.4). >> >> >> > There's also some fairly standard content to put in here about allowing >> > for an unsigned error response to a signed request, so an attacker (even >> > off-path) can spoof such resposnes. (Section 5.4 indicates that the >> > client should continue to wait if it gets such a thing, which helps a >> > lot.) >> >> I’ve just added text that an unsigned response is not considered >> acceptable because can be subject to spoofing and manipulation. >> >> >> > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two >> > entities. >> > >> > I suggest adding "; any such additional sharing would allow any party >> > knowing the key to impersonate any other such party to members of the >> > group”. >> >> Added. >> >> >> > A fudge value that is too large may leave the server open to replay >> > attacks. A fudge value that is too small may cause failures if >> > machines are not time synchronized or there are unexpected network >> > delays. The RECOMMENDED value in most situations is 300 seconds. >> > >> > Our experience with kerberos in modern network environments has shown >> > that 5 minutes is much larger than needed, though it's not clear there's >> > a strong need to change this recommendation right now. >> >> The value is recommended (and even then, only in “most situations”), so >> implementations are free to set their own value. However, any guidance as >> to typical time skews measured across a network would be useful in a number >> of protocols. >> >> >> > Significant progress has been made recently in cryptanalysis of hash >> > functions of the types used here. While the results so far should >> > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are being >> > made mandatory as a precaution. >> > >> > Please revise this note to not imply that SHA-1 is considered "strong”. >> >> Text revised to >> >> Significant progress has been made recently in cryptanalysis of >> hash >> functions of the types used here. While the results so far >> should not >> affect HMAC, the stronger SHA-256 algorithm is being made >> mandatory >> as a precaution. >> >> >> > Section 11.2 >> > >> > I'm not sure why RFC 2104 is listed as informative. >> >> RFC2104 is an Informational RFC and “Idnits” warns of a possible downref >> if the reference is placed in the “Normative” section. >> >> >> >> Comments from Mirja Kühlewind >> >> > I only had limited time for a quick review of this document, so I might >> not be aware of all the needed background and details. Still I have two >> quick questions on retries: >> > >> > 1) Sec 5.2.3: >> > "Implementations should be aware >> > of this possibility and be prepared to deal with it, e.g. by >> > retransmitting the rejected request with a new TSIG once outstanding >> > requests have completed or the time given by their time signed plus >> > fudge value has passed." >> > I might not be aware of all protocol details and maybe this is already >> specified somewhere: While unlikely, it is possible that a request might be >> retransmitted multiple times, as that could cause president congestion over >> time, it's always good practice to define a maximum number of >> retransmissions. If that is already defined somewhere, maybe adding a >> note/pointer would be good as well. >> >> If someone can suggest a suitable number (and a reason for it), we can >> consider doing this. In the meantime, I’ve merely stated that >> implementation should limit the number of retransmissions and so leave the >> choice up to the implementation. >> >> >> > 2) Sec 5.3.1: >> > " This allows the client to rapidly detect when the session has been >> > altered; at which point it can close the connection and retry." >> > When (immediately or after some waiting time) should the client retry >> and how often? >> >> I think that should be down to the implementation to decide. >> >> >> > You further say >> > "The client SHOULD treat this the >> > same way as they would any other interrupted transfer (although the >> > exact behavior is not specified here)." >> > Where is that specified? Can you provide a pointer in the text? >> >> That was a mistake in transcribing the original RFC2845 text. The final >> word “here” has been removed paragraph now reads: >> >> The client SHOULD treat this the same way as they would any other >> interrupted transfer (although the exact behavior is not >> specified). >> >> >> > 3) Sec 8. Shared Secrets: Would it be appropriate to use more >> normative language here? There are a bunch of lower case shoulds in this >> section; is that on purpose? >> >> The context in which the lower-case “should”s appear is very general >> security advice. Although this is something users ought to do, it is not >> really a specific recommendation. >> >> >> >> Comments from Barry Leiba >> >> > — Section 4.2 — >> > >> > * Other Len - an unsigned 16-bit integer specifying the length >> > of the "Other Data" field in octets. >> > * Other Data - this unsigned 48-bit integer field will be >> > >> > Does this mean that “other data” is always 48 bits? If so, does that >> mean tgat the value of “other len” is always 6? If so, then shouldn’t it >> say that? If not, then what don’t I understand? >> >> Benjamin Kaduk also made the same comment, it has been addressed above. >> >> >> > — Section 5.1 — >> > >> > Clients SHOULD only attempt signed >> > transactions with servers who are known to support TSIG and share >> > some algorithm and secret key with the client -- so, this is not a >> > problem in practice. >> > >> > Why SHOULD and not MUST? >> >> Benjamin Kaduk also noted an issue here. The paragraph has been removed.. >> >> >> > — Section 5.3.2 — >> > >> > The server SHOULD also cache the most recent time signed >> > value in a message generated by a key >> > >> > I tripped over this until I realized you mean “Time Signed value”. You >> capitalize it elsewhere, and it helps the parsing if it’s consistent. There >> are four uncapitalized instances in this section. >> >> “time signed” has been capitalised. In addition, in the description of >> the field, “tims signed” has been replaced with “time the message was >> signed”. >> >> Elsewhere, a “fudge field” has been replaced by “Fudge field” (although >> occurrences of “fudge value” have not been capitalised, as the context of >> that is that it is referring to the contents of the Fudge field). Also, >> “other data” and “other data length” have been replaced with the >> (capitalised) field names, “Other Data” and “Other Len”. >> >> >> > — Section 9 — >> > >> > There is no structure >> > required other than names for different algorithms must be unique >> > when compared as DNS names, i.e., comparison is case insensitive. >> > >> > I found this sentence to be really awkward and hard to parse. May I >> suggest this?: >> > >> > NEW >> > There is no structure to the names, and algorithm names are compared as >> if they were DNS names (the comparison is case-insensitive). >> > END >> > >> > I don’t think you really need to say that each name is >> different/unique, right? >> >> Agreed. The text has been changed to that suggested. >> >> >> > other algorithm >> > names are simple (i.e., single-component) names. >> > >> > Nitty thing that you can completely ignore, but I would avoid the Latin >> abbreviation thus: “other algorithm names are simple, single-component >> names.” >> >> Changed. >> >> >> >> Comments from Éric Vyncke >> >> > Thank you for the work put into this document. It is clear and easy to >> read. >> > >> > Please find below some non-blocking COMMENTs and NITs. An answer will >> be appreciated. >> > >> > I hope that this helps to improve the document, >> > >> > Regards, >> > >> > -éric >> > >> > == COMMENTS == >> > >> > There are 6 authors while the usual procedure is to limit to 5 >> authors.. Personally, I do not care. >> > >> > -- Section 1.3 -- >> > It is a little unclear to me whether the "two nameservers" were two >> implementations or two actual DNS servers. >> >> Agreed, it was unclear. Changed to “two name server implementations”. >> >> >> > -- Section 5.2 -- >> > Suggest to provide some justifications about "copied to a safe >> location": the DNS message was sent in the clear, why does the TSIG part be >> copied in a safe location? Please define what is meant by "safe location" >> (Mainly for my own curiosity) >> >> It is a bit over-specified and has been changed. The text now reads: >> >> Upon receipt of >> a message with exactly one correctly placed TSIG RR, a copy of the >> TSIG RR is stored, and the TSIG RR is removed from the DNS Message, >> and decremented out of the DNS message header's ARCOUNT. >> >> >> > "cannot be understood" is also quite vague. >> >> Changed to “cannot be interpreted”. >> >> >> > -- Section 5.3 -- >> > About rejecting request with a time signed value being earlier than the >> last received value. I wonder what is the value of this behavior if there >> is no 'fudge' as well... The last paragraph of this section describes this >> case and push the error handling to the request initiator. Any reason why >> being flexible on the receiving site was not selected ? >> >> The fudge value is to cope with clock skew between the sender and >> receiver. This won't impact on the order in which the packets are received >> by the receiver, for which the “time signed” is a first-level check. (It is >> not fool-proof - a number of packets signed by the sender within a second >> of one another may have the same “Time Signed” field.) >> >> Pushing the error handling to the initiation goes back to the original >> RFC 2845. >> >> >> > == NITS == >> > >> > -- Section 4.3.2 -- >> > Is " A whole and complete DNS message in wire format." a complete and >> valid sentence? >> >> This was also pointed out by Roman Danyliw and has been addressed. >> >> >> Other changes made during editing >> >> * There was no description of the contents of the “Error” and “Other >> Data” fields were in a request. This has now been corrected (Error is set >> to 0. The contents of “Other Data” are stated to be undefined to allow for >> extensions such as draft-andrews-dnsop-defeat-frag-attack.) >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
