Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-verification-techniques-01
Tim Wicinski <tjw.ietf@gmail.com> Wed, 05 July 2023 18:43 UTC
Return-Path: <tjw.ietf@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 56F54C15106D for <dnsop@ietfa.amsl.com>; Wed, 5 Jul 2023 11:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4hJanwKqrq6 for <dnsop@ietfa.amsl.com>; Wed, 5 Jul 2023 11:43:21 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F136C151089 for <dnsop@ietf.org>; Wed, 5 Jul 2023 11:43:03 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-992f6d7c7fbso643849666b.3 for <dnsop@ietf.org>; Wed, 05 Jul 2023 11:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688582581; x=1691174581; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H+Pzm3lqnwR04H3Uaq503b6+KDsV4sQzbyNfAiqcnPI=; b=sNHRa6hSGBQJETJVcY9uowXzooQjcPXzHnjWkRfSFz6Rqt/RCVdceONqueqX9k3Qpg C/o1P2Vpe5sjzj8HgZUthPitAyL4G+cJSlDhjjhIFjzavV0z8NRTC9BEJiTgC7Bv7ked 2oMk+LDGKlywISR84HpkmaeS3tyEvU8sp45/KzjCHxl88ELk4QNWPOzRwv+ydcIouFkO YEWA61zy1VSs7pWqfYdjGB0YiejMciacMJzShMLdED0CO0rSSYCQqGTpEIP9Mm1TunSc GXCMNZT+9M6pYggbby8VyOysX1Sl4cEVNxcL6nqK0YL6jD56KfJB0rLCu54DE1yEDsXF 7C4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688582581; x=1691174581; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H+Pzm3lqnwR04H3Uaq503b6+KDsV4sQzbyNfAiqcnPI=; b=FEqJGZmvmfWuJR5P52J+JZi06bzLJIbiFQa7lO7jt/uPwbvBU962UWTFukk0n32Vil U2J66LJVXvU6f7CmKYECtsQSMEmEZ3Xb/F8k/DYjQvz+HiCbTz01er/Q7RJmEM6/gn9m zJzVH1YyGINiOePPDcVkUyM3TrZMt/1OgCfP7WTvNu8MdPPIf80jUSblt0icak7yH7lR bsgtEh4tF+X3LjYVPyRCOO+4Vq+RwMkZaNymlbGSkLApFd3wPi/mCcV8ne+N9KtA3Ze8 HoMPSwybP7Q8f7fguNFpQp787B46k/27toLyLU3HBvjzxOtLtJbKIjDjYRWjElqYx3vH ceZg==
X-Gm-Message-State: ABy/qLYgkwgqbQ5/XiZFJCb9JPHIg8d0Yjlt8M+mMqXzsptrZUdJk28I P3TqnfKv/00xQru08u4+Xx05+K7fKTQRPQYqc50=
X-Google-Smtp-Source: APBJJlH3oba4+9jAvzvz1PhcP7dWYbLniLphmPprLk6ECDGuNyrL4DN1n82S6wTIDxyFm81fRnk5EXKm9c8pMzaoBX4=
X-Received: by 2002:a17:906:a88b:b0:992:9d41:874d with SMTP id ha11-20020a170906a88b00b009929d41874dmr12466920ejb.13.1688582581427; Wed, 05 Jul 2023 11:43:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJiNXLzOXBnZ6XCzuqO=YpVbtFGPvVdXhJ8tuhSaJadkFw@mail.gmail.com>
In-Reply-To: <CAKC-DJiNXLzOXBnZ6XCzuqO=YpVbtFGPvVdXhJ8tuhSaJadkFw@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Wed, 05 Jul 2023 14:42:49 -0400
Message-ID: <CADyWQ+FSDRpabkAD_qk=cK+Oqw2Wd5TdX5ngSyx9RT6bBbJ--Q@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: dnsop WG <dnsop@ietf.org>, Shumon Huque <shuque@gmail.com>, paul.wouters@aiven.io, shivankaulsahib@gmail.com, Erik Nygren <nygren@akamai.com>
Content-Type: multipart/alternative; boundary="000000000000f0a0f905ffc1c405"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lYUGLwHOIYjgtS7YlYAZe2QdB-A>
Subject: Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-verification-techniques-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 05 Jul 2023 18:43:25 -0000
Erik I placed your excellent comments into the author's issue tracker, then we decided to split them up into separate issues. Take a look to confirm. If anything is wrong, it's one me tim APEX domains, and hostnames vs domains https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/65 Public Suffix https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/66 SaaS/Paas/intermediary provider cases (eg CDNs) https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/67 Leveraging ACME challenges for other purposes https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/68 Multi-provider / multi-CDN setups https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/69 Token format / construction https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/70 Binding tokens to requests https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/71 TTL recommendations https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/72 Policy constraints as a variant https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/73 Registry of labels https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/74 On Thu, Mar 30, 2023 at 4:53 PM Erik Nygren <erik+ietf@nygren.org> wrote: > Hello, > > Thank you for pulling together this draft! Having worked on related > systems a number of times it will be valuable to have something here > standardized. > > A number of comments and suggestions: > > 1) APEX domains, and hostnames vs domains > > You define APEX but don't then reference this. This is an important topic > to cover in considerably more detail, however. In particular, some systems > want to validate an apex domain while others want to validate each > particular hostname. It is critical that validation record and its > contents are unambiguous as to which of these is the case. > > As an example, ACME has separate mechanisms for wildcard certs (eg, "*. > example.com") vs individual names (eg, "bar.example.com"). > This is likely to apply across the board to these systems: sometimes they > want to validate usage for a domain and sometimes for just specific names. > > For the individual hostname case, it is important to clarify that the > challenge should be "_foo-challenge.bar.example.com". > > For the whole domain case this could be "_ > foo-wildcard-challenge.example.com" or have an attribute in the TXT > token (eg, wildcard=true). ACME (rfc8555 section-8.4) doesn't seem to > have this differentiation, which seems unfortunate, unless I'm misreading. > I'd think that it should be unambiguous to domain admins whether a > challenge is for just the "example.com" name, for "*.example.com", or for > "example.com, *.example.com, *.*.example,com, etc". > > What it means to validate a hostname or a domain or a wildcard set of > hostnames may vary widely per application, and we may want to talk more > about the security considerations here. > > Ambiguities about whether a given verification token grants powers over a > specific hostname or an entire domain also introduce security challenges > that we may wish to talk about in Security Considerations. DNS domain > administrators need to be able to understand the consequences of adding in > particular challenge entries into their domain, especially in cases like a > multi-tenant Enterprise environment. > > 2) Public suffixes > > We may wish to encourage (or require) validating against Public Suffix > lists (eg, https://publicsuffix.org/), in the absence of a more general > DBOUND solution. At a minimum we should discuss this in security > considerations. > > One Security Consideration is that services operating a public suffix > should take extreme care about when they allow underscore labels to be > created within a shared domain. As an example, if a service provider > allows "_foo-challenge.publicsuffix.example" to be registered as a domain > (for a DNS registrar) or to be created as a CNAME or TXT record (eg, for a > dynamic DNS provider or cloud provider) then this might grant unintended > powers over all of "publicsuffix.example". > > We may also want to (encourage? require?) confirming that a user isn't > trying to place a validation token on a public suffix. ACME has this as a > "CA Policy Consideration" (Section 10.5 of rfc8555). There are some > legitimate use-cases here, but caution (and perhaps extra validation?) is > needed. > > (For the Appendix, another example would be the PSL itself. Per > https://github.com/publicsuffix/list/wiki/Guidelines > It uses "_psl.alphaexample.com TXT > https://github.com/publicsuffix/list/pull/100" for validation.) > > 3) SaaS/Paas/intermediary provider cases (eg, CDNs) > > A common use-case is for delegation of control over to an intermediate. > For example, indicating that a SaaS provider or CDN may manage certificates > for "foo.example.com". One way to handle this is to have CNAME the > challenge to that intermediary and then the intermediary returns the TXT > record. For example, you might have: > > _acme-challenge.foo.example.com. IN CNAME > ${TOKENA}.intermediate-provider.example. > ${TOKENA}.intermediate-provider.example. IN TXT ${TOKENB} > > This allows .intermediate-provider.example to keep updating TOKENB > for each renewal. (It's not reasonable for the intermediate provider to > tell their customer > to go back and require updating _acme-challenge.foo.example.com every > three months.) > > This is often going to be done alongside delegating the hostname > to the intermediate provider. For example, there will likely also be a > CNAME of: > > foo.example.com. IN CNAME foo-example-com.cdn.example. > > The separate CNAMEs (ie, these being distinct labels) are important > because > the certificate and validation needs to happen before actually moving the > hostname over. > > This is a case where the CNAME for "_acme-challenge.foo.example.com" > generally needs to be persistent > for frequent/periodic renewals. > > Of critical importance is that TOKENA is also secure and has enough entropy > and is tied to the particular customer account that provisioned > foo.example.com. > > In the draft we probably want to talk about this as cases where there is a > CNAME to the TXT record, > and that the target of the CNAME needs to itself always have a token with > adequate cryptographic entropy. > > We might mention in A.1.4 on Time-bound checking that cert renewals are a > case where > persistence is required, at least of a CNAME to a provider who may be > managing the renewals. > > 3a) Leveraging ACME challenges for other purposes > > A related question worth considering: when is it acceptable to leverage > ACME challenge for other purposes? For example, if moving a domain onto a > CDN that is going to get a certificate for the domain prior to the > migration but which also wants to validate that it is authorized for the > domain to be transferred to it, when can the ACME challenge also be > leveraged for both purposes? > I'm not sure we need to go into this, but perhaps it should be discussed. > > 4) Multi-provider / multi-CDN setups > > A related and messier corner-case are multi-provider / multi-CDN setups. > For example, "foo.example.com" may CNAME to one of three different CDNs. > Each one of these needs to be able to manage a certificate and renew it > every three months. > This likely applies to some of these other cases as well. I don't have > good answers --- ACME doesn't > handle this terribly well today --- but it is worth some thought as to how > to handle. > > 5) Token format / construction > > It seems like the actual token contents should have more flexibility. > I don't think we want a "MUST" on that particular construct. It may be > worth > a MUST that there is at least 128 bits of secure entropy, and that the > token is > either base64 or hex encoded. But there may be a need to use other > constructs in the future (eg, not SHA256). Giving the current example > as a MAY seems reasonable. > > There may be reasons for other constructs that embed state within the > token. > For example: "HMAC-SHA256(private_key, label+account+domain)" may be > appropriate in some cases, > although has enough security considerations that I'm not sure we want to > include that. > > 6) Binding tokens to requests > > We should have a note on the critical importance of binding the token to > the requesting account and to the requested name. > At a minimum this should be in Security Considerations, but it may also > wish to be normative. > Usage here typically follows a flow of: > a) user/account requests a token for a given $name from a service > provider > b) user/account has their DNS admin put their token in for > _challenge.$name > c) service validates that _challenge.$name has $token and then grants > access to the user/account > > There are chains of custody here and linkages that need to happen, and are > exploitable if they break down. > For example, if steps (a) and (c) aren't explicitly linked then a > different user on a different account > could potentially jump in at step c and grab access. There may be other > corner cases here, > and it may be worth some more detailed formal analysis to be able to > express what properties are critical > for safety. > > There may be a related Security Consideration that I'm not sure how to > handle where a MitM style attack could jump in before step (a). For > example, if the user is phished into talking to a different service > provider than they thought they were talking to. (I'm not sure this needs > to be discussed, but is a risk.) > > 7) TTL recommendations > > We should provide some TTL recommendations for the TXT record, and perhaps > also provide > a warning on long SOA (negative caching) TTLs. > > This seems like a case where we'd want to recommend using short TTLs on > the TXT record > to allow recovering from misconfigurations. These shouldn't be polled > frequently so cachability > is unlikely to be an issue, but if there's a typo and the TTL is long then > there may not be a way > to recover since the validator may have the bad entry cached for the TTL. > > A long SOA TTL (ie, negative caching TTL) could also cause issues. > Once the service provider issues the challenge the validator may start > polling for its presence. > The first attempts are likely to get an NXDOMAIN, and if the NXDOMAIN is > cached too long > this could cause user confusion and/or delay the validation. > (I'm not sure it's reasonable to suggest that validators bound the maximum > NXDOMAIN caching time?) > > 8) Policy constraints as a variant > > Within ACME, challenge tokens exist as only one part of the validation > process. > They act as an explicit "allow this particular name to be issued this > particular cert based on a CSR". > There is also another safeguard, however, which is the CAA record. That > acts as a policy-based constraint. > > As we are generalizing the challenges, it may be worth considering > generalizing the policy-based constraints. > For example, in an enterprise environment "example.com" may wish to limit > the use of _foo-challenge > under their domain so that bar.quux.example.com can't put in "_ > foo-challenge.bar.quux.example.com". > (More concretely, example.com may wish to limit the CDNs and/or SaaS > providers that can be used > within their domain.) > > This is almost certainly substantial scope creep for this draft, but > without it domain admins > may be unable to apply policies or manage the sort of risks managed with > CAA records. > > This might be as simple as allowing the definition of _ > foo-constraint.example.com as a TXT record, > with whoever defines _foo-challenge also defining the format of > _foo-constraint. > As part of validating _foo-challenge.bar.quux.example.com, validators > should look for > _foo-constraint.example.com and _foo-constraint.quux.example.com and _ > foo-constraint.bar.quux.example.com > and implementing their constraints when present. > > 9) Registry of labels? > > I hate to ask it, but is there a need for a registry of _foo-challenge > labels? > It seems like there could be potential security and operational risks > of multiple entities starting to use "_foo-challenge" for unrelated > purposes. > > 10) Security review > > Given that domain verification is often used as part of security systems, > it seems like it would be worth getting some additional security review, > such as bringing this to SAAG? > > Thanks again for working on this much needed draft! > > Erik > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] Feedback on draft-ietf-dnsop-domain-verif… Erik Nygren
- Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-v… Shumon Huque
- Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-v… Tim Wicinski
- Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-v… Tim Wicinski
- Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-v… Shumon Huque