Last Call Review of draft-ietf-dprive-dtls-and-tls-profiles-08

Request Review of draft-ietf-dprive-dtls-and-tls-profiles
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2017-03-02
Requested 2017-02-16
Authors Sara Dickinson, Daniel Gillmor, Tirumaleswar Reddy.K
Draft last updated 2017-03-03
Completed reviews Tsvart Last Call review of -08 by Colin Perkins (diff)
Opsdir Last Call review of -09 by Éric Vyncke (diff)
Secdir Last Call review of -09 by Ben Laurie (diff)
Genart Telechat review of -09 by Francis Dupont (diff)
Assignment Reviewer Colin Perkins 
State Completed
Review review-ietf-dprive-dtls-and-tls-profiles-08-tsvart-lc-perkins-2017-02-27
Reviewed rev. 08 (document currently at 11)
Review result Ready with Nits
Review completed: 2017-03-03


I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC if you reply to or forward this review.

Summary: Ready with nits

The draft describe authentication mechanisms for DNS servers accessed via TLS and DTLS, and defines profiles for DNS clients and servers implementing DNS-over-TLS and DTLS. There seems little of transport concern here, since the draft refers to RFC 7858 and draft-ietf-dprive-dnsodtls to specify DNS over TLS and DTLS, and doesn't define such mechanisms itself, Similarly, the (D)TLS profile is a security profile, rather than transport-related changes.

I just had a couple of nits:

- The short title at the top of each page is “(D)TLS Authentication”. If there’s space, it'd be clearer if this was “(D)TLS Authentication for DNS”, or similar, to avoid confusion about what is being authenticated. 

- Section 9 mandates implementation of TLS session resumption without server-side state [RFC5077], TLS False Start, and the TLS Cached Information Extension. I can’t comment on the security implications, if any, but these extensions seem appropriate for reducing transport overheads. However, the recommendations in this draft seem inconsistent with those in RFC 7858 (e.g., RFC 7858 says "DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections" but this draft is "MUST implement"). It would help to align these, or mark this draft as updating the RFC.