Subject: [yam] AD DISCUSS about Section 8 of draft-ietf-yam-rfc4409bis-02 - Message Modifications

From: S Moonesamy <[email-masked]>
Date: Mon, 22 Aug 2011 15:26:03 -0700

Hello,

Russ Housley, Area Director, posted the following DISCUSS about 
Section 8 of draft-ietf-yam-rfc4409bis-02:

"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 "shepherding AD and the DISCUSSing AD agree that dropping the 
paragraph in question is probably the easiest (and perhaps best) 
course of action".  I haven't discussed the matter with Tony yet.  My 
recommendation is to drop the last paragraph in Section 8.

If there are any objections, please come up with very convincing 
arguments.  It was pointed out that the text is not in RFC 4409.  The 
shepherding AD is "inclined to be *extremely* conservative about 
changes" and I strongly agree with him.

Regards,
S. Moonesamy
YAM WG co-chair

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Aug 2011 16:53:08 -0700

On 8/22/2011 3:26 PM, S Moonesamy wrote:
> The "shepherding AD and the DISCUSSing AD agree that dropping the paragraph in
> question is probably the easiest (and perhaps best) course of action". I haven't
> discussed the matter with Tony yet. My recommendation is to drop the last
> paragraph in Section 8.
>
> If there are any objections, please come up with very convincing arguments. It
> was pointed out that the text is not in RFC 4409. The shepherding AD is
> "inclined to be *extremely* conservative about changes" and I strongly agree
> with him.

This is a pretty classic case of avoiding a problematic Discuss, through an easy 
expedient.

Russ' opinion is understandable.  I also think it is wrong.

But indeed, this isn't worth debating, since the existing text is extremely 
minor, in practical terms.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Mon, 22 Aug 2011 16:52:19 -0700 (PDT)

>      a criterion when deciding what, if any, modifications to make.

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

Awareness of the possibility of signature-breaking is an important thing when
implementing submit processors so I think some text along these lines is useful
advice. So my recommendation is keep the text but lower case the SHOULD.

>    tell the reader anything about the real consequences.

That's because it can't. The actual consequences are completely
context-specific. (I'm sorry, saying "the signature won't be valid any more if 
you change the content under the hash is stating the obvious, totally vague,
and therefore useless.)

>    I believe

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 asssociated with a submit agent. And the latter can be a
legal requirement in some venues.

I am absolutely opposed to putting stuff in standards that in effect says you
have to perfectly predict the future in order to comply, and this
recommendation does exactly that. I'm almost as opposed to recommendations that
are at odds with operational requirements at a nonnegligible number of sites,
and this recommendation does that too.

Now, this could be limited to just S/MIME, PGP, and DKIM. If that were done I
could almost buy this argument in the case of S/MIME or PGP since those only
cover message content, not primary headers, and since both of those include
operational recommendations that make them immune to the more common MIME
transformations, e.g., CTE downgrading. But not DKIM. DKIM is not designed to
be able to survive the more common submit message processing and saying that
agents are supposed to make an effort to preserve it not just pointless, it may
be actively harmful.

>    the security considerations."

And finally, a substantial change to implementation requirements - which this
absolutely is - is *highly* inappropriate when moving to full standard. In fact
I believe the rules flatly prohibit it, and if this text gets added you may
rest assured I for one will file an appeal.

I also note in passing that this is *precisely* the sort of inappropriate
feedback from the IESG for advancement at this level that I was complaining
about in my recent posting to the IETF list.

> changes" and I strongly agree with him.

See above - I think pointing out the possibility of client signatures is
important and the text should be retained, but without the compliance language. 
I think deleting it weakens the document and therefore I object to its total
removal. That said, I can live with it going if not removing it will prevent
the move to full standard.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Mon, 22 Aug 2011 19:50:15 -0500

On 8/22/11 6:52 PM, Ned Freed wrote:

> ...a substantial change to implementation requirements - which this 
> absolutely is - is *highly* inappropriate when moving to full standard.

Yup. That's why I pushed back against Russ on this, and why he agreed 
with me that removal is a reasonable alternative.

> I think pointing out the possibility of client signatures is important 
> and the text should be retained, but without the compliance language. 
> I think deleting it weakens the document and therefore I object to its 
> total removal. That said, I can live with it going if not removing it 
> will prevent the move to full standard.

