From nobody Thu Dec 10 15:48:28 2020 Return-Path: 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 E99DB3A134F for ; Thu, 10 Dec 2020 15:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AKz26AQNw6pt for ; Thu, 10 Dec 2020 15:48:24 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 8437B3A1350 for ; Thu, 10 Dec 2020 15:48:19 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id f71so1664539vka.12 for ; Thu, 10 Dec 2020 15:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ceGcnccjwRZX1Y6uCBpaVm7WFRIgT1+Xp+EZbwzkYag=; b=evnbKlHG9C7uzCsTWxdeivbd06kPn47PGy1X3CS9iu35UzLUYI8bYDYQqWuOcVmamq DjmvIAnobKnogT2wd2hSg+UPVpMwK+6sqway5IyhhgR1zxjDJvSWFYOd1XVNI3bTtvbi +27X1B5DUYzyKtfUjA/mYP4Fbn13GI3u1UBj/tM7P3l+l7q/i9jDdvoresbCV5VtBu4Y g4teN5wONwNrGTqiwrxPH3g+mfaLGkRGngQq4yVt5t/WgZMC74B1k7pWCZoggKfrXaZn pSA7GsCHr/nGHUd3ASl8SfFyn6/Yl+9dZ3f6HAQ0Dz+otTMH8aUW6IDpZyQk41bAOS0+ G9og== 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=ceGcnccjwRZX1Y6uCBpaVm7WFRIgT1+Xp+EZbwzkYag=; b=IplBPrzJoBRliCa+W1maztFIFTpicbEy9YIVhHFPRs4bNchiWzFDeo0S6tNW6vt6fM 25xglgYONizxniUHi0RmkDi2aaxgVolanVTERD3cBDqc6txdeDFkZdgn0zFsTLaCHb67 kjo0i7Py6CRhEdvX/gRxJE7H/PqMaSc4HDbGx2ZGtJXQ4NRpisuoIq8PDeba4Ec5S0qg hVAApF+w+koNVopPyc+1+ZJX0wqAywN70ivSgbpLmfeE+t0IUxT2EK7NPvJDWX8SzGgt IpAZ0gaXUag1i3hoPfZct0D4cCLNxIU2ecrzIalnb91vl+7L8q/5LaITQ+2HRjZaMDSK YlqA== X-Gm-Message-State: AOAM533h+V/JmZ4KxpzDRQOR5tbo4h9nc93ymrGDrsU8MILJyF3S7UZe GvnVx8ngQNrIUNBFvTG5+umKlcLnR4vC6DxFkz3Gt18vuJsFEg== X-Google-Smtp-Source: ABdhPJwXdrSdBUavFWTfNPsZucM8AIOPp/jgLeLnyAyTJK7uEGn/bt1E1oqM17GUgqexkJGsHNAwOWok7bmm1Qow4Ac= X-Received: by 2002:a1f:34c4:: with SMTP id b187mr11552493vka.0.1607644098430; Thu, 10 Dec 2020 15:48:18 -0800 (PST) MIME-Version: 1.0 References: <20201105.172635.572683028769863094.fujiwara@jprs.co.jp> <20201112.183133.1534594902398859181.fujiwara@jprs.co.jp> In-Reply-To: From: Brian Dickson Date: Thu, 10 Dec 2020 15:48:07 -0800 Message-ID: To: Peter van Dijk Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000698b3d05b624cfe6" Archived-At: Subject: Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer)) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 23:48:27 -0000 --000000000000698b3d05b624cfe6 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk wrote: > Hello Paul, > > On Mon, 2020-11-30 at 15:43 +0000, Paul Hoffman wrote: > > The more I think about > draft-fujiwara-dnsop-delegation-information-signer, the more I think that > it is much more complex than what we are doing now in DNSSEC, and therefore > undesirable. > > My feelings are similar but not identical - the conversation already > shows that the glue story will be almost impossible to implement. Next > to that, I haven't figured out why we'd want to authenticate glue. > However, authenticating the delegation NSset fills an obvious gap in > various suggested answers to the dprive phase2 question (privacy > between resolvers and authoritatives). > > > If the goal is "a way for a signer in a parent to sign child NS in a way > that does not affect validators that have not been updated (or don't > care)", a significantly easier solution would be a new RRtype (maybe called > "CNSRRSIG") that closely mimics RRSIG but only allows child NS for signing. > An aware signer included the CNSRRSIG in the zone, and an aware > authoritative server includes in in the Authority section when serving > child NS records. An aware resolver can use this, an unware resolver would > treat it like any other unknown RRtype that appears in the Authority > section. > > I think this is close to the mark, but still slightly off. My take on this is roughly as follows: - The goal here (as I understand it, or perhaps how I interpret it) is to have NS data, corresponding to the child apex NS set, published on the parent zone and signed by the parent (and used by upgraded resolvers without breaking anything not upgraded). - This involves at minimum the following elements, presented in a kind of "reverse Polish" order: - An RRSIG (or RRSIG-like thing) in the parent zone over something new (TBD1) - A way of publishing that "something new" to the parent (TBD2) - A way of authenticating/validating that "something new" in the process of publishing to the parent (TBD3) - A way of linking the published "authenticating/validating" data with data signed in the child zone, when being used/validated by the resolver (or client) (TBD4) - For "TBD1" If we keep the existing RRSIG signatures themselves, the only question is when to include the "something new" in the delegation response, along with the matching RRSIG. - This suggests no need for a new RRSIG-like record type per se. - Existing 403x/5155 logic handles adding RRSIGs to answers - For "TBD2", the concern over what "something new" could be, and how it gets published to the parent. - Options to consider for "something new" itself are: - A new RRTYPE with owner name of "apex" - An existing RRTYPE with owner name of "apex", with new parameters - An existing RRTYPE with different owner name - (For completeness, A new RRTYPE with different owner name) - Options to consider for "how it gets published" are basically: - EPP - This suggests the fewer "new" things involved, the better. Zero new things would be ideal. - This itself leads to preference for "An existing RRTYPE with owner name of 'apex', with new parameters", specifically: - Published RRTYPE == DS - DS value is hash of DNSKEY with new parameters, specifically a new algorithm - The new algorithm is "concatenation of child apex NS RRSET in canonical form and order" (i.e. that is what the DNSKEY 'public key' field would be comprised of) - NB: The existing specifications handle this -- new (unknown) algorithms MUST be treated as if the record didn't exist. - Some implementations may need to be fixed, based on some experiments thus far. - I think TBD3 and TBD4 are flip sides of the same coin. - RRTYPE == DNSKEY or DS (depending on TLD) transferred via EPP to the parent - If RRTYPE transferred is DNSKEY, perform hash to produce DS. - TBD3 is probably optional as it related to EPP - TBD4 is the resolver/client validation, in two parts: - Construct DNSKEY from input data (NS RRSET) - Hash to create DS - Compare to published DS - Check RRSIG over DS - The use case of getting the glue (and validating it) without actually sending queries to the auth server itself prior to validating the glue, is a classic "catch 22". The owner name of the NS set in the child zone, is "privacy sensitive", at least in most use cases. However: - Keeping the apex and delegation NS set in sync, and the DNSKEY and DS in sync, can address this problem: - Use CDS/CDNSKEY to publish DS/DNSKEY records that match the current AND updated NS RRSET, prior to changing the NS RRSET - Use the *delegation* NS RRSET rather than the *child* apex NS RRSET for the validation (ie for recreation of DNSKEY and DS records) - This would add extra steps when changing NS, but would still be deterministic and possible to build into a state machine, with an extra moving part (or two) - It would then be feasible to get validated glue prior to querying the authority server (e.g. for its TLSA record) and/or to establish a TLS connection to the correct IP and name. The TL;DR: of this is: no EPP changes needed, no new RRTYPEs needed, slightly more steps in rolling the NS set during a change. > This makes a ton of sense to me. > > Compared to DiS, registrar complexity is identical (because the > complexity is also hidden in the signer here); signer complexity is > potentially lower. The only real complexity change vs. DiS is in the > auths, that now need to know to serve CNSRRSIG from the parent side in > the additional part of a delegation response. For resolvers, this vs. > DiS is again pretty much moot. > The CNSRRSIG would also require delegation auths (i.e. TLDs) to make changes, and I think also require EPP changes. See above for a very slightly different take on this idea, that avoids these issues. (EPP and TLDs are definitely the "long pole in the tent".) > > > There are probably a few other diffs from the RRSIG definition in RFC > 403x, but they should be minor. This might make implementation more likely > to be correct for signers, servers, and resolvers. > > Yes, this calls for some experiments, but I suspect the outcome will be > as you described above - which means no hurdles to incremental rollout. > > (I am not even convinced this needs to be a new type, vs. reusing RRSIG > under the specific semantics you described, but a new type feels > cleaner to me.) > > > Thoughts? > > +1 ! > +1 for me too. Brian --000000000000698b3d05b624cfe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 10, 2020 at 1:19 PM Peter= van Dijk <peter.van.dijk= @powerdns.com> wrote:
Hello Paul,

On Mon, 2020-11-30 at 15:43 +0000, Paul Hoffman wrote:
> The more I think about draft-fujiwara-dnsop-delegation-information-sig= ner, the more I think that it is much more complex than what we are doing n= ow in DNSSEC, and therefore undesirable.

My feelings are similar but not identical - the conversation already
shows that the glue story will be almost impossible to implement. Next
to that, I haven't figured out why we'd want to authenticate glue.<= br> However, authenticating the delegation NSset fills an obvious gap in
various suggested answers to the dprive phase2 question (privacy
between resolvers and authoritatives).

> If the goal is "a way for a signer in a parent to sign child NS i= n a way that does not affect validators that have not been updated (or don&= #39;t care)", a significantly easier solution would be a new RRtype (m= aybe called "CNSRRSIG") that closely mimics RRSIG but only allows= child NS for signing. An aware signer included the CNSRRSIG in the zone, a= nd an aware authoritative server includes in in the Authority section when = serving child NS records. An aware resolver can use this, an unware resolve= r would treat it like any other unknown RRtype that appears in the Authorit= y section.


I think this is close to the mark, but= still slightly off.
My take on this is roughly as follows:
=
  • The goal here (as I understand it, or perhaps how I interpret = it) is to have NS data, corresponding to the child apex NS set, published o= n the parent zone and signed by the parent (and used by upgraded resolvers = without breaking anything not upgraded).
  • This involves at minimum t= he following elements, presented in a kind of "reverse Polish" or= der:
    • An RRSIG (or RRSIG-like thing) in the parent zone over som= ething new (TBD1)
    • A way of publishing that "something new"= ; to the parent (TBD2)
    • A way of authenticating/validating that &quo= t;something new" in the process of publishing to the parent (TBD3)
    • A way of linking the published "authenticating/validating" d= ata with data signed in the child zone, when being used/validated by the re= solver (or client) (TBD4)
  • For "TBD1" If we keep the = existing RRSIG signatures themselves, the only question is when to include = the "something new" in the delegation response, along with the ma= tching RRSIG.=C2=A0
    • This suggests no need for a new RRSIG-like = record type per se.
    • Existing 403x/5155 logic handles adding RRSIGs = to answers
  • For "TBD2", the concern over what "s= omething new" could be, and how it gets published to the parent.=C2=A0=
    • Options to consider for "something new" itself are:<= /li>
      • A new RRTYPE with owner name of "apex"
      • An exi= sting RRTYPE with owner name of "apex", with new parameters
        • <= li>An existing RRTYPE with different owner name
      • (For completeness, = A new RRTYPE with different owner name)
    • Options to consider fo= r "how it gets published" are basically:
      • EPP
      • = This suggests the fewer "new" things involved, the better. Zero n= ew things would be ideal.
    • This itself leads to preference for = "An existing RRTYPE with owner name of 'apex', with new parame= ters", specifically:
      • Published RRTYPE =3D=3D DS
      • DS= value is hash of DNSKEY with new parameters, specifically a new algorithm<= /li>
      • The new algorithm is "concatenation of child apex NS RRSET in = canonical form and order" (i.e. that is what the DNSKEY 'public ke= y' field would be comprised of)
      • NB: The existing specifications= handle this -- new (unknown) algorithms MUST be treated as if the record d= idn't exist.=C2=A0
        • Some implementations may need to be fixe= d, based on some experiments thus far.
  • I think TBD3 = and TBD4 are flip sides of the same coin.
    • RRTYPE =3D=3D DNSKEY = or DS (depending on TLD) transferred via EPP to the parent
    • If R= RTYPE transferred is DNSKEY, perform hash to produce DS.
    • TBD3 is pr= obably optional as it related to EPP
    • TBD4 is the resolver/client va= lidation, in two parts:
      • Construct DNSKEY from input data (NS RR= SET)
      • Hash to create DS
      • Compare to published DS
      • Chec= k RRSIG over DS
  • The use case of getting the glue (and val= idating it) without actually sending queries to the auth server itself prio= r to validating the glue, is a classic "catch 22". The owner name= of the NS set in the child zone, is "privacy sensitive", at leas= t in most use cases. However:
    • Keeping the apex and delegation N= S set in sync, and the DNSKEY and DS in sync, can address this problem:
      • Use CDS/CDNSKEY to publish DS/DNSKEY records that match the curren= t AND updated NS RRSET, prior to changing the NS RRSET
      • Use the d= elegation NS RRSET rather than the child apex NS RRSET for the v= alidation (ie for recreation of DNSKEY and DS records)
      • This would a= dd extra steps when changing NS, but would still be deterministic and possi= ble to build into a state machine, with an extra moving part (or two)
        • <= li>It would then be feasible to get validated glue prior to querying the au= thority server (e.g. for its TLSA record) and/or to establish a TLS connect= ion to the correct IP and name.
The TL;DR: of this = is: no EPP changes needed, no new RRTYPEs needed, slightly more steps in ro= lling the NS set during a change.
=C2=A0
This makes a ton of sense to me.

Compared to DiS, registrar complexity is identical (because the
complexity is also hidden in the signer here); signer complexity is
potentially lower. The only real complexity change vs. DiS is in the
auths, that now need to know to serve CNSRRSIG from the parent side in
the additional part of a delegation response. For resolvers, this vs.
DiS is again pretty much moot.

The CNSR= RSIG=C2=A0would also require delegation auths (i.e. TLDs) to make changes, = and I think also require EPP changes.
See above for a very slight= ly different take on this idea, that avoids these issues.
(EPP an= d TLDs are definitely the "long pole in the tent".)
=C2= =A0

> There are probably a few other diffs from the RRSIG definition in RFC = 403x, but they should be minor. This might make implementation more likely = to be correct for signers, servers, and resolvers.

Yes, this calls for some experiments, but I suspect the outcome will be
as you described above - which means no hurdles to incremental rollout.

(I am not even convinced this needs to be a new type, vs. reusing RRSIG
under the specific semantics you described, but a new type feels
cleaner to me.)

> Thoughts?

+1 !

+1 for me too.

Brian=C2=A0
--000000000000698b3d05b624cfe6--