Subject: [yam] RFC 4409bis - status and additional text

From: John C Klensin <[email-masked]>
Date: Wed, 04 May 2011 16:36:03 -0400

Hi.

Per earlier notes, Randy and I have an update to 4409 just about
ready to go.  To reprise some comments in those notes, the
revision reflects all of the changes proposed in the (now
expired) pre-evaluation document.  It also contains changes that
reflect...

	- some additional reference updates
	
	- a few (stupid but inconsequential) changes needed to
	make the revision go through the current version of
	XML2RFC.
	
	- more proof of the principal that a careful editorial
	examination of substantially any document, after one has
	not looked at it for a while, will identify text that
	could be improved.

There is also some proposed text to insert a clarification into
4409bis about the appropriateness of encoding changes and other
changes that might be useful in an EAI context.  My reading of
4409 is that those changes have always been permitted in
Submission Servers but it seemed worthwhile to insert additional
text to avoid any possible confusion and/or attempts at
protocol-lawyering.

The key text is below.  I'd appreciate if it the WG would
comment on it (and suggest improvements if needed) before we
post the actual draft (which I hope is otherwise routine).

> 6.5.  Adjust Character Encodings

> Subject to limits imposed by other protocols and
> specifications, the MSA MAY convert among character sets or
> string encodings to improve message usefulness, likelihood
> of delivery, or conformance with other specifications or
> recommendations.  Such conversions MAY include, when
> necessary, replacement of addresses whose encoding does not
> conform to RFC 5321 with ones that do, using information
> available out to band.

  --john

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 5 May 2011 10:15:37 -0400

On Wed, May 4, 2011 at 4:36 PM, John C Klensin <[email-masked]> wrote:
<snip>
>        make the revision go through the current version of

yes, that is annoying. :)

<snip>
>> conform to RFC 5321 with ones that do, using information

Should there be advice mentioning that such changes should be done
before (or after?) such things as digital signing? I'm thinking PGP
and SMIME.

--
Jeff Macdonald
Ayer, MA

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 May 2011 11:20:17 -0400

--On Thursday, May 05, 2011 10:15 -0400 Jeff Macdonald
<[email-masked]> wrote:

>...
> Should there be advice mentioning that such changes should be
> done before (or after?) such things as digital signing? I'm
> thinking PGP and SMIME.

Hmm.

I'm usually reluctant to start down the path of offering that
sort of advice because it is hard to know when to stop, hard to
be comprehensive, and may mislead the unwary.   And, of course,
the implications of PGP and S/MIME (neither of which signs
headers) are rather different from those of DKIM (which does).
Perhaps an intermediate approach would be to insert a sentence
into the Security Considerations section that says,
approximately, that if a message arrives at the MSA with a
signature or any other sort of message integrity check, or the
MSA is expected to apply one, any actions must be applied with
extreme caution to ensure that the message that is sent out by
the submission server contains information consistent with the
message being sent.

Does that work?  Does anyone want to suggest specific text?
Would such a statement be improved by a forward pointer from
Section 8.5?  Anywhere else?

This also raises one other issue that apparently was not raised
in the pre-evaluation process.  RFC 4141 provides specific
mechanisms and headers for content conversions of various sorts
by intermediaries who have no specific control relationship to
either the sender or the receiver.  I believe that the
conversions contemplated there have always been permitted to
MSAs, even before we started explicitly documenting that fact in
RFC 2476.  The new text (from the pre-evaluation document)
explicitly says that the 4141 extensions MAY be used with MSAs.
Should the document go a half-step further and indicate that
content conversions may still be applied by the MSA whether the
4141 extensions are specified or not and that an MSA MAY add
4141 header fields when it makes such conversions?

    john

---

From: "John Levine" <[email-masked]>
Date: 5 May 2011 16:54:24 -0000

>the submission server contains information consistent with the

This is really a policy issue.  If you get a message with 8bit
characters and a DKIM signature, and your outgoing channel is 7bit, do
you downcode it so you can deliver it, at the cost of breaking the
signature (which, according to DKIM rules, is not an error, but just
equivalent to no signature), or do you preserve the signature?  It
depends.

So I'd prefer noting that if a message is signed, the MSA should
consider what effect downcoding will have on the validity of the
signature, but not offer any advice about when to do what.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 5 May 2011 13:47:01 -0400

> equivalent to no signature), or do you preserve the signature?  It

right, so an implementation would offer a knob.

> signature, but not offer any advice about when to do what.

I can live with this advice.

