Subject: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08

From: Chris Lonvick <[email-masked]>
Date: Wed, 01 Apr 2015 10:14:57 -0700

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I only got a chance to skim through the document but the Security
Considerations section looks to be consistent with RFC 2388, which it
intends to replace.

I would suggest placing the last paragraph of the Security Considerations
section at the top of the section.  That paragraph seems to be the most
comprehensive in these considerations, and the other paragraphs seem to
augment and give specific details.  It just seems to me that it would
provide a better flow to reading that section.

Also, I'm just not sure that I'm following the second paragraph of
Appendix B:
    More problematic is the ambiguity introduced because implementations
    did not follow [RFC2388  <https://tools.ietf.org/html/rfc2388>] because it used "may" instead of "MUST" when
    specifying encoding of field names, and for other unknown reasons, so
    now, parsers need to be more complex for fuzzy matching against the
    possible outputs of various encoding methods.
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Finally, I usually advocate giving directions to implementers about what
to do if they find implementations using the older, outdated spec.  As
an example, what should a receiver do if it gets a ContentType that does
not have a "boundary" parameter?  However, as I'm not really familiar
with this technology, and as the document says there are many ways to
do all of this, then I'm not sure that could or should be discussed.  If
it is something that would better define behavior then I would suggest
providing some guidance here.

Best regards,
Chris

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Apr 2015 09:38:38 -0400

>> augment and give specific details. It just seems to me that it would provide
>> a better flow to reading that section.
>
> I tried it and it didn't flow any better.  I'd make the edit if I felt it
> made a difference but I don't think it helps.

At least three ADs have now agreed with Chris, and I have to say that
I do as well.  None of us think it's at the level of DISCUSS, and if
you, Larry, really feel strongly about leaving it as it is I won't
hold things up for it.  But please do consider that a Security
Directorate reviewer thinks it would read better with the last graf up
front, and that four ADs agree.

Barry

---

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 06:30:44 +0000

On 4/1/15, 10:14 AM, "Chris Lonvick" <[email-masked]<mailto:[email-masked]>> wrote:
> I would suggest placing the last paragraph of the Security Considerations section at the top of the section. That paragraph seems to be the most comprehensive in these considerations, and the other paragraphs seem to augment and give specific details. It just seems to me that it would provide a better flow to reading that section.

I tried it and it didn’t flow any better.  I’d make the edit if I felt it made a difference but I don’t think it helps.

   did not follow [RFC2388<https://tools.ietf.org/html/rfc2388>] because it used "may" instead of "MUST" when

This is also editorial, as to who is at fault.  if the spec says “you can use method A for situation S” and
implementor says “didn’t say MUST, so I’ll use method B instead”, do you blame the spec writer or
the implementor.  I'd implementors to read IETF RFCs with engineering common sense and not play
legalistic games around normative terms. So I’lm going to stick with my language.

Finally, I usually advocate giving directions to implementers about what to do if they find implementations using the older, outdated spec. As an example, what should a receiver do if it gets a ContentType that does not have a "boundary" parameter? However, as I'm not really familiar with this technology, and as the document says there are many ways to do all of this, then I'm not sure that could or should be discussed. If it is something that would better define behavior then I would suggest providing some guidance here.

the boundary parameter is used in all multipart types, which are widespread in the Internet. The
common understanding of multipart is why we picked it for framing form-data, even though it’s
ugly and the probabilistic boundary generation drives lots of people crazy. So this kind of stuff that
is inherited from MIME doesn’t need discussing.

The main reason this update was even necessary is because that advantage wasn’t as great any more,
and thus the divergences from other multipart types.

Larry
—
http://larry.masinter.net