Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Ben Schwartz <bemasc@google.com> Wed, 06 January 2021 19:45 UTC

Return-Path: <bemasc@google.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 5214A3A123E for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 11:45:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 us-fXQWFUq0S for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 11:45:06 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 049CB3A1229 for <dnsop@ietf.org>; Wed, 6 Jan 2021 11:45:06 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id u26so3858945iof.3 for <dnsop@ietf.org>; Wed, 06 Jan 2021 11:45:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lKm7V7FhFY3vkCNLXz/QGdzV1fAzkPezaACZ7SOTJE8=; b=g25BTSfw8biqT+hiXt9ZPrhcADFRf1dMebHdZMTsttNy5Ko9lOofp1dkh4mKgyPKk7 FYZE0VCSgDDDbczO+j4zVPr2Fr31kdrXuXJ0nUsR2ZkHnHkasMxE+VvrXxMRTzK46JVZ v9xSYwCJJky3i4CiezvK7CMiaaUTk+eX1l1eYq1Pu/mCqi5dlike9qI4pzwA5ilAEF+q j1bEn8RIRnFtFlljUOCZSFRzFYhGAWeqWMDmFFL1dXHBZD5dKyf5jqBihyu6znrl8Xg6 Zf/6LSTz2Byn8nWN4mHzupvPY0CZerXWe/OkDrICF3yU/eVzRNKtQzmPk/JFmFLGgnX4 Lkvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lKm7V7FhFY3vkCNLXz/QGdzV1fAzkPezaACZ7SOTJE8=; b=o+sQ7mv+cIFq2iMIumO2OIqrcmE0I+2xaImVNpNSWkhN2o7IXNpeURWp2wepztrG9v 3zT2CgD0mx6tQsRZAHovYNvEnj6SAbSADBk3BZk7ehVJqPJmkwFoVIYToW1OwiMIW3if DB0RzLInTfk03yhgHnx1GNPrR9CZRAyi3JssYo4lzQfIBz9VVGVqETVWgjGwpTXAdq0T +cFqo+8F41Z284OHIo8vT+hmPDmMwce6uWyCugFsArl54SxauIWzVNnyeMkBvdSUqXqh m6snYbSkF+DUp5A7YaCVgHTWv9JHtTpTxSS0eSbjAwt6lL006NfmQWMqmth5Y5Tqp/K1 gYrg==
X-Gm-Message-State: AOAM530+zHRmhLj7dogfxhYyeLJxmUaFoCXY4zMaflQb1NvufeJJYL7Z KVtdHGVSvyWsTbJiEGBH9fTnlrwe1oIb5nOFdg1cmcSCEag=
X-Google-Smtp-Source: ABdhPJzVZIJYJBD0qiQYxCeFJK+xRtyE8M1KxLKKH0wwxBvvj5sTUXVqQQbisEz/MvgJxhIbnz2oib+fPPMSzJkXmCk=
X-Received: by 2002:a6b:b788:: with SMTP id h130mr4094561iof.134.1609962305133; Wed, 06 Jan 2021 11:45:05 -0800 (PST)
MIME-Version: 1.0
References: <CADZyTkn1QuvjencR8+wVtQ9bzQHJT9JXXNku1LPr3YRmRt4KQg@mail.gmail.com> <2E8229BE-E764-4C29-A258-8C469717E38A@nohats.ca> <CABcZeBMr5Muijx5V7Se1UcxTB9DbAzF1iXZb7_FzEGfw982x8w@mail.gmail.com> <65e3288d-bdfe-ff10-2fbc-63a5d2dd9508@cs.tcd.ie> <797AAE77-2D50-4189-81D8-44BA495146F5@icann.org> <546e60c6-b109-8552-dfb4-7d3ba2ecbc71@cs.tcd.ie> <E58B4013-9491-43ED-83C9-250FF7647570@icann.org> <0746397c-ed85-429c-ff6e-a4a559520e86@cs.tcd.ie> <487928351.1557.1609759876775@appsuite-gw1.open-xchange.com> <60ba1f68-b07f-7a06-539f-60ce442ffbff@cs.tcd.ie> <195eb4c7-306f-97e1-b0df-f6678ebe732@nohats.ca> <ebb27f27-a243-67cd-2b5c-d2ecea741942@cs.tcd.ie> <24505bb1-cf40-25a7-337c-9b50fedfedc1@nohats.ca> <98299ffc-056b-16ee-1929-78543f5ec6d5@cs.tcd.ie> <F66DA99B-910E-4324-895D-F617B447612F@gmail.com> <CAHbrMsAqNXENeP2AdkEs7OC+YL6_z9VU89B7mNu3qOFBc7PQ=A@mail.gmail.com> <3a914ab5-2744-cec0-bbc8-bf39ec64a051@nohats.ca>
In-Reply-To: <3a914ab5-2744-cec0-bbc8-bf39ec64a051@nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 06 Jan 2021 14:44:53 -0500
Message-ID: <CAHbrMsDAMsXzAhcu35_GqL54JNF2jO-HhYWEZyE2VLP=V8dN5A@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000052557405b8408f85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Zs1ZfPsBzES6cG0LK9wWwb0kxQ0>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 06 Jan 2021 19:45:08 -0000

