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 > >
- [DNSOP] A conversational description of sentinel. Warren Kumari
- Re: [DNSOP] A conversational description of senti… Joe Abley
- Re: [DNSOP] A conversational description of senti… william manning
- Re: [DNSOP] A conversational description of senti… Joe Abley
- Re: [DNSOP] A conversational description of senti… Ralph Dolmans
- Re: [DNSOP] A conversational description of senti… Warren Kumari
- Re: [DNSOP] A conversational description of senti… Tony Finch
- Re: [DNSOP] A conversational description of senti… Warren Kumari
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… Geoff Huston
- Re: [DNSOP] A conversational description of senti… Andrew Sullivan
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… Geoff Huston
- Re: [DNSOP] A conversational description of senti… Paul Vixie
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… A. Schulze
- Re: [DNSOP] A conversational description of senti… Petr Špaček
- Re: [DNSOP] A conversational description of senti… Mark Andrews
- Re: [DNSOP] A conversational description of senti… Ray Bellis
- Re: [DNSOP] A conversational description of senti… Petr Špaček
- Re: [DNSOP] A conversational description of senti… Warren Kumari
- Re: [DNSOP] A conversational description of senti… Petr Špaček
- Re: [DNSOP] A conversational description of senti… Geoff Huston
- Re: [DNSOP] A conversational description of senti… Vladimír Čunát
- Re: [DNSOP] A conversational description of senti… Ray Bellis
- Re: [DNSOP] A conversational description of senti… Tony Finch
- Re: [DNSOP] A conversational description of senti… Geoff Huston
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… A. Schulze
- Re: [DNSOP] A conversational description of senti… Tony Finch
- Re: [DNSOP] A conversational description of senti… Patrick Mevzek
- Re: [DNSOP] A conversational description of senti… Petr Špaček
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… joel jaeggli
- Re: [DNSOP] A conversational description of senti… Joe Abley
- Re: [DNSOP] A conversational description of senti… Paul Hoffman
- Re: [DNSOP] A conversational description of senti… Petr Špaček
- Re: [DNSOP] A conversational description of senti… Warren Kumari
- Re: [DNSOP] A conversational description of senti… Warren Kumari
- Re: [DNSOP] A conversational description of senti… Benno Overeinder
- Re: [DNSOP] A conversational description of senti… Bob Harold
- Re: [DNSOP] A conversational description of senti… Matt Larson
- Re: [DNSOP] A conversational description of senti… Geoff Huston
- [DNSOP] Risk of using underscores for sentinel (W… Stephane Bortzmeyer
- Re: [DNSOP] Risk of using underscores for sentine… Vladimír Čunát