Subject: [EAI] Security Considerations section of draft-ietf-eai-popimap-downgrade-03

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Nov 2011 18:31:03 +0800

At today's EAI session, I took an action item to re-write the first
paragraph of the Security Considerations section of
draft-ietf-eai-popimap-downgrade-03.  I've done that, and here's my
draft of it, followed by further comment:

OLD
Existing clients do not know new From: and Sender: header fields
syntax updated by Section 3 and may get wrong when they confront
<group> syntax in From: and Sender: fields.

NEW
Section 3 of this document redefines "From" and "Sender" header
fields, adding group syntax that was previously allowed only in
destination fields such as "To" and "cc".  It is anticipated that
when existing implementations encounter a downgraded "From" or
"Sender", many will tolerate the appearance of a group, even
though RFC 5322 does not permit it.  Implementations that do not
tolerate it will likely fail in non-disruptive ways.  But some
implementations could fail badly, with unpredictable results.

OK, so...
We had this extended discussion of this situation in Beijing, and
after cycling around the different alternatives, we all came back to
using the group syntax as the only workable answer, even though it
might cause breakage.  I'm good with that.  But...

...if we really do think it needs to be called out as a security
consideration, if we really do think that some old implementations
could fail in ways that might compromise security in some way, can we
really go through with this?  It amounts to saying that I can send you
a message that will do Really Bad Things to your implementation, and
you have no way to know or protect yourself.  If I were an AD, I'm
pretty sure I'd put a DISCUSS on that.

But the reality is that anyone can send such a message today, in
violation of RFC 5322, and implementations that receive it had better
cope somehow.  And, of course, most do, as it says above.  So my
question is whether this really needs to be in the Security
Considerations section this way.  Is it a security consideration?  Or
should a version of this without the last sentence or two just be up
there in Section 3?

Barry

---

From: "John Levine" <[email-masked]>
Date: 15 Nov 2011 10:44:46 -0000

> Is it a security consideration?  Or should a version of this without
>the last sentence or two just be up there in Section 3?

I'm inclined to agree with you that it's just a subcase of the general
security issue that bad people can send your software arbitrarily hostile
strings of bits.  That is not news.

But it's worth saying somewhere that this is a deliberate violation of
5322 syntax.  Perhaps flip it around and say that implementations that
do strict validation of 5322 syntax may reject downgraded messages due
to the group syntax in From: lines.

While you're rewriting the security section, in the fourth paragraph,
how about noting that if the delivery agent added an RFC 5451
Authentication-Results: header, the MUA can use that to check whether
signatures in the undowngraded message were valid?

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Nov 2011 08:55:15 -0500

> to the group syntax in From: lines.

Indeed.  So I suggest that we eliminate the first paragraph in Section
7, the one that was just added, and that we add a paragraph to the end
of Section 3:

This adds group syntax to "From" and "Sender" that was previously
allowed only in destination fields such as "To" and "cc".  It is
anticipated that when existing implementations encounter a
downgraded field from this set, many will tolerate the appearance
of a group, even though RFC 5322 does not permit it.
Implementations that do not tolerate it will fail in unpredictable
ways, and they might refuse to process such messages.

> signatures in the undowngraded message were valid?

In Section 7, I propose adding the following sentence to the paragraph
that mentions DKIM, S/MIME, and PGP:

In addition, the presence of an Authentication-Results header
field [RFC5451] can be used to assess whether the digital
signatures were valid before the header fields were downgraded.

Barry