Last Call Review of draft-ietf-dprive-dns-over-tls-08

Request Review of draft-ietf-dprive-dns-over-tls
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-03-15
Requested 2016-03-10
Authors Zi Hu, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, Paul Hoffman
Draft last updated 2016-03-17
Completed reviews Genart Last Call review of -07 by Brian Carpenter (diff)
Genart Last Call review of -08 by Brian Carpenter (diff)
Intdir Early review of -05 by Bob Halley (diff)
Intdir Early review of -05 by Bob Halley (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-dprive-dns-over-tls-08-genart-lc-carpenter-2016-03-17
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2016-03-17


And of course that crossed in the mail with the new draft ;-)

So now my review is "Ready", thanks. I am short of time so
I will omit the Gen-ART boilerplate.


On 16/03/2016 17:22, Brian E Carpenter wrote:
> I am on travel and have not yet seen a -08 version appear, but it's
> getting quite close to the IESG telechat.
> Formally my review is still "Almost ready". However, if the changes
> suggested by the authors are in the -08 version, that will become "Ready."
> Regards
>    Brian Carpenter
> On 08/03/2016 14:48, Brian E Carpenter wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-ietf-dprive-dns-over-tls-07.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-03-08
>> IETF LC End Date: 2016-03-15
>> IESG Telechat date: 2016-03-17
>> Summary: Almost ready
>> --------
>> Minor Issues:
>> -------------
>> "3.1.  Session Initiation
>>    A DNS server that supports DNS-over-TLS MUST listen for and accept
>>    TCP connections on port 853.  By mutual agreement with its clients,
>>    the server MAY, instead, use a port other than 853 for DNS-over-TLS.
>>    DNS clients desiring privacy from DNS-over-TLS from a particular
>>    server MUST establish a TCP connection to port 853 on the server.  By
>>    mutual agreement with its server, the client MAY, instead, use a port
>>    other than port 853 for DNS-over-TLS."
>> Well, that makes my head hurt. I think the only way to relieve the pain
>> is if both of those MUSTs are replaced by "MUST by default". However,
>> that means that both clients and servers need a configuration option
>> to use a different port, and I think that needs to be stated too.
>> "4.1.  Opportunistic Privacy Profile
>>    ...
>>    With opportunistic privacy, a client might learn of a TLS-enabled
>>    recursive DNS resolver from an untrusted source (such as DHCP while
>>    roaming), it might or might not validate the resolver."
>> This seems rather underspecified to me. How would a TLS-enabled
>> resolver be identified in DHCP? How would it be described in
>> an IPv6 RA (RFC6106)?
>> I would have thought that the natural thing would have been to
>> simply try TLS on port 853, and be happy if it worked.
>> "9.  Security Considerations"
>> I hoped to find a comment on interaction between DNS/TLS and DNSSEC,
>> even if the comment is only that there is no issue.