Re: [dns-privacy] RE I-D Action: draft-ietf-dprive-dnsodtls-08.txt

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Sara,

Please see inline

From: Sara Dickinson [mailto:[e-mail]]
Sent: Monday, August 8, 2016 5:52 PM
To: Tirumaleswar Reddy (tireddy) <[e-mail]>
Cc: [e-mail]
Subject: RE [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt


On 5 Aug 2016, at 03:47, Tirumaleswar Reddy (tireddy) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Sara,

Thanks for the review. Please see inline

Hi Tiru,

Thanks for the detailed response.



With regard to the separate https://tools.ietf.org/html/draft-wing-dprive-
profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG:
Is there anything DNS specific in the draft? I don’t recall anything particularly
DNS specific. I definitely see value in a draft comparing message flows
between TLS and DTLS in general, but my feeling is it might be better
progressed though another working group with more (D)TLS experts - TLS or
UTA ?

I don't think other WG will care enough for this draft, maybe the chairs can request reviewers from the above WG’s.

I’d be interested to know what others think about this.



then also drop
the suggested acronym "(DNSoD, pronounced "dee-eon-sod”)”. In draft-ietf-
dprive-dtls-and-tls-profiles we use DNS-over-(D)TLS throughout so calling this
mechanism simply DNS-over-DTLS feels more consistent.

The acronym was added as it sounded easy to pronounce.

I haven’t ever heard that acronym used -  I’ve only heard people talk about DNS-over-DTLS :-)

[TR] Okay, removed the acronym ☺

If the acronym is retained then I think in a pass is needed though the document to improve consistency because at the moment both DNSoD and DNS-over-DTLS are used in different sections to (I think) mean the same thing.


1. Introduction:

- Second bullet point, last paragraph: I think it is currently correct that TCP
Fast open is not yet ubiquitous but given the recent significant deployment
efforts I’m not sure that will remain true for long.  Also, TFO is now available
on Windows, Linux, OS X and (server side) FreeBSD.

Removed the second line in the last paragraph.

I think the reference to TFO is still relevant and shouldn’t be completely removed, how about something like:

“ DTLS session resumption consumes 1 round trip whereas TLS session
    resumption can start only after TCP handshake is complete. However TCP Fast Open [
   RFC7413] can eliminate 1-RTT in the latter case. “

[TR] Updated.

- I’d also like to see some statement about how many concurrent DTLS
sessions a client should establish to a particular DNS Server (just one?).

Yes, one DTLS session is sufficient. Its already discussed in Section 3.3
<snip>To reduce client and server workload, clients SHOULD re-use the DTLS session. A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.</snip>

