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

Shumon Huque <shuque@gmail.com> Mon, 10 July 2017 20:22 UTC

Return-Path: <shuque@gmail.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 104A61317C9 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 13:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 s7lY-wyoxFV5 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 13:22:39 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 F235912F258 for <dnsop@ietf.org>; Mon, 10 Jul 2017 13:22:38 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id z22so61781595uah.1 for <dnsop@ietf.org>; Mon, 10 Jul 2017 13:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NZ5oWsczhHZyGTYOcNkUuMMuAXefBqqaJv6Pfw2Cq8=; b=cKh6SZaYK0vrGWxjExavo65zaOas2blSIsH6yLRHuRWwnyMlMF7izrbyfC9WUcQFH3 dkv553Mn4FitLxrMHaMLIjqU/vla7qxxVMGNYc/liX5pk2j1e0+OgEc0VoqBuVMT05kM +OewbFgiHO5P8z+Bb2NiHnNQEpuYOmkbcfz0CSRWNmWaYgTbIVuCoNwsT//c8QPNr5rk GYte/UwTPLQ72TN47nO/qLIDnJ10he/vs/UndUtJBZS6S9q1GrxKFL8Ph9LyE+EyY1TG yCkLr3jX438zcUVRmSYEmAQlVLbY3xkt/W51IXp1Ylvlu+wTjGlT4/S4AQCplL51sMW4 NRUQ==
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=2NZ5oWsczhHZyGTYOcNkUuMMuAXefBqqaJv6Pfw2Cq8=; b=nzlbfa0T6xbvU+PfyW1emttae98h7zJQsVlrIxiCRXgAj13sXIeedXsojnNlw9k/Ll 0QDLTvc15CKDVVjZgIHrK4rpey75A2jzch0iWZ+denrHVzgw2BzF/jqycckN4JFXibKF Ez34bZz1lDM/wqcFDHOXawTpSVqnkXaCBq2AeqUETbLRD1NB1HYH9UhmM0JzH8lM2BxK gCJJpOXIZQXxwZHQzON3Y+sgh6F9geWylnSG+v+Bh63cCunMLP2WlNIw9LsQ3vTeK/Td lF6t33DQWpr0z9UyWNuijEm/tgPNqbhyCprPJUAtZ4nG43BR283utNlfxAU3K5biTzJH PCaQ==
X-Gm-Message-State: AIVw1102KF289zr0MGfJZSOXBcd+OvyMwxttSrFizhlrmbel0G0OLRwS g4S9PJJ1VVbCTm225S9kgll11bVuCg==
X-Received: by 10.176.93.2 with SMTP id u2mr9837518uaf.109.1499718158140; Mon, 10 Jul 2017 13:22:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 13:22:37 -0700 (PDT)
In-Reply-To: <CAHPuVdVWi-4nQeoBuyKe7f81mieVpznFwd25Nb5at6t-JpYzUA@mail.gmail.com>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com> <CA+nkc8BiSMSNqa9FifNAqWiZuf7prVjD6EKSnbFjq_EWi8kSoA@mail.gmail.com> <CAHPuVdVWi-4nQeoBuyKe7f81mieVpznFwd25Nb5at6t-JpYzUA@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 10 Jul 2017 16:22:37 -0400
Message-ID: <CAHPuVdUnUhfVtvgBWbyXD1fWjz04QMKp59Ar1HNonmAkJeLj6A@mail.gmail.com>
To: Bob Harold <rharolde@umich.edu>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f40304362188144a330553fc58df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m6LRvJo_4fIawhSkRs2u-gKOVy8>
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 20:22:41 -0000

On Mon, Jul 10, 2017 at 2:53 PM, Shumon Huque <shuque@gmail.com>; wrote:

> On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold <rharolde@umich.edu>; wrote:
>
>>
>> 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
>>>
>>> --
>>> Shumon Huque
>>>
>>>
>> I like the idea.  I am not an DNSSEC expert, but wondering in section 7,
>> paragraph:
>>
>>    In order to detect such attacks, the client SHOULD compare the zone
>>    signing algorithms listed in the zone's authenticated DNSKEY RRset,
>>    and the preferred list in the query that it sent, to the algorithms
>>    seen in the response signatures.  If signatures by the most preferred
>>    algorithm they have in common have not been sent, this may indicate
>>
>>    an algorithm downgrade attack.
>>
>> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet,
>> to would not be available for response signatures?
>>
>
> Hi Bob,
>
> Very good question Yes, there certainly can be. If the pre-published key's
> algorithm is higher strength than the others, then it could cause the
> resolver to mistakenly deduce an algorithm downgrade attack might be in
> progress. I think this argues that we really do need the new zone apex
> (active) algorithms list record - which we already were thinking of
> proposing - in the last paragraph of Section 7.
>

Replying to my own message (sorry!) ..

It occurs to me that RFC 4035 and RFC 6781 both say that zone data
currently need to be signed by a key of each algorithm in the DNSKEY RRset.
So perhaps you can't pre-publish a key of a new algorithm. This draft, if
adopted, may also have to qualify some existing language (e.g.
distinguishing an authoritative server _having_ signatures of each
algorithm, from selectively _returning_ signatures of a specific algorithm,
if signaled).

-- 
Shumon Huque