-- 
Jeff Macdonald
Ayer, MA

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2011 13:51:08 -0400

> right, so an implementation would offer a knob.

It might, or depending on the nature of the implementation, it might be 
able to do something without a knob, e.g., if it adds its own signature, 
it could always downcode if needed, then sign.

> I can live with this advice.

Oh, good.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 5 May 2011 13:59:25 -0400

> Section 8.5?  Anywhere else?

8.6 and 8.8. Or mention it in the beginning of 8?

> 4141 header fields when it makes such conversions?

This seems logical to me. But I fully admit not being savvy to 4141.

-- 
Jeff Macdonald
Ayer, MA

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 May 2011 15:56:09 -0400

>> conform to RFC 5321 with ones that do, using information

Apart from the typo at the end ("out OF band", please), it's fine.

I'm happy with John Levine's response to Jeff's concern, though I'll
point out that (1) the MSA is meant to be the first server to process
a message, generally getting it from an MUA, (2) an MUA is not likely
to do DKIM signing, and (3) PGP and S/MIME are likely to be put there
*only* by the MUA, at least today (PLASMA aside), with the MSA having
no way to make any corrections.

All that sort of means that I'd very much like to stay away from any
discussion of specific signing, and just say that if a message or
parts of it are signed, the choice to convert SHOULD take into account
the effect on the signature -- the last paragraph of John L's message,
basically.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 May 2011 17:21:33 -0400

--On Thursday, May 05, 2011 16:54 +0000 John Levine
<[email-masked]> wrote:

>...
> So I'd prefer noting that if a message is signed, the MSA
> should consider what effect downcoding will have on the
> validity of the signature, but not offer any advice about when
> to do what.

That is pretty much where I was headed, but this seems like a
better way to make the statement.  Want to suggest text and
where to put it?

    john

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2011 23:37:21 -0400

> better way to make the statement.  Want to suggest text and

Hmmn.  On page 11, just before section 8.1:

   If a incoming message includes a DKIM 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.

Regards,

---

From: Tony Hansen <[email-masked]>
Date: Fri, 06 May 2011 08:34:07 -0400

One minor item. I think it would be better to use a placeholder 
reference to 5321bis instead of 5321.

     Tony

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2011 08:41:02 -0400

> If a incoming message includes a DKIM 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.

Generally, wfm.  Noting that the text is (deliberately) broad
enough to cover body part encoding modifications as well as
those that do integrity checks on headers, so it seems unwise,
and possibly misleading, to single out DKIM.   Unless someone
objects, I'll make that "DKIM, PGP, S/MIME  or other..." and add
the appropriate citations.

I-D should be posted, or at least awaiting approval from the
co-chairs, later today

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2011 09:11:33 -0400

--On Friday, May 06, 2011 08:34 -0400 Tony Hansen <[email-masked]>
wrote:

> One minor item. I think it would be better to use a
> placeholder reference to 5321bis instead of 5321.

Hmm.

If we do, I need to remove the places (including the new text
identified in the first change item in the pre-eval doc) where
I've put in 5321 Section numbers.  I think that, when 4409bis
makes a sufficiently-precise comment that the reader can be
pointed to one section of 5321, listing the section number is
useful -- I'm more aware than most that 5321 is long and not
easy to navigate.

Worse, while I thought I'd have the bandwidth to get back to
5321bis as soon as I dropped off the IAB, the combination of
health issues and the IAB itself have caused a different
conclusion.  My current best guess is that the next rev of
5321bis is going to be mid-summer at the earliest.  Not even
draft-housley-two-maturity-levels would permit a normative
reference to an expired I-D.  When this is approved, YAM will
also need to review whether 5321bis is actually worth the effort
-- both by itself and given opportunity costs.   I don't think
the answer is obvious.

Suggested compromise: annotate the references to indicated that
newer versions of 5321/5322 may be forthcoming and that the
document should be reviewed for updates to those documents and
adjustments to the annotation just before publication.

     john

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 6 May 2011 12:59:38 -0400

> the appropriate citations.

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: SM <[email-masked]>
Date: Fri, 06 May 2011 12:59:24 -0700

Hi John,
>the appropriate citations.

Quoting Section 8:

   "Sites MAY modify submissions to ensure compliance with standards and
    site policy.  This section describes a number of such modifications
    that are often considered useful.

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

I would like to emphasize the last sentence.  It would be helpful if 
we can keep the discussion short and sweet. :-)

I would like to avoid a down-ref unless there is a good explanation for it.

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Fri, 06 May 2011 13:06:06 -0700

