Re: [dane] List of incidents that DANE would have blocked?

Warren Kumari <warren@kumari.net> Fri, 03 October 2014 20:45 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BBA1A03A5 for <dane@ietfa.amsl.com>; Fri, 3 Oct 2014 13:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 K4n9s_KfqCLJ for <dane@ietfa.amsl.com>; Fri, 3 Oct 2014 13:45:48 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19EE1A1A59 for <dane@ietf.org>; Fri, 3 Oct 2014 13:45:45 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id cc10so2472151wib.2 for <dane@ietf.org>; Fri, 03 Oct 2014 13:45:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/eaZrTFEm8+/YcYc6Kgkc0EX8YbP+pr4oRyhcs3HLFY=; b=d1UOM+22Bus1v5Ww3UbagdrMGFrLEDPe950JQMz6oyHuMZ0cm/6FM8OIFqGWuOii1L rHULumHfHrSVjBFZgyT0hF5Cao3AtF5sw25WecLcEYeX4JWl+5QdymFjokmrvJOZYL3T 4A0p7gVi4oC+EPot+4gdYmzNEGMJ+MAn0w46tg7MwIfs2UccstX6OBqLYhOTq89MNSOS Mnxy/Ig8NRAak9+r5/lmsPJ3g8+CuTXFHotYcjb81W2gs/iq1sFE4ZWBzibnWgizs6Ue osmQI04fhyxR167AuCUZFAxzzYOMAMb5krTzaAKX2x+CdmrfBmCm6HohUIbfQdcZRk0r 3Bdg==
X-Gm-Message-State: ALoCoQkIw6Ez8WuWsgzPnE5BqcZMj67+ynGHjpgz2CjHRrxR45ZyX5e7/XDzfXmapvS3HUCe5dhV
MIME-Version: 1.0
X-Received: by 10.194.24.169 with SMTP id v9mr10684394wjf.114.1412369144520; Fri, 03 Oct 2014 13:45:44 -0700 (PDT)
Received: by 10.194.119.233 with HTTP; Fri, 3 Oct 2014 13:45:44 -0700 (PDT)
In-Reply-To: <570ff050aaf87884e5d2d81a2f6ecf2a@triangulum.uberspace.de>
References: <DD18BA26-107D-4584-ACDE-131DD3D45AE6@mac.com> <570ff050aaf87884e5d2d81a2f6ecf2a@triangulum.uberspace.de>
Date: Fri, 03 Oct 2014 16:45:44 -0400
Message-ID: <CAHw9_iKoLCst7d7TqHGrozOVa6-N8TkgJqhHjYtbGsBXFBUj1Q@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Rene Bartsch <ietf@bartschnet.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HxvrZDWjwXWlstLqO38H7rdu6sM
Cc: IETF DANE Mailinglist <dane@ietf.org>
Subject: Re: [dane] List of incidents that DANE would have blocked?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 20:45:49 -0000

On Fri, Oct 3, 2014 at 5:38 AM, Rene Bartsch <ietf@bartschnet.de> wrote:
> Am 2014-10-01 18:37, schrieb William Stouder-Studenmund:
>>
>> I learned about DANE recently and was excitedly talking to some
>> operations friends of mine about it. Some of them work in shops that
>> aren’t using DNSSEC yet, and DANE’s requirement of it would trigger
>> push-back from management.
>
>
> Primary nameservers like BIND or PowerDNS generate DNSSEC-resource records
> automagically.

Yup.

> All you need to do is to handover your DSKEY/ZSK to your
> domain registry periodically.

Yup.

> Usually you just have to Copy&Paste the new
> keys into your registrar's web-interface per quarter, half-year or year.


Which gets annoying *really* fast.
May I introduce you to RFC7344 - Automating DNSSEC Delegation Trust
Maintenance (http://tools.ietf.org/html/rfc7344)

Ask your favorite name server vendor to implement this -- basically it
automates rolling over of your keys, by having the old key introduce
the new one.

W



> Even my private domains are secured with DNSSEC/DANE by using a DNS-operator
> with managed DNSSEC. I only generate the TLSA-RRs myself when I change the
> TLS-certs every two years.
>
> As a quick-start I suggest to use Shumon Huque's web-generator for TLSA-RRs
> (https://www.huque.com/bin/gen_tlsa). To reduce effort of changing TLSA-RRs
> when changing the TLS-certificate you can use CNAMES and wildcard-RRs
> pointing to ONE single TLSA-RR. For client-side I suggest a warning message
> in your shops to encourage users to install the CZNIC DNSSEC/TLSA Validator
> web browser add-on (https://www.dnssec-validator.cz/).
>
>
> Renne
>
>
> --
> Best regards,
>
> Rene Bartsch, B. Sc. Informatics
>
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane



-- 
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