So, I hadn't considered the possibility of simply weakening the current 
language so it's strictly explanatory and had no 2119 language. I have 
to agree with Russ that the current text is hand-wavy and with Ned that 
more explanations are context-specific, but I'm less sanguine than Ned 
that simply removing the 2119 language from what's currently there would 
make the text terribly useful without additional context-specific 
explanations. However, if there is a general feeling that including such 
text is a better choice than removing this entirely, I'd say come up 
with some text and bring Russ into the conversation. Speaking for 
myself, I think it's just as well to remove it.

pr

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Aug 2011 18:03:13 -0700

On 8/22/2011 5:50 PM, Pete Resnick wrote:
>> I think pointing out the possibility of client signatures is important and the
>> text should be retained, but without the compliance language. I think deleting
>> it weakens the document and therefore I object to its total removal. That
>> said, I can live with it going if not removing it will prevent the move to
>> full standard.
>
> So, I hadn't considered the possibility of simply weakening the current language
> so it's strictly explanatory and had no 2119 language.

Indeed, it doesn't make much sense to have normative language for something that 
is merely highlighting an issue and encouraging attention to it.

Perhaps:

     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.

d/
-- 

   Dave Crocker

---

From: S Moonesamy <[email-masked]>
Date: Mon, 22 Aug 2011 21:43:35 -0700

At 16:53 22-08-2011, Dave CROCKER wrote:
>This is a pretty classic case of avoiding a problematic Discuss, 
>through an easy expedient.

If YAM WG participants view it as such a case, they can voice their concern.

At 16:52 22-08-2011, Ned Freed wrote:
>important and the text should be retained, but without the 
>compliance language. I think deleting it weakens the document and 
>therefore I object to its total

Ok.

Dave suggested the following text:

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

As an individual comment, the "that consider ..." could be dropped as 
the text mentions that validity can affect message handling.

Dave and Ned are in favor of including some text and Pete is for 
removal.  I would appreciate some more feedback.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2011 07:14:28 -0000

>     a criterion when deciding what, if any, modifications to make.

I think the existing text is dandy, but I would, since I wrote it.

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.  The
sort of stuff I was thinking of includes:

* If there's a valid S/MIME signature, don't mess with the body.  (I
can tell you from experience that if you wrap a signed MIME body in a
multipart/related, about half of MUAs will still recognize the
signature and half won't.)

* If there's a DKIM signature, and the MSA doesn't sign, don't mess
with the message.  But if the MSA does sign, do mess and then sign the
modified message.

I'm not saying either of these are always the right thing to do, but
they're the sort of tradeoffs I had in mind.  And I'm not at all sure
that there is any way to say that that will not be misread as
normative NEVER CHANGE A DKIM SIGNED MESSAGE or the like.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Aug 2011 09:52:29 +0100

S Moonesamy wrote:

>> important and the text should be retained, but without the compliance 
>> language. I think deleting it weakens the document and therefore I 
>> object to its total

I am against removing the text, as it will be a disservice to the 
community. I am Ok with weakening it and possibly adding examples. 
Dave's suggestion looks good to me.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Aug 2011 09:55:09 -0400

>> This is a pretty classic case of avoiding a problematic Discuss, through
>> an easy expedient.
>

It seems to me, SM, that that's exactly what's happening.

>    receivers, such as filtering engines that consider the presence or
>    absence of a signature"

And I think that text is good.  I support changing the text to this,
and telling Russ that the WG is strongly in favour of having this in
there.  (And I'm not in favour of SM's suggested change to it.)

Having text such as this is important:
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.

We're not changing the protocol, but it's critical that anyone looking
at the new Message Submission spec be aware of its effect on
signatures.  We MUST NOT remove this alert.

Barry

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 23 Aug 2011 11:05:07 -0400

> signatures.  We MUST NOT remove this alert.

+1 (that means Dave modified text is OK with me)

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Aug 2011 10:12:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, August 23, 2011 6:55 AM
> To: Yet Another Mail Working Group
> Subject: Re: [yam] AD DISCUSS about Section 8 of draft-ietf-yam- rfc4409bis-02 - Message Modifications
> 

Concur on all points.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 23 Aug 2011 22:21:09 +0200

On 23 August 2011 06:43, S Moonesamy wrote:

> I would appreciate some more feedback.

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.  Let's remove the note, it is not helpful.  If there is
a problem in this scenario it is elsewhere, not in 4409bis, and not
in DKIM.

-Frank

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Aug 2011 16:03:03 -0500

> Dave's suggestion looks good to me.

And to be clear: I am not "for removal". I am for removal *of the 
current text*, because I think it is reasonable to complain about new 
requirements language in something moving from Draft Standard to 
Standard. But I do not object to Dave's suggested language, and I think 
some kind of language is probably useful.

pr