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

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Aug 2011 13:04:57 -0700

Hi Russ,
At 10:45 22-08-2011, Russ Housley wrote:
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>
>   The specification says:
>
>     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.
>
>   This text is a warning that there are dragons here, but it does not
>   tell the reader anything about the real consequences.  I believe
>   that the text ought to be saying that portions of the incoming
>   message that are covered by the signature SHOULD NOT be altered.
>   The consequences of such alteration should probably be included in
>   the security considerations.

The YAM WG was asked for feedback about this issue.  Dave Crocker 
suggested the following text as a replacement for the text you quoted above:

    "Message modification can affect the validity of an existing message
     signature, such as by DKIM [DKIM], PGP [RFC4880], 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 signature."

The rationale for having the text is that "awareness of the 
possibility of signature-breaking is an important thing when 
implementing submit processors, so some text along these lines is 
useful advice.  The actual consequences are completely context-specific".

Ned Freed pointed out that "first and foremost, since "signature" is 
in general completely open-ended thing, recommending that signature 
preservation always be a priority over submit message processing is:

   (a) Impossible to implement since there's no way to tell the difference
       between a new signature scheme and some random collection of header
       fields, a new media type, or whatever and

   (b) A really bad idea since the use of a signature can (and sometimes does)
       conflict with the operational policies associated with a submit agent.
       And the latter can be a legal requirement in some venues.

There were several objections to the total removal of the text.

Based on the feedback received, I think the appropriate path is to 
have the text replaced.  Do you consider the proposed change as acceptable?

Regards,
S. Moonesamy

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Aug 2011 10:06:07 -0400

SM:

Thanks for facilitating this discussion.

As Dave well knows, the presence of an invalid signature is different than no signature at all.  The technical community keeps telling implementors that they are not really different, but folks that writ code seem to think otherwise.  The proposed text does not say anything about the signature validity,  At a minimum, is should say "...of a valid signature."

I can live with this compromise.

Russ

On Aug 23, 2011, at 4:04 PM, S Moonesamy wrote:

> The YAM WG was asked for feedback about this issue.  Dave Crocker suggested the following text as a replacement for the text you quoted above:
> 
> The rationale for having the text is that "awareness of the possibility of signature-breaking is an important thing when implementing submit processors, so some text along these lines is useful advice.  The actual consequences are completely context-specific".
> 
> Ned Freed pointed out that "first and foremost, since "signature" is in general completely open-ended thing, recommending that signature preservation always be a priority over submit message processing is:
> 
> Based on the feedback received, I think the appropriate path is to have the text replaced.  Do you consider the proposed change as acceptable?
> 
> Regards,
> S. Moonesamy

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 24 Aug 2011 07:52:49 -0700

On 8/24/2011 7:06 AM, Russ Housley wrote:
> As Dave well knows, the presence of an invalid signature is different than no
> signature at all.
 >
 > The technical community keeps telling implementors that
 > they are not really different, but folks that writ code seem to think
 > otherwise.  The proposed text does not say anything about the signature
 > validity,

Russ,

As you well know, there are many, very different reasons a signature can be 
invalid.  As you also might know, the DKIM specification therefore declares the 
semantics of an invalid signature to be the same as having no signature present.

Within the formal 4 walls of DKIM, that means that the the presence of an 
invalid signature is /not/ different than no signature at all.

The fact that various receivers might choose to distinguish between the two 
conditions is well and good, but it also is outside the four walls of formal DKIM.

Pragmatics often prompt going beyond a formal specification.  That does not make 
either the specification or the pragmatics "wrong".  Each has its own purpose 
and constraints.(*)

>  At a minimum, i[t] should say "...of a valid signature."

I assume you mean that you are requesting the proposed text to be revised to be:

    of a [valid] signature."

Given your own view about the distinction, I'd have thought you would prefer the 
original wording.  While adding "valid" does change the meaning slightly, I 
don't see it as a problem.

d/

(*) Receivers choosing to make a distinction between an absent DKIM signature 
and a present, invalid one currently represents an intuition rather than a 
certainty.  That's a good basis for experimentation, but a very poor basis for 
language in a formal standards specification...

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Aug 2011 11:46:10 -0700

Hi Russ,
At 07:06 24-08-2011, Russ Housley wrote:
>As Dave well knows, the presence of an invalid signature is 
>different than no signature at all.  The technical community keeps 
>telling implementors that they are not really different, but folks 
>that writ code seem to think otherwise.  The proposed text does not 
>say anything about the signature validity,  At a minimum, is should 
>say "...of a valid signature."

Dave suggested the following (new) text as a replacement:

    of a valid signature."

