IETF Logo Mail Archive

[dane] Scope of the protocol document or plea for progress

Olafur Gudmundsson <ogud@ogud.com> Tue, 15 November 2011 22:34 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B900121F8512 for <dane@ietfa.amsl.com>; Tue, 15 Nov 2011 14:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level:
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTwgss38TAy for <dane@ietfa.amsl.com>; Tue, 15 Nov 2011 14:34:04 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F921F8511 for <dane@ietf.org>; Tue, 15 Nov 2011 14:34:01 -0800 (PST)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pAFMXwGR048033 for <dane@ietf.org>; Tue, 15 Nov 2011 17:34:00 -0500 (EST) (envelope-from ogud@ogud.com)
Message-ID: <4EC2E8CA.1060009@ogud.com>
Date: Wed, 16 Nov 2011 06:33:46 +0800
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dane@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Subject: [dane] Scope of the protocol document or plea for progress
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2011 22:34:08 -0000

Dear colleagues,

I'm getting worried that the WG is falling off the tracks, it is
getting distracted by trying to address every possible corner case.

I want to propose that the Current protocol document explicitly only 
cover the following case:
     Target zone is DNSSEC signed [1]
and    Consumer performs DNSSEC validation [2]
and     Target zone can be validated by the consumer.

In this case there are two positive outcomes:
     - Validated TLSA RRset
     - Proof that the TLSA RRset does not exist

and one Negative outcome:
     - TLSA RRset fails validation

The document should say what the Consumer application does in each one 
of these cases for each type TLSA of record  i.e. if there is need to 
check revocation lists, etc.

For the other cases we just say "The consumer application falls back to 
the processing it is currently doing".

This is the 98% solution and the faster we can start deploying it the 
better off we are!!!!

A subsequent document can address the transition cases i.e. when
DNSSEC validation can not succeed due to:
     Breaks in trust chain
     Algorithm mismatch
     Unsigned publisher zone
     No Validating resolver available
     DNSSEC records not getting through
     timeouts
     Incomplete Trust Chain
     etc.

I would call this document
"Value of TLSA records when DNSSEC validation is not available".

I feel that using words like "DNS optional" does nothing but confuse 
both potential publishers and consumers of TLSA records as well as the 
implementors.

I want to thank Richard Barnes for forcing me to think though the 
implications of his incomplete flow chart on the document. [3]
My subsequent flowchart takes multiple pages and is not yet complete, 
thus I think any document that tries to address those issues will take a 
long time to write. Conversely writing such a document will be
much easier if the positive cases are taken out of it.

     Comments
     Olafur

[1] Target zone is the zone the name of the service resides in, i.e.
     the name _443._tcp.gmail.com is in gmail.com or _tcp.gmail.com.

[2] Consumer has a DNSSEC capable validator that she/he trusts the 
answer from.

[3] http://tools.ietf.org/agenda/82/slides/dane-2.pdf slide 9.

v2.23.0 | Report a Bug | By Email