[DNSOP] Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[John Kristoff]

Friends,

Duane and I pushed out a recent update to this draft.  There are at
least a couple of small TODO items we have to address (search text
for TODO) before it can be published, but I think we've exhausted
largely what we set out to do for this document and would like to see
this wrapped up.

If you could give it perusal and provide and alert us to anything
needing attention that would be lovely.  Thank you,

  

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  It also considers the
   consequences with this form of DNS communication and the potential
   operational issues that can arise when this best common practice is
   not upheld.

John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephen Morris]

> On 25 Jun 2019, at 10:07, 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-04.txt
>   Pages   : 26
>   Date: 2019-06-25

Back in March, Martin Hoffman did a comprehensive review of the RFC2845bis 
draft and made a number of very good suggestions for improvements to its 
readability.  I've edited the draft to take account of his comments, something 
that has had a significant effect on its structure. For this reason, I'd 
appreciate if reviewers could cross-check against RFCs 2845 and 4635 to ensure 
that nothing got lost in the process.

Martin's email - and a description of the changes made in response to it - are 
below.

Stephen



> Hi,
> 
> the following is a review of draft-ieft-dnsop-rfc2845bis-03. As an
> implementer, let me say how much I appreciate this being a full revision on
> RFC 2845 instead of just an update for the issues discovered. I strongly
> believe that keeping the full specification in a single place by writing
> revisions instead of a stream of updates greatly improves the quality of
> software since it avoids people missing important implementation experience.
> 
> As someone who coincidentally is just in the middle of implementing TSIG
> specifically, I have to admit I found RFC 2845 to be somewhat difficult to
> read and understand. As such, I had hoped that the bis would attempt to
> improve the overall clarity of the document. I have pointed out the
> places that I believe to benefit from re-writing below and I am very much
> willing to help with doing that.
> 
> Now on to some concrete points, in order of appearance.
> 
> 1. Introduction
> 
>   o  The second paragraph seems misplaced. It describes why there is this
>  particular revision. Shouldn’t that be towards the end of the
>  introduction?
> 
>   o  Third paragraph: Give a short explanation what "the protocol described
>  in [RFC 3007]" actually is?

Accepted.  The introduction section has been rewritten to include a background
section, a protocol overview and finally the reasons why the document has
been written.
 
> 
> 3. New Assigned Numbers
> 
>   o  Is this necessary here? The RRTYPE is mentioned right after; the error
>  codes might be better listed in 4.3 together with the error field.

As this is a replacement for RFC 2845, I think explicitly listing the numbers
is important as it clearly indicates that this document is responsible for 
defining
them.  

> 
> 4. TSIG RR Format
> 
>   o  It would be nice to have a section before this one that describing the
>  overall protocol operation in more general terms so that a reader isn’t
>  thrown in at the deep end.

Accepted and so it appears before any detailed protocol description.

> 
> 4.2 TSIG Calculation
> 
>   o  This sections seems a bit unnecessary here. For one, it doesn’t
>  actually talk about TSIG calculation. The noting that the record gets
>  discarded can be merged into 4.1 or left for later. The note about
>  network byte order is better added with the record data description
>  below.

Accepted.  The section has been included in the description of the TSIG RR.

> 
> 4.3. TSIG Record Format
> 
>   o  The "NAME" is normally called the "owner".

I'm not sure about this - this is really a key name and not a domain name in 
the normal sense.

> 
>   o  Would it be possible to spell out things like "uint48_t" as "unsigned
>  48 bit integer". Not everyone speaks C anymore. And even then,
>  "uint48_t" isn’t a thing.

Accepted.

>   o  "Octet stream" for a field sounds wrong; "octet string" would be more
>  appropriate but is also misleading, maybe "octet sequence"?

I've used "octet sequence".

> 
>   o  The guidance for choosing a value for "fudge" is currently buried in
>  the security considerations. Perhaps it should be given right here
>  instead.

The choice of a "Fudge" value is a bit subjective, so I think it should remain 
in the security consideration section.

> 
>   o  MAC. A little more on what that is what be nice. It should also say
>  that how it is calculated depends on the particular message and refer
>  to the section with the details for that. (This is what had me most
>  fooled in RFC 2845 where these details are in a section called "TSIG
>  Variables and Coverage", but we will come to that ...)

I hope that the restructuring of the document has made this clearer...

> 
> 4.4. Example
> 
>

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

[internet-drafts]

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-04.txt
Pages   : 26
Date: 2019-06-25

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-04

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


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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop