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

[Alexey Melnikov <[e-mail]>]

Hi Barry,

On 29/10/2020 21:33, Barry Leiba wrote:

> 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?
When asked in the WG there was not enough support to make it a Proposed 
Standard, in particular due to CA requirements for S/MIME evolving 
outside of IETF. The rest is above my paygrade, I am afraid. I just want 
this this to be published :-).

> To the other points:
>
>>> 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 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.
> 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.
Ok, I will add SHOULD for US-ASCII. Thank you for the discussion.
>>>          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.
>> Sloppy wording on my part. Would something like "which implies
>> 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.
>
>>> 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.
>> 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.
> 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.

No, I am really not happy with waiting for DMARC process to be finished.

>>> 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?
>> We can't use S/MIME, as the whole point of this document is to get an
>> S/MIME certificate.
> Umm...
>
>     5.  In order to prove authenticity of a challenge message, it MUST be
>         either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.
>
> ...so you are using S/MIME signing.

I might have got myself confused here, because there is assymetry here. 
S/MIME can be used for ACME challenges, but it can't be used for ACME 
responses.

>> 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.
> 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 want identifier alignment for sure. Policy checking not so much.
> 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.

Actually, if DKIM signature is fine, but SPF is broken, this is still a 
reason to suspect that something is not right.

But I think I will let go of SPF and will remove DMARC/SPF. I will cut & 
paste specific text about identifier alignment into my draft.

>>>          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?
>> 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.
> 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
I used a version of your text.
>>>      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?
>> Because some email clients wouldn't set it and I would like to achieve
>> 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?
It would improve usability/debugging and ability to use other protocols 
(like IMAP and Sieve) to automate processing.
> 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"?
>
>>>      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.
>> I would like to, but I don't control when MUAs/web mail would apply CTE
>> 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
I used your new text, thank you.
>>> The example body contains a “.”, which is not a valid base64url character.
>> 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).
I will come back to you on this.
> Again, thanks for the response, and I look forward to continuing the
> discussion.  :-)
>
> Barry