Re: [Gen-art] gen-art review of draft-ietf-dprive-dnsodtls-12
"jouni.nospam" <jouni.nospam@gmail.com> Tue, 29 November 2016 17:53 UTC
Return-Path: <jouni.nospam@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1B1295B4; Tue, 29 Nov 2016 09:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MZLC044E1-ir; Tue, 29 Nov 2016 09:53:05 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B581295C9; Tue, 29 Nov 2016 09:53:05 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id x23so71820192pgx.1; Tue, 29 Nov 2016 09:53:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bi5qEf1bbBMr8qRVw8zbsDmNxaOzZqtRyKtKA/YXnPk=; b=tNWMz/tnbMzUyOfLUEH5LSPoEH/HxkTxkNd+fqkCksFMfAgiRzxUCjlo1/HmWtv/HI GxlNxTiT1vky/cLPhLs/iZ2syXQNvEHS6JrYWgcMFUsK/eU2DPAe8HV58Pka6Jh4E1OH 1SnV0ph6NJfNrBr4ysXeGL2p6rSEDWOhwg7P9If7dntg22sZapBzPGwqw0pfVFafPBd7 rk+W1FGXyMFS2bv5snFiHyYEaMZHaJzaOkss0AoZJ+Eu9pZ0oZcJw5FWmlNzWWl5xjLZ 5+J2M1aEty1nyNAhvESxS0Go5cCV9a727OBupjFNRUisJ0VEbsYMSFBzzKdkJ7Ojj03B QX0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bi5qEf1bbBMr8qRVw8zbsDmNxaOzZqtRyKtKA/YXnPk=; b=TUpbUZ1RWaim9/hBSR7JlwC2tFGF3jD2c4SzENTMHCQO9BXB/nA8Yv3PmYwYt9bfYO mnMc6beLMeeYMp3ltMmjoEUDIjXBzM9Pm1eSPuOXpmztwavNtBb6aFotvx9cffbAjzR7 l08W5mM4CxBk+8ffJZgq5U8xOhObABo+fBnG2f/xYMIkISlu2H9nmdpQeP3BmiJsp+sN qN21pLrfat/IjSYyiVZQOhSe1OwHdeVMt0qOU9Z7lggT3TsImxotVDICiG7/U6ik9+ie b5MUl3hguiJbX6ul1SFeZLEwXm7ZkmykTcol6VXdkUUDh4tbJTZq/h63WILcKaO9KjPf WG+w==
X-Gm-Message-State: AKaTC01XwIaFdCkee1BggQ68GDLH2XjDLp+IcOgMPMVKv2yk9UNb1L9ToqRhgg1GbLZO5w==
X-Received: by 10.98.99.197 with SMTP id x188mr28476466pfb.179.1480441985348; Tue, 29 Nov 2016 09:53:05 -0800 (PST)
Received: from dhcpw5-sj1-42.sj.broadcom.com ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id c142sm96679647pfb.23.2016.11.29.09.53.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 09:53:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: "jouni.nospam" <jouni.nospam@gmail.com>
In-Reply-To: <17bf8917a55044be98162abbc578ce2c@XCH-RCD-017.cisco.com>
Date: Tue, 29 Nov 2016 09:53:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <027AF21F-53BA-4858-B3B5-6B3F2A393046@gmail.com>
References: <B1F5F8A7-0D09-49BC-9544-27EB32D84BEB@gmail.com> <f1ac6f3b179a4027b7742659e6dbe6a3@XCH-RCD-017.cisco.com> <4271EA70-1010-4596-9D48-DB2EA1CB0491@gmail.com> <17bf8917a55044be98162abbc578ce2c@XCH-RCD-017.cisco.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/rdAr6fSo-Mgn92PjFN2WF_KZbAE>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dprive-dnsodtls.all@ietf.org" <draft-ietf-dprive-dnsodtls.all@ietf.org>
Subject: Re: [Gen-art] gen-art review of draft-ietf-dprive-dnsodtls-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2016 17:53:10 -0000
Thanks. > On Nov 28, 2016, at 9:50 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote: > > Thanks, Jouni. Updated draft. > > -Tiru > >> -----Original Message----- >> From: jouni.nospam [mailto:jouni.nospam@gmail.com] >> Sent: Monday, November 28, 2016 11:12 PM >> To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> >> Cc: gen-art@ietf.org; draft-ietf-dprive-dnsodtls.all@ietf.org >> Subject: Re: gen-art review of draft-ietf-dprive-dnsodtls-12 >> >> Hi, >> >> Sorry for being under the radar. See my comments below. >> >> >>> On Nov 18, 2016, at 8:40 AM, Tirumaleswar Reddy (tireddy) >> <tireddy@cisco.com> wrote: >>> >>>> -----Original Message----- >>>> From: jouni.nospam [mailto:jouni.nospam@gmail.com] >>>> Sent: Thursday, November 17, 2016 3:33 PM >>>> To: gen-art@ietf.org >>>> Cc: draft-ietf-dprive-dnsodtls.all@ietf.org >>>> Subject: gen-art review of draft-ietf-dprive-dnsodtls-12 >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed by >>>> the IESG for the IETF Chair. Please treat these comments just like >>>> any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-dprive-dnsodtls-12 >>>> Reviewer: Jouni Korhonen >>>> Review Date: 2016-11-17 >>>> IETF LC End Date: 2016-11-16 >>>> IESG Telechat date: 2016-12-15 >>>> >>>> Summary: >>>> >>>> The document is ready for publication. >>>> >>>> Comments/questions: >>>> >>>> o Section 3.1. has “first-come, first-served” port range. What port >>>> range this actually is? Does it refer to ephemeral port range (rfc6335). >>> >>> User Ports, range is 1024-49151; assigned based on first come and first >> served policy. >> >> Ok. Thanks. Could you state that in the document (with a reference)? >> >> >>>> o Section 6 describes a case where an anycasted DTLS packet reaches a >>>> DNS server that does not have an existing security association with >>>> the client. A DTLS session resumption should initiated as a result. >>>> Is it possible that the next DTLS message again reaches another DNS >>>> server without security association, which would cause a new fatal >>>> alert to be returned.. etc?? If this is the case there should be >>>> some text pointing at this case. If I am just confused the current >>>> text is fine. >>> >>> It's the same problem as DNS-over-TCP (see >> https://tools.ietf.org/html/rfc7766#appendix-A), routing changes can disrupt >> TCP, DNS-over-TLS and DNS-over-DTLS session. >>> >>> Please suggest additional text you would like us to add. >> >> Easiest way here would be saying something along the lines: >> >> OLD: >> context from the DNS-over-DTLS handshake. But when the network >> configuration changes, a DNS-over-DTLS packet can be received by a >> server that does not have the necessary cryptographic context. To >> encourage the client to initiate a new DTLS handshake, DNS servers >> SHOULD generate a DTLS fatal alert message in response to receiving a >> DTLS packet for which the server does not have any cryptographic >> context. Upon receipt of an un-authenicated DTLS fatal alert, the >> >> NEW: >> context from the DNS-over-DTLS handshake. But when the network >> configuration or routing changes, a DNS-over-DTLS packet can be >> received by a server that does not have the necessary cryptographic >> context. Clients using DNS-over-DTLS need to always be prepared >> to re-initiate DTLS handshake and in the worst case this could even >> happen immediately after re-initiating a new handshake. To encourage >> the client to initiate a new DTLS handshake, DNS servers SHOULD >> generate a DTLS fatal alert message in response to receiving a DTLS >> packet for which the server does not have any cryptographic context. >> Upon receipt of an un-authenticated DTLS fatal alert, the ... >> >> - Jouni >> >>> >>> -Tiru >
- [Gen-art] gen-art review of draft-ietf-dprive-dns… jouni.nospam
- Re: [Gen-art] gen-art review of draft-ietf-dprive… Tirumaleswar Reddy (tireddy)
- Re: [Gen-art] gen-art review of draft-ietf-dprive… jouni.nospam
- Re: [Gen-art] gen-art review of draft-ietf-dprive… Tirumaleswar Reddy (tireddy)
- Re: [Gen-art] gen-art review of draft-ietf-dprive… jouni.nospam
- Re: [Gen-art] gen-art review of draft-ietf-dprive… Jari Arkko