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

Bob Harold <rharolde@umich.edu> Mon, 10 July 2017 17:50 UTC

Return-Path: <rharolde@umich.edu>
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 D46FB12EB99 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 10:50:20 -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 (2048-bit key) header.d=umich.edu
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 V9ZHjtUvDBV1 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 10:50:18 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 7AEC71315FF for <dnsop@ietf.org>; Mon, 10 Jul 2017 10:50:17 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id e201so30518489ybb.1 for <dnsop@ietf.org>; Mon, 10 Jul 2017 10:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r88VOM+R9C78ICDkJLNd4yGspJ0lYCR+FG1oMrt8R0Q=; b=AKIM6hBoj7/NFig4JpwUKDm/xJHElrPILKwHgwyzRpVJc2gWXj27HqblpeL/9Tldgx GC3MwVC+t80v1mxtEPpNdelpQR+Qxu8DpZw+hrOzPU8HErTJLzEPhLQY1TLS+HLpWykC Z4u3HznqfiWraQKYDYqnl03BvkPyC+FKaaX9UpeiLzGvgTG3hkXOz2rCaPGCggVhWUgr 08sb8tDAIdA4jCviMTdv0cfavezzpwarqxdnw8pUf+Ml+/QfCbMjY0a7P2CxK03FXCl+ rUiwS24oGoL10azRM4mcAe3bS2ESb5E3rsDmQ3CZgxjC+eihhk/hWLYO4fds2PvSEh/H xgzA==
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=r88VOM+R9C78ICDkJLNd4yGspJ0lYCR+FG1oMrt8R0Q=; b=Sk2Wei3VFvumvbrgc6w8zn4u4XPLCF82jbO/PlVS0R/2U60hNq5meMZrPkzfWP6oCw lfawPYEJs0CT19tZpIHfOqfVMGtszro6VlgRw7Dig8AebwGYSci0IspHBCzciWVpCIHe B9UfxKMkSP+msl2ul+kdFlsDG2et4958wYT+iRIL9OpPR2Of8ibliuZyPa/R6aPbY5kK JrBTxFKphqqI1CjXgdD6Pjhn4vTHQsnGM8ABHQnGG9UItZ/FHFLLvWyFZtP3VrVPmXb3 fx9voDbLAbRqn6BAROeJnpTDZB2mK2WFItT2YJs1EEoi+F4AuLSCfF1qZUOBY2YI8dRW 3PuQ==
X-Gm-Message-State: AIVw111VmJORVHa1upXfueX5BNkbKYR3lFGJnFG2eZzeXEWYGyfzjCO1 m3JhAyBFh/PlaqIgwW+L1t2P27ClUrIT
X-Received: by 10.37.35.198 with SMTP id j189mr16109487ybj.91.1499709016601; Mon, 10 Jul 2017 10:50:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.51.132 with HTTP; Mon, 10 Jul 2017 10:50:16 -0700 (PDT)
In-Reply-To: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Mon, 10 Jul 2017 13:50:16 -0400
Message-ID: <CA+nkc8BiSMSNqa9FifNAqWiZuf7prVjD6EKSnbFjq_EWi8kSoA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d40cc3390900553fa37c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fY-MQKDDlv43qrin9hrjGu0ijQQ>
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 17:50:21 -0000

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

And perhaps a really dumb off-topic question:
I do not use DNSSEC yet, mostly due to time and effort, secondly due to
concern over the additional size and processing.  Is it possible for me to
start with a new, rarely implemented, algorithm with shorter records, that
most resolvers won't understand yet, and have those that don't understand
it treat the zone as unsigned?  Or will it break everything?  (Section 5
sounds like it breaks)

-- 
Bob Harold