Hi John, Tony,
>useful -- I'm more aware than most that 5321 is long and not

Yes.

>health issues and the IAB itself have caused a different

I wish you a prompt recovery.

>-- both by itself and given opportunity costs.   I don't think

Ok.

>adjustments to the annotation just before publication.

That sounds fine.

Best regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2011 16:52:03 -0400

--On Friday, May 06, 2011 12:59 -0700 SM <[email-masked]>
wrote:

>> objects, I'll make that "DKIM, PGP, S/MIME  or other..." and
>> add the appropriate citations.
> 
> Quoting Section 8:
> 
> I would like to emphasize the last sentence.  It would be
> helpful if we can keep the discussion short and sweet. :-)
> 

The references (DKIM, PGP, S/MIME) are all downward but
distinctly informative.  I don't know how to add the text John
Leslie suggested (modified or not) without putting in references
of some sort -- if we don't do it and the IESG doesn't notice,
the RFC Editor is likely to do so, resulting in an AUTH48
battle.  By talking about signatures or the even more generic
"message integrity checks", my original suggestion is better
from a referencing standpoint but probably worse from every
other one.

So I see three possible reasonable solutions:

	(1) Stay more or less with the text that now appears in
	4409bis-00 and tolerate the downward reference.
	
	(2) Drop the new text and say nothing.  The piece of
	Section 8 that you quote is fairly clear, there wasn't a
	request to add specific signature text during the
	pre-evaluation work, and the new clarification, while
	motivated by EAI, adds nothing new: while address and
	header coding changes could cause issues for DKIM
	signatures, 4409 (especially in the presence of the 4141
	extensions explicitly authorized for Submit by the 4409
	pre-evaluation document) could rather thoroughly mess up
	PGP or S/MIME signatures over body parts.  So, if our
	theory is that if something isn't seriously broken,
	isn't causing demonstrable problems or confusion, and
	isn't reflected in the pre-evaluation document, we don't
	change it, then we should drop this.
	
	(3) Really explain the issues with signed messages and,
	in particular, define the rules under which MSAs can
	process various sorts of messages that come to them
	already signed.  Those rules would change several things
	in Sections 4, 5, 6, and 8 into "MUST NOT unless you
	have the private key and are ready to reconstruct the
	signature".  Note that this is a relatively large piece
	of work that arguably imposes new requirements, i.e., it
	would immediately take the document out of YAM's scope.
 
I have no personal preference between (1) and (2) other than
that we quickly make a decision and move on.   I'm strongly
opposed to (3) for reasons that I hope are obvious.

  best,
   john

---

From: "John Levine" <[email-masked]>
Date: 6 May 2011 21:00:08 -0000

>	4409bis-00 and tolerate the downward reference.

They're examples, doesn't seem to be a problem to me.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2011 17:12:38 -0400

> They're examples, doesn't seem to be a problem to me.

Didn't seem to be a problem to me either.  I just really hope
that we don't need to spend a lot of time on this.

best,
   john

---

From: Tony Hansen <[email-masked]>
Date: Fri, 06 May 2011 17:17:45 -0400

On 5/6/2011 9:11 AM, John C Klensin wrote:
> adjustments to the annotation just before publication

Sounds good to me.

     Tony Hansen
     [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 17:22:09 -0400

I don't see the issue here.  We don't worry about "downrefs" for
non-normative references.  I don't understand SM's concern.

Barry

---

From: SM <[email-masked]>
Date: Fri, 06 May 2011 16:47:21 -0700

Hi John, Barry,
>Leslie suggested (modified or not) without putting in references

I'm fine if the references are informative.  FWIW, I used down-ref as 
meaning a reference which is "Normative".  I gather that it is the 
text suggested by John Levine and not John Leslie.

>from a referencing standpoint but probably worse from every

I avoid flights under the radar. :-)

>         change it, then we should drop this.

Section 8 is about "specific problems that have clear 
solutions".  The change for PGP or S/MIME signatures was not raised 
during the pre-evaluation work.  I read that as something isn't 
seriously broken or there isn't a clear solution.

Header and body changes can cause issues for DKIM signatures.  The 
advice given is that:

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

Now I have to decide which message modifications mentioned in the 
sub-sections can be useful depending on whether there is a signature 
or not.  It may be a departure from clear solutions.

>         would immediately take the document out of YAM's scope.

In an perfect world, I would pick the this alternative.  Fortunately, 
such changes are out of scope for YAM.

>non-normative references.  I don't understand SM's concern.

I was thinking of normative references.

Best regards,
-sm