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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-email-smime-10: 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-email-smime/



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

I have one point that I am not sure of the significance of and would
like to discuss further, and one point that I think has a fairly
clear/straightforward resolution.

One of the key properties of ACME is that its authenticator provides
assurance that both a party controlling the identifier to be certified
and the ACME client jointly assent to the certification request of that
identifier.  I'm trying to explore a bit more the "jointly assent" part,
and whether it is clear that all steps of the challenge/validation flow
are ultimatetly tied to the same order request.
In the validation flows for the challenge types from 8555, the full
token is returned to the ACME client, which then provides the token to
the entity that controls the identifier being certified, in order to set
up state to expect a verification attempt using that token.  In this
email validation flow, though, the token-part1 is *only* present in the
challenge email, so there is no thread of continuity that allows the
email account holder to tie the validation attempt to the specific
request (i.e., token).  Any message that comes in claiming to be an ACME
challenge would end up being treated as a validation attempt for the
pending request, so the ACME server (or a party pretending to be one)
does not have to provide any proof of knowledge of the pending
validation before the response email is generated.  Some key properties
here seem to include: there is a portion (token-part2) to the response
email that can only be provided by the ACME client, there is a part
(token-part1) to the response email that can only be provided by an
entity that can receive email at the email address being validated, and
that the validation attempt, response email, and ACME order request can
be tied together by unique identifiers.  It seems that we could achieve
all three of these by having the HTTPS response to the ACME client
include a token-part0 as well as the token-part2, with token-part0 being
used as the subject line of the challenge email and token-part1 being
conveyed in some fashion (whether body or headers) of the challenge
email.  Does such a scheme provide any useful properties that are not
provided by the current scheme?

The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request.  I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1.  In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.


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

The discuss point notwithstanding, if we assume that the current
validation process does provide the necessary linkage across steps, it
seems that the procedure would provide only similar properties to the
RFC 8555 validation flows -- I am having a hard time convincing myself
that we definitely have the 128-bit security level for all the
information paths at play.  It seems like having both token-part1 and
token-part2 each be 128+ bits would be fairly low-cost and would give
greater peace of mind that we are not opening up any 64-bit attacks.

Using "ACME:" as the Subject: marker for both challenge mail and
response mail potentially sets us up for various reflection/janus-like
attacks.  We could give some warnings about this in the security
considerations, or just indicate in-band whether it is a challenge or a
response...

Section 3

       contains at least 64 bits of entropy.  (ACME server MUST generate
       token afresh for each S/MIME issuance request.)  The challenge

nit: missing article ("the"), twice ("The ACME server", "the token").

   2.  The To header field MUST be the email address of the entity that
       requested the S/MIME certificate to be generated.

Is this required to be the same email address that is in the CSR?
How does it relate to the identity of the ACME client involved in the
process (to the extent that an ACME client has an identity).

Section 3.1

   5.  In order to prove authenticity of a challenge message, it MUST be
       either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.  If DKIM

S/MIME brings in X.509 and a PKI.  Is there anything useful to say about
the nature of that PKI (e.g., chaining to the same CA that would issue
the ACME cert, etc.)?  In general, on some intuitive sense, it seems
like we might want to say more about who is doing the signing (of
whichever form) and have that relate to the CA and/or ACME server in
some specific fashion, so the absence of such discussion in the document
suggests that there are some previous discussions of this topic in the
acme list archives; a pointer thereto would be welcome.

   5.  In order to prove authenticity of a challenge message, it MUST be
       either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.  If DKIM
       signing is used, the resulting DKIM-Signature header field MUST
       contain the "h=" tag that includes at least "From", "Sender",
       "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-To",
       "References", "Message-ID", "Content-Type", and "Content-
       Transfer-Encoding" header fields.  [...]

Cross-referencing this against
https://tools.ietf.org/html/rfc6376#section-5.4.1, do we want to say
anything about Resent-* and/or List-*?

                                          The message MUST also pass
       DMARC validation [RFC7489], which implies DKIM and SPF validation
       [RFC7208].

I don't see a need to duplicate the content, but am very interested in
the outcome of Barry's thread about DMARC/etc.

We should probably also say somewhere that challenge emails that fail
validation are ignored with no response generated.

     Auto-Submitted: auto-generated; type=acme
     Date: Sat, 1 Sep 2018 10:08:55 +0100
     Message-ID: <[e-mail]>

We might consider moderninzing the date to something closer to the time
of final publication.

     Subject: ACME: <base64url-encoded-token-with-64-bits-of-entropy>

I feel like it might be more illustrative to just include some random
base64.  E.g., LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= should be
sufficiently random (and, fortuitously, this invocation of base64(1) did
not emit any non-URL-safe characters!).

     this request automatically, or you might have to paste the first
     token part into an external program.

(side note) "subject line" might be more accessible for an ordinary user
of such a service than "first token part".

Section 3.2

   2.  The From: header field contains the email address of the user
       that is requesting S/MIME certificate issuance.

Again, is this required to match the rfc822Name SAN in the CSR?

   9.  In order to prove authenticity of a response message, it MUST be
       DKIM [RFC6376] signed.  The resulting DKIM-Signature header field
       MUST contain the "h=" tag that includes at least "From",
       "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-
       To", "References", "Message-ID", "Content-Type", and "Content-
       Transfer-Encoding" header fields.  The message MUST also pass
       DMARC validation [RFC7489], which implies DKIM and SPF validation
       [RFC7208].

[same comments as for the challenge message]

      Date: Sat, 1 Sep 2018 11:12:00 +0100
      Message-ID: <[e-mail]>
      From: [e-mail]
      To: [e-mail]
      Subject: Re: ACME: <base64url-encoded-token-with-enough-entropy>

We should probably have an In-Reply-To to tie us to the challenge
example, and the same date and token1 updates as for the challenge
example.

      -----BEGIN ACME RESPONSE-----
      LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
      jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9
      fm21mqTI
      -----END ACME RESPONSE-----

I see that Barry already noted the non-base64url '.' character, and
also fail to understand the explanation about JWS.  (It okay to hit me
over the head with it, too.)
The content here also does not seem to be JWS itself, since the base64
of both components decodes to non-ASCII stuff, and JWS would have a JSON
header (and two '.'s).

Section 4

   [RFC8616] updated/clarified use of DKIM/SPF/DMARC with
   Internationalized Email addresses [RFC6531].  Please consult RFC 8616
   in regards to any changes that need to be implemented.

Changes with respect to what baseline?

Section 6

Related to my discuss point, it may be worth saying something about how
clients should not provide any special treatment to messages with
"ACME:" in the subject if they are not aware of any pending ACME
email validations.

   3.  protocol specified in this document is not suitable for use with

nit: "the protocol"

   Use of DNSSEC by email system administrators is recommended to avoid
   making it easy to spoof DNS records affecting email system.  However
   use of DNSSEC is not ubiquitous at the time of publishing of this
   document, so it is not required here.  [...]

That's a fairly weak justification; we should prioritize doing the right
thing if it is in conflict with what is currently deployed.  I'd almost
prefer to just drop this justification and leave the subsequent
comparison to other existing ("trustworthy enough") systems to stand on
its own merits.

   [...]                                                  So the risk of
   not requiring DNSSEC is presumed acceptable in this document.

I suggest adding "at the time of this writing" (or similar).

Section 7

RFC 6234 would work just as well as FIPS180-4 for a SHA256 reference,
right?

RFCs 4021 and 8058 are cited as things that you MUST NOT use, which does
not normally require them to be normative references.

RFC 8550 is cited only in the introductory remarks and may not need to
be normative.