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

Phillip Hallam-Baker <phill@hallambaker.com> Sun, 01 March 2015 15:21 UTC

Return-Path: <hallam@gmail.com>
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 165C91A9102 for <ietf@ietfa.amsl.com>; Sun, 1 Mar 2015 07:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 IrfKMCVuE3xE for <ietf@ietfa.amsl.com>; Sun, 1 Mar 2015 07:21:55 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (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 D1CD61B29FF for <ietf@ietf.org>; Sun, 1 Mar 2015 07:21:35 -0800 (PST)
Received: by labgf13 with SMTP id gf13so1202552lab.10 for <ietf@ietf.org>; Sun, 01 Mar 2015 07:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UiXBZC9GN68hSWMnzAAYareCcx2uW8EISLMDBdKWtN8=; b=fzxRxd/JEWFktjnwDf4DtRq2hBgtnie1tM5N/hPLPiy5h6/mP5zELqDtYDcU6S0rl2 6AIifU3LYmLM90cO3mK8tUHSBNF6J6O+hTPQZ6sFHaWcbAn8K5tsIvKszYbnqRqqxcsO zqskNc33V7UQm7WzI/k29yOO8rXMXrBqSHfY8vPK4K/CPEHacO+kBMERwqbgPROso0Je 6qPrR7xyLhwqDSzqxbbfYLvmltbEQGm0xYehi7CEotAUqxA9UUO7hgWVk6P3rAA/CsJV nTSwGrduOhOy1xUgqypCsF3WA6KANOl7lrqw8P+rqw6b+zjQaQmXHD5c0Zeprgv6DILb GLBw==
MIME-Version: 1.0
X-Received: by 10.152.179.135 with SMTP id dg7mr21154050lac.58.1425223294186; Sun, 01 Mar 2015 07:21:34 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.113.3.165 with HTTP; Sun, 1 Mar 2015 07:21:33 -0800 (PST)
In-Reply-To: <20150228222733.51B432A92EE3@rock.dv.isc.org>
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> <20150228222733.51B432A92EE3@rock.dv.isc.org>
Date: Sun, 1 Mar 2015 10:21:33 -0500
X-Google-Sender-Auth: hFckpcu6x45tMKRcnEKMuXotsZM
Message-ID: <CAMm+Lwhn=D=nOG4Bt3xcgZWja4-L-RvzJ00CkhKNhs6GnsTXGw@mail.gmail.com>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=001a11349ae62cfb5805103ba85f
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Lo6HLCLOD0WZncjBdJSPDs0hEIE>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <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: Sun, 01 Mar 2015 15:21:57 -0000

On Sat, Feb 28, 2015 at 5:27 PM, Mark Andrews <marka@isc.org> wrote:

>
> And that is coming "_25._tlsa" and it uses DNSSEC to prevent the
> downgrade.  Whether your MTA uses STARTTLS or not is another matter
> but we can prevent downgrade attacks from succeeding.
>

No it is not coming. The only way that can happen and be considered a
secure proposal is to charter a new working group in the security area to
work on a new security policy record to address the problem.

This is an important and difficult problem and one that the DANE working
group declared to be OUT OF SCOPE.

Every time I tried to raise the issues I was told they were OUT OF SCOPE.

As a result TLSA is a dogs breakfast. It is a combination of the key
publication mechanism the WG was chartered for and a security policy
mechanism that wasn't really chartered but was done anyway but only in a
half baked fashion.


This was my main concern with the DANE approach from the start. They would
refuse to consider the general problem. Deliver a product that creates more
problems than it solves when trying to solve the larger one and then insist
that we use it because it is 'a standard'.

Well DANE has practically no deployment or traction so I don't see it as a
fact on the ground that has to be worked on. This is a hard problem and it
is a problem that is easier to address from a clean sheet of paper than one
with a legacy support issue.


The way to address security policy for SRV type records is as follows:

1) Free the client end from the performance and data size issues imposed by
the legacy DNS client-resolver protocol.

DPRIV is a really good opportunity to tweak the protocol so we don't have
to worry about the client having to ask for multiple DNS RRs or that the
results might not fit into 500 bytes or an ethernet MTU.

2) Define a new security policy record that is designed to work with SRV
from the start and covers all the security policy concerns.

In particular make it possible to explicitly specify criteria such as 'use
TLS transport' or 'XYZ authentication is required'.


The first change is the more important one and the fix is quite easy.
Traditionally UDP DNS queries are one request packet and one response
packet. This ensures that the services are idempotent and the resolver does
not need to maintain TCP/IP connection state.

If we change the protocol so that a DNS request must still be a single
packet but a response can have multiple response packets we preserve the
connectionless, idempotent property while freeing ourselves from much of
the impact of the MTU size constraint.