Re: [yam] Russ Housley's Discuss on draft-ietf-yam-rfc4409bis-02: (with DISCUSS)

[S Moonesamy <[e-mail]>]

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