The only change from the previous text is the last line.

The only comment received from the YAM WG has been from Dave.  Based 
on both comments, I think we have replacement text that all parties 
can live with.  I'll consider this DISCUSS as addressed.

Thanks,
S. Moonesamy

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Aug 2011 14:01:23 -0500

Were other comments getting fixed and therefore a new draft will be 
produced (today preferably) that will address this DISCUSS, or is this 
the only thing and I should put in an RFC Editor note?

pr

On 8/24/11 1:46 PM, S Moonesamy wrote:
>> As Dave well knows, the presence of an invalid signature is different 
>> than no signature at all.  The technical community keeps telling 
>> implementors that they are not really different, but folks that writ 
>> code seem to think otherwise.  The proposed text does not say 
>> anything about the signature validity,  At a minimum, is should say 
>> "...of a valid signature."
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Aug 2011 12:25:57 -0700 (PDT)

> The only change from the previous text is the last line.

That's not correct. The original text was worded fairly differently, also
referenced S/MIME, and mentioned the possibility of other signiatures.

I don't have a problem with the approach the new text takes, but I don't
understand why the reference to S/MIME was dropped. It seems likely
it was an unintentional omission, and if so I suggest it be restored.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Aug 2011 12:56:41 -0700

Hi Ned,
>referenced S/MIME, and mentioned the possibility of other signiatures.

I meant the previous replacement text that was suggested.

>it was an unintentional omission, and if so I suggest it be restored.

The reference to S/MIME may have been dropped unintentionally.  I am 
copying Dave as he suggested the replacement text.  I noticed the 
omission.  I did not ask about it as nobody raised it as an issue.  I 
used text from your message [1] to respond to the DISCUSS.  It looks 
like I misread your message; you were actually arguing for the 
original text to be retained without the compliance language.

Would this work for you:

   "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."

If you would like to suggest any change, I am open to it.  I'll wait 
a few hours in case the WG would like to comment.

Regards,
S. Moonesamy
YAM WG co-chair

1. http://www.ietf.org/mail-archive/web/yam/current/msg00756.html

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 24 Aug 2011 13:48:31 -0700

On 8/24/2011 12:56 PM, S Moonesamy wrote:
> The reference to S/MIME may have been dropped unintentionally.

damn.  sorry.  /absolutely/ unintentional.

> consider the presence or absence of a valid signature."

+1

d/
-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Aug 2011 13:50:56 -0700 (PDT)

> I meant the previous replacement text that was suggested.

Ah, that makes a lot more sense. Sorry for the misunderstanding.

> original text to be retained without the compliance language.

That would be fine, but the replacement text is also fine.

>     consider the presence or absence of a valid signature."

Works for me.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2011 16:58:44 -0400

Speaking personally, not as editor.

First, I can live, both personally and as editor, with Dave's
latest proposed text (although I'd prefer to see S/MIME added
back in).

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.

Depending on the method used, what it signs or verifies, and
what canonicalization is specified, many of the transformations
explicitly permitted by submission servers may mess things up,
usually be rendering a signature or separate MIC invalid.
Keeping in mind that we assume, at least formally, that
Submission servers are under the administrative control of the
sender, we can sensibly advise that the sender make sure the
Submission server is aware of any specialized constraints on its
actions (not only ones associated with signatures, although
those may be the most important case).   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. 

Other than advising such communication (which is better than a
dragon-warning, but maybe not much), there really isn't anything
we can say here because such statements would be very
method-dependent  and possibly dependent on the submission
environment (as well as too dependent on the  details of
less-mature protocols to be appropriate in a full standard). 

I think Dave's phrasing is better than the original, but I don't
think we should delude ourselves that it supplies real advice.
All it does is to make a statement about damage that can occur,
leaving it to the imagination of the reader or implementer what
should be done about it.  In that sense, it is just a
translation of the original "there be dragons" warning into
slightly more attractive standards-language.   Again, if that is
what the community wants, I'm ok with it.  But 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".

     john

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Aug 2011 14:26:31 -0700 (PDT)

> in the envelope or message that a check is being done.

This is the same primary point, more or less, that I made in my original reply.
It's why it's simply wrong to be using compliance language here, irrespective
of the process issues with adding it to a full standard: Since you cannot in
general tell if a signature/hash/mic/whatever is even being used, short of
never touching message content at all, including stuff like MIME downgrading,
you cannot possibly honor a "SHOULD respect any signature scheme that is
present".

> usually be rendering a signature or separate MIC invalid.

Yep, although I note that your chances are a lot greater if you restrict your
signature to inner message content and use the generic multipart/signed
container to indicate its presence.

