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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 28 Oct 2020 09:55:46 -0700

Barry Leiba 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:
----------------------------------------------------------------------

— Section 3.1 —

       [RFC2231] encoding of the message Subject header field
       MUST be supported, but when used, only "UTF-8" and "US-ASCII"
       charsets MUST be used (i.e. other charsets MUST NOT be used).

NOT DISCUSS: I don’t like the second use of MUST: it’s confusing (for example,
it’s not the case that you always MUST use both charsets).  I suggest this:

NEW
   [RFC2231] encoding of the message Subject header field
   MUST be supported, and when used, only the "UTF-8" and "US-ASCII"
   charsets are allowed: other charsets MUST NOT be used.
END

DISCUSS: That said, I don’t understand the need to specifically allow UTF-8
here.  If the subject only contains “ACME:”, FWS, and a base64 string, it will
always be ASCII.  Why are we talking about UTF-8 at all?

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

Two things here, which apply to bullet 9 in Section 3.2 also:

1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to
do Identifier Alignment.

2. I have an issue with requiring the use of DMARC at this point, as it’s
specified only in an Informational document in the Independent stream.  In any
case, what’s the point of requiring DMARC?  It seems to me that the
authentication you need is provided by DKIM or S/MIME; what do you need from
DMARC?

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

— Section 2 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— Section 3 —

   This document defines a new Identifier Type "email" which corresponds
   to an (all ASCII) email address [RFC5321] or Internationalized Email
   addresses [RFC6531].  (When Internationalized Email addresses are
   used, both U-labels and A-labels [RFC5890] are allowed in the domain
   part.)

Why “an email address” (singular) when it’s ASCII and “email addresses”
(plural) when they’re internationalized?  I think you mean for this to be a
single address in either case.  Also, why capitalize “internationalized”, and
why capitalize “email” only when it’s internationalized?  I’m also not fond of
putting important things and normative requirements in parentheses.

I suggest this (and similar comments apply to Section 5.1):

NEW
   This document defines a new Identifier Type "email" that identifies
   an email address.  The address can be all ASCII [RFC5321] or
   internationalized [RFC6531]; when an internationalized email
   address is used, the domain part can contain both U-labels and
   A-labels [RFC5890].
END

   2.  The ACME server (run by the Certificate Authority or their
       authorized third party) generates a "challenge" email message
       with the subject "ACME: <token-part1>", where <token-part1> is
       the base64url encoded [RFC4648] first part of the token, which
       contains at least 64 bits of entropy.  (ACME server MUST generate
       token afresh for each S/MIME issuance request.)

When I get to “the token,” my first thought is “What token?”  And in the
description that follows it isn’t clear whether the 64 bits of entropy applies
to token-part1, or to the token itself.  I suggest this:

NEW
   2.  The ACME server (run by the Certificate Authority or their
       authorized third party) generates a token and a "challenge"
       email message with the subject "ACME: <token-part1>", where
       <token-part1> is the base64url encoded [RFC4648] first part of
       the token.  The ACME server MUST generate a fresh token for each
       S/MIME issuance request, and token-part1 MUST contain at least
       64 bits of entropy.
END

— Section 3.1 —

   3.  The message MAY contain a Reply-To header field.

It seems odd to expliticly call this out without explanation.  It makes me
wonder whether I should do that or not.  Is there a reason I’d want to?  Is
there a reason I wouldn’t?

       The "Auto-Submitted" header field SHOULD
       include the "type=acme" parameter.

Why not MUST?  What are the consequences of not doing this, and why might it be
hard to?

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

These should properly be “DKIM-signed” and “S/MIME-signed”, but the citations
make that awkward.  I suggest instead, “MUST be signed using either DKIM
[RFC6376] or S/MIME [RFC8551].”

       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.

Do you not also want to include “Auto-Submitted”, given that its inclusion in
the message is a MUST?

   An example ACME "challenge" email (note that DKIM related header
   fields are not included for simplicity).

Make it “(note that for simplicity, DKIM-related header fields are not
included).”

— Section 3.2 —

Bullet 1 seems a bit confusingly worded, and is anyway overspecified because
it’s just formed as a reply to the incoming message.  I suggest simply
referring to Section 3.1 bullet 1 for the format, something like this:

