Subject: [EAI] SimpleDowngrade and excising MIME parameters

From: John C Klensin <[email-masked]>
Date: Wed, 16 May 2012 19:15:17 -0400

The things one notices when trying to go through the documents
looking for things that Monday's strategy requires adjusting...

Section 2.2 says:
	"Any MIME parameter [RFC2045] (whether in the message
	header or a bodypart header) which cannot be presented
	as-is to the client is silently excised."

I can't remember examples offhand (others might do better) but
there is nothing in RFC 2045 that prevents a content [media]
type (or header field that uses parameters) from having
parameters whose meaning is interdependent.  In part because of
that, one really can't start dropping parameters (silently or
not) without risking silly states unless the media type or
header field type is understood.  

I believe that you should add to this section (and/or the
Security Considerations one) a note that indicates that
parameter-dropping might turn the associated field into nonsense
or, perhaps even worse, reverse its meaning.

     john

---

From: [email-masked]
Date: Wed, 16 May 2012 17:41:22 -0700 (PDT)

> parameters whose meaning is interdependent.

Not only is is allowed, I believe it's been donee. For example, there are audio
and video formats with multiple parameters specifying encoder settings, and I
think there's one where a couple specify values and another specify the units
for those values.

OTOH, such parameters are unlikely to contain EAI material.

> In part because of

In practice the far bigger risk is that of broken behavior from EAI filename
parameters and clients that depend on those parameters for type identification.

Given that we specify that utf-8 in in the subject field should be turned
into encoded-words, and that RFC 2231 encoding is not significantly harder
to do than that, I have a really hard time not understanding why that option
wasn't chosen. 

> or, perhaps even worse, reverse its meaning.

IMO the present security considerations section in this specification isn't
even close to adequate, but this particular issue is way, way, way down the
list.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 May 2012 22:26:52 -0400

--On Wednesday, May 16, 2012 17:41 -0700 Ned Freed
<[email-masked]> wrote:

> Not only is is allowed, I believe it's been donee. For
> example, there are audio and video formats with multiple
> parameters specifying encoder settings, and I think there's
> one where a couple specify values and another specify the units
> for those values.
> 

Yes, but my lack of conviction that it was an actual, rather
than theoretical/potential problem was related precisely to the
question of whether such parameters were likely to end up with
non-ASCII values.  The examples I could think of or make up in
which dropping a parameter would make a major difference all
used either digits, keywords from a reserved (and ASCII) list,
or something similar.  But the future is harder to predict.

> In practice the far bigger risk is that of broken behavior
> from EAI filename parameters and clients that depend on those
> parameters for type identification.

Yes, but I don't see any way to solve that problem other than
possibly warning about it.
> 
> Given that we specify that utf-8 in in the subject field
> should be turned into encoded-words, and that RFC 2231
> encoding is not significantly harder to do than that, I have a
> really hard time not understanding why that option wasn't
> chosen. 

Arnt can defend his own design choices but I can give two
possible answers from my own perspective:

(i) To the extent to which the plan is "simple" and "covering
most of the obvious cases while minimizing effort", one has to
draw the line somewhere.  Whether it should be drawn after
"Subject:" and before parameter values, or after parameter
values is a very subjective judgment call.

(ii) The encoded work specs are very explicit about being able
to encode Subject fields, quite independent of EAI.  If memory
serves, they don't make a general rule about parameter values.
That could make their use in parameter values as part of EAI
"downgrading" a little dicey.  We are doing lots of dicey things
already, but the tradeoffs on this one are not completely
obvious to me.

>> parameter-dropping might turn the associated field into
>> nonsense or, perhaps even worse, reverse its meaning.
> 
> IMO the present security considerations section in this
> specification isn't even close to adequate, but this
> particular issue is way, way, way down the list.

That is fair.  My belief at this stage is that we should divide
Security Considerations material into two categories.  Material
that would apply generically to "simple downgrade", "original
downgrade", or any other approach to synthesize a surrogate
message that is more or less conformant to 5322 ought to be
phrased as generically as possible and stuffed into the new
Section 7 of the IMAP spec.  Anything else should be as explicit
as need in the individual downgrade docs.  I personally wouldn't
mind seeing one or the other location go a little further than
my draft text and essentially say "if one of these surrogate
messages is generated, the user is screwed and the only specific
security issues are what form that activity takes", but I
couldn't figure out a nice enough way to say that.

best,
    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 17 May 2012 08:40:44 +0200

John answers Ned:
> Arnt can defend his own design choices

That's the one I feel least sure of.

The state of 2231 parsing in clients isn't too good, at least it wasn't
when I last needed to look at it. I feel that asking servers to learn
how to generate 2231 when clients aren't that good at parsing is a bit
too much of a detour.

But it's close.

I wouldn't mind saying this in the document — should I do that?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 17 May 2012 09:26:37 +0200

> or, perhaps even worse, reverse its meaning.

The same applies to header fields.

The only example I've been able to find was more semantic than
syntactic: File sets. "See appended files", before.jpg and after.jpg.

I'll try to wordsmith something suitable.

Arnt