> messages don't screw things up".

I think it's important to at least point it out so that there's some
chance people will at least be aware of the issue. I agree that anything
more is too much.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2011 18:23:07 -0400

--On Wednesday, August 24, 2011 14:26 -0700 Ned Freed
<[email-masked]> wrote:

>...
  
>> 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
>...

> This is the same primary point, more or less, that I made in

Yes, I know.  But the point seems to have gotten lost in the
noise.  My apologies for not explicitly crediting you.

> It's why it's simply wrong to be using
> compliance language here, irrespective of the process issues
> with adding it to a full standard: Since you cannot in general
> tell if a signature/hash/mic/whatever is even being used,
> short of never touching message content at all, including
> stuff like MIME downgrading, you cannot possibly honor a
> "SHOULD respect any signature scheme that is present".

Right.

>> what canonicalization is specified, many of the
>> transformations explicitly permitted by submission servers
>> may mess things up, usually be rendering a signature or
>> separate MIC invalid.

> Yep, although I note that your chances are a lot greater if
> you restrict your signature to inner message content and use
> the generic multipart/signed container to indicate its
> presence.

Again, yes.  And that is why the IETF versions of the PGP and
S/MIME approaches do just that, rather than trying to sign outer
headers and, fwiw, why we didn't feel a need to mention this
issue (any more than other things a Submission server could mess
up) in earlier versions of the Submission server RFCs.  In order
to accomplish a different objective, DKIM signs headers.   For
that reason, I think it would be entirely reasonable to require
that the DKIM specs say something like "If an MUA is going to
use a Submission server that modifies, fixes, or otherwise
diddles with headers that need to be signed, the DKIM signature
better be applied by that Submission server and not the MUA or
originating machine".  But that is a DKIM problem and not a
4409bis one.  And, yes, I think you've said that before too.

>> Submission server is aware of any specialized constraints on
>> its actions (not only ones associated with signatures,
>> although those may be the most important case).   We can
>> sensibly advise (and probably should, given the concerns Russ
>...
>> I think Dave's phrasing is better than the original, but I
>> don't think we should delude ourselves that it supplies real
>> advice. All it does is to make a statement about damage that
>> can occur, leaving it to the imagination of the reader or
>> implementer what should be done about it.  In that sense, it
>> is just a translation of the original "there be dragons"
>> warning into slightly more attractive standards-language.
>> Again, if that is what the community wants, I'm ok with it.
>> But 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".
> 
> I think it's important to at least point it out so that
> there's some chance people will at least be aware of the
> issue. I agree that anything more is too much.

Then, IMO, Dave's latest version is too much between it can be
read as implying that, if the signature isn't associated with
DKIM or PGP (or maybe S/MIME), then transformations are safe.
It can also be read as implying that the Submission server can
tell whether or not the message is signed and we know that isn't
true.  So, if something should be said (and I agree that is
useful), it should be closer to:

	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.

Still no normative language, but I think that addresses the
concerns we have been trying to raise while, at the same time,
actually saying something (and not implying that three
IETF-defined protocols are the only options).  It can probably
be improved by editing -- it is really just an example of a
slightly different approach -- or by eliminating statements that
go into more detail than is needed.

best,
    john

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Aug 2011 01:27:17 +0200

>        types of message integrity checks (MICs) to messages and
[...]
>        signatures may become invalid as appropriate.

Rather long, but I think it is clearer *who* is supposed to check
that everything works as it should: the signer (on behalf of the
submitter/sender, or of the MSA/SUBMIT ADMD in the case of DKIM.)

> IETF-defined protocols are the only options).

You could reference DKIM as an example, because DKIM signatures
added in the ADMD of the MSA obviously MUST not be destroyed in
that ADMD, and because its "not necessarily end-to-end" concept
is still new (= interesting for readers) and maybe unique.

In an earlier mail you wrote:
| Keeping in mind that we assume, at least formally, that
| Submission servers are under the administrative control of the
| sender

I'm not sure how to interpret that: "Gmail, fix the SPF FAIL for
me, will you."  I fear my administrative control has limits, as
outlined in RFC 5598 figure 4 s/transit/SUBMIT/.

-Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2011 19:41:34 -0400

> is still new (= interesting for readers) and maybe unique.

Yes, except that DKIM doesn't necessarily sign _all_ headers, so
mentioning it specifically in this context requires a lot more
detail... detail that is inappropriate in a full standard given
DKIM's apparent maturity.   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.

