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

Ólafur Guðmundsson <olafur@cloudflare.com> Thu, 20 July 2017 08:39 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 BEFD2127735 for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 01:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 vAxYxIndDFpB for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 01:39:40 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 B883B127869 for <dnsop@ietf.org>; Thu, 20 Jul 2017 01:39:39 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id n42so16498368qtn.0 for <dnsop@ietf.org>; Thu, 20 Jul 2017 01:39:39 -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=mzXQp89c0mawNN8rxigxcw4w3j5Uf5pB/VeHmiFcrBk=; b=c+I+XZF8AIqV6vwxaGe2s10Uaez5QXru5/NutnS4spjb3szy8v1AbbLYzVRs8tYmvt +wFqU8GEAKFLtE0jvFqOuurViEcMIEj6EJQmHaNdla/N73/74Lqg3BXa+mjuMc2uyH73 RRDRwZe1K/uUFjUZRDTeLrOsriBG4nRzGQF0s=
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=mzXQp89c0mawNN8rxigxcw4w3j5Uf5pB/VeHmiFcrBk=; b=dGdcqGNMDnk1lEP86gUu5WfYZ3rAt7gMywsSMRTGk0qBRrlMFJp0zTR8L2WuyDAR/v 6J7F19MntTZwvwuqOwvd9Y1naRsV3Tq7nKlR1y60oyRyPjodPevLAOIcfgu0ZdzXE3lX 4Yyn1hvSXMJjMFaTMctFtuUSn1vN/M7u3qDTcZOCF890dwGODR/SO3rhnWrah1Q5p4QQ 05eXBJzbwuMWzaAjb0vhPmYh9Px+8J+WQPnE4TlGR/o7thZDdk53dX6j+47l27+w2z2I oKW8AIE0Ab/OWqUwwzg1geg2FfvqqjXfmvZHVLwisAL+hh2aIzandlMKLJ9LAH3hji76 FBFg==
X-Gm-Message-State: AIVw113mOLQNOUhHZij/9JT8ev+eiEXmG1SfIi+mWOxlPwbJJ0mHf+X5 FEIsDKPPLafS9z6NcXqlwDg0PGEd71sK
X-Received: by 10.237.60.57 with SMTP id t54mr4029260qte.281.1500539976116; Thu, 20 Jul 2017 01:39:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.88.228 with HTTP; Thu, 20 Jul 2017 01:39:35 -0700 (PDT)
In-Reply-To: <CAHPuVdWisdPS3ezBsGSyX7Uh7Yw3HHcTaHHz3y9xA+Fow7G4Yw@mail.gmail.com>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com> <CAN6NTqwi62xGtLnjNtV-CDCBKBV1TVEsCjbGUvtf_nxmcZEapw@mail.gmail.com> <CAHPuVdWisdPS3ezBsGSyX7Uh7Yw3HHcTaHHz3y9xA+Fow7G4Yw@mail.gmail.com>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Thu, 20 Jul 2017 10:39:35 +0200
Message-ID: <CAN6NTqwB8b1aFsZg=LnaLWLrhLDe9-N3CVPO=qcHWXZTqSettg@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c191f5c3f82e60554bbb089"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iXFU3-DwUoLPJ9dC3H9nsUP59-k>
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 08:39:42 -0000

On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque <shuque@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson <olafur@cloudflare.com
> > wrote:
>
>> 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.
>>
>
> As I tried to explain in my previous note to Paul Wouters - fail open is
> horrible for DANE. Protocols can evolve. If DNSSEC had algorithm
> negotiation from the beginning, fail open would not have been necessary.
> This fail open behavior frequently takes people not in the DNSSEC club by
> complete surprise. I've lost track of how many "WTF" moments I've had to
> explain to other people about this behavior. This proposed behavior change
> is also signaled, not unilateral. But let's debate ...
>
>
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....


> 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.
>>
>
> There has to be some initial fallback behavior with costs. This is not
> uncommon in new protocols. Think about longer term benefits.
>

After thinking about this a few times,  I still see no future benefits.

>
>
>> 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.
>>
>
> See previous discussion.
>
>
>>
>> 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
>>
>
> DNSSEC already has a DDoS reputation - this isn't going to make things
> that much worse. Also DNSSEC has already been way surpassed in this area by
> NTP/SNMP etc. What we should be working on is deployment of proper protocol
> level mitigations, like Cookies, etc.
>
>

I'm not sold on Cookies solving real problems.
The way to get away from that reputation  is online signing of negative
answers and retirement of all RSA signatures (no I'm not promoting NSEC5),
Online signing with NSEC works just fine.

Olafur