Subject: [EAI] draft-leiba-5322upd-from-group discussion

From: Barry Leiba <[email-masked]>
Date: Mon, 2 Jul 2012 10:57:51 -0400

I think the subject document will do; please review it:
http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group

The "replacement for 3.6.2" section should be solid except for one
issue, noted: one sentence needs to change, for our purposes, and we
need to decide how to make the change.

   If the from field contains more than one address in the address-list,
   then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.

I don't believe that we plan to use the "Sender" field in the cases
where we'll use group syntax in "From", so that MUST can't stay.  The
simple change would be to make it SHOULD and have done with it, but
I'm not entirely happy with that.  The alternative is to leave the
MUST, but add "unless...", and then we have to craft the "unless"
text.

Please also review the Security Considerations, and make sure I got that right.

Barry

---

From: [email-masked]
Date: Sun, 08 Jul 2012 22:10:55 -0700 (PDT)

> where we'll use group syntax in "From", so that MUST can't stay.

Then I guess I'm confused. The cases I'm familiar with in EAI at least involve
constructing empty groups. The text says "more than one", not "anything 
other than one", so the MUST would not be violated.

If there's a use-case for creating a From: field using a group that
ends up containing multiple addreseses, I'd like to know what it is so I can
evaluate whether it warrants overrding the MUST.

> The

> Please also review the Security Considerations, and make sure I got that

The one I don't see is possible exploits involving different clients handling
of something that used to not be allowed.

					Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Jul 2012 15:02:29 -0400

> evaluate whether it warrants overrding the MUST.

Hm, good point.  The text in question was written with the idea of
"from" being mailboxes, and it's not clear that the sender always
knows how groups will expand.

But now that you say this, I think we can consider that a "group" is a
single "address" (as opposed to a multi-address list), and so we can
leave that paragraph as is, with the MUST.  And so I don't think this
is a problem.  Does anyone think otherwise?

> of something that used to not be allowed.

Good point; I'll craft something for that and post an updated draft.

b

---

From: Barry Leiba <[email-masked]>
Date: Sat, 14 Jul 2012 15:56:07 -0400

> Good point; I'll craft something for that and post an updated draft.

I have updated the security considerations with this new paragraph in -02:

   Because group syntax in the "From" header field has previously not
   been allowed, it is possible that some implementations that conform
   to RFC 5322 might not be prepared to handle the syntax, and, indeed,
   might not even recognize that group syntax is being used.  Of those
   implementations, some subset might, when presented with "From" group
   syntax, behave in a way that is exploitable by an attacker.  It is
   deemed unlikely that this will be a serious problem in practice:
   address field parsing is generally an integral component of
   implementations, and address field parsers are required to understand
   group syntax.  In addition, if any implementations should be
   exploitable through this mechanism, it is already possible for
   attackers to do it by violating RFC 5322, and other RFC 5322
   violations are commonly used by malefactors.

Here's the current -02 version:
https://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group

To compare the changed text with the original text from RFC 5322, diff
this version against the -00 version:
https://tools.ietf.org/rfcdiff?url1=draft-leiba-5322upd-from-group-00.txt&url2=draft-leiba-5322upd-from-group-02.txt

I believe -02 is ready for me to send to Pete for sponsorship.  Will
folks please review this and give your assessment of that?  And will
someone please volunteer to be the document shepherd, and to do a
shepherd writeup (
https://www.ietf.org/iesg/template/individual-doc-writeup.txt ) ?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Sat, 14 Jul 2012 15:35:36 -0500

> http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group

IANA Considerations should update the Permanent Header Field Registry 
<http://www.iana.org/assignments/message-headers/perm-headers.html> so 
that the "From" entry points to this document *in addition to* RFC 5322.

pr

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

---

From: Barry Leiba <[email-masked]>
Date: Sat, 14 Jul 2012 17:01:45 -0400

> <http://www.iana.org/assignments/message-headers/perm-headers.html> so that
> the "From" entry points to this document *in addition to* RFC 5322.

Good catch; thanks.  Updated -03 submitted.

b

---

From: [email-masked]
Date: Sun, 22 Jul 2012 07:53:40 -0700 (PDT)

I was going to suggest that we might want to emphasize the possibility
of exploiting differences in behavior between different implementations,
but on reflection this issue is so generally pervasive that it really makes
no sense to call it out in this narrow context.

In other words, I think what you have is fine.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jul 2012 09:19:45 -0400

Updated for -03:

> https://tools.ietf.org/rfcdiff?url1=draft-leiba-5322upd-from-group-00.txt&url2=draft-leiba-5322upd-from-group-03.txt
>
> I believe -03 is ready for me to send to Pete for sponsorship.  Will

Thanks to Ned for his review.  Any other reviews?  I'd be happiest
with at least a couple more.  Any volunteers to shepherd it?

Barry

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2012 18:00:48 -0000

>with at least a couple more.

Technically it's almost fine.  The Note: in section 3.6.2 says "The
transmitter information is always present" which is no longer true. if
there's no Sender hader and the From header is something like this:

 From: downgraded from an EAI address :;

I'd suggest rewording the note to:

  Note: The transmitter information is usually present. The absence of
  the "Sender:" field is sometimes mistakenly taken to mean that the
  agent responsible for transmission of the message has not been
  specified. This absence merely means that the transmitter is identical
  to the author, which is found in the "From:" field.  The only case
  when there is no transmitter information is one where there is no
  "Sender:" field and the "From:" field contains only groups with no
  mailboxes.

The last part of the security considerations is a bit convoluted.  Perhaps
rewrite it as:

  This problem is unlikely to occor in practice: implmentations
  typically use a single parser for all address fields in a message,
  so the parsers have to handle group syntax, and in all likelihood they
  will already handle it in From: headers. Also, since few if any
  implementations validate header syntax before attempting to parse it,
  such an attack is already possible by violating RFC 5322 syntax.
  Other RFC 5322 violations are commonly used by malefactors.

> Any volunteers to shepherd it?

If you don't already have another suc^W^Wan enthusiastic volunteer, I'll do it.

R's,
John