> | Submission servers are under the administrative control of
> the | sender
> 
> I'm not sure how to interpret that: "Gmail, fix the SPF FAIL
> for me, will you."  I fear my administrative control has
> limits, as outlined in RFC 5598 figure 4 s/transit/SUBMIT/.

Please note "formally" and observe that, if you don't like what
Gmail is doing, you are not obligated to use them as an address
or submission server.  Note too that I did not suggest including
that text or anything like it in 4409bis.

   john

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Aug 2011 02:35:54 +0200

On 25 August 2011 01:41, John C Klensin wrote:

>> still new (= interesting for readers) and maybe unique.

> Yes, except that DKIM doesn't necessarily sign _all_ headers,
> so mentioning it specifically in this context requires a lot
> more detail...

IMHO "e.g., [DKIM]" would not require more details, but I'm not
hot about it, and certainly agree that more details are wrong:
<http://www.ietf.org/mail-archive/web/yam/current/msg00769.html>

> If a primary goal is to mention (advertise?) DKIM

Not by me.  I just happen to know that DKIM is not like PGP or
other signatures; DKIM could have "a high astonishment factor"
for 4409bis readers who think to know what MICs and signatures
are, but don't know DKIM.

>> "Gmail, fix the SPF FAIL for me, will you."  I fear my
>>  administrative control has limits, as outlined in RFC 5598
>>  figure 4 s/transit/SUBMIT/.

> Please note "formally" and observe that, if you don't like
> what Gmail is doing, you are not obligated to use them as an
> address or submission server.

Maybe I'll revive the GMX account where SPF FAIL works, or use
@xyzzy.claranet.de again.  While we evaluate the last comma in
present or absent references, somebody said that an informative
RFC 5332 reference is no downref.  Checking RFC 4897 after Sam
and you talked about it I found that nothing is wrong with the
RFC 5332 downref note:

| At the option of the author, similar notes may be attached
| to non-normative references.

-Frank

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Aug 2011 20:05:58 -0700

Hi Pete,
At 12:01 24-08-2011, Pete Resnick wrote:
>produced (today preferably) that will address this DISCUSS, or is 
>this the only thing and I should put in an RFC Editor note?

The other comments have been resolved.  It's may be too late to ask 
for a new draft to be produced.

There were concerns within the working group about taking the easy 
path which was to drop the text.  There has been further discussions 
about the replacement text since my latest reply to Russ.  I would 
like to discuss the issue with my co-chair.  My recommendation is to 
remove draft-ietf-yam-rfc4409bis-02 from tomorrow's IESG agenda.

Regards,
S. Moonesamy
YAM WG co-chair

P.S. The easier path was actually different from what some WG 
participants may have perceived.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2011 23:45:04 -0400

> | to non-normative references.

And that is why 5322 was noted there... that and my expectation
that descendants of 5321 and 5322 would be published together,
just  as they and their predecessors were.  Not only can I not
predict the future accurately, I've done no analysis that would
permit me to reach a conclusion about what would happen if
4409bis were read in conjunction with a hypothetical 5321bis and
5322 or with 5322bis and 5321.  I've now gone back and checked
my notes (after removing the reference to 5322 from the list in
the working version of what will eventually become -03) and
including 5322 on the list was not an accident or an oversight
due to not noticing it wasn't normative.

   john

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Aug 2011 22:53:55 -0500

On 8/24/11 10:05 PM, S Moonesamy wrote:
> My recommendation is to remove draft-ietf-yam-rfc4409bis-02 from 
> tomorrow's IESG agenda. 

No need to remove it. We can discuss it to make sure we know what the 
open issues are, and then just wait for a revised I-D with the fixes. So 
long as everyone on the IESG is happy after that, we don't have to bring 
it back to a telechat for me to approve it.

pr

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Aug 2011 16:14:31 -0700

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:

      (ii)  John Klensin suggested the following replacement text:

      "Implementers of MSAs and those who submit messages to
	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

    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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Aug 2011 12:28:56 +0200

On 25/Aug/11 00:23, John C Klensin wrote:
> And that is why the IETF versions of the PGP and S/MIME approaches
> do just that, rather than trying to sign outer headers and, fwiw,
> why we didn't feel a need to mention this issue (any more than
> other things a Submission server could mess up) in earlier versions
> of the Submission server RFCs.  In order to accomplish a different
> objective, DKIM signs headers.  For that reason, I think it would
> be entirely reasonable to require that the DKIM specs say something
> like "If an MUA is going to use a Submission server that modifies,
> fixes, or otherwise diddles with headers that need to be signed,
> the DKIM signature better be applied by that Submission server and
> not the MUA or originating machine".  But that is a DKIM problem
> and not a 4409bis one.

