[Gen-art] Genart last call review of draft-ietf-uta-tls-for-email-04

[Brian Carpenter via Datatracker]

Reviewer: Brian Carpenter
Review result: Ready with Nits

Gen-ART Last Call review of draft-ietf-uta-tls-for-email-04

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-uta-tls-for-email-04.txt
Reviewer: Brian Carpenter
Review Date: 2020-01-25
IETF LC End Date: 2020-01-31
IESG Telechat date:  

Summary: Ready with nit


Nit:


> Abstract
>
>   This specification updates current recommendation for...

s/current/the current/

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07

[Sara Dickinson]

Mohit, 

I’m out of the office next week so in order to try to move the draft along I 
have published an -08 version which I think addresses most of your comments 
(there were a few questions in my response below). Please let me know if any 
are still outstanding. 

Best regards

Sara. 

> On 17 Jan 2020, at 15:33, Sara Dickinson  wrote:
> 
> 
>> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker > > wrote:
>> 
>> Reviewer: Mohit Sethi
>> Review result: On the Right Track
>> 
>> 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-bcp-op-07
>> Reviewer: Mohit Sethi
>> Review Date: 2019-12-29
>> IETF LC End Date: 2020-01-02
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:
>> This draft discusses privacy challenges for recursive DNS resolvers. It then
>> describes policy and security considerations that DNS service providers can 
>> use
>> for enhanced user privacy. The draft is 'On the Right Track' but not yet 
>> ready.
> 
> Many thanks for the detailed review! Ben, Rob I hope theses fixes also 
> address your comments.
> 
>> 
>> Major issues:
>> 
>> I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP
>> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you 
>> want
>> to mention it here in section 5.1.2.1/5.1.3.1?
> 
> What exactly are you thinking of here - something that just says “Server 
> operators should also follow the best practices with regard to OCSP as 
> described in RFC7525”? If something more could you please suggest text?
> 
>> 
>> In section 5.1.2.1, what is meant by 'authentication domain names'? Later, 
>> the
>> text says 'authentication name for the service'. I guess you are implying the
>> authentic domain name of the DNS resolver service that the client software
>> should verify through the common name (CN) in the certificate? Some more
>> explanation here would be beneficial.
> 
> It is defined in the terminology section of RFC8310:
> 
> "Authentication domain name: A domain name that can be used to authenticate a 
> privacy-enabling DNS server.  Sources of authentication domain names are 
> discussed in Section 7."
> 
> I have added a reference for RFC8310 after the first use of ‘authentication 
> domain name’ and made sure every instance of 'authentication name' is updated 
> to 'authentication domain name' for clarity.
> 
>> 
>> In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock
>> avoidance'? And please add a reference to RFC 8027 here if that is the case.
> 
> Yes, good catch - will do. 
> 
>> 
>> Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A". It
>> is pointing to the wrong appendix. 
> 
> Fixed - thanks.
> 
>> Also, this section talks about implementing
>> traffic monitoring by the DNS service provider. I would argue that in most
>> deployments, the traffic monitoring is required (and implemented) by a
>> different entity. Think of a home network router that has a parental control.
>> Or an enterprise restricting employees from visiting certain sites (to 
>> prevent
>> insider attacks)? The impact of encryption is more serious for them and less 
>> so
>> for a DNS service provider. What is the BCP advice for them? 
> 
> You are correct that the there are differing concerns but I don’t believe 
> this document should tackle that - the audience of the document is 
> specifically operators of DNS privacy services, typically monitoring to 
> prevent DDoS or similar, not network operators in general (although they may 
> be both in some cases). For the more general case I think the impact is 
> covered in RFC8404 'Effects of Pervasive Encryption on Operators’?
> 
> I do notice a couple of places where just ‘operators’ is used in the text so 
> could add ‘DNS Privacy Service’ before that to clarify?
> 
>> Also, is it fair
>> to say that this is a best current practice? It feels that we need more
>> experience before we start recommending it as an optimization.
> 
> Given the specific scope discussed above I think it is fair. The privacy 
> policies of most of the public resolver operators and ISPs that offer 
> encrypted DNS are pretty good today in terms of how they try to minimise the 
> user data retained and I’m sure they all still have monitoring in place… 
> 
>> 
>> This comment applies to all 5.1.1-5.1.8. Each subsection starts rather 
>> abruptly
>> by discussing threats. It would be nice if you add a sentence at the 
>> beginning
>> of each sub-section telling the reader what are they heading into. This is
>> probably most obvious from section 5.1.8.