NEW
   1.  The message Subject header field is formed as a reply to the
       ACME challenge email (see Section 3.1).  Its syntax is the same
       as that of the challenge message except that it may be prefixed
       by a US-ASCII reply prefix (typically “Re:”) and folding white
       space (FWS, see [RFC5322]), as is normal in reply messages. When
       parsing the subject, ACME servers must decode [RFC2231] encoding
       (if any) and then they can ignore any prefix before the "ACME:"
       label.
END

   4.  The Cc: header field is ignored if present in the "response"
       email message.

Why is it necessary to say this?  And if it is, why is it not necessary to say
it in Section 3.1?

   5.  The In-Reply-To: header field SHOULD be set to the Message-ID
       header field of the challenge message according to rules in
       Section 3.6.4 of [RFC5322].

As with an earlier comment: Why is this SHOULD and not MUST?

In bullet 7:

       See the 3rd bullet point in Section 3 for
       more details.

But there aren’t actually any more details there.  Maybe just append, “as
outlined in the 3rd bullet point in Section 3,” to the previous sentence.

   8.  There is no need to use any Content-Transfer-Encoding other than
       7bit for the text/plain body part, however use of Quoted-
       Printable or base64 is not prohibited in a "response" email
       message.

Is the “is not prohibited” meant to discourage it?  If so, that should be done
more directly.  In any case, we’re better off avoiding the use of two negatives
to make a positive: “is permitted”.

For bullet 9, see my comments about bullet 5 in Section 3.1, with the
additional concern that requiring DMARC on this side limits the end user, who
has no control over whether her domain does or doesn’t publish DMARC policies.

   Example ACME "response" email (note that DKIM related header fields
   are not included for simplicity).

Same comment as in 3.1.

The example body contains a “.”, which is not a valid base64url character.

— Section 6 —

   Any claims about the correctness or
   fitness-for-purpose of the email address must be otherwise assured.
   I.e.  ACME server is only vouching that the requested email address
   seem to belong to the entity that requested the certificate.

The “i.e.” part doesn’t make sense to me: “seem to belong” is understating it,
isn’t it?  The point of this is assurance, not “seem to”.  Maybe this?:

NEW
   The ACME server is confirming that the requested email address
   belongs to the entity that requested the certificate, but this
   makes no claim to correctness or fitness-for-purpose of the
   address.  It such claims are needed they must be obtained by
   some other mechanism.
END

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Oct 2020 13:25:43 +0000

Hi Barry,

Thank you for your comments.

Replying to all but a few of your comments below:

Done.
> always be ASCII.  Why are we talking about UTF-8 at all?
The idea is to be as compatible with existing software (e.g. MUAs and 
web mail clients). I did some tests and some implementations 
unconditionally use UTF-8 charset label even if the data is purely 
ASCII. Thus the text above.
> 1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to
Sloppy wording on my part. Would something like "which implies 
compliance with DKIM [ref] and SPF [ref]" work better?
> specified only in an Informational document in the Independent stream.
This is an Informational document on IETF stream, so the bar is already 
pretty low ;-). Besides you know that that DMARC itself is being revised.
> In any

We can't use S/MIME, as the whole point of this document is to get an 
S/MIME certificate.

I suppose just requiring DKIM is fine, but properly configured SPF will 
get an extra assurance that the domain owner has a properly (securely, 
for some definition of securely) configured email system. So I am open 
to suggestions.

> single address in either case.
Yes, good point.
> Also, why capitalize “internationalized”, and
> why capitalize “email” only when it’s internationalized?
Probably because I cut and pasted this from somewhere ;-).
> I’m also not fond of
Good point. Removed.
>     address is used, the domain part can contain both U-labels and
Changed, thank you.
>         S/MIME issuance request, and token-part1 MUST contain at least
This reads better, thank you.
> there a reason I wouldn’t?
Initially it hasn't occurred to me that this is sensible. Somebody 
suggested that, so I was pointing out that this is Ok.
> Why not MUST?  What are the consequences of not doing this, and why might it be

This is for backward compatibility with existing email/web mail clients. 
I don't really know how hard it would be for existing clients to have an 
extra parameter there.

Its presence would really help in debugging, but nothing should break if 
it is absent.

