Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Edward Lewis <edward.lewis@icann.org> Thu, 02 November 2017 15:27 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69113FAAD for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uhpMaXw8wP5G for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:27:46 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FC913FAA3 for <dnsop@ietf.org>; Thu, 2 Nov 2017 08:27:46 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 08:27:44 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 2 Nov 2017 08:27:44 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Bob Harold <rharolde@umich.edu>, Matt Larson <matt@kahlerlarson.org>
CC: Paul Wouters <paul@nohats.ca>, Moritz Muller <moritz.muller@sidn.nl>, =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors
Thread-Index: AQHTU+i9bgXp0SADEEG6x6vd1yaJ3qMBpWUAgAAGY4A=
Date: Thu, 2 Nov 2017 15:27:44 +0000
Message-ID: <D7FDD127-8468-4124-B049-6013E2865C0E@icann.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com> <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <alpine.LRH.2.21.1710311541090.23568@bofh.nohats.ca> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com>
In-Reply-To: <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592466863_1372802540"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/X-UuX7k6NIOCQhfW6M5ezidu7P0>
Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 02 Nov 2017 15:27:50 -0000

On 11/2/17, 11:04, "Bob Harold" <rharolde@umich.edu>; wrote:

>I generally agree with you, but wonder if there is a performance penalty to searching every possible path before failing.  Is that a reasonable concern?

There are a bunch of tradeoffs to consider.  (I'll start with "it is a concern" but not sure if it's "something to be afraid of.")

For one, in terms of latency (time to answering the question), if the attempts are in parallel then there's arguably less impact, as network latency might be greater than compute latency.  ("Might" is the operative word.)

One of the old debates between myself and Olafur was whether the cost of a network retrieval was greater than or less than the cost of a cryptographic operation.  That debate is so old I've forgotten which of us sided with which side.  I do know that we never resolved it, knew it wasn't generally resolvable, and would probably change over time anyway.

For two, in terms of load on the network (more traffic), it's hard to know.  Depends on what is cached, how often the work is done, whether it is each validation or not.  (You'd only have the question arise when you have a trust anchor besides the root to consider - the frequency might be dependent on whether split-DNS is an issue or not, and so on.)

For three, performing actions in parallel complicate code writing.  If you were educated in the days before thread packages existed, you are tempted to try serially.  (pthreads, IEEE Std 1003.1c-1995, came along too late in the game for me.)  Younger kids are apparently able to multi-task better these days, I hear, so I hope that makes for better code (a'la Go).

There's always the "one branch gives me this result, the other branch seems to be hitting a timeout" case meaning sometimes you have to estimate when it's time to give up and get on with it.  It's that case that makes coders implement "first result wins" more often than is probably wise.

This is what makes "robustness" a tricky thing (and why I like to dive into this again now and then).  If "robust" means returning as much data to a query as possible (like finding the one working secure chain), you might risk breaking a different definition of "robust" for the relying application, which has a time-deadline to meet.

In short - it's a tradeoff of time (latency) and maximizing validation of answers (robustness) which depends a lot on how the code is implemented and the workload provided.  Like looking for a needle in a haystack - the longer you look the higher the chance you will find it, with how you look being a factor in speed, as well as the size of the haystack, number of needles present, etc.