IETF Logo Mail Archive

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

Willem Toorop <willem@nlnetlabs.nl> Thu, 20 July 2017 09:48 UTC

Return-Path: <willem@nlnetlabs.nl>
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 7348213170E for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 02:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 mrdDsVeAgJkA for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 02:48:56 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C7613157A for <dnsop@ietf.org>; Thu, 20 Jul 2017 02:48:53 -0700 (PDT)
Received: from [IPv6:2001:67c:370:128:386d:ca0b:2cef:6352] (unknown [IPv6:2001:67c:370:128:386d:ca0b:2cef:6352]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id EC0F3B06E for <dnsop@ietf.org>; Thu, 20 Jul 2017 11:48:51 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1500544132; bh=CVw+hhO3lzDS+VW7wHtsaLsa8s4QfMK0SHJAde+wrTs=; h=Subject:To:References:From:Date:In-Reply-To; b=wBc9RVZ7/CFJjUtXkWSfs2WkYA7YertjjHvXQ8bTKjmwoaY2SRWIU3rhmuKgKyBgt /xoSDSB1vJRBzEex0pdntTiabIUUrcuXlSU0lBkgCZh5Mk/p/xtofdAeGJ0ggzIRsU QZTd2krxhIWs4lsfACixG53Jlud0rY5nGTicyFRg=
To: dnsop@ietf.org
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com> <CAN6NTqwi62xGtLnjNtV-CDCBKBV1TVEsCjbGUvtf_nxmcZEapw@mail.gmail.com> <CAHPuVdWisdPS3ezBsGSyX7Uh7Yw3HHcTaHHz3y9xA+Fow7G4Yw@mail.gmail.com> <CAN6NTqwB8b1aFsZg=LnaLWLrhLDe9-N3CVPO=qcHWXZTqSettg@mail.gmail.com> <CAHPuVdVGn0p9g5c-kXwmy_N2WtrGxDhcEG2mkxWyvh5XVTcMoQ@mail.gmail.com>
From: Willem Toorop <willem@nlnetlabs.nl>
Message-ID: <257a0f7a-a78d-d665-512f-ff2a71dfaede@nlnetlabs.nl>
Date: Thu, 20 Jul 2017 11:48:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAHPuVdVGn0p9g5c-kXwmy_N2WtrGxDhcEG2mkxWyvh5XVTcMoQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pEMEM2xmtI-5aq_4074E8j-uQ1M>
Subject: Re: [DNSOP] 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: Thu, 20 Jul 2017 09:48:58 -0000

Op 20-07-17 om 10:45 schreef Shumon Huque:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
> <olafur@cloudflare.com <mailto:olafur@cloudflare.com>> wrote:
> 
> 
>     I disagree, if a zone operator selects "less-than" common algorithm
>     they do that at their own risk, 
>     if the risk is not acceptable then it should dual sign.... 
> 
> 
> Yes. The point I was trying to make is that DANE sites (and probably
> others if they care about security) cannot afford to fail open. So they
> have to dual sign if they can stomach the costs, or delay deploying new
> algorithms for a long time. This draft is intended to (eventually) make
> the dual signing case easier to deal with operationally.

So,

Providers of DANE backed services are stuck on the well-known
algorithms, and do not have insight on algorithm support by clients
verifying these services with DANE.

This draft in combination with double signing, provides the means to
deal with this (and in a secure manner too).

I think this is an important motivation of this work and that this
should be reflected in the Introduction section of the draft.

-- Willem

> 
> -- 
> Shumon Huque
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email