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

[Warren Kumari <[e-mail]>]

On Fri, May 29, 2020 at 12:23 PM Warren Kumari <[e-mail]> wrote:

> On Mon, May 11, 2020 at 3:39 PM Donald Eastlake <[e-mail]> wrote:
> >
> > Hi Tim,
> >
> > On Mon, May 11, 2020 at 1:51 PM Tim Wicinski <[e-mail]> wrote:
> >>
> >> Donald
> >>
> >> So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ?
> >
> >
> > Yes, that would be fine.
> >
>
>
> Having heard no objections / other comments, let's go with this.
>
> Thank you everyone, and special thanks to the authors for being so
> diligent, and Tim for the writeup / summary...
>
> Authors, please submit the updated version, and POKE ME LOUDLY so I
> don't miss it.
>

Authors -- it has been almost a month. Please let me know when you will be
able to submit the new version.

W

>
> W
>
>
> > SHA-224 is just SHA-256 with some different initial vectors and the
> result truncated to 224 bits. So if you have implemented SHA-256, it takes
> like 0.1% more code to add SHA-224. And, while the value of SHA-224 would
> be different for a particular input from the value of SHA-256 truncated to
> 224 bits, I don't see any reason why it would be less secure.
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E.. Eastlake 3rd   [phone] (cell)
> >  2386 Panoramic Circle, Apopka, FL 32703 USA
> >  [e-mail]
> >
> >> On Mon, May 11, 2020 at 12:29 AM Donald Eastlake <[e-mail]>
> wrote:
> >>>
> >>> 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.  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
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf