Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Sat, May 9, 2020 at 9:52 PM Tim Wicinski <[e-mail]> 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 <[e-mail]>
> wrote:
>
>>
>> > On 4 May 2020, at 19:00, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>