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

[Richard Barnes <[e-mail]>]

Focusing on DISCUSS comment for now, will pick up COMMENTs later.

On your DISCUSS, I think you're off on a couple of small things, but right
on the underlying point that the document doesn't really provide any
guidance as to which resources a server should consider sensitive.  I agree
that it would be good to say more, and I've started up a PR for this.

https://github.com/ietf-wg-acme/acme/pull/443

I don't agree that sensitivity entails a need for non-guessable URLs.  If
accessing the URL requires authentication, then it doesn't matter if
someone can guess it; unauthorized people can't access it even if they can
guess it.  I guess you could argue that if you made a random URL and only
distributed it in authenticated channels, then you could allow GETs to it,
using the URL itself as an authenticator.  But that seems super brittle; I
would rather just have all the authentication be based on signing.  So at
best, random URLs are a backstop against a CA making the wrong decision
about GETs.

You're also correct to note that some resources might be sensitive that we
now instruct clients to poll with GETs.  For example, the client is
supposed to poll an authorization resource to see when it validates, but if
the authz has a TN in it and so is considered sensitive, you won't be able
to do a GET.  I think the right answer here is to have the server return
405 Method Not Allowed if it gets a GET and have the client fall back to an
authenticated "POST {}", which should be equivalent to a GET in all cases.

--Richard


