Re: [DNSOP] Updated KSK Sentinel document

Bob Harold <rharolde@umich.edu> Tue, 13 February 2018 17:11 UTC

Return-Path: <rharolde@umich.edu>
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 C465A126CE8 for <dnsop@ietfa.amsl.com>; Tue, 13 Feb 2018 09:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 WlKzNuoq0kYJ for <dnsop@ietfa.amsl.com>; Tue, 13 Feb 2018 09:10:59 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 97E3512D84A for <dnsop@ietf.org>; Tue, 13 Feb 2018 09:10:58 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id k19so26039198lfj.1 for <dnsop@ietf.org>; Tue, 13 Feb 2018 09:10:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3D8i1ucSaC6QZ2lgbVpfJq2EkKDBQXIZAuGR6ymLncc=; b=UA8GVHB5drpjpAsYAp5NhSI2kIU6WnlSIPf0DobtU1h6mDis04gG50t15B0PkXrVpi rV0ap/HyvVMBiAEuLNJIjCWLHT7vjYHDSDDL8ReuElMIs8BkTuRCX2MnJYyp8bRKIsvs eEJ7lhNzahEeZePc0TYYYm12rn3SyCEFnwxqrgc18hsZjIerX5daC1CEFcCEdAgjoxRV dywYAyNRNe8ti/tyccBKXaiawWL7b3LpcC8d9xId6TB8Xudgv+mdKg5eGs+UWchBo3cV gjTBrvQqnQEyZBqTEklAy5AW80GYItkEA2ZcJyhpvwVoFaJ4rZmjdbBQpgT+KUbhyz1l G4kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3D8i1ucSaC6QZ2lgbVpfJq2EkKDBQXIZAuGR6ymLncc=; b=XTrVzG3BQClsrf2XdFHrLiKr9gp1awcTaUmfpUyZH6Z3puos7L3XkqB0ilFJxbnkgO rQx4tZ72qn1DKQn4wf3h9lYsg6749y1nhz2gK4OeqrWLKznj0UBNhRrKKd6dP9hdfO+Q W5ILHCfTMJ84bvi7wMAJcwZfOxAv3TxCgByVneFde7AVTre8TuVTYOyYljsz7pSGg4DV +wTQtR7j80ndUyAjgNwOVV18z4W/Mhfnm1qxJM9bf8cJvu1W4WUJmcuMGbx4bddrdKMG hMnFdNwbyYhjuiuBFvaACglRVeTqUyeVVzBLY00wq5JcmdhIDJwcySr1IjzA9/mb1pcE DdvA==
X-Gm-Message-State: APf1xPBO2nhnFTwJaCHKGGfUlDfv0a1/vwo6tXxWYKb+86J3gNhPFryd yNaSvP2B2gVllhApl9fP4QsoJyNFK5MWVuQnsvtrnQ==
X-Google-Smtp-Source: AH8x2251np27IIffvite5k3pR1pGIirXjv6yn5OkJQiQLKJqqFEd1s2THa0QrG8PLEPBpYEOqUrGYI877xVe4M1hXz0=
X-Received: by 10.46.16.74 with SMTP id j71mr1344954lje.139.1518541856814; Tue, 13 Feb 2018 09:10:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.84.21 with HTTP; Tue, 13 Feb 2018 09:10:56 -0800 (PST)
In-Reply-To: <CAHw9_iJ5Dr0sHw3EkWyHeAVDDb3k=8C6XOfrA02-_bQzd4n2Sg@mail.gmail.com>
References: <CAHw9_iJ5Dr0sHw3EkWyHeAVDDb3k=8C6XOfrA02-_bQzd4n2Sg@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Tue, 13 Feb 2018 12:10:56 -0500
Message-ID: <CA+nkc8AeY2+Azw7Rk-y4s5Gfp=amYZNiN=_kxtetgS9s8kcEYg@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1a6224f3c4b105651b1344"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YzNnm_NopocrKugNASMqOT4BpDo>
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: Tue, 13 Feb 2018 17:11:02 -0000

On Mon, Feb 12, 2018 at 3:28 PM, Warren Kumari <warren@kumari.net> 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
>
>
Thanks, the explanation helped.  I finally realized that it only works if
all (or most) validating resolvers are updated to support this new feature,
otherwise we have a bunch of responses that are uncertain.

Thinking out loud...
If an entry could be put in the root zone, that is signed only with the new
key, then could users query that and always get a yes/no answer to whether
they will be affected?
I realize it might be difficult politically or process-wise.
Not sure if it could be just a pair of A and AAAA records, or a delegation
to a temporary TLD.
And is it even possible, since it probably needs a new ZSK based on the new
KSK?

-- 
Bob Harold