Re: [Tsv-art] [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

[Brian Haberman <[e-mail]>]

I support the additional text on padding.

As a process note, I believe we will need to re-issue the IETF Last Call 
to allow for the discussion of the down-ref to 8467.

Regards,
Brian

On 1/27/22 8:36 AM, Allison Mankin wrote:
> I share Sara's position.
> 
> On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <[e-mail]> wrote:
> 
>> Hi Brian,
>>
>> Thanks for the review, and as Christian said the padding question has been
>> a point of discussion.
>>
>> I’m personally comfortable with a downref to RFC 8467 with text to support
>> why this is done as you suggest. Multiple studies have shown just how easy
>> traffic analysis is without any padding - we could actually cite one of the
>> more recent ones. RFC 8467 is implemented for stub-recursive DoT in most
>> open source software and is in use by major recursive operators.  For me
>> this approach mitigates the immediate risk of exposing DNS names -
>> preventing traffic analysis from identifying DoQ is a much longer term goal
>> (and requires ECH).
>>
>> I’ve had a first pass at a PR making RFC8467 normative here:
>> https://github.com/huitema/dnsoquic/pull/143
>>
>> Regards
>>
>> Sara
>>
>>
>>> On 26 Jan 2022, at 20:32, Christian Huitema <[e-mail]> wrote:
>>>
>>> Thanks for the review, Brian.
>>>
>>> We have been going back and forth on the padding requirements, and the
>> current text is specifically written to avoid a downward reference to RFC
>> 8467. You are making a good arguments that it is hard for implementers to
>> comply with a requirement that they MUST pad if there is no specific
>> guidance about how to pad. On the other hand, I think that we should not
>> delay publication until getting definitive agreement on the appropriate
>> padding policy. For example, we would have to resolve the tension between
>> application specific padding, with a goal to hide which DNS names are being
>> queried, and generic transport level padding, with a goal to prevent
>> traffic analysis from distinguishing between DoQ and other applications.
>> So, I am inclined to just replace MUST by SHOULD, and leave it at that.
>> That's one of your proposed remedies,  but I wonder whether others might
>> object.
>>>
>>> -- Christian Huitema
>>>
>>>
>>> On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote:
>>>> Reviewer: Brian Trammell
>>>> Review result: Ready with Nits
>>>>
>>>> This document has been reviewed as part of the transport area review
>> team's
>>>> ongoing effort to review key IETF documents. These comments were written
>>>> primarily for the transport area directors, but are copied to the
>> document's
>>>> authors and WG to allow them to address any issues raised and also to
>> the IETF
>>>> discussion list for information.
>>>>
>>>> When done at the time of IETF Last Call, the authors should consider
>> this
>>>> review as part of the last-call comments they receive. Please always CC
>>>> [e-mail] if you reply to or forward this review.
>>>>
>>>> This document is a mature and straightforward mapping of DNS over QUIC,
>>>> modeling a QUIC connection as equivalent to DNS over TCP with one query
>>>> per stream. 0-RTT and fallback design choices are reasonable and
>>>> well-explained. Security and privacy considerations are well-presented