IETF Logo Mail Archive

Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Sam Hartman <hartmans-ietf@mit.edu> Fri, 27 February 2015 14:40 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA901ACAD5 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 06:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 vf4nifuUkOkk for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 06:40:39 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411931AC7E7 for <ietf@ietf.org>; Fri, 27 Feb 2015 06:40:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6729020606; Fri, 27 Feb 2015 09:39:59 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGsNmaCeBUUI; Fri, 27 Feb 2015 09:39:59 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 27 Feb 2015 09:39:59 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CAEA487131; Fri, 27 Feb 2015 09:40:36 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Eliot Lear <lear@cisco.com>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
References: <20150127223859.28024.43756.idtracker@ietfa.amsl.com> <4257D8A3-0EFE-40E3-B0AD-8E23772B7693@mnot.net> <6F9BB11D-C224-4D7B-A06C-41EACBAAB4B2@netnod.se> <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <tsl8ufoh9ko.fsf@mit.edu> <20150224170209.GV1260@mournblade.imrryr.org> <54F03F38.9090601@cisco.com> <1ED9F633-40B1-4A90-85FE-14526C27A485@frobbit.se> <54F043F8.6090409@cisco.com>
Date: Fri, 27 Feb 2015 09:40:36 -0500
In-Reply-To: <54F043F8.6090409@cisco.com> (Eliot Lear's message of "Fri, 27 Feb 2015 11:16:24 +0100")
Message-ID: <tsl7fv35sez.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/u_26BaE9cXcEiy6jeozHkUQhja4>
X-Mailman-Approved-At: Fri, 27 Feb 2015 08:12:19 -0800
Cc: ietf@ietf.org, Patrik Fältström <paf@frobbit.se>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2015 14:40:41 -0000

>>>>> "Eliot" == Eliot Lear <lear@cisco.com> writes:


    Eliot> DNSSEC: it's not just for breakfast anymore.

I've mentioned this before, but DNSSec is not really a complete answer
here.
DNSSec is only an appropriate answer when the set of DNS trust anchors
are appropriate to the information being protected.

Today, I expect for many applications that the information entered by
the user will be validated against an application-specific set of trust
anchors.  If DNS is trusted to make decisions about what my target
security principal can be, then the DNS trust anchors become part of
that trusted set.  For a number of enterprise applications that's really
bad from a security standpoint.

For other applications, this is a great technology and DNSSec is a
reasonable way to protect it.

v2.23.0 | Report a Bug | By Email