> [RFC6376] or S/MIME [RFC8551].”
Sounds good, thank you.
> Do you not also want to include “Auto-Submitted”, given that its inclusion in
Good point, well presented. Added.
> Make it “(note that for simplicity, DKIM-related header fields are not
Ok.

  [snip]

> As with an earlier comment: Why is this SHOULD and not MUST?
Because some email clients wouldn't set it and I would like to achieve 
highest compatibility with deployed MUA/web mail base.
> outlined in the 3rd bullet point in Section 3,” to the previous sentence.
Ok.
> more directly.
I would like to, but I don't control when MUAs/web mail would apply CTE 
to the body, thus the above text.
> In any case, we’re better off avoiding the use of two negatives
Changed, thanks.
>     are not included for simplicity).
Done.
> The example body contains a “.”, which is not a valid base64url character.
It is JWS, which contains a dot.
> isn’t it?  The point of this is assurance, not “seem to”.
The account could have been hijacked, so I was trying to avoid making 
overly strong claim. I have struggled with this text and your 
suggestions below is better.
> Maybe this?:

---

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Oct 2020 17:33:30 -0400

Hi, Alexey, and thanks for the response.  You responded to the first
message, rather than to the second, so you didn't pick up my first
DISCUSS point, repeated here:

> I question why this is Informational, and the shepherd writeup doesn't really
> explain it.  I get that this fills a gap, and that the working group wants to
> see this adopted.  I don't get why, therefore, you aren't proposing a standard
> here.  What is the point of making this Informational, and not Proposed
> Standard... or Experimental, if you're less sure of whether it will work as
> expected?

> ASCII. Thus the text above.

OK, I guess that's not a problem.  I might prefer a SHOULD for ASCII,
or some such, and inclusion of an explanation that ASCII is all that's
needed, and that UTF-8 is permitted only for compatibility.  Please
consider that, but this item is no longer at a DISCUSS level: we've
had the discussion.

> compliance with DKIM [ref] and SPF [ref]" work better?

I think that "which implies validation of DKIM or SPF" is accurate and
better.  In any case, definitely "or", not "and".  But that's only if
we keep the DMARC bit, which is a more important discussion.

> pretty low ;-). Besides you know that that DMARC itself is being revised.

That speaks to my first DISCUSS point, at the top of this message, and
is something we need to talk about.  Apart from that, if you want to
wait for the DMARC revision as Proposed Standard, sure.  I'm very much
not happy building standards around what we know to be a problematic,
non-standard protocol that we're working on revising.

> We can't use S/MIME, as the whole point of this document is to get an

Umm...

...so you are using S/MIME signing.

> for some definition of securely) configured email system. So I am open

You haven't answered what you're trying to get from DMARC.  You can
say that the message has to be signed.  Doesn't that accomplish what
you need?  It seems to me that what DMARC provides beyond that is
Identifier Alignment and sender policy checking, which don't seem to
provide anything you need for this protocol.  I'd like to understand
why the protocol needs them, or what else it is that it needs from
DMARC.  I don't see why you get any benefit from SPF either -- in
conjunction with DKIM, SPF is only useful in cases where the DKIM
signature is broken -- so let's include that in the discussion as
well.

> Its presence would really help in debugging, but nothing should break if

If the parameter is just to help debugging, then maybe just say that
as an explanation for the SHOULD?:

NEW
      The "Auto-Submitted" header field SHOULD include
      the "type=acme" parameter to aid in debugging.
END

> highest compatibility with deployed MUA/web mail base.

Keeping in mind that this is a non-blocking comment... I'm never happy
when we waffle because we think implementations won't do it.  Either
we want this there for a good reason, or we don't... if we do, it
should be a MUST, and everyone knows that won't be thrown in jail for
not doing it.  If we leave it as SHOULD, I think we should explain
that better.

The bottom line, I guess, is this: why do we want it there?  Does it
improve interoperability, security, usability, or debugging?  If so,
can we explain that so there's useful context?  If it doesn't, then
maybe it should just be "should", rather than "SHOULD"?

> to the body, thus the above text.

If you'd like to discourage it, we can do that without being too
strong.  Maybe something like this?:

NEW
   8.  There is no need to use any Content-Transfer-Encoding other than
        7bit for the text/plain body part.  Use of Quoted-Printable or base64
        in a "response" email message is not necessary and should be avoided,
        though it is permitted.
END

> It is JWS, which contains a dot.

I'm confused, then.  The text says that it's "one or more line
containing the base64url-encoded SHA-256 digest [FIPS180-4] of the key
authorization".

How can that contain a dot?  The key authorization might, but then you
make a digest of it and encode the digest, and that encoded blob can't
contain a dot, right?  What am I missing (just hit me over the head;
it's OK).

Again, thanks for the response, and I look forward to continuing the
discussion.  :-)

Barry