> On Mar 9, 2016, at 1:17 PM, Stephen Farrell <[email protected]> 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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
