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

Ólafur Guðmundsson <olafur@cloudflare.com> Mon, 10 July 2017 21:01 UTC

Return-Path: <olafur@cloudflare.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 DBDC01318EA for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 dKq4V7rIxFgY for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:01:18 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 EC0F61318D7 for <dnsop@ietf.org>; Mon, 10 Jul 2017 14:01:17 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id d78so84653640qkb.1 for <dnsop@ietf.org>; Mon, 10 Jul 2017 14:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=rgJB90LDr/rBfaP461oGnJkRTB5Zu669m80m+p8dWvbjiIosb64LY104YvDpwaYs0i rAeWH8lA6nUY6wYS9PHtZ4+t0sP549vlF8/2VjlPMfhOWV0eOPn5oCtxy+GN2NuuLYgj BUwUEVzkksksNqXuHTSSy1xj6BryEaoHcJVLk=
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=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=P7NZSBNMpH5Q8LJ9wlDey0ZUKnEVjJS+g4o0HB0XdjVTTikrpo3DAXv/UWj46Qm4X+ QPvRwVvZUpjSHBX1FkfGdD6GEKQUcr0dg1vVFn1rBva2hgV8GZ4DVVgMCstjdnXRzQZM eAFb6FY2/5b4x9+Qle6KBX/cNaDStogAKE8U2muu2kEBkqPVltjIPuoS1MSAULDFrM9m ec64DJhyiU5IDtD3i8wcZsXSSvCMeA7PM5FqeTD2H5SrJ9sKLFrnwA2HiyQdFwUq5Rk7 ZxoPMfFZaVNqrJpnO54GErH94nOR6XbnOs/W8UHE09BacvCuF+nuDeAwIqlsqY68NTXw NVNw==
X-Gm-Message-State: AIVw112Pq0gqoffO5Jhg58SM49MEbg+W7RdvXQqUd7/XEMWoRZ9zrkIj EbF6G9ciBZ3BEs1h1RqE71ICpQ1qayMa++3V0g==
X-Received: by 10.55.53.202 with SMTP id c193mr6075934qka.232.1499720476851; Mon, 10 Jul 2017 14:01:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.88.136 with HTTP; Mon, 10 Jul 2017 14:01:16 -0700 (PDT)
In-Reply-To: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Mon, 10 Jul 2017 17:01:16 -0400
Message-ID: <CAN6NTqwi62xGtLnjNtV-CDCBKBV1TVEsCjbGUvtf_nxmcZEapw@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146f28e4926a00553fce23f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ydWkpFtSfD0aQ6zjuJrpCweropA>
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: Mon, 10 Jul 2017 21:01:20 -0000

Shumon,

In section 5 your draft says:

   If an Authoritative Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.



This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

Section 6
This is hopeless algorithm, that goes against the justification of the
document.
basically it may force validating resolvers to fetch the answers multiple
times for each TTL; once without DNSSEC, then for first algorithm, then for
all algorithms ==> right now validating resolvers only fetch once with
DNSSEC enabled.


This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

overall this draft main idea: DNS publishers should sign with more
algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set
==> better for DDoS

Olafur



On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <shuque@gmail.com>; wrote:

> Hi folks,
>
> We've posted a new draft on algorithm negotiation which we're hoping to
> discuss at IETF99 (and on list of course). I've discussed this topic with
> several folks at DNS-OARC recently.
>
>     https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Algorithm Negotiation in DNSSEC
>         Authors         : Shumon Huque
>                           Haya Shulman
>  Filename        : draft-huque-dnssec-alg-nego-00.txt
>  Pages           : 9
>  Date            : 2017-07-03
>
> Abstract:
>    This document specifies a DNS extension that allows a DNS client to
>    specify a list of DNSSEC algorithms, in preference order, that the
>    client desires to use.  A DNS server upon receipt of this extension
>    can choose to selectively respond with DNSSEC signatures using the
>    most preferred algorithm they support.  This mechanism may make it
>    easier for DNS zone operators to support signing zone data
>    simultaneously with multiple DNSSEC algorithms, without significantly
>    increasing the size of DNS responses.  It will also allow an easier
>    way to transition to new algorithms while still retaining support for
>    older DNS validators that do not yet support the new algorithms.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
> https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00
>
> --
> Shumon Huque
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>