Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-05.txt

From: [email-masked]
Date: Sun, 07 Jul 2019 12:17:08 -0700

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-05.txt
	Pages           : 27
	Date            : 2019-07-07

Abstract:
   This document describes a protocol for transaction level
   authentication using shared secrets and one way hashing.  It can be
   used to authenticate dynamic updates as coming from an approved
   client, or to authenticate responses as coming from an approved name
   server.

   No recommendation is made here for distributing the shared secrets:
   it is expected that a network administrator will statically configure
   name servers and clients using some out of band mechanism.

   This document obsoletes RFC2845 and RFC4635.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-05
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc2845bis-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Morris <[email-masked]>
Date: Sun, 7 Jul 2019 20:25:29 +0100

> 	Filename        : draft-ietf-dnsop-rfc2845bis-05.txt

Following up Martin Hoffman’s comments on the -04 version of the draft:

On 1 Jul 2019, at 11:39, Martin Hoffmann <[email-masked]> wrote:
> 
> Thank you for taking the time to rework the document -- and sorry for
> causing all this work. I do believe this is a much better document now!

Your comments were most helpful in getting it to that state. Many thanks.

I’ve just submitted the -05 version which, I think, addresses the outstanding points.

> On 1 Jul 2019, at 11:39, Martin Hoffmann <[email-masked]> wrote:
> 
> I have only one thing that I would like to see addressed: MD5 being
> mandatory. I asked back in March if we could make it optional and, as
> far as I remember, there was some agreement.

MD5 has now been made optional.

> Also, there are two requests for feedback in your comments to my
> comments, which I thought I keep here so that they become more visible:
> 
>>> 6.5.3.  Time Check and Error Handling
>>> 
>>>  o  An actual protocol question: What is the point of the caching
>>> the last Time Signed per key and rejecting earlier messages? What
>>> about reordering of messages as can happen with UDP?  

The requirement (a “SHOULD”) to cache the most recent Time Signed field is in RFC 2845 and, in practice, does not seem to have caused problems.  However, a paragraph has been added discussing packet reordering: basically, it is stated that it is up to the implementation to recognise that message reordering has happened and to take appropriate action, e.g. by retransmitting the rejected message with a new TSIG, taking into account outstanding messages.

>>>  o  What Fudge should the server use in its BADTIME response?  

Although the fudge is not relevant to the response message (so could be zero), we opted to set it to the value sent by the client.  That way the values in the packet (time signed, server time, fudge) document why the packet was rejected.

Stephen