Re: [saag] Agenda request: draft-barnes-dane-uks

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 28 October 2016 00:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFE1295D9 for <saag@ietfa.amsl.com>; Thu, 27 Oct 2016 17:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 9JMeWQtySgQX for <saag@ietfa.amsl.com>; Thu, 27 Oct 2016 17:18:05 -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 1E9231295FB for <saag@ietf.org>; Thu, 27 Oct 2016 17:18:04 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D5FA7284E5B; Fri, 28 Oct 2016 00:18:03 +0000 (UTC)
Date: Fri, 28 Oct 2016 00:18:03 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag <saag@ietf.org>
Message-ID: <20161028001803.GC26244@mournblade.imrryr.org>
References: <CABkgnnU1Lyyi7jqQteVYTJL-j5V3m0tE=o=XumD2jqroynWBgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABkgnnU1Lyyi7jqQteVYTJL-j5V3m0tE=o=XumD2jqroynWBgA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/fD_59tLVCFu7Ci2WpqxqPgtt1Os>
Subject: Re: [saag] Agenda request: draft-barnes-dane-uks
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: saag <saag@ietf.org>
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: Fri, 28 Oct 2016 00:18:06 -0000

On Fri, Oct 28, 2016 at 08:19:56AM +1100, Martin Thomson wrote:

> DANE aren't meeting this time around, and this has a pretty strong
> security bent.  The implications for web security in particular are
> interesting.  I'm also interested in discussing how we can avoid
> creating more cases like this in the future.  Can we have 10-15 for
> this?

If the discussion is about how to ammend RFC 7671, and what
counter-measures are appropriate in any update, then I think this
discussion is best handled on list.  I won't be at the meeting.

The recommendations of the draft in the subject are IMHO too broad
and, for example, needlessly limit the use of raw public keys even
in protocols where UKS is a non-issue [*].

If the discussion is of a more general nature, on how to avoid
potential pitfalls in future documents, by all means proceed on-site.

-- 
	Viktor.

[*] While indeed RFC 7671 introduces issues for HTTPS, DANE is not
in use with HTTPS, and if and when it is, it will almost certainly
use DNSSEC stapling, in which case the UKS attacks don't apply as
the server then signs its TLSA records.  For applications much
simpler than browsers with their "same-origin" trust-mode, and
especially applications that already employ MX, SRV or similar
indirection, UKS is out of scope.