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

[Chris Lonvick <[e-mail]>]

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