Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

[Allison Mankin <[e-mail]>]

My calendar reminds me this is the last day of this WGLC.

Overall comments:

This is a well-written spec.  I'm especially appreciative of how much the
draft has gotten aligned with RFC 7858.  I support its publication soon as
an Experimental.

Three suggestions/concerns:

Abstract and Section 1 -

I'd like to see a note added that the Experiment will be concluded when the
spec is evaluated through an implementation and some testing of the
details.

Section 1

> However TCP Fast Open [RFC7413 <https://tools.ietf.org/html/rfc7413>] can
eliminate 1-RTT in the latter case.

If the TLS Resume and the TCP Fast Open are pipelined, there is no extra
RTT in comparison with DTLS. So I think it would be better to say that with
TCP Fast Open, the implementation can achieve the same RTT efficiency as
DTLS.

Section 6

I don't recall recent WG discussion of this section on Anycast (JohnH
reviewed an earlier approach in https://www.ietf.org/mail-
archive/web/dns-privacy/current/msg00989.html).

The section states that a server receiving a DTLS message for which it
doesn't have cryptographic context SHOULD generate a DTLS Alert message to
encourage the client to try to recover.  But it acknowledges that the Alert
can't be authenticated, and so it advise the client receiving this Alert to
try two things:

   upon receipt
   of an in-window DTLS Alert, the client SHOULD continue re-
   transmitting the DTLS packet (in the event the Alert was spoofed),
   and at the same time it SHOULD initiate DTLS session resumption.
   When the DTLS client receives an authenticated DNS response from one
   of those DTLS sessions, the other DTLS session should be terminated.

Why do we think that the server is allowed to send a non-fatal Alert
message for this case?  See the MUST in RFC 6347 4.1.2.7[*].  And if it is
OK to send a non-fatal Alert message, under what conditions might the
client's two attempts have success?  The assumption seems to be a very
transient Anycast routing change (for the retransmit) or an Anycast routing
change that cycled to a previous server within the time window for the
valid resume.  One of John Heidemann's points in the message I linked to is
that there's a lack of data on Anycast impacts on transport in DNS.

Does others think that a server must send a fatal Alert (or else contradict
RFC 6347)?

In general, is the complexity of this recovery worthwhile compared with
fault-tolerantly giving up and starting over?   Is the assumed rapid and/or
cycling Anycast change common enough to justify the proposed behavior?

Suggestion: let the client give up.  Or else add language about the
assumptions and about the section being pretty theoretical/untested.

Thanks,

Allison

[*] RFC 6347 4.1.2.7:

   Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
   invalid formatting, length, MAC, etc.).  In general, invalid records
   SHOULD be silently discarded, thus preserving the association;
   however, an error MAY be logged for diagnostic purposes.
   Implementations which choose to generate an alert instead, MUST
   generate fatal level alerts to avoid attacks where the attacker
   repeatedly probes the implementation to see how it responds to
   various types of error.  Note that if DTLS is run over UDP, then any
   implementation which does this will be extremely susceptible to
   denial-of-service (DoS) attacks because UDP forgery is so easy.
   Thus, this practice is NOT RECOMMENDED for such transports.




On 22 August 2016 at 21:44, Tirumaleswar Reddy (tireddy) <[e-mail]>
wrote:

> > -----Original Message-----
> > From: dns-privacy [mailto:[e-mail]] On Behalf Of
> > Stephane Bortzmeyer
> > Sent: Monday, August 22, 2016 8:42 PM
> > To: Warren Kumari <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> draft-ietf-dprive-
> > [e-mail]
> > Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
> >
> > On Tue, Aug 16, 2016 at 01:05:40PM -0400,  Warren Kumari
> > <[e-mail]> wrote  a message of 38 lines which said:
> >
> > > https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
> >
> > I've read it (the last version, -10) and, for me, it is OK, and ready to
> be sent to
> > the next step.
> >
> > I would like to make it a bit shorter by deleting two sentences, "An
> active
> > attacker can send bogus responses causing misdirection of the subsequent
> > connection" in the abstract and "Active attackers have long been
> successful at
> > injecting bogus responses, causing cache poisoning and causing
> misdirection
> > of the subsequent connection (if attacking A or AAAA records).  A popular
> > mitigation against that attack is to use ephemeral and random source
> ports
> > for DNS queries [RFC5452]." in section 1. Both are about an attack which
> is
> > *not* mitigated by DNS-over-DTLS and these two sentences are clearly out
> of
> > scope. (The relationship with DNSSEC, which solves these attacks, is
> already
> > handled in section 1.1.)
>
> Done.
>
> >
> > Otherwise, now that the well-knon port is not absolutely mandatory, I
> suggest
> > to change "Once the DNS client succeeds in receiving HelloVerifyRequest
> from
> > the server via UDP on the well-known port for DNS-over-DTLS" to "Once the
> > DNS client succeeds in receiving HelloVerifyRequest from the server via
> UDP
> > from the port used for DNS-over-DTLS".
>
> Based on feedback from Christian that HelloVerifyRequest is optional from
> the server, removed the above line and replaced with the following lines:
>
>    DNS client initiates DTLS handshake as described in [RFC6347],
>    following the best practices specified in [RFC7525].  After DTLS
>    negotiation completes, if the DTLS handshake succeeds according to
>    [RFC6347] the connection will be encrypted and is now protected from
>    eavesdropping.
>
> >
> > RFC 2119 mandatory flame war: "the DNS client may want to probe the
> server
> > using DTLS heartbeat" May or MAY?
>
> Changed to "MAY".
>
> -Tiru
>
> >
> >
> > _______________________________________________
> > dns-privacy mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>