Last Call Review of draft-ietf-dprive-dtls-and-tls-profiles-09
review-ietf-dprive-dtls-and-tls-profiles-09-opsdir-lc-vyncke-2017-05-22-00

Request Review of draft-ietf-dprive-dtls-and-tls-profiles
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-03-02
Requested 2017-02-16
Draft last updated 2017-05-22
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 Éric Vyncke
State Completed
Review review-ietf-dprive-dtls-and-tls-profiles-09-opsdir-lc-vyncke-2017-05-22
Reviewed rev. 09 (document currently at 11)
Review result Has Issues
Review completed: 2017-05-22

Review
review-ietf-dprive-dtls-and-tls-profiles-09-opsdir-lc-vyncke-2017-05-22

I have reviewed draft-ietf-6man-rfc4291bis-07 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

From the abstract: This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  This document also specifies new authentication mechanisms. DPRIVE (DNS Private exchange) aims at enhancing DNS privacy by encrypting the DNS traffic (DNSsec only provides authentication/integrity).

 

There are two profiles: strict and opportunistic. The latter allows normal DNS operations as a fallback, which is key for successful deployment.

 

This document in section 6  compares the SIX different authentication mechanisms and gives some guidelines with a lot of SHOULD and MAY and little MUST. Unsure whether it makes the implementers' task easy. Section 8 is more directive and more useful.

 

Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4. No word about IPv6 and no word about RFC 8106 (DNS info for SLAAC).

 

Overall, there are no discussion about the performance (latency, load of clients/servers) of one authentication mechanism compared to the others, no discussion about resilience (i.e. if one server fails, for example in the PKIX cert chains) and I believe that performance and resilience to network error could be useful for the implementer/architect.

 

As a reader, I regret that this document combines two aspects: description of the profiles but also how to extend one TLS authentication method to DTLS... I would have preferred having two documents. But, this is mainly about readability.

 

Hope this helps

 

-éric