Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

George Michaelson <ggm@algebras.org> Fri, 21 July 2017 12:58 UTC

Return-Path: <ggm@algebras.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 0064B1300BB for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 05:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=algebras-org.20150623.gappssmtp.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 tD7Jlt9M72fF for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 05:58:24 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 8CCFD12F24E for <dnsop@ietf.org>; Fri, 21 Jul 2017 05:58:24 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id k43so8116634uaf.3 for <dnsop@ietf.org>; Fri, 21 Jul 2017 05:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YDCh6OaxKktwCpcKbKOqZ4pzhivpCNrJqHt0NB7j1/I=; b=e1pwHYasmThKtwpO6VvqERBCi4/jIAgZpIkg24xBTmlkB0Wbo05SjhfNArByK4uNI1 omfVVtmb1buYgSSTqllWbIY50lLGvawB28EgXv7hJAKl2aRENMdijKBbQeBfF7PmkORx 1vVK5vxNc/pyXT7XCClkr3yC13FCkaN1Ovzu5jK6RbQTTEhlPMViS01iHCmKBUEMO2ex fT0rjtKIOeuWM36dyDe1s0AM7gC0fbfQS6W9klU73iH4Pwv0NiqQU5FfmdHlnANzHMby vmM8PZL5srYfhX77h1gtgu9btqmjQV2VG4vc3mxZnTLKa8tMV4kTF2inFtSkqYcy826C 5a9A==
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=YDCh6OaxKktwCpcKbKOqZ4pzhivpCNrJqHt0NB7j1/I=; b=aKcub3w1mCFcosNrKWR0OWuo5mOo+iPyqyx/0ZVtN7mk49pFDx4xGdjiE0wegeKjfu FYPQy38+igp1iEfNkYk9NJkFm2arUfKUyqhPYXKbyR2NA53IQch1qjVA8q89I4zFLwwr s3dGSq3+BOWfhVxt5IcqIhQmUMhNdq8NzqrdJuIim5K6WCBh8ZDwTRdVOg68WgFJx9wU rAUdQkpelkPVmJlL6AObeB80eJVpyMFfd3BbiwKTWcVtBXXUFp7/RcQAYZx8sYixx2RW fjas1qCyW0K1KTbpvIzSj7CQA5kG15NGOnZ0txHuQLLCEI3ZGFZfCphu9H4d1EZBzfTy FH4Q==
X-Gm-Message-State: AIVw111jK/iiBvTCXfKv8mEw0PTizZHhdT28Bbohm59RTni0nq4Z+k9S O17D5dQhqzkcYhTJZfHHctgDYaLRyMoj3Pk=
X-Received: by 10.176.23.3 with SMTP id j3mr4938905uaf.128.1500641903600; Fri, 21 Jul 2017 05:58:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.68.87 with HTTP; Fri, 21 Jul 2017 05:58:23 -0700 (PDT)
X-Originating-IP: [212.71.191.138]
In-Reply-To: <CAHw9_iKnXzXp6RDx+H8Ui5FUdpVjWzbnNJb-Y9+EjEaJEEKP7A@mail.gmail.com>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com> <CAN6NTqwi62xGtLnjNtV-CDCBKBV1TVEsCjbGUvtf_nxmcZEapw@mail.gmail.com> <CAHPuVdWisdPS3ezBsGSyX7Uh7Yw3HHcTaHHz3y9xA+Fow7G4Yw@mail.gmail.com> <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> <alpine.DEB.2.11.1707211229310.4413@grey.csi.cam.ac.uk> <CAHw9_iKnXzXp6RDx+H8Ui5FUdpVjWzbnNJb-Y9+EjEaJEEKP7A@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 21 Jul 2017 14:58:23 +0200
Message-ID: <CAKr6gn2X3RdXYRkW+b9rWESHZCfdfkEQ1of6AEy9f6MgYWMvjQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wqOwNcEcXg5w9Sqe4ITeHO4VFIQ>
Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
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: Fri, 21 Jul 2017 12:58:27 -0000

A fine bit of epistemology lies in the question: is it the same
certificate, if you re-issue it with the same keys? No, because it has
a different serial. but the crypto doesn't care, its the validation
which cares which is a product of the crypto. so validation cares but
cryptographic functions themselves, not such.

The nice thing about bare key cryptography, is that fish don't need
bicycles. Dates are dates and validity intervals are a thing, but you
can re-bake as many times as you like if there is nothing embedded in
the structure like a serial. Oh wait.. we sign the SOA don't we...

I (for one) hang onto the .req file. Maybe thats naughty, but I do, so
in my case Warren routine is that the keypair is being reused,
because.. well.. because I like to. Software I consume I suspect (like
you) doesn't, and re-mints shiny new keys now with added keynomium,
but when I do it by hand? yes I reuse the .req file.

But I am probably being led into bad places as a result. I am sure
wiser heads will say.

On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari <warren@kumari.net> wrote:
> On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch <dot@dotat.at> wrote:
>> Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>>>
>>> For instance, people also express astonishment that DNSKEYs don't
>>> expire.  Everyone always has to be reminded that signatures expire, and
>>> if you want to expire keys you take them out of the zone.
>>
>> I agree with your message.
>>
>> It might be useful to explain this DNSKEY oddity by comparison with x.509
>> certificates. In particular, it's the cert that expires, not the key, and
>> when you renew a cert you can re-use the same key.
>
>
> Yeah, you *can* reuse the same key, but (I suspect) most don't -- from
> what I've seen, then general process is:
> 1: Erk! My cert is about to / has just expired!!!
> 2: Search for and follow some online recipe related to "make ssl certificate"
> 3: ????
> 4: Go back to sleep.
>
> I think that (but would be happy to be proven wrong) that most
> certificate renewals[0] involve a change of keys too.
>
> W
> [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc.
>
>>
>> Tony.
>> --
>> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
>> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8
>> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or
>> rough. Rain or showers. Good, occasionally poor.
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> 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