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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Wed, 31 August 2016 05:54 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3324612D09B; Tue, 30 Aug 2016 22:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.067
X-Spam-Level:
X-Spam-Status: No, score=-15.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOupd1ax7o6Q; Tue, 30 Aug 2016 22:54:03 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DFF12D091; Tue, 30 Aug 2016 22:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33322; q=dns/txt; s=iport; t=1472622842; x=1473832442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=idJCCVEB2Oq2gvN/56qTIhs6ZCrJacrMTcxJgKjq7NI=; b=Au/rBDc56/ngHFklPYBitWJhyMmI9vSntkxTBCmb2fXjZEg7MWdPkCm5 EmgEoAbc7kREqhQUygoY7OuE4R6bhrNTh3HUmk0rzuPBNa9czFLGzjKo8 U1PpCFowU0oJ04+X4wT8xpDurhhRetYXWg1SJjzqRJwhHALx0zJphm84C I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AfAgCMcMZX/4MNJK1cgxozAQEBAQEeV3wHpn+FCow1ggEkhXkCHCmBCzgUAQIBAQEBAQEBXieEYQEBBAEBASEKHgEiBAcFBwQCAQgRAgIBAQEgBwMCAgIfBAILFAkIAgQOBQiIJAMPCA6uN4VNAYYLDYM9AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYwg0qBA4JDgWABAQVMCIJEgloFlAmFEzQBhh+GPoJLgXSEXYM0hVmIP4QJg3gBDw82gkocgU1wAYRMgSB/AQEB
X-IronPort-AV: E=Sophos;i="5.30,260,1470700800"; d="scan'208,217";a="316697806"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2016 05:54:01 +0000
Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7V5s10m008691 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 05:54:01 GMT
Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 00:54:00 -0500
Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 00:54:00 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Allison Mankin <allison.mankin@gmail.com>
Thread-Topic: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
Thread-Index: AQHR9+CDOfLshiPyWUOvmEml7Lnb/qBVc0KA//+wkDCADXdGAP//9eoQ
Date: Wed, 31 Aug 2016 05:54:00 +0000
Message-ID: <026a1e754895459186a5164f960e1b3c@XCH-RCD-017.cisco.com>
References: <CAHw9_iLWW-e_de9ieq_oe_eR=RBWg9swG7EiAPTp93825Vm=pw@mail.gmail.com> <20160822151229.k5wms6k6kktrut4o@nic.fr> <d21a5081c7614e5bbeef371d83501693@XCH-RCD-017.cisco.com> <CAP8yD=s+cD_-=AVs8NU0ZxjxwKCY81xEm_JzBO7vu80P6DXysw@mail.gmail.com>
In-Reply-To: <CAP8yD=s+cD_-=AVs8NU0ZxjxwKCY81xEm_JzBO7vu80P6DXysw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.80.149]
Content-Type: multipart/alternative; boundary="_000_026a1e754895459186a5164f960e1b3cXCHRCD017ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/OjMO9-081nQ9yEn5swPmwL5W1zY>
Cc: "DPRIVE-chairs@tools.ietf.org" <DPRIVE-chairs@tools.ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Warren Kumari <warren@kumari.net>, "draft-ietf-dprive-dnsodtls@ietf.org" <draft-ietf-dprive-dnsodtls@ietf.org>, John Heidemann <johnh@isi.edu>
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 05:54:05 -0000

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<http://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<mailto:tireddy@cisco.com>> wrote:
> -----Original Message-----
> From: dns-privacy [mailto:dns-privacy-bounces@ietf.org<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<mailto:warren@kumari.net>>
> Cc: dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>; DPRIVE-chairs@tools.ietf.org<mailto:DPRIVE-chairs@tools.ietf.org>; draft-ietf-dprive-
> dnsodtls@ietf.org<mailto: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<mailto: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<mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
https://www.ietf.org/mailman/listinfo/dns-privacy