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

>    This text is a warning that there are dragons here, but it does not
>    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
>    that the text ought to be saying that portions of the incoming
>    message that are covered by the signature SHOULD NOT be altered.

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 consequences of such alteration should probably be included in
>    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.

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

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