Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views

Petr Spacek <pspacek@redhat.com> Wed, 07 October 2015 15:47 UTC

Return-Path: <pspacek@redhat.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20C1AC44A for <dnsop@ietfa.amsl.com>; Wed, 7 Oct 2015 08:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.511
X-Spam-Level:
X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 nABdPivO0ZwG for <dnsop@ietfa.amsl.com>; Wed, 7 Oct 2015 08:47:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543571AC442 for <dnsop@ietf.org>; Wed, 7 Oct 2015 08:47:57 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id B396F36B1C1; Wed, 7 Oct 2015 15:47:56 +0000 (UTC)
Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t97Flq90021202 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2015 11:47:53 -0400
To: dnsop@ietf.org, Tomas Hozza <thozza@redhat.com>, Olafur Gudmundsson <ogud@ogud.com>, dnsop-chairs@tools.ietf.org, Jared Engstrom <jengstro@redhat.com>
References: <54DB8233.5010405@redhat.com> <D2829CD2-1951-4F0B-848F-F05A9BBD011E@ogud.com> <55DC8B0D.1010205@redhat.com>
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
Message-ID: <56153EA8.4030207@redhat.com>
Date: Wed, 07 Oct 2015 17:47:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <55DC8B0D.1010205@redhat.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/qja0EhooIVgNZnigoA497sZjt0s>
Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 15:47:59 -0000

On 25.8.2015 17:34, Petr Spacek wrote:
> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek <pspacek@redhat.com> wrote:
> [...]
>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how to
>>> improve usability without sacrificing security.
>>>
>>>
>>> Disclaimer
>>> ==========
>>> Method described below is covered by US patent application named "USING DOMAIN
>>> NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".
>>>
>>> See Red Hat, Inc. Statement of Position and Our Promise on Software Patents:
>>> http://www.redhat.com/legal/patent_policy.html
>>>
>>>
>> I reject the below text as I do not want any IPR on anything in this informational document. 
>> Olafur
> 
> Olafur and dnsop chairs,
> 
> would you be willing to accept the text below if Red Hat granted a license
> similar to https://datatracker.ietf.org/ipr/1430/ ?
> (I.e. the patent could be asserted only for defensive purposes.)
> 
> I'm asking because the text might be suitable for some other document
> describing split-dns, so this question is still valid even if the text might
> not be directly usable in draft-ietf-dnsop-dnssec-roadblock-avoidance.
> 
> Thank you for considering this as an option.

I'm sorry for nagging you again, but we are still interesting in knowing if
proposed approach how to deal with patent issue would be acceptable to dnsop.

Thank you very much,
Petr Spacek  @  Red Hat

> Petr Spacek @ Red Hat
> 
>>> The Hack
>>> ========
>>> Fundamental assumption:
>>> Internal & external DNS view are both signed with the same keys or both
>>> unsigned. This assumption allows the method to work without explicit
>>> configuration on every client and removes dependency on reliable/secure
>>> network-detection logic.
>>>
>>>
>>> The main idea can re-phrased as amendment to section 5 of the draft:
>>>
>>>   The general fallback approach can be described by the following
>>>   sequence:
>>>
>>>       If the resolver is labeled as "Validator" or "DNSSEC aware"
>>>           Send query through this resolver and perform local
>>>           validation on the results.
>>>
>>>           If validation fails, try the next resolver
>>>
>>>       Else if the resolver is labeled "Not a DNS Resolver" or
>>>          "Non-DNSSEC capable"
>>>           Mark it as unusable and try next resolver
>>>
>>> --- amended text begins here ---
>>>
>>>       Else if no more resolvers are configured and if direct queries
>>>       are supported
>>>          1. Try iterating from Root
>>>
>>>          2. If the answer is SECURE/BOGUS
>>>            Return the result of iteration.
>>>
>>>          3. If the answer is INSECURE
>>>            Re-query "Non-DNSSEC capable" servers and get answer
>>>            from "Non-DNSSEC capable" servers.
>>>            Set AD bit to 0 before returning the answer to client.
>>>
>>>       Else return a useful error code
>>>
>>>
>>> This method covers DNS split-views with internal unsigned views pretty
>>> nicely as long as the fundamental assumption holds. (Naturally it works only
>>> for cases where fallback to iteration is possible.)
>>>
>>> We wanted to write Unbound module for this but it is harder than it seems.
>>> (Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
>>> Unbound module architecture - not with the described method.)
>>>
>>> Feel free to incorporate the idea to the draft if you wish.
>>>
>>> -- 
>>> Petr Spacek  @  Red Hat