But this doesn’t explicitly say a client SHOULD only use one session. How about considering adding a section based on 6.2.2 of RFC7766 (https://tools.ietf.org/html/rfc7766#section-6.2.2) to cover this?

[TR] Done.

3.3 Established Sessions

- Is there anything additional here that can be said about expected session
lifetimes or idle timeouts? Is it expected that clients keep session open
indefinitely until some sort of error is encountered or can some sort of
reasonable idle timeout be suggested? Is there any expectation about whether
the client or server typically terminates a session?

Yes, updated draft.
NEW:
In between normal DNS traffic while the communication to the DNS server is quiescent,

You could re-use/reference the definition of an idle DNS-over-TCP session as defined in RFC7766 here for clarity and consistency ?

the DNS client may want to probe the server to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.

I’m not clear what kind of ‘probing’ you are suggesting here? A dummy DNS message or some sort of keepalive mechanism - can you expand please ?

[TR] DTLS heartbeat is used for probing, updated text. I am not sure what to pick from RFC7766 (edns-tcp-keepalive is specific to TCP) ?

-- Question: What does a server do if the client doesn’t send an EDNS0 option?

The maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU.

Sorry - I meant that adding a sentence on this to the draft might be helpful to remove ambiguity.

[TR] Okay, added the following lines: If the DNS client does set the EDNS0 option defined in [RFC6891] then the maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed.

-- I do think there is a DTLS Usage Profile specific point to make related to this,
which is that if a client gets a truncated answer over DTLS it could choose to
fallback to UDP/TCP instead of TLS _if_ it were using an Opportunistic profile
which would result in a kind of ‘hybrid’ security.

In Opportunistic profile, if server sends truncated response then
DNS client should first try TLS and if the TLS handshake fails then fallback to TCP.


I don’t really see any
advantage in that if TLS is available, but the last sentence is unclear on this
possibility, suggesting only TLS can be used - which is correct for Strict Privacy
but perhaps not (at least technically) for Opportunistic. This feel worthy of
some discussion.

Added following line:
If DNS-over-TLS connection fails and the client is using Opportunistic Privacy profile then the client can fallback to DNS-over-TCP.

On re-reading this and the profiles draft (draft-ietf-dprive-dtls-and-tls-profiles), this seems rather specific. I’m leaning towards keeping the discussion protocol neutral, as we did in the profiles draft... but I’d like to see some more feedback on this...

There is, of course, a small subset of DNS responses that are too large to be sent using DTLS, but could be send plain text over UDP given the same MTU. The TC bit in this scenario simply signals to the client that the response is too large for DTLS, but of course this signalling can’t convey any more detailed information. Again, it is a bit of a corner case but a question in my mind is how detailed this draft should be in specifying the fallback mechanisms?

One approach would be something like:

“Upon receiving a response with the TC bit set and wanting to
   receive the entire response, the client behaviour is governed by the current Usage profile
   [draft-ietf-dprive-dtls-and-tls-profiles]. For Strict Privacy the client MUST only send
   a new DNS request for the same resource record over an encrypted transport
  (e.g. DNS-over-TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD
  try for the best case  (an encrypted and authenticated transport) but MAY fallback to intermediate cases and eventually the worst case
   scenario (clear text) in order to obtain a response”

This is then almost identical to the text in section 4.2 of the profiles draft but allows clients flexibility.

[TR] Proposed text looks good, updated draft.


DNS client can setup both DNSoD and DNS-over-TLS connections in parallel, to reduce the latency to send DNS queries over DNS-over-TLS if the DNS response is truncated over the DNSoD and the client needs the entire response.

Ah, ‘parallel connections’  is a new idea and warrants discussion. It also seems to be spilling over into the area of preference between the protocols, which I think I would argue is out of scope for this document. Additionally it occurs to me that using DNS-over-DTLS and then just using ‘one-shot’ TLS for truncated messages is really paying a price (more so than falling back to TCP from UDP). So perhaps it makes more sense to use the above rather neutral text and defer this discussion to another document that can include implementation and deployment experience ?

[TR] Removed above line from my local copy.

- “For servers with no connection history…” I think this sentence can also be
removed since it is more fully covered in the draft-ietf-dprive-dtls-and-tls-
profiles draft.

I don’t think it's discussed in profile draft, please check.

I read this as just another description of selecting behaviour depending on the Usage Profile (called I think Privacy Profile here) where b) is Opportunistic and c) is Strict. I don’t think is says anything new above that unless I have mis-read or misunderstood?

[TR] Removed.

- “Once a DNSoD client has established
  a security association with a particular DNS server, and outstanding
  normal DNS queries with that server (if any) have been received, the
  DNSoD client MUST ignore any subsequent normal DNS responses from
  that server, as all subsequent responses should be encrypted.”
I think this text is a hangover from the earlier draft when port 53 was used.

No, the above line explains that if the DNS client is using DNSoD it must not accept plain text DNS responses arriving on any port.
Added more details to clarify.

Can you send the updated text please - a few more thoughts occur to me here but perhaps they are addressed in the new text ?

[TR] Sure, will do.

-Tiru

Sara.