Hello,
The last issue is how to resolve Russ's DISCUSS [1]. The options are:
(1) Drop the text.
Dave mentioned that it is classic to a avoid problematic Discuss
through an easy expedient. In general, that's what done, but not in
this case. The argument from Russ was:
"This text is a warning that there are dragons here, but it does not
tell the reader anything about the real consequences."
Now, if there was working group consensus on new text in a Full
Standard and a reader points out the above, I'll pause and think
carefully. Please note that I am not arguing for you to review your
position about dropping the text. Some day someone will read this
message and find it useful or view it as rubbish.
(2) Provide replacement text.
(i) Dave Crocker provided the following replacement text:
"Message modification can affect the validity of an existing message
signature, such as by DKIM [DKIM], PGP [RFC4880], S/MIME [RFC5751]
and can render the signature invalid. This, in turn, can affect
message handling by later receivers, such as filtering engines that
consider the presence or absence of a valid signature."
(ii) John Klensin suggested the following replacement text:
"Implementers of MSAs and those who submit messages to
them should be aware that MUAs (or other submission
system components) may apply digital signatures or other
types of message integrity checks (MICs) to messages and
that, in the most general case, the MSA may not be able
to detect the fact that MIC arrangements have been used
by inspection of the message. Some of the
transformations permitted by this specification will
invalidate such MICs. Although the risk is less
if MICs protect only internal body parts (i.e., that the
main header fields are not signed) that restriction does
not completely eliminate the risk. Consequently,
operators of message originating systems that apply such
signatures should ensure that the relevant MSAs are
aware that signatures may be present (or external MICs
used) and that they are properly configured to avoid
making changes, remove signatures, or accept that
signatures may become invalid as appropriate."
If anyone else want to suggest replacement text, please do so.
(iii) I'll lower-case the text Ned Freed first commented on:
"If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
S/MIME [RFC5751], or other signature, sites should consider what
effect message modifications will have on the validity of the
signature, and may use the presence or absence of a signature as
a criterion when deciding what, if any, modifications to make.
I'll attempt to summarize the comments that were
posted. Exceptionally, I'll comment on them. As usual, if I
misinterpreted what you said, please correct me.
Dave thinks that Russ' opinion is wrong [2].
Comment: I could not use that to argue against the DISCUSS as it
would not be viewed as a substantive comment.
Ned mentioned that [3]:
"This text seems entirely appropriate to me, although I think the use of
compliance language in it is wrong since (a) considering something isn't
really a concrete, actionable thing and (b) this is newly added text and
we should not be adding compliance language during a move to full standard.
(The MAY is fine as far as I'm concerned, but then again the difference
between upper and lower case MAY mostly escapes me.)"
Comment: He also provided several other arguments. I considered them
as substantive enough and used them to respond to the DISCUSS.
John Levine mentioned that "I suppose we could add some examples, but
as others have noted, there's a lot of different possibilities, and
we don't know what they are." [4]
Comment: It was not substantive enough to be used as an argument.
Alexey Melnikov mentioned [5] that removing the text will be a
disservice to the community.
Comment: I would not use that to convince the AD.
Barry Leiba mentioned "telling Russ that the WG is strongly in favour
of having this in
there"[6]. He also commented that:
"This is a common case, where something needs to progress on the
standards track, but something else has come along in the interim that
(1) does not change the existing protocol that's progressing, but
(2) implementors of the existing protocol now need to be aware of."
And that it is "critical that anyone looking at the new Message
Submission spec be aware of its effect on signatures".
Comment: I would have used those arguments if there was a next round
of discussions. I did not pick it as the (first) arguments I found
seemed convincing enough to clear the DISCUSS. BTW, I was wary of
saying the WG is strongly in favour of keeping the text as the
argument as it would lead to a fight. As the working group is in
shutdown mode, it was not clear to me that the WG had the energy to
put up a fight.
Jeff Macdonald sent a "+1" [7] to support Barry's argument.
Comment: It gave a sense about whether the WG would like to keep some
text in. I would also like to have substantive comments. I consider
the message as helpful.
Murray Kucherawy concurred [8] with Dave on telling Russ that the WG
is strongly in favour.
Comment: The previous comment apply here.
I received Frank Ellermann's message [9] a few minutes after I sent
my reply to Russ.
Frank commented on removing the note:
"One potential conflict is an MSA following "MAY add Sender", and a
DKIM signature explicitly confirming the absence of a Sender header
field. Several things are odd in this scenario, but it is clearly
not the wish to add a Sender. In other words, 4409bis is not a
good place to discuss this oddity, and it would be very wrong if
an MSA stops to add a Sender only because it breaks a "no Sender"
signature."
Comment: As far as I recall, this was not mentioned during WG discussions.
The argument is based on a "potential conflict". Any replacement
text will not be a requirement. As other WG participants have
pointed out, the replacement text is advice.
Section 8 describes a number of modifications that are often
considered useful. I'll highlight a point in the note:
"As a matter of guidance for local decisions to implement
message modification, a paramount rule is to limit such actions to
remedies for specific problems that have clear solutions."
The point about the "good place to discuss this oddity" reminds me of
a discussion in the DKIM WG. My position is that if there is WG
agreement on discussing the problem, it is a good enough reason to do
it even if it is the wrong place to do it. I'll borrow some words
from Alexey: I don't believe in "disservice to the community". If
you ask me whether it is appropriate to fix that in a Full Standard,
I'll point out that rough consensus can be an overriding factor.
Ned pointed out that S/MIME was dropped [10].
Comment: The replacement text I sent out would need a fix. I don't
think that the AD would object to that.
John Klensin pointed out that [11]:
"But I think that, in the quest of apparent precision, we are
being a little unrealistic. There are digital signature systems
around and in use that do not conform to the IETF-standardized
versions of DKIM, PGP, and S/MIME. There are still environments
in which message content is secured by computing a message
integrity check values and then sending that value over a
separate channel, independent of the message itself. In the
general case -- the three IETF-standard protocols excluded-- we
can't even have a general expectation that the Submission server
will be able to recognize the presence of a signature mechanism
because that mechanism may be supported through
undocumented/non-standard message header fields or
undocumented/non-standard envelope fields. In the case of
out-of-band transmission of a MIC, there may be no hint at all
in the envelope or message that a check is being done.
We can sensibly advise (and probably should, given the concerns
Russ identified about invalid signatures versus no signatures)
that part of that Sender (or MUA) communication with the submission
server include agreements about whether the Submission server should
remove possibly-affected signatures, ignore the problem, re-sign the
message with its own keys and mechanisms (or incrementally if
that is feasible), or even return the message to the submitter
with an explanation of the problem."
"we are spending a lot of time on this for a very small
incremental gain over either saying nothing or saying
"Submission servers should be really, really, careful
that their well-intentioned changes to messages don't
screw things up"
Ned mentioned that "it's important to at least point it out so that
there's some
chance people will at least be aware of the issue" [12].
Comment: It gives a sense about whether the WG would like to keep some text in.
Chris Newman believes "the alternative text that was proposed is
fine, but I would also be fine with the current text and also with
dropping the offending paragraph if necessary to advance the
specification" [13].
John Klensin mentioned [14] that "If a primary goal is to mention
(advertise?) DKIM, then it it probably better to use Dave's text
(despite my concerns and Ned's) and be done with it".
Could the working group please provide feedback to help resolve this
last issue?
Thank you,
S. Moonesamy
YAM WG co-chair
1. http://www.ietf.org/mail-archive/web/yam/current/msg00753.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00755.html
3. http://www.ietf.org/mail-archive/web/yam/current/msg00756.html
4. http://www.ietf.org/mail-archive/web/yam/current/msg00760.html
5. http://www.ietf.org/mail-archive/web/yam/current/msg00761.html
6. http://www.ietf.org/mail-archive/web/yam/current/msg00762.html
7. http://www.ietf.org/mail-archive/web/yam/current/msg00763.html
8. http://www.ietf.org/mail-archive/web/yam/current/msg00767.html
9. http://www.ietf.org/mail-archive/web/yam/current/msg00769.html
10. http://www.ietf.org/mail-archive/web/yam/current/msg00781.html
11. http://www.ietf.org/mail-archive/web/yam/current/msg00785.html
12. http://www.ietf.org/mail-archive/web/yam/current/msg00786.html
13. http://www.ietf.org/mail-archive/web/yam/current/msg00787.html
14. http://www.ietf.org/mail-archive/web/yam/current/msg00790.html
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
