Re: [Acme] WGLC for ACME DTN Node ID

Hi Brian,

On Fri, Apr 16, 2021 at 09:28:14PM +0000, Brian Sipos wrote:
> Ryan,
> Thank you for the review comments. My responses are inline with prefix "[BS1]".
> 
> > With admittedly very little context for this specific use case, a few
> > things stand out:
> 
> > Section 2 states "Any identifier of type "uri" in a newOrder request MUST
> > NOT have a wildcard ("*") character in its value." This seems to
> > unnecessarily constrain the character space. While I suspect the purpose
> > was to exclude wildcards from the authority-part of a generic URI/specific
> > to a particular scheme, it ends up defining the semantics for all URIs.
> > Given URI's well-known ambiguity in representation across implementations,
> > and the ability to do things like include pct-encoded characters in
> > reg-name (it's only a must requirement, not a MUST requirement), this both
> > seems unnecessarily restrictive and fails to achieve the goal, especially
> > since such decoding to prevent this scenario, at the ACME server, is SHALL
> > NOT'd by the same section.
> 
> > If the goal is to prevent wildcards that imply certain semantics for a
> > given scheme (e.g. "dtn:"), then that probably deserves a separate section
> > detailing the requirements for the extraction and validation of the Node ID
> > from the URI, and can define any restrictions on the character namespace.
> 
> > Alternatively, since identifier labels are cheap, making the identifier
> > type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
> > to impose requirements specific to DTN URIs without risk of overfitting for
> > other types of URIs.
> 
> [BS1] This was a copy-paste statement from ietf-acme-email-smime, and I agree
> that this imposes unnecessary restrictions on the "uri" type. I will add
> clarification that the URI must conform to any scheme-specific syntax.
> It is actually the case that both "dtn" and "ipn" URI specifications [1]
> restrict a Node ID to have a specific set of allowed characters (similar to
> restrictions on DNS names). So a Node ID is a more restricted form of a generic
> "dtn" or "ipn" URI, and I will add clarifying statements outside of the "uri"
> type definition.
> 
> > Section 3 describes how this cribs from ietf-acme-email-smime, but provides
> > no clear explanation as to the _why_, only the _how_. For example, the
> > statement "requires that the ACME client have access to the results of each
> > channel to get both parts of the token" describes a result, but does not
> > describe the motivation that necessitates such a design. This seems like it
> > might be relevant for security considerations, but documenting the
> > rationale for this design seems relevant to successfully and securely
> > implementing/extending this spec. This becomes equally relevant when
> > attempting to understand why the choice of 128-bits of entropy within
> > Section 3.1, since it seems the choice in the size of the parts is equally
> > related to this undocumented threat.
> 
> [BS1] Yes, there is a missing "Threat: Bundle Replay" which applies to both
> Challenge and Response bundles in similar ways. The "token-part2" is the unique
> value for the whole ACME challenge and the "token-part1" is the unique value for
> each bundle exchange. Having -part1 proves recepton of the Challenge Bundle (but
> on-path attackers will also see this) and having -part2 proves access as the
> ACME client (which will be hidden from OPAs).
> Thinking through the logic a bit, I don't know if there is much value in -part2
> since:
>  1. It's not part of the challenge bundle itself, so can't be used for on-path-
> attack filtering.
>  2. It's used for the Key Authorization value alongside the client key
> thumbprint, so there already is data binding the response to that ACME client.
>  3. The 
> Maybe Alexey (CC'd on this message) has some insight about the token splitting
> for a messaging challenge (i.e. not a HTTP/TLS/DNS request-response exchange).

My recollection from the email+S/MIME document (which is to be published as
an RFC imminently) is that the token-part2 was playing the role of a way to
bind the authorization to the specific ACME order.  I also wanted to have a
unique identifier that binds the challenge email to the ACME order, and
that aspect changed a fair amount during the review process, but IIRC we
ended up with a bit of a fudge where the ACME exchange includes the "From:"
header field for the challenge email, and that could be unique to the order
but isn't required to be.

> > In Section 3.1, I'm probably just not familiar enough with the underlying
> > specs, but as far as I could tell, it's not clear why Step 3 the ACME
> > client needs to indicate the <token-part2> to the BP agent, versus just the
> > source. The source Node ID is clear, at least, but it seems like, at best,
> > <token-part2> might just be serving as a "request ID" of sorts (judging by
> > 3.4)
> 
> > The reason I highlight this is because I think it diverges from some of the
> > classic assumptions about ACME and challenge design, because it seems to
> > suggest that <token-part2> may transit the network in the clear and/or be
> > held by multiple parties, which is a very different model than the history
> > of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
> > Token (which not simply a random value, but uniquely bound to the original
> > request and is single-use). I *think* this might just be a terminology
> > issue here, but would it make sense to name these according to their
> > structural purpose, rather than just "token-part1" / "token-part2"?
> 
> [BS1] I agree that more purposeful names could help; the current ones were chose
> only to follow in the steps of ietf-acme-email-smime draft.
> The purpose of "token-part2" is in fact to be unique for the ACME challenge,
> while the ACME server Node ID would be long-lived and shared across many
> challenges. The -smime draft actually doesn't say (either way) about whether
> multiple emails sent to validate a single challenge should all contain the same
> "token-part1". It seems to be implied that one challenge would produce exactly
> one challenge email.
> 
> > In Section 3.3, it's stated "The ACME server SHOULD NOT perform URI
> > normalization on the Node ID given by the ACME client.". It seems like this
> > deserves its own section within Security Considerations, because as with
> > the above remarks, when, where, and how URI normalization is performed
> > seems like it has significant security impact. Even if this protocol uses
> > unnormalized URIs throughout the entire protocol, if implemented on top of
> > anything that performs normalization, or the certificates that are issued
> > are used by clients that perform normalization, you can end up with
> > ambiguities / confused deputies. Normally in a security protocol you would
> > want to validate and normalize your 'hostile' inputs as early as possible
> > in this flow, and that's one of the key roles of the ACME Server / CA, so
> > that it uses identifiers that are post-normalized/unambiguous. This seems
> > like a major oversight, but it could be that I'm misunderstanding something
> > specific to DTN.
> 
> [BS1] I don't believe that you are misunderstanding, and this is a good point to
> clarify. 
> 
> > Section 3.3 states "BP agents SHALL refuse to respond to a Challenge Bundle
> > which is signed by a known ACME server but has an invalid signature.". It
> > seems like this also deserves a note within the Security Considerations,
> > both in terms of how BP agents/ACME clients should determine whether an
> > ACME server is "known" and how they can successfully determine an invalid
> > signature (i.e. how to maintain the expected signing keys). This might
> > merely be a spec reference to DTN, but this normative language appears to
> > be trying to mitigate an undocumented security threat.
> 
> [BS1] I am adding clarifying text under "Threat: BP Node Impersonation" as it
> applies on both sides of the BP messaging.
> There is a way to use BPSec BIB signature/MAC to behave in a very similar way to
> email DKIM, in that you trust a signing entity to vouch for some message-
> generating end entity. Unfortunately BP doesn't (currently) have the same kind
> of in-band control over naming that something like DNS provides (to support
> DKIM), so this configuration is all out-of-band and implementation-specific.
> 
> For ACME server authentication, the ACME client BP agent would need to be
> configured to trust either a raw key or an end-entity PKIX cert signed by some
> client-trusted CA.
> 
> > I agree with Russ' comments on Section 4 where the EKU MUST be included in
> > the issued certificate. Related, the profile from that Section 4.4.2 seems
> > problematic for implementation (around keyUsage), but alas, that's a whole
> > other issue for a whole other spec :)
> 
> [BS1] I agree also and am adding lanugage about this.

I think this is good.

That said, I have a (very vague, for which I apologize) recollection that
earlier in the evolution of the TCPCLv4 document there was an option where
certain TLS certificates would have an indication that the CA asserts that
the holder of the private key is trusted to provide its Node ID in the
TCPCL SESS_INIT even if the Node ID itself is not included in the
certificate.  If that indication from the CA was the id-kp-bundleSecurity
EKU, then requiring ACME to always include that EKU in the issued
certificate would have surprising semantics.  That said, it looks like in
at least the latest version of the TCPCLv4 draft, id-kp-bundleSecurity does
not play that role, so there is no issue.  I'm only mentioning it now
because the potential scope of consequences is so large, and I am sure that
you will do the right thing (assuming I have been able to describe the
situation I'm worried about clearly enough).

Thanks,

Ben

> > Section 6.1 feels unnecessarily light for explaining why it's not a
> > concern. It feels like a bit of a handwave, rather than a statement of how
> > the conclusions are reached. If I'm correctly understanding, the reason
> > you're saying both the challenge and response are fine to be publicly known
> > is that they can only be used in conjunction with the ACME account
> > performing the challenge, which relies on a private key which is not
> > communicated. Is that right? It doesn't seem like that provides much
> > assurance, for the reasons detailed in Section 6.2
> 
> [BS1] Yes, the reason why 6.1 is not an issue (for ACME) is that all on-the-wire
> ACME data is either random token or cryptographic hash data, and it's all per-
> challenge so there should be no risk of replay-ability.
> 
> Regarding proof-of-naming-authority (which is part of what this validation
> relies on), I am strengthening the requirement that Challenge and Response
> bundles must be signed by a trusted security source but still the configuration
> of which security source is trusted for which Node IDs is left to the
> implementation. DTN does not yet have the same kind of robust naming authority
> and hierarchical structure that DKIM/DNSSEC/DNS provides; the security
> configuration would be something like "I trust the source dtn://their-
> enclave.authority/ to sign for Node IDs matching pattern dtn://their-
> enclave\.(.+)/" so that validating ownership of individual Node IDs relies on
> that delegation of trust similar to how ACME validation of "dns" claims relies
> on trusting DNS.
> 

> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme