Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk <[e-mail]> wrote:

> On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > I've started a PR for your DISCUSS comments here:
> >
> > https://github.com/ietf-wg-acme/acme/pull/447
> >
> > Right now, there are the following major edits there:
> >
> > - Added some text to the Security Considerations that clarifies that the
> > only protection we provide against an ACME MitM is that we prevent it
> from
> > getting improper authorization.  We don't prevent it from doing downgrade
> > attacks or DoS.
> >
> > - Added an explicit statement that there are no restrictions on the use
> of
> > 0-RTT
> >
> > - Clarified what contents are expected in the "challenges" array
> >
> > Some more comments inline below.  Comments addressed by PR / overcome by
> > events trimmed.
> >
> >
> > On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > > > Section 7.1.1 discusses how the server can include a caaIdentities
> > > element
> > > > > in its directory metadata; does this (or anything else) need to be
> > > > > integrity protected by anything stronger than the Web PKI cert
> > > > > authenticating the HTTPS connection?  It seems that a bogus
> > > caaIdentities
> > > > > value could lead to an unfortunate DoS in some cases.
> > > > >
> > > >
> > > > I don't know what you would consider stronger than a WebPKI cert.
> You
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction.  But that would require clients to
> configure
> > > a
> > > > public key as well as a URL, and you would have to figure out
> whether you
> > > > wanted caching or anti-replay and build the corresponding addenda to
> JWS.
> > > > All in all, a lot of complexity for marginal benefit, especially this
> > > late
> > > > in the game.
> > >
> > > Yeah, it's clearly a lot of complexity for marginal benefit (since the
> DoS
> > > would likely be easy to notice and recover from) and late in the game.
> > > Though the CA does already have a key that the client trusts...
> > >
> >
> > I guess it's true that the CA could present a key certified by its
> trusted
> > root, say in the directory object.  But that just turns the complexity
> knob
> > even higher :)
>
> Yup.  And having the trusted root directly sign a statement of CAA
> identifiers is probably right out for many reasons, including X.509
> constraints and it being a bad idea operationally to pull out your offline
> key to do something this mundane.
>
> >
> >
> > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > some control over the trust anchors that are used, in the security
> > > considerations?  (This is a serious question; I am leaning towards it
> being
> > > worth doing, but it would not be very hard to convince me otherwise.)
> > >
> >
> > I'm not sure what you mean by "caaIdentities element gives a leaf cert
> some
> > control over the trust anchors that are used".  Who is controlling whose
> > use of trust anchors, and how?
>
> The scenario I had in mind, which may be completely bogus, was that you
> have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> in principle be signed by a different CA hierarchy than the ACME server is
> doing issuance for.  So you have a TLS cert from CA XYZ that is the
> authentication on a statement "use CAA value <foo> for CA ABC".  If the
> ACME
> client and its friends then go off and installs <foo> as their CAA record
> with a large TTL, when the client goes to ask for a cert, ABC goes and
> checks the CAA record and says "nothing doing".  If ABC caches for the full
> TTL, the client might have to find a different CA (perhaps one that does
> not use an actively harmful CDN to front its operations, heh).  This seems
> to only differ from the case of a CDN just dropping traffic on the floor or
> the other DoS vectors available to it, by virtue of the long TTL on the CAA
> record -- even after ABC decides that this CDN is evil and switches, that
> bogus CAA record is still valid.  Maybe it's better to say that the CDN's
> EE cert is controlling which trust anchor is *not* used [for issuing
> certificates for the client's domain] than to say it controls which trust
> anchor is used.
>

I agree that the TTL is the only issue here, and I don't think even that's
an issue.  RFC 6844 already requires CAs to be self-reliant and do their
own recursing ("Data cached by third parties MUST NOT be relied on"), so
they won't be stuck behind someone else's cache.  And it seems like CAs
have an incentive to get fresh data, since if they don't issue because of a
bad cached CAA record, they're losing business.

So I don't think there's anything to resolve here.

--Richard



>
> -Benjamin
>
>
> >
> >
> >
> >
> > On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote:
> > > > Hi Ben,
> > > >
> > > > Thanks for the detailed review.  Responses to the DISCUSS comments
> > > inline.
> > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > > >
> > > > --Richard
> > > >
> > > > On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk <[e-mail]>
> wrote:
> > > >
> > > > >
> > > > > It looks like the server returns an unauthenticated
> > > "badSignatureAlgorithm"
> > > > > error when the client sends a JWS using an unsupported signature
> > > algorithm
> > > > > (Section 6.2).  What prevents an active attacker from performing a
> > > > > downgrade attack on the signature algorithm used?
> > > > >
> > > >
> > > > HTTPS, and the minimum requirements established in this document.
> We can
> > > > add some comments to the Security Considerations if you want.
> > >
> > > It's probably worth some security considerations text.
> > > (BTW, I was more picky than usual for this doc, since apparently TLS
> MitM
> > > capabilities are explicitly in the threat model via the
> > > "CDN-in-front-of-ACME-server" case.  So in some sense that is implying
> that
> > > the web PKI is not quite good enough for that channel.)
> > >
> > > >
> > > >
> > > > > Similarly, since we include in the threat model a potentially
> hostile
> > > > > CDN/MitM between the ACME client and ACME server, can that attacker
> > > strip a
> > > > > success response and replace it with a badNonce error, causing the
> > > client
> > > > > to retry (and thus duplicate the request processing on the server)?
> > > > >
> > > >
> > > > In the spectrum of DoS attacks the CDN could wage against the server,
> > > this
> > > > seems pretty lame.  The CDN could also just stop forwarding requests.
> > > >
> > > > In other words, I don't really think the
> > >
> > > (incomplete sentence)
> > > But yes, I was thinking about this some more after I balloted and it
> did
> > > end up seeming likely innocuous by comparison.  It's still good to have
> > > people more familiar with the document than me think about the
> > > possibilities, though -- it seems like most things the client would be
> > > trying to do are relatively idempotent (that is, new challenge tokens
> and
> > > such could be generated, but that's easy to recover from unless the
> CDN is
> > > blocking lots of stuff, in which case nothing works anyway), but maybe
> I
> > > missed something.
> > >
> > > >
> > > > > I am not an ART AD, but there is not yet an internationalization
> > > > > directorate, and seeing statements like "inputs for digest
> computations
> > > > > MUST be encoded using the UTF-8 character set" (Section 5) without
> > > > > additional discussion of normalization and/or what the canonical
> form
> > > for
> > > > > the digest input is makes me nervous.  Has sufficient
> > > internationalization
> > > > > review been performed to ensure that there are no latent issues in
> this
> > > > > space?
> > > > >
> > > >
> > > > Two of the three ART ADs have already signed off, so we have that
> going
> > > for
> > > > us :)
> > > >
> > > > The only place we have human-readable text is in the problem
> documents,
> > > so
> > > > at that level, the i18n considerations are handled by that spec.
> Other
> > > > than that, everything is ASCII, so saying "UTF-8" is just a fancy
> way of
> > > > saying, "don't send extra zero bytes".
> > >
> > > [this thread forked]
> > >
> > > >
> > > >
> > > > > Section 6.1 has text discussing TLS 1.3's 0-RTT mode.  If this
> text is
> > > > > intended to be a profile that defines/allows the use of TLS 1.3
> 0-RTT
> > > data
> > > > > for the ACME protocol, I think you need to be more specific and say
> > > > > something like "MAY allow clients to send early data (0-RTT); there
> > > are no
> > > > > ACME-specific restrictions on which types of requests are
> permitted in
> > > > > 0-RTT", since the runtime configuration is just 0-RTT yes/no, and
> the
> > > > > protocol spec is in charge of saying which PDUs are allowed or not.
> > > > >
> > > >
> > > > The risk for HTTPS with 0-RTT is replay of requests.  The text
> already
> > > > notes that that is not an issue for ACME requests because they have
> their
> > > > own anti-replay protection.  There are no restrictions on which PDUs
> are
> > > > allowed.   What further specificity do you need?
> > >
> > > I would like it to be explicitly stated that there are no restrictions
> on
> > > which PDUs are allowed.
> > >
> > > If it helps, I'm trying to make a distinction between "you can
> negotiate
> > > 0-RTT in the TLS handshake" and "this is what you can put in early
> data";
> > > in my mind, an application profile should explicitly cover the latter.
> > >
> > > >
> > > >
> > > > > Section 6.2 notes that servers MUST NOT respond to GET requests for
> > > > > sensitvie resources.  Why are account resources the only sensitive
> > > ones?
> > > > > Are authorizations not sensitive?  Or are those considered to fall
> > > under
> > > > > the umbrella of "account resources" (Section 7.1 seems pretty clear
> > > that
> > > > > they do not)?
> > > > >
> > > >
> > > > That sentence has an overly prescriptive tone.  Obviously it's up to
> the
> > > > CA's policy what it considers sensitive.  (Some especially
> profligate CA
> > > > that's not subject to GDPR might be OK publishing its account
> objects.)
> > > > Happy to dial it back to something like "For example, most CAs will
> > > likely
> > > > consider account resources to be sensitive."
> > >
> > > I think this is basically going to be subsumed/rendered OBE by Adam's
> > > DISCUSS; please let me know if you think there is more to talk about
> here.
> > >
> > > >
> > > >
> > > > > Section 7.1.1 discusses how the server can include a caaIdentities
> > > element
> > > > > in its directory metadata; does this (or anything else) need to be
> > > > > integrity protected by anything stronger than the Web PKI cert
> > > > > authenticating the HTTPS connection?  It seems that a bogus
> > > caaIdentities
> > > > > value could lead to an unfortunate DoS in some cases.
> > > > >
> > > >
> > > > I don't know what you would consider stronger than a WebPKI cert.
> You
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction.  But that would require clients to
> configure
> > > a
> > > > public key as well as a URL, and you would have to figure out
> whether you
> > > > wanted caching or anti-replay and build the corresponding addenda to
> JWS.
> > > > All in all, a lot of complexity for marginal benefit, especially this
> > > late
> > > > in the game.
> > >
> > > Yeah, it's clearly a lot of complexity for marginal benefit (since the
> DoS
> > > would likely be easy to notice and recover from) and late in the game.
> > > Though the CA does already have a key that the client trusts...
> > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > some control over the trust anchors that are used, in the security
> > > considerations?  (This is a serious question; I am leaning towards it
> being
> > > worth doing, but it would not be very hard to convince me otherwise.)
> > >
> > > >
> > > >
> > > > > I am also a bit uncertain if the document is internally consistent
> > > about
> > > > > whether one challenge verification suffices or there can be cases
> when
> > > > > multiple challenge verifications are required for a successful
> > > > > authorization.  I attmpted to note relevant snippets of the text
> in my
> > > > > comments on Section 7.1.4.
> > > > >
> > > >
> > > > The document is clear that (1) any one challenge is sufficient for a
> > > given
> > > > authorization ("the server should consider any one of the challenges
> > > > sufficient to make the authorization valid") and (2) the server may
> > > provide
> > > > multiple authorizations in the order object if it requires multiple
> > > > different validations.
> > >
> > > I think I'm still confused.  How could we end up with a case where a
> single
> > > authorization object in the "valid" state includes more than one
> challenge?
> > > (Looking at my notes, maybe this is just an editorial matter where a
> stray
> > > 's' slipped into one instance of "challenges", so we want "challenge
> that
> > > was used" vs. "challenges that were used"?)
> > >
> > > Thanks for the discussion!
> > >
> > > -Benjamin
> > >
>