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

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-acme-star-09: 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-star/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the work that everyone put into this document! I have
one item that needs discussion, and then a small number of very
minor editorial nits. I plan to ballot YES once the issue I identify
below has been addressed.

7.3:

>  In order to avoid correlation of certificates by account, if
>  unauthenticated GET is negotiated (Section 3.4) the recommendation in
>  Section 10.5 of [RFC8555] regarding the choice of URL structure
>  applies, i.e. servers SHOULD choose URLs of certificate resources in
>  a non-guessable way, for example using capability URLs
>  [W3C.WD-capability-urls-20140218].

Thanks for reinforcing the privacy point from 8555 here; however, I think
the situation here is substantially more sensitive. With base 8555 behavior, the
existence of a URL (as can be deduced by distinguishing between 401 and 404
responses) poses a privacy risk, if parties can deduce a pattern to the URL
paths, allowing correlation of users' domains.

With unauthenticated GET, the ability to guess the associated URL would
be incredibly dire, allowing arbitrary unauthorized parties to download
the cert in question. While this may be somewhat obvious to the authors
and working groups, it's the kind of thing that really needs to be
spelled out in the security section, to avoid any oversight on the part
of implementors.

For a similar reason, I'm pretty sure that "SHOULD" is not the right
level of requirement for unguessability. An ACME STAR service with
guessable URLs may as well not perform validation at all, since it's
effectively handing out everyone's cert to everyone on the Internet.

Unguessability for unauthenticated GET needs to be a MUST, and the
document should explain why this is a hard requirement.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

§3.3:

>  The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After"
>  HTTP headers in the response.

Nit: "...HTTP header fields..."

>  Following are further clarifications regarding usage of these
>  headers, as per [RFC7231] Sec. 8.3.1.  All apply to both headers.

Nit: "...header fields..."

>
>  o  This header is a single value, not a list.

Nit: "...header field..."

>  o  The header is used only in responses to GET, HEAD and POST-as-GET

Nit: "...header field..."

>     requests, and only for MIME types that denote public key
>     certificates.
>  o  Header semantics are independent of context.

Nit: "Header field..."

>  o  The header is not hop-by-hop.

Nit: "...header field..."

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value

Nit: "...header field..."

>     within the credential.
>  o  The header is not appropriate for a Vary field.

Nit: "...header field..."

>  o  The header is allowed within message trailers.

Nit: "...header field..."

>  o  The header is not appropriate within redirects.

Nit: "...header field..."

>  o  The header does not introduce additional security considerations.

Nit: "...header field..."

>     It discloses in a simpler form information that is already
>     available inside the credential.

---------------------------------------------------------------------------

§3.3:

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value
>     within the credential.

This probably isn't what you want to say. Read literally, this imposes
a requirements on intermediaries who are neither removing nor adding
these header fields to validate that they match the value in the certs.
That's clearly an unrealistic expectation. I suspect the intention here
is that any entity who inserts a value must ensure that the newly inserted
value matches the corresponding value in the certificate.