On 7 Jul 2019, at 20:17, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Secret Key Transaction Authentication for DNS (TSIG) > Authors : Francis Dupont > Stephen Morris > Paul Vixie > Donald E. Eastlake 3rd > Olafur Gudmundsson > Brian Wellington > Filename : draft-ietf-dnsop-rfc2845bis-05.txt > Pages : 27 > Date : 2019-07-07
Following up Martin Hoffman’s comments on the -04 version of the draft: On 1 Jul 2019, at 11:39, Martin Hoffmann <mar...@opennetlabs.com> 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 <mar...@opennetlabs.com> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
