Re: [DNSOP] A conversational description of sentinel.

william manning <chinese.apricot@gmail.com> Mon, 15 January 2018 12:22 UTC

Return-Path: <chinese.apricot@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 1277B12741D for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 04:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 JiGY7PdP36Kr for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 04:22:42 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 E0FAC127342 for <dnsop@ietf.org>; Mon, 15 Jan 2018 04:22:41 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id w14so14287itc.3 for <dnsop@ietf.org>; Mon, 15 Jan 2018 04:22:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HwlqQvmcvGJ8c0jhE8Jne2NwJV9MY5QrjpyqXZ8NuBs=; b=FiTB1lzunGPuyvLvyhsZHT0stmItok+SkMMeHTFJ9eq1NTEuHExVtoNEudXbWctR7k QBs1tBcocPgPMmTGp6DFx50z6HICGUHbLouANFekJyd/rs2aeKi/O2RHpJxYHyoKwoGT zk1QFjryFtJjmHUauVN6Pk/Td7+vjTLoXeAJhEXUOJVtvlFnnNHT5HF6Qmpaiayo2rF5 DfxhKt+8e+Kwnyp/k1DMjl2YQEU+eOHjXEFjEfK+atUj/1JB4zPYA5KgTRVN+RIdkHY/ Trx4gRy1gJfX3wnJ47VOBsTDePe2NpXY7WWBmbF6mD6zvd5qTn1aT27PEqYgd1IZ4iHx vAQA==
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=HwlqQvmcvGJ8c0jhE8Jne2NwJV9MY5QrjpyqXZ8NuBs=; b=RzTuZx1uPokL17kIwDnZlScM9tCT0Tqf7KLMa38YbkcoeJXXxxLYJUUfakK0OXP4yb Huz8RD2zj/W3lU80ojdA3QCmKLlKiMB5Q+YWO3/BbERyGGdFeqadTBfjEttqFjsnBS3r HhXl43Ybc2udsnK3zxBbFG6w/EZZApQ6ME/FgefXo586qN8nuUml/fhocpLzjXTIfWVR Dn9TSz3Nlb2VW7XV8YFNXkCZ2U9jmGfjkSugVf4A5g/ab39eEKkZKEfFWBhv7U7ZfX4n ywv9kFndY7/muMi5+7jP8syZN0Ay72kIFR8cr4XwSEm/Tv3MVaKQBokBzk2DSTz5PNR4 9s/Q==
X-Gm-Message-State: AKwxyteD1biWO7TFH9GlYd15OViJhemnpvRN0yRUv88ncoqSazjaYcLG wKtdJLCBrc1wk5QDkXL/I2PlURiCTxg0pbGXvxk=
X-Google-Smtp-Source: ACJfBovDCSo7e6xHUkpBMDk14b9/mgZczv8lEnfMUzjpakWGeQRo5iydPU0Np6ze5m9Eno3x40Ql0mr01eKfxeATzcU=
X-Received: by 10.36.16.142 with SMTP id 136mr14601401ity.18.1516018960924; Mon, 15 Jan 2018 04:22:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.185.132 with HTTP; Mon, 15 Jan 2018 04:22:40 -0800 (PST)
In-Reply-To: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com>
References: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com>
From: william manning <chinese.apricot@gmail.com>
Date: Mon, 15 Jan 2018 04:22:40 -0800
Message-ID: <CACfw2hgEjmerPvB1vPj5z+XCd_rO=CRf=K244tWiwKoCL6PJLA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143877aa383790562cfab8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eidVkFbseQ7rZO-uitP8VjM4_w4>
Subject: Re: [DNSOP] A conversational description of sentinel.
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: Mon, 15 Jan 2018 12:22:44 -0000

your wrote,: "​In the real world, the user will not be expected to figure
this out [...] --  a bit of JS on www.example.com will do the 3 fetches and
report "You'll be just fine", "You will have issues, call your ISP and get
them to install the new key" or "Sorry, cannot tell.​ Call your ISP and ask
them to upgrade to a resolver which does this!"."

I think its a bit  sad that for the DNS to work, one now needs to run
http[s] and JS.   So much for stand alone protocols. Now if you could show
how this works without JS or HTTP, then we might be getting somewhere.

/Wm

On Sun, Jan 14, 2018 at 5:51 PM, Warren Kumari <warren@kumari.net> wrote:

> Hi all,
>
> I had a conversation with a friend earlier today, who had carefully read
> the document
> ​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​
> , but had not managed to understand it at all
> ​.​
> ​Since
>  this friend is bright, and really understand
> ​s​
> DNS, I figured that the document doesn't do as good a job explaining how
> this would be used in practice as it should. Sometimes it is easier to
> explain things in an informal manner, and so here is a (hopefully better)
> description of draft-ietf-dnsop-kskroll-sentinel).
>
> 2 things seemed to be causing confusion:
> 1: The only "magic" that happens is in validating recursive resolvers,
> right before they send the response to a query
> ​. T​
> here is no magic / change needed in authoritative servers, stubs, or
> anywhere else.
>
> 2: Anyone who wants to provide a service like this
> ​(see below) ​
> can - you don't need to be in any special location in the DNS tree to do
> this.
>
>
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).
> B: If the qname starts with _not-ta and the included keyid *IS* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).
>
> (There is some pseudo-code below, but it makes this look much more complex
> (and I dislike pseudo-code - it's hard to guess at the level of abstraction
> to use!).
>
>
> ​Let's pretend ​
> I'm the operator of example.com, and I'd like to help users know if the
> resolvers that they use will survive the new keyroll (with key id 12345).
>
> I publish this in my a zone:
>
> _is-ta-12345.example.com.   600     IN      A       192.0.2.1
> _is-ta-12345.example.com.   600     IN     RRSIG   A <valid signature>
>
> _not-ta-12345.example.com.   600     IN      A       192.0.2.2
> _not-ta-12345.example.com.   600     IN     RRSIG   A <valid signature>
>
> invalid.example.com. 600     IN      A       192.0.2.3
> invalid.example.com. 600     IN      RRSIG A <0x0000 (an invalid
> signature)>
>
> ​I also run 3 webservers:
> ​
> 192.0.2.1
> ​   -- a picture of a cute kitten
> 192.0.2.
> ​2   -- a picture of a puppy
> 192.0.2.
> ​3  -- a picture of a fish.​
> ​
> ​
>
>
>
> I now tell users to please browse to www.example.com, where I have a
> webpage which includes the following links: http://_is-ta-12345.example.
> com/
> ​(​
> kitten) , http://_not-ta-12345.example.com/ (puppy),
> http://invalid.example.com/ (fish).
> ​The pictures the user can see tells them if they will survive the
> rollover.
> ​
>
>
> The user can be in one of 4 classes, depending on which animals they see:
>
> 1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the
> URLs (including http://invalid.example.com/). If they see a Fish, they
> are not using a validating resolver and so will survive the keyroll (it
> actually means that at least 1 of their resolvers is not validating). The
> user is happy and goes to have ice-cream (nonV).
>
> 2: The user sees a only Kitten and a Puppy (they fetched http://_
> is-ta-12345.example.com/ and http://_not-ta-12345.example.com/, but not
> http://invalid.example.com/.) This means that they are using a
> ​legacy ​
> validating resolver
> ​ (it ​
> doesn't implement this mechanism
> ​)​
> .
> ​They cannot tell, and this test doesn't tell them anything
>  (Vleg).
>
> 3: They see only a Kitten (they fetched http://_is-ta-12345.example.com/,
> not http://_not-ta-12345.example.com/, and not http://invalid.example.com/).
> The user is behind a validating resolver which implements this mechanism,
> and knows about the new key. They are happy, and go have ice-cream (Vnew).
>
> 4: The user sees only a Puppy (they did not fetch http://_
> is-ta-12345.example.com/, they did fetch http://_not-ta-12345.example.com/,
> they did not fetch http://invalid.example.com). The user is behind a
> validating resolver which implements this mechanism, but does NOT have the
> new key). The user is sad, and calls their ISP to complain (and has cold
> porridge for dinner) (Vold).
>
> +-------------+----------+-----------+------------+
> | Type\Query  |  _is-ta  |  _not-ta  |  invalid   |
> +-------------+----------+-----------+------------+
> | Vnew        |    A     |  SERVFAIL |  SERVFAIL  |
> | Vold        | SERVFAIL |      A    |  SERVFAIL  |
> | Vleg        |    A     |      A    |  SERVFAIL  |
> | nonV        |    A     |      A    |     A      |
> +-------------+----------+-----------+------------+
>
> ​In the real world, the user will not be expected to figure this out from
> looking at pictures --  a bit of JS on www.example.com will do the 3
> fetches and report "You'll be just fine", "You will have issues, call your
> ISP and get them to install the new key" or "Sorry, cannot tell.​ Call your
> ISP and ask them to upgrade to a resolver which does this!". There will
> also likely be some Geoffvertisement which will do this on a large scale
> and report back.
>
> ​Hopefully this clears things up some -- the only code change needs to
> happen on recursive resolvers, the A record returned is unmolested (so that
> if can be used for something) and the only action is to make some VALID
> answers INVALID (A (or whatever) -> SERVFAIL).
>
> W​
>
>
>
> ​Pseudo-code:​
>
> func extract_ta(string):
>    # Extracts the queried trust anchor (a set of digits) from a qname.
>    # E.g: "perl -pne "s/_.*-ta-(\d*)\..*/\1/" (_is-ta-55555.foo -> 55555)
>    return (numbers)
>
> <normal processing>
> ...
> queried_ta = extract_ta (qname);
> if qname startswith("_is-ta-"):
>    if queried_ta is in trust_store:
>       return;
>    else:
>       return SERVFAIL
>
> if qname startswith("_not-ta-"):
>    if queried_ta is in trust_store:
>       return SERVFAIL;
>    else:
>       return;
> ---
>
>
> --
> 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
>
>