Re: [DNSOP] Updated KSK Sentinel document

Geoff Huston <gih902@gmail.com> Sun, 18 February 2018 20:21 UTC

Return-Path: <gih902@gmail.com>
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 A31551242EA for <dnsop@ietfa.amsl.com>; Sun, 18 Feb 2018 12:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pmih8CdV2opl for <dnsop@ietfa.amsl.com>; Sun, 18 Feb 2018 12:21:43 -0800 (PST)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 C867A12422F for <dnsop@ietf.org>; Sun, 18 Feb 2018 12:21:43 -0800 (PST)
Received: by mail-pl0-x231.google.com with SMTP id t4so4559979plo.0 for <dnsop@ietf.org>; Sun, 18 Feb 2018 12:21:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K3MnD4UQslWkYz/yexl/P2p+tVDTJvNghGzuuvIBQeA=; b=PfOHQkTbk8QUC7zxbVnL1L+Xq5sNYyi9xbTELSOfwZirQsvdiKLCiDL8h6KG+gbP9S 6EV2csNVb+8Ik3K7JNkVTd85OSmrUdZLG/avUIlT0LfjDw+61zbFeq71OCZmkKLLfCrs jRaHnxSw3vHFj2vAKNnM6SwU8fWJ82l44f0OiGocF/Di78oWeSvYl3gVHsolrO0FSUyB r1y4ofMsFX4krAn3GrqsBEZpP+JuciIHIkPGOFcW67o/jSLtf+FNqs1k1JE3BEJdOT5V s9kW4ORToE3rt4/f7bDekmMYncoskYQHFfV73eiiDPgZzM0lOySAieXZTOt21Xek6kbV IYKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K3MnD4UQslWkYz/yexl/P2p+tVDTJvNghGzuuvIBQeA=; b=LYv1Wb7XR1YuVNLHPx+Q63ElxxYjTfIaldP6HR4sYVQincSINWWRyOS6K0w+JZQcfp lqw0Fd3+oHAPpulAetiYzcgJenAOgT+G9wHLYiQEE2lvsPfgk/wQ+t+scu+7NxwWv/Fd dRi9M55r/yrtPBRakeBgJTJFw/GfJ5J6LoxgQzOs20i4ZUmkH0S5ANlgbJMpd/uR0N2p hyWVoSiV57FJzXcmH/IPSXGcaYh4GJ6k7spPAPOruijwn4OuE2v4Hw+T6rk87/2bozZb kdugtmlvnbPwyAwgHp/i/3Ti+XWLvx8hdnBl7YcLzUAsZwpfvdYYF6GzvOOcsMelx+wk iPAA==
X-Gm-Message-State: APf1xPDyXeXOqaU21wf4+25gXfRbXw4qji2qzru0AND4znyao1xMOGDA 5grMfdw58jXJRpuL0nZagyv3j6U9
X-Google-Smtp-Source: AH8x224CN7jlCSs2v4Xt2KBZifZluwvsbU3vBKMelfzgtu7hFsKKpaV6qTR6KwvNblmj98K9W6BQXQ==
X-Received: by 2002:a17:902:34f:: with SMTP id 73-v6mr11812774pld.55.1518985303267; Sun, 18 Feb 2018 12:21:43 -0800 (PST)
Received: from 2001-44b8-1121-1a00-4937-ae6e-e8c3-5cc1.static.ipv6.internode.on.net (2001-44b8-1121-1a00-4937-ae6e-e8c3-5cc1.static.ipv6.internode.on.net. [2001:44b8:1121:1a00:4937:ae6e:e8c3:5cc1]) by smtp.gmail.com with ESMTPSA id f3sm49325160pgn.9.2018.02.18.12.21.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 12:21:42 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Geoff Huston <gih902@gmail.com>
In-Reply-To: <02D558F6-F820-4627-BAC6-1A38AB00B4F5@sinodun.com>
Date: Mon, 19 Feb 2018 07:21:37 +1100
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A384C66F-E285-4AD2-A8F8-CF9CE0F43DB7@gmail.com>
References: <CAHw9_iJ5Dr0sHw3EkWyHeAVDDb3k=8C6XOfrA02-_bQzd4n2Sg@mail.gmail.com> <02D558F6-F820-4627-BAC6-1A38AB00B4F5@sinodun.com>
To: John Dickinson <jad@sinodun.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yhmlwKdGqWJqw3B93ytPqg3rGj4>
Subject: Re: [DNSOP] Updated KSK Sentinel document
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: Sun, 18 Feb 2018 20:21:46 -0000

