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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
