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

Olafur Gudmundsson <ogud@ogud.com> Fri, 30 October 2015 01:32 UTC

Return-Path: <ogud@ogud.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 5218F1B338A for <dnsop@ietfa.amsl.com>; Thu, 29 Oct 2015 18:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 GnYDzOisrTcM for <dnsop@ietfa.amsl.com>; Thu, 29 Oct 2015 18:32:18 -0700 (PDT)
Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC871B3386 for <dnsop@ietf.org>; Thu, 29 Oct 2015 18:32:17 -0700 (PDT)
Received: from smtp2.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8FC6A180369; Thu, 29 Oct 2015 21:32:16 -0400 (EDT)
Received: by smtp2.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 566E918037B; Thu, 29 Oct 2015 21:32:15 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 29 Oct 2015 21:32:16 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <562A0014.5060500@redhat.com>
Date: Thu, 29 Oct 2015 21:32:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7D96308-F5CF-4FB6-BA44-951E0488FE90@ogud.com>
References: <54DB8233.5010405@redhat.com> <D2829CD2-1951-4F0B-848F-F05A9BBD011E@ogud.com> <55DC8B0D.1010205@redhat.com> <56153EA8.4030207@redhat.com> <562A0014.5060500@redhat.com>
To: Petr Spacek <pspacek@redhat.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/LvGyg13ja4oE7sl7FA9uF_JTxDA>
Cc: Tomas Hozza <thozza@redhat.com>, Jared Engstrom <jengstro@redhat.com>, dnsop@ietf.org, dnsop-chairs@tools.ietf.org
Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views: IPR issues
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: Fri, 30 Oct 2015 01:32:20 -0000

Petr, 
sorry of my tardiness,
I’m fine with adding text along the lines you outlined, as long as there is
and IPR statement that is inline with the terms you referred. 

Wes, do you agree ? 

Olafur

> On Oct 23, 2015, at 5:38 AM, Petr Spacek <pspacek@redhat.com> wrote:
> 
> On 7.10.2015 17:47, Petr Spacek wrote:
>> 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
> 
> Hello once again,
> 
> we as a company are really interested in contributing to IETF but we have to
> sort out situation about the patent first. Could chairs (or possibly draft
> authors) clarify dnsop (or author's?) position on this?
> 
> Thank you for your time,
> 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