Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 22 June 2015 18:52 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889321A1BF4; Mon, 22 Jun 2015 11:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 apZdMKA7pXru; Mon, 22 Jun 2015 11:52:41 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC8D1A1BE4; Mon, 22 Jun 2015 11:52:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F90D282FB9; Mon, 22 Jun 2015 18:52:40 +0000 (UTC)
Date: Mon, 22 Jun 2015 18:52:40 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: Elwyn Davies <elwynd@dial.pipex.com>
Message-ID: <20150622185239.GU14121@mournblade.imrryr.org>
References: <558851A5.20803@dial.pipex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <558851A5.20803@dial.pipex.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/F3IVnbPNkpCRQ1YZJGoFeXVjPkk>
Cc: draft-ietf-dane-ops.all@tools.ietf.org, General area reviewing team <gen-art@ietf.org>, saag@ietf.org, dane@ietf.org
Subject: Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 18:52:43 -0000
On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote: > Summary: Almost ready. There are a couple of minor issues, and I think > the authors need to reassess whether all the cases where RFC 2119 keyworrds > are actually protocol requirements as opposed to operation best practice > recommendations. Thanks, will double-check the SHOULDS/MUSTS/... > s3: I am not a security expert, but I suspect you may get some pushback on > not making TLS 1.2 mandatory. We'll see what happens. The most widely deployed use of DANE is with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like an unnecessary restriction for an opportunistic protocol. However, non-support of TLS 1.2 is getting increasingly less common, so if push comes to shove, we can "require" TLS 1.2. Of course with no Internet Police to enforce this, the requirement will likely make little difference in practice. > > TLS clients and servers using DANE SHOULD support the > > "Server Name Indication" (SNI) extension of TLS. > > Under what circumstances would it be reasonable for a DANE/TLSA server not > to support SNI? Maybe I could see that a single domain server could do > without it. That's the primary use case, a server with a single certificate, and a "3 1 1" TLSA record has no need to support SNI. It can just respond with the same default certificate, regardless of the SNI extension value sent by the client. > I think this needs to be spelt out - earlier text seems to > indicate that SNI support was pretty much mandatory.... Ah! Later I see that > s5.1 gives a case where SNI is not mandatory - a forward pointer would help. Thanks, will try to make the text more consistent throughout. > s4.1: I am not clear that this section adds any value to the discussion in > s4. Why should the protocol designer be less inclined to use PKIX-xx rather > than DANE-xx when the protocol supports an OS mode as opposed to just fully > authenticated or fully authenticated plus cleartext modes? The basic principle is based on RFC7435. The issue is that PKIX is more brittle, the client and server must happen to agree on a mutually trusted CA, but with OS the client is just trying to protect the communication at the request of the server, and would otherwise be willing to use cleartext or unauthenticated TLS. Use of fragile mechanisms (like public CA authentication for some unspecified set of trusted CAs) is not sufficiently reliable. Since the OS client is basing the decision to employ DANE on the presence of TLSA RRs in DNS, no additional security is gained via the PKIX usages unless they are the only ones supported by the application protocol (the attacker who compromises DNS can just inject "3 1 1" records instead). So DANE-xx is more reliable at no security loss. Thus PKIX-xx is just a needless opportunity to fail that should be avoided. > Nits/editorial comments: > ===================== Will review those... thanks. > s17.2: I can't decide whether I would like RFC6781 to be normative. It would > of course be a downref. This is always going to be a problem since the > draft is combining operational considerations and protocol updates. The > one explicit reference indicates you have to know something about how to run > DNSSEC to run DANE - in practice I think you have to know a great deal about > how to run DNSSEC if you are going to run DANE so I would be inclined to > make this normative (and maybe refer to it in the introduction as well). Not sure what if anything to do about that. -- Viktor.
- Re: [saag] Gen-art LC review of draft-ietf-dane-o… Viktor Dukhovni
- Re: [saag] Gen-art LC review of draft-ietf-dane-o… Viktor Dukhovni
- Re: [saag] Gen-art LC review of draft-ietf-dane-o… Elwyn Davies
- Re: [saag] Gen-art LC review of draft-ietf-dane-o… Elwyn Davies