While I agree with the above, I'd like to make explicit that the
concept of "submission" (and that of author domain signature) may
change due to the adoption of smart-hosts, possibly imposed by
deliverability reasons.  Personally, I dislike such tendency, because
smaller ADMDs can potentially identify their users with better
accuracy and behave more humanly than 1984ish giant providers.
However, this feeling is not a good reason to try and hinder that
tendency by introducing a rigid concept of submission in 4409bis.

> 	signatures may become invalid as appropriate.

+1, far better than the other options listed by SM.

> be improved by editing

I'd propose to slightly alter the last sentence so that it reads
something like
	                                      Consequently,
	operators of message originating systems that apply such
	signatures should either ensure that the relevant MSAs are
	aware that signatures may be present (or external MICs
	used) and that their site policy provides for avoiding
	to make changes and remove signatures, or accept that
	signatures may become invalid as appropriate.

The intent is to clarify that the normative standing of this paragraph
is still within the MAY in the first paragraph, where the site policy
is evoked.  (And an attempt to ease the reading of "or accept", please
improve my English...)

jm2c

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Aug 2011 09:07:42 -0400

>         consider the presence or absence of a valid signature."

I'll repeat that my very strong preference is what's above.

> Comment: I could not use that to argue against the DISCUSS as it would not
> be viewed as a substantive comment.

Well, it certainly *is* a substantive comment, but put it in
perspective.  "Dave thinks Russ is wrong," is not enough to have Russ
clear his DISCUSS ballot.  "The working group considered Russ's
comments, and its consensus is that he's wrong," may well be a part of
convincing him to clear.

I don't think it's a secondary argument, to be held back because the
"primary" argument is more compelling.  I think it's an important
adjunct to *any* argument, to say that the WG as a whole is behind
what's being said.

> Could the working group please provide feedback to help resolve this last
> issue?

I'm not sure what "this last issue" is, because the last thing you
mention is a comment by John that doesn't raise an issue.  But
assuming that's what you want comments on:

> (advertise?) DKIM, then it it probably better to use Dave's text (despite my
> concerns and Ned's) and be done with it".

I think a primary goal is to make implementors aware of the fact that
modifications can affect digital signatures, in general terms.  Dave's
text does that, and gives references to some of the most common
signature mechanisms that MSAs are likely to encounter.  So I repeat
that I think Dave's text is appropriate, and also appropriately
concise.  I think John's text is too much, and doesn't add enough
extra benefit.

That paragraph was, indeed, meant as a simple "there be dragons"
statement, and I strongly support leaving it simple.

Barry

---

From: Ned Freed <[email-masked]>
Date: Fri, 26 Aug 2011 09:08:11 -0700 (PDT)

Barry said exactly what I was going to say here. +1 on all points, including
the preference for Dave's text.

				Ned

> Barry
> _______________________________________________
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2011 16:27:02 -0000

>I'll repeat that my very strong preference is what's above.

Same here, better than my current text.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Aug 2011 10:45:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ned Freed
> Sent: Friday, August 26, 2011 9:08 AM
> To: Barry Leiba
> Cc: S Moonesamy; [email-masked]
> Subject: Re: [yam] Russ Housley's Discuss on draft-ietf-yam-rfc4409bis-02: (with DISCUSS)
> 

You beat me to it.

+1 to Barry's last post.

-MSK

---

From: Tony Hansen <[email-masked]>
Date: Sat, 27 Aug 2011 00:00:32 -0400

And everybody said together: "there be dragons". :-) Consequently, I 
think we should go with the following text:

Incantation modifications can affect the efficacy of spells, such as 
those introduced by the presence of various species of dragons, both 
big, small and purple, some of which can even render the spell useless. 
This in turn can affect secondary applications of the spells, such as 
those applied by certain minor mages who cannot handle the violet spectrum.

Sorry, I was feeling a bit of whimsey. I think it's all this prepping 
for hurricanes.

     Tony Hansen

---

From: SM <[email-masked]>
Date: Fri, 26 Aug 2011 21:39:18 -0700

At 21:00 26-08-2011, Tony Hansen wrote:
>big, small and purple, some of which can even render the spell 
>useless. This in turn can affect secondary applications of the 
>spells, such as those applied by certain minor mages who cannot 
>handle the violet spectrum.

I like the above text. :-)

Regards,
-sm

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Aug 2011 21:24:13 -0700

The text in the fourth paragraph of Section 8 of 
draft-ietf-yam-rfc4409bis-02 will be replaced with the following text:

Regards,
S. Moonesamy, Tony Hansen
co-chairs, YAM