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> Tue, 24 February 2015 17:32 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 DB9071A1A27 for <ietf@ietfa.amsl.com>; Tue, 24 Feb 2015 09:32:53 -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 QnVv01kihkKQ for <ietf@ietfa.amsl.com>; Tue, 24 Feb 2015 09:32:52 -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 AD0C11A00D0 for <ietf@ietf.org>; Tue, 24 Feb 2015 09:32:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8679520582 for <ietf@ietf.org>; Tue, 24 Feb 2015 12:32:19 -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 ZSnnDdxqQ2ly for <ietf@ietf.org>; Tue, 24 Feb 2015 12:32:19 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (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 for <ietf@ietf.org>; Tue, 24 Feb 2015 12:32:18 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 66E9780435; Tue, 24 Feb 2015 12:32:50 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org
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> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org>
Date: Tue, 24 Feb 2015 12:32:50 -0500
In-Reply-To: <20150224172649.GX1260@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 24 Feb 2015 17:26:49 +0000")
Message-ID: <tslvbircj0d.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/Y-8UtC7BNvSi3L7PMjKxM_pblYU>
X-Mailman-Approved-At: Wed, 25 Feb 2015 08:19:08 -0800
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: Tue, 24 Feb 2015 17:32:54 -0000

>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

    Viktor> On Tue, Feb 24, 2015 at 08:49:29AM -0800, Paul Hoffman wrote:
    >> On Feb 23, 2015, at 8:33 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
    >> > Yes, I see significant security problems with this URI.
    >> 
    >> It sounds like you have issues with URIs in general, not in a DNS
    >> RTYPE that carries a URI. That is, any URI that has a domain name
    >> that can lead to redirection (though CNAME, DNAME, or SRV) would
    >> have the properties that worry you. It that a fair summary?

    Viktor> That's not how I read it.  The issue here is that the draft
    Viktor> introduces a DNS-based rewrite of the TLS reference
    Viktor> identifier.

Victor is correct.  This draft introduces indirection through DNS.
Typically in the past when we've done indirection through DNS, we've not
changed the expected security principal that we're targeting.
It's that change  that significantly changes the security model.

There are times when an indirection through a trusted directory service
is the right approach.
However, I think the security model change has been inadequately
explored in this draft as evidenced in the text and in responses I
received.

So I continue to believe that last-call is premature until the security
model changes are adequately explored and then documented.