Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dns-over-tls-07: (with DISCUSS and COMMENT)

["Wessels, Duane" <[e-mail]>]

> On Mar 9, 2016, at 1:17 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
>> 
>>> 
>>> - 3.2: "make use of trusted a SPKI Fingerprint pinset" needs to be
>>> rephrased.
>> 
>> Do you say that because SPKI is not spelled out at this point, or
>> something else?  We've since expanded SPKI here.
> 
> No "trusted a SPKI" seems like Yoda-speak is all:-)

Okay, wow... I must've read that at least five times today and not noticed.


> 
>> 
>>> 
>>> - 3.4, 2nd last para: this recommends using tickets (RFC5077), which
>>> is fine. RFC7525 (section 3.4) suggests changing tickets at least
>>> weekly. Is that suggestion also good here or would it be better to
>>> recommend (or suggest) some other ticket lifetime? I'd guess 
>>> it's fine but maybe you know better?
>> 
>> Ticket lifetime hasn't come up before, so I would assume the RFC7525
>> recommendation is fine.
>> 
>> 
>>> 
>>> - 4.1, RFC 7435 is about "opportunistic security" and not about
>>> "opportunistic encryption." That followed a long terminology debate,
>>> so you might want to s/encryption/security/ there. (But I don't care
>>> personally:-)
>> 
>> I've changed it to opportunistic encryption.
> 
> It was that before, though. Maybe you did s/encryption/security/
> which'd be fine.

Yes, sorry!

       <section title="Opportunistic Privacy Profile">
         <t>
           For opportunistic privacy, analogous to SMTP opportunistic
-          encryption <xref target="RFC7435"/> one does not require privacy,
+          security <xref target="RFC7435"/>, one does not require privacy,
          but one desires privacy when
           possible.
         </t>



>> 
>> How does this look to you?
>> 
>>       Since
>>       padding of DNS messages is new, implementations might need to
>>       support multiple types of padding or other mitigation techniques
>>       in response to traffic analysis threats.
> 
> I'd suggest instead:
> 
> "Since traffic analysis can be based on many kinds of pattern
> and many kinds of classifier, simple padding schemes may not
> by themselves be sufficient to mitigate the attack. Padding
> will however form a part of more complex mitigations for the
> traffic analysis attack that are likely to be developed over
> time. Implementers who can offer flexibility in terms of how
> padding can be used may be in a better position to enable such
> mitigations to be deployed in future."


Excellent, thank you.

DW