On Wed, Jan 6, 2021 at 9:57 AM Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 5 Jan 2021, Ben Schwartz wrote:
>
> > One thing I found surprising here is that RFC 6840 Section 5.11 says
> >    Validators
> >    SHOULD accept any single valid path.  They SHOULD NOT insist that all
> >    algorithms signaled in the DS RRset work, and they MUST NOT insist
> >    that all algorithms signaled in the DNSKEY RRset work.
> >
> > If a validator has more confidence in Algorithm A than Algorithm B, it's
> frustrating for it to be required to accept a B signature when
> > Algorithm A indicates that the record is Bogus.  Do validators actually
> behave this way, checking each signature until they find a valid one?
> >
> > Perhaps if we updated RFC 6840 to indicate that validators should
> validate only the most-preferred available signature (or indeed insist that
> > all supported signatures are valid), that would reduce the level of
> concern here.  Zones and resolvers could add more algorithms with no risk of
> > weakening their security posture.
>
> But it is the zone owner that declares what is acceptable to them for
> their domain, by using DS records of the type they want.


That model works well when (a) all validators implement an algorithm you
like OR (b) you view each algorithm as either "definitely strong" or
"worthless" (no middle ground).  Otherwise, the zone owner has a dilemma.
Should I protect fewer users with higher confidence, or more users with
lower confidence?  I think that is the sticking point in this conversation.

Telling validators to "insist" that all signatures are valid would resolve
this dilemma.  Zone owners could add algorithms without weakening anything.

Why should a
> resolver override that?
>
> Also, you would end up building a list of algorithms from worst to best.
> This is not always obvious. Sure, the SHA1 vs SHA2 is obvious. Would you
> prefer a NIST ECC curve over a GOST ECC curve or not?
>

TLS implementations always have a preference order, so I think this is
doable.  Literally any preference order would be more secure than the
behavior recommended in RFC 6840.


> DNS RFC's stick to the rule that validators should not be in the space
> of determining which crypto algorithm is preferred.
>

FWIW, a validate-all behavior would still be consistent with this rule.

Paul
>
>
> > On Tue, Jan 5, 2021 at 3:24 AM Василий Долматов <vdolmatov@gmail.com>
> wrote:
> >
> >
> >       > 4 янв. 2021 г., в 19:20, Stephen Farrell <
> stephen.farrell@cs.tcd.ie> написал(а):
> >       >
> >       >
> >       > Hiya,
> >       >
> >       > On 04/01/2021 16:05, Paul Wouters wrote:
> >       >> While asking is fair, you would also have to define what you
> >       >> do based on the outcome of that ask. You left that out,
> >       >
> >       > I don't think I did omit that. My stated reason to ask was
> >       > to help me figure out what I think about the draft named in
> >       > the subject line. And yes, I do think that if a codepoint
> >       > is being requested for a new version of an existing one
> >       > then asking about how the existing one was used is a good
> >       > thing to do. The case with gost and rsa+sha1/sha256 isn't
> >       > the same because gost is a series of national standards.
> >       >
> >       > > As to answer your question, I believe GOST did not see
> >       > > more than about 5 domains use it in what was clearly a
> >       > > "Testing" deployment.
> >       >
> >       > Thanks. In that case, it sounds like it'd have been better
> >       > to use a private or experimental code point for that kind
> >       > of thing. OTOH, my understanding (based only on hallway
> >       > chats over the years) was that the codepoint was allocated
> >       > for political reasons. Either way, does that mean that a
> >       > lot of effort to implement and test was wasted since that
> >       > codepoint was allocated? If so, avoiding that in future
> >       > would be good, if there's a way to do that.
> >       The situation with GOST in DNSSEC is explainable and was explained
> >       in the list during the discussion of another draft (and to you
> personally, AFAIR,
> >       maybe you’ve forgotten that).
> >
> >       To the time when RFC5933 was published and corresponding codepoint
> was allocated
> >       it has been known already that new version of underlying standards
> for hash and signature were on the way,
> >       so there were no reason to implement it immediately using
> standards which will be obsoleted soon.
> >
> >       That explains why there  were only several test implementations
> performed, which were intended to check
> >       smooth interoperability, if different algorithms were used in
> DNSSEC validation chain, with even several
> >       algorithms switches along the chain.  The interoperability was
> proven and results were presented on
> >       one of the RIPE meetings.
> >
> >       Then the DNSSEC deployment in Russia went into «waiting state»,
> waiting for:
> >        - new standards to be published in Russia
> >        - reference implementations of it were created  by different
> software teams with interoperability checks
> >        - making IETF community aware of them by publishing set of
> Informational RFC
> >        - «running code» was created for new standards in open-source
> software (implementing it in OpenSSL for instance)
> >        - assigning codepoints in DNSSEC registry
> >
> >       Now we are at the last step in this list, and after its completion
> we consider that it will become possible to deploy GOST in
> >       DNSSEC.
> >
> >       That explains why there is no wide deployment of GOST in DNSSEC
> until now. We prefer slow-pace but reliable way forward.
> >
> >       Btw, the same way was passed for TLS now, after codepoints for
> GOST in TLS has been assigned already, we have
> >       several different implementations of TLS with GOST by different
> software developer teams and we have a stand for TLS
> >       interoperability check which is run by the team independent from
> any of software vendors and performing the check that all
> >       implementations are mutually compatible and aligned with the
> corresponding RFCs.
> >       This stand  is used for the interoperability check of IPSEC
> implementations also and will incorporate DNSSEC in its scope in proper
> >       time.
> >
> >       dol@
> >
> >       >
> >       > Cheers,
> >       > S.
> >       >
> >       > PS: note that I'm neither supporting, nor objecting to,
> >       > Paul's draft in the above.
> >       >
> >       >
> >       >
> <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
> >       > DNSOP mailing list
> >       > DNSOP@ietf.org
> >       > https://www.ietf.org/mailman/listinfo/dnsop
> >
> >       _______________________________________________
> >       DNSOP mailing list
> >       DNSOP@ietf.org
> >       https://www.ietf.org/mailman/listinfo/dnsop
> >
> >
> >
>