Last Call Review of draft-ietf-dprive-dns-over-tls-08
review-ietf-dprive-dns-over-tls-08-genart-lc-carpenter-2016-03-17-00

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.

Regards
   Brian

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
>> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> 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.
>>