Hi John,

thanks for the review of this draft


> On 17 Feb 2018, at 4:35 am, John Dickinson <jad@sinodun.com> wrote:
> 
> Hi,
> 
> I like what this draft is trying to do.
> 
> I am a bit concerned about adding a invalid RR in to a otherwise correctly signed zone. It suspect that there may be a variation in how validating resolvers treat authoritative servers that appear to have sent bogus data. Some might retry, retry other auth servers, stop using that server altogether etc etc…

I have been doing this for many years in an ad-based measurement campaign. When a validating resolver is incapable of validating a response it sends back a SERVFAIL response code of course. Some years back “incapable of validating a response” implied an exhaustive search through all NS’s of all parent zones to see if any path exists that can validate the RRSIG - these days many resolvers simply accept the first invalid response and pass back SERVFAIL. Obviously the SERVFAIL response will prompt a stub resolver to pass the query tyo any other recursive resolvers that it is configured to query. This is of course the same behaviour as one would expect from a validating recursive resolver that has failed to track a KSK roll. I have not observed any signal that a client resolver accepts a SERVFAIL response from a recursive resolver as anything other than a failure for the query itself. 


> 
> I suggest that the example A/AAAA RRs on page 4 be written fully qualified so there can be no doubt that this draft does not imply new special names at the root (which is what I first thought).

“example.com” appears four times on page 4 - are you suggesting that this be altered to read “example.com.”?

Or are you suggesting that the 5 instances of the label kskroll-sentinel-(is|not)-ta-2222 which refer to a “resoirce” be edited to read "kskroll-sentinel-(is|not)-ta-2222.example.com"?

Or both?


> 
> In the discussion of Charlie’s resolvers I think “from
>   this he knows (see the logic below) that he is using legacy, non-
>   validating resolvers.”
> 
> should have the “non-“ removed.
> 


yes - that’s correct. That was a typo.


> regards
> John
> 
> 
> On 12 Feb 2018, at 20:28, Warren Kumari wrote:
> 
>> <author hat only>
>> 
>> Hi all,
>> 
>> Sorry it has taken so long to get a new version of this document
>> posted - you deserve better.
>> 
>> Anyway, we've finally posted an updated version -
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>> 
>> This version includes a (hopefully easily understood) description of
>> how this would actually be used, and not just "here's a protocol, k,
>> thnx, bye!". I've tried to layout what each party does, and how it all
>> fits together - please let me know if it isn't clear. This section is
>> towards the top of the document - we will likely make it an Appendix
>> before publication.
>> 
>> I've also updated it to use the kskroll-sentinel-is-ta-<id> format. It
>> is easy to change again in the future, but this seemed to be what the
>> working group liked. I also updated my demo implementation
>> (http://www.ksk-test.net) to use this naming scheme.
>> 
>> This version also clarifies that the test is "Is the Key ID a DNSSEC
>> root KSK?" Originally my view was that it should be "Is there *any*
>> key in the trust store with this keyID?", but after running some
>> numbers I decided that there is a significant chance of false
>> positives.
>> 
>> As I mentioned, it took an embarrassingly long time to post the update
>> - please let us know if we missed your comments.
>> 
>> W
>> -- 
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>   ---maf
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> John Dickinson
> 
> http://sinodun.com
> 
> Sinodun Internet Technologies Ltd.
> Magdalen Centre
> Oxford Science Park
> Robert Robinson Avenue
> Oxford OX4 4GA
> U.K.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop