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

Tiru,

Thanks for your response.  I guess the Chairs and ADs will make the call
about whether there's a note motivating the Experimental status.

Wrt to your change about anycast, once the Alert is fatal, do you have the
client give up the association versus trying to resume a past association?

Allison

On 31 August 2016 at 01:54, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>
wrote:

> Hi Allison,
>
>
>
> Thanks for the review. Please see inline [TR]
>
>
>
> *From:* Allison Mankin [mailto:allison.mankin@gmail.com]
> *Sent:* Wednesday, August 31, 2016 5:36 AM
> *To:* Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>
> *Cc:* Warren Kumari <warren@kumari.net>; dns-privacy@ietf.org;
> DPRIVE-chairs@tools.ietf.org; draft-ietf-dprive-dnsodtls@ietf.org;
> Allison Mankin <allison.mankin@gmail.com>; John Heidemann <johnh@isi.edu>
> *Subject:* Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
>
>
>
> 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.
>
>
>
> [TR] I am not sure if this line is required, I don’t see other drafts with
> Experimental status adding this line !
>
>
>
> 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.
>
> [TR] Updated.
>
> 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[*].
>
>
>
> [TR] Good point, changed to fatal alert.
>
>
>
> -Tiru
>
>
>
> 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) <
> tireddy@cisco.com> wrote:
>
> > -----Original Message-----
> > From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of
> > Stephane Bortzmeyer
> > Sent: Monday, August 22, 2016 8:42 PM
> > To: Warren Kumari <warren@kumari.net>
> > Cc: dns-privacy@ietf.org; DPRIVE-chairs@tools.ietf.org;
> draft-ietf-dprive-
> > dnsodtls@ietf.org
> > Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
> >
> > On Tue, Aug 16, 2016 at 01:05:40PM -0400,  Warren Kumari
> > <warren@kumari.net> 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
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>