On Thu, Aug 30, 2018 at 12:50 AM Adam Roach <[e-mail]> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-acme-acme-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for all the work that everyone has put into this protocol. I'm
> excited by
> what it's been able to do for the certificate issuance sector as a whole,
> and
> truly appreciate all of the early implementors who have put both clients
> and
> servers into active production. I'm definitely balloting YES once we get
> clarity
> on my DISCUSS, below.
>
> ---------------------------------------------------------------------------
>
> I've looked at this several different ways, and I must be missing something
> obvious -- which should make this easy to clear.
>
> §6.2:
>
> >  Note that authentication via signed JWS request bodies implies that
> >  GET requests are not authenticated.  Servers MUST NOT respond to GET
> >  requests for resources that might be considered sensitive.  Account
> >  resources are the only sensitive resources defined in this
> >  specification.
>
> This doesn't seem correct.
>
> For example, let's imagine that I, as a user, get the directory for an ACME
> server, the body of which is the example in §7.1.1. Then, I go through the
> new-account process, and receive the Account object in §7.1.2:
>
>    {
>      "status": "valid",
>      "contact": [
>        "mailto:[e-mail]",
>        "mailto:[e-mail]"
>      ],
>      "termsOfServiceAgreed": true,
>      "orders": "https://example.com/acme/acct/1/orders"
>    }
>
> Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed
> that
> different users' orders are apparently at a predictable URL that varies
> only by
> a small integer. Curious, I change the "1" to a "2" and send:
>
>   GET /acme/acct/2/orders HTTP/1.1
>   Host: example.com
>
> And get back not *my* orders, but someone *else's* orders.
>
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>
>    {
>      "orders": [
>        "https://example.com/acme/acct/2/order/1",
>        "https://example.com/acme/acct/2/order/2",
>        "https://example.com/acme/acct/2/order/3",
>        "https://example.com/acme/acct/2/order/4"
>      ]
>    }
>
> Interesting. So now I can do four more unauthenticated GETs and grab those
> order
> objects.
>
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>
>    {
>      "status": "valid",
>      ...
>      "identifiers": [
>        { "type": "dns", "value": "smithforcongress.example" }
>      ],
>      ...
>      "certificate": "https://example.com/acme/cert/1234"
>    }
> ----------
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>
>    {
>      "status": "valid",
>      ...
>      "identifiers": [
>        { "type": "dns", "value":
> "something-embarassing-with-goats.example" }
>      ],
>      ...
>      "certificate": "https://example.com/acme/cert/5678"
>    }
> ----------
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>
>    {
>      "status": "valid",
>      ...
>      "identifiers": [
>        { "type": "email", "value": "[e-mail]"
> }
>      ],
>      ...
>      "certificate": "https://example.com/acme/cert/9abc"
>    }
> ----------
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>
>    {
>      "status": "valid",
>      ...
>      "identifiers": [
>        { "type": "tn", "value": "[phone]" }
>      ],
>      ...
>      "certificate": "https://example.com/acme/cert/defg"
>    }
>
> So now I've learned that the same account has pulled certs for both
> "smithforcongress.example" and "something-embarassing-with-goats.example";
> that
> they have control over the email address
> "[e-mail]," and that their phone number is
> +1 202
> 555 0172. There's a pretty good chance that... someone didn't want all of
> that
> to be generally known.
>
> And... huh... that's interesting.
>
>      GET /acme/cert/9abc HTTP/1.1
>      Host: example.com
>
>      HTTP/1.1 200 OK
>      Content-Type: application/pem-certificate-chain
>      Link: <https://example.com/acme/some-directory>;rel="index"
>
>      -----BEGIN CERTIFICATE-----
>      [X.509 Cert for [e-mail]]
>      -----END CERTIFICATE-----
>      -----BEGIN CERTIFICATE-----
>      [Issuer certificate contents]
>      -----END CERTIFICATE-----
>      -----BEGIN CERTIFICATE-----
>      [Other certificate contents]
>      -----END CERTIFICATE-----
>
> Whoa. That's cool. The next thing I'm doing is configuring Thunderbird to
> forge
> mail from [e-mail] and going on an email
> spree
> admitting to owning a rather embarrassing domain name, in which I ask
> concerned
> constituents to call me on my unlisted phone number to discuss the issue.
>
> Clearly I've missed something, because this just seems way too obvious.
> What
> prevents this attack (or a similar one from observing that the order URLs
> are
> predictable?)
>
> If I *haven't* missed something, then there appears to have been an
> assumption
> here, never written into the document, that the URLs generated for the
> orders
> list and for the order objects are unguessable. If that's the case, I
> would:
>
> (1) Expect this to be stated in section 7.1.2.1 and 7.1.3
>
> (2) Expect a specification of a reasonable number of bits of entropy to
> use in
>     orders list and order object URLs.
>
> (3) Expect the examples to show appropriately random URLs (e.g.
>
> https://example.com/acme/acct/9258fac3-7866-4922-90e6-bbd0c89e751a/orders)
>
>
> (4) Expect a treatment in section 10 of the risks that might arise from
> third
>     parties gaining access to orders, as doing so provides free-and-clear
> access
>     to private certificates (which, for dns, can be trivially used to
>     revoke certs; and for other types, can be used for impersonation as
> well)
>
> Again, I'm still expecting that I've simply missed something obvious -- I
> just
> can't for the life of me figure out what it is.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have a small handful of substantive comments, and several editorial nits.
>
> ---------------------------------------------------------------------------
>
> General:
>
> This protocol specifies the use of RFC 3339 time formats in several
> places. Most
> modern protocols that reference RFC 3339 choose to place further
> restrictions on
> the format; commonly, the time-secfrac portion is required to be omitted,
> and
> the time-offset portion is required to be "Z". In addition to making
> parsing
> easier, these restrictions have the property of any given time having only
> one
> possible string representation.
>
> My suggestion would be for ACME to include similar restrictions.
> Alternately, if
> the full range of optionality allowed by RFC 3339 is actually intended,
> please
> adjust the examples so that at least a few of them include fractional
> seconds
> and non-UTC timezones.
>
> ---------------------------------------------------------------------------
>
> §5:
>
> For avoidance of doubt, this section should probably indicate that values
> that
> will appear in certificates will be used and conveyed in the form present
> in
> certificates, possibly with a reference to RFC 5280 section 7.
>
> ---------------------------------------------------------------------------
>
> §6.4.1:
>
> >  The server MUST generate the value provided in
> >  Replay-Nonce in such a way that they are unique to each message, with
> >  high probability.  For instance, it is acceptable to generate Replay-
> >  Nonces randomly.
>
> It's not clear whether the values need to also be unpredictable; e.g.,
> would it
> be okay if the value of the nonce for operation n+1 could be easily
> derived or
> guessed from the nonce for operation n?
>
> ---------------------------------------------------------------------------
>
> §7.4.2:
>
> >  GET /acme/cert/asdf HTTP/1.1
> >  Host: example.com
> >  Accept: application/pkix-cert
> >
> >  HTTP/1.1 200 OK
> >  Content-Type: application/pem-certificate-chain
>
> This pairing of "Accept: application/pkix-cert" with "Content-Type:
> application/pem-certificate-chain" seems to be at odds with the
> description in
> RFC 7231 §5.3.2. I know that proactive negotiation is optional in HTTP,
> but it
> seems that it would be much better to show this as something like:
>
>    GET /acme/cert/asdf HTTP/1.1
>    Host: example.com
>    Accept: application/pkix-cert, application/pem-certificate-chain;q=0.5
>
> ===========================================================================
>
> All of my remaining comments are editorial in nature, and most of those are
> minor editorial nits.
>
>
> i-d nits reports:
>
>   ** There are 3 instances of too long lines in the document, the longest
> one
>      being 15 characters in excess of 72.
>
> I'm not sure it's reasonable to expect the RFC editor to have enough
> knowledge
> to know how to best split the key authorization across lines (or to elide
> portions of it, whichever makes more sense).
>
> ---------------------------------------------------------------------------
>
> i-d nits also reports:
>
>   -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is
> not
>      defined in RFC 2119.  If it is intended as a requirements expression,
> it
>      should be rewritten using one of the combinations defined in RFC 2119;
>      otherwise it should not be all-uppercase.
>
> ---------------------------------------------------------------------------
>
> §1:
>
> >  Existing Web PKI certificate authorities tend to use a set of ad hoc
> >  protocols for certificate issuance and identity verification.  In the
> >  case of DV certificates, a typical user experience is something like:
>
> I expect this text won't age gracefully. Even at the time of publication of
> this document, over 64% of all certificates issued on the web have been
> issued
> using the ACME protocol, arguably making it the "typical user experience."
> (see
>
> https://censys.io/certificates/report?q=tags%3Atrusted&field=parsed.issuer.organization.raw&max_buckets=50
> )
>
> I suggest caveating this paragraph with text along the lines of "prior to
> the
> advent of the protocol described by this document, the typical user
> experience
> was..."
>
> ---------------------------------------------------------------------------
>
> §1:
>
> >  For example, as of this writing, there is
> >  ongoing work to use ACME for issuance of Web PKI certificates
> >  attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates
> >  attesting to telephone numbers [I-D.ietf-acme-telephone].
>
> Suggestion: consider including [draft-ietf-acme-email-smime] in this list.
>
> ---------------------------------------------------------------------------
>
> §6.2:
>
> >  These intermediaries can also change values in the request that are
> >  not signed in the HTTPS request, e.g., the request URL and headers.
>
> Nit: "...header fields."
>
> ---------------------------------------------------------------------------
>
> §6.4:
>
> >  An error response with the
> >  "badNonce" error type MUST include a Replay-Nonce header with a fresh
> >  nonce.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §6.5:
>
> >  "urn:ietf:params:acme:error:rateLimited".  Additionally, the server
> >  SHOULD send a "Retry-After" header [RFC7231] indicating when the
> >  current request may succeed again.
>
> Nit: "...header field..."
>
> >  In addition to the human-readable "detail" field of the error
> >  response, the server MAY send one or multiple link relations in the
> >  "Link" header  [RFC8288] pointing to documentation about the specific
> >  rate limit that was hit, using the "help" link relation type.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §7.1:
>
> >  The "->" is a mnemonic for a Location
> >  header pointing to a created resource.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §7.1.2.1:
>
> >  The server MAY
> >  return an incomplete list, along with a Link header with a "next"
> >  link relation indicating where further entries can be acquired.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §7.3.4:
>
> >  This response MUST
> >  include a Link header with link relation "terms-of-service" and the
> >  latest terms-of-service URL.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §7.4.2:
>
> >  Because certificate resources are immutable once issuance is
> >  complete, the server MAY enable the caching of the resource by adding
> >  Expires and Cache-Control headers specifying a point in time in the
> >  distant future.  These headers have no relation to the certificate's
> >  period of validity.
>
> Nit: "...header fields..." (twice)
>
> >  The ACME client MAY request other formats by including an Accept
> >  header [RFC7231] in its request.
>
> Nit: "...header field..."
>
> >  provide one or more "Link: rel="up"" headers pointing to an issuer or
>
> Nit: "...header fields..."
>
> ---------------------------------------------------------------------------
>
> §7.5:
>
> >  When a client receives an order from the server it downloads the
> >  authorization resources by sending GET requests to the indicated
> >  URLs.
>
> Nit: "...from the server, it downloads..."
>
>
>