Subject: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data

From: Larry Masinter <[email-masked]>
Date: Sun, 23 Nov 2014 19:04:15 +0000

I've tried to address  WG last call comments, and submitted
a new version (with a few editorial clarifications too).

I'd like suggestions for how to address the request for 'stronger'
 security considerations. (See below)
=====
> Ned Freed Sent: Thursday, November 06, 2014 8:02 AM

> The wording in section 5.1 is a little odd. Quotes are only required
> around parameter values when a tspecial character is present. But the
> way this section is worded makes it sound like parameters always have to be
> quoted and systems that emit an unquoted parameter are doing
> something that's at a minimum wierd if not downright incorrect. I don't have
> alternate wording to suggest, but some clarification would be good.

I wound up rewriting this to eliminate the confusing text, and just
be clearer that multipart/form-data follows multipart rules here.

> I question the need to reference RFC 1806 in section 5.2. RFC 2183  is
> the standards-track specification of content-disposition which replaced the
> experimental RFC 1806. (OTOH, the documents say that RFC 2183
> updates RFC 1806; I don't understand why it didn't obsolete it. So maybe there's some
> need to reference it...)

I took out the reference to 1806, I don't think it's needed.

> Section 5.2 makes use of the content-disposition "name" parameter.
> When I checked the IANA registry for this parameter
> (http://www.iana.org/assignments/cont-disp/cont-disp.xhtml#cont-
> disp-2) I noticed something odd: The parameter is supposedly defined in RFC
> 2388, which is the earlier version of this document. Moreover, RFC 2388 just talks
> about the parameter, it doesn't actually say it registers it.
> 
> I suggest adding appropriate registration text to the IANA Considerations
> section and updating the registry to point to this document.

Done.

> Section 5.9 talks about what MIME fields are supported in form data
> parts, but doesn't go so far as to say they MUST NOT be present. It might be
> a good thing to clarify whether they are simply ignored if present or
> whether they might actually screw things up if you include them.

Belt & suspenders: I spec'd MUST NOT be sent and MUST be ignored.

> Section 8 and/or the security considerations in section 9 probably should
> say something about privacy and integrity protection for form data.

**** I'm not sure what to say, suggestions? ****
 
> All media types are supposed to state whether or not they involve
> executable content, so this needs to be mentioned in section 9.

Added a note.

===============
From t.petch 7 Nov 2014

Typos fixed.

> ' restricting field names to ASCII  will help avoid some interoperability issues.'
> worth making a SHOULD?

There's a section on non-ascii field names I referenced 

> s.5.3
> Should there be a reference for '"file:" URI' or has that been omitted
> because there is no good one:-(

There is no good one.  The most recent and (IMO promising) take is
http://intertwingly.net/projects/pegurl/url.html#file-url  but that's
not ready yet.

I did add an explicit note not to follow RFC 5987 (content-disposition
In HTTP) because even though multipart/form-data is typically sent
by HTTP with POST, I don't think anyone adds a 'filename*' parameter.
I reworded 'generally the way that a "file:" URI would be encoded'

> s.8
> I think that the Security Considerations should be stronger about
> protecting the privacy of confidential information

Ned made a similar comment but I'm not sure what to add.
I moved a sentence from the template to the Security Considerations
section, but I don't have any good ideas how to make it 'stronger'. 

> The registration has two references to this document - these should
> probably be called out as RFCxxxx with the usual note to replace xxxx
> with the RFC number

The media type registry points to this document for the template.
It doesn't copy the registration, so same-document references area OK.

---

From: t.petch <[email-masked]>
Date: Tue, 25 Nov 2014 12:56:24 +0000

Looks good.

On security, my thinking is that a form can be used to solicit data
which is confidential, personal or which might be damaging if revealed
to a wider audience or modified in transit.

I think that most of the 'Security with everything' proposals are
misplaced and that encrypting every client-server transaction gives a
worse service, not worth any increase in the quality of the data.

Here, however, I think we should call out the obvious and say that where
the data is or should be confidential, then suitably strong encryption
should be used; and, much harder to achieve, the client should
authenticate the server before sending any data.

Something along those lines.

Tom Petch

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: "Ned Freed" <[email-masked]>; "Salvatore Loreto"
<[email-masked]>
Cc: "Sam Ruby" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Sent: Sunday, November 23, 2014 7:04 PM
Subject: [apps-discuss] response to WG last call comments for
draft-ietf-appsawg-multipart-form-data

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Larry Masinter <[email-masked]>
Date: Tue, 25 Nov 2014 22:11:55 +0000

> Here, however, I think we should call out the obvious and say that
> where the data is or should be confidential, then suitably strong encryption

This is a general concern, independent of the media type. It would apply equally to 
http://darobin.github.io/formic/specs/json/ (a proposal for a JSON form-data).

I'm reluctant to say something that seems useless and not really the domain of the form encoding at all. 

How about:

"All form processing software should treat user supplied form-data with sensitivity, as it often contains confidential or personally identifying information.  Multipart/form-data does not supply any features for checking integrity, ensuring confidentiality; those concerns must be addressed by the form-filling and form-data-interpreting applications."

---

From: Ned Freed <[email-masked]>
Date: Wed, 26 Nov 2014 09:11:48 -0800 (PST)

> http://darobin.github.io/formic/specs/json/ (a proposal for a JSON form-data).

Actually, it isn't. There are media types whose sole purpose is to convey
public information; privacy protection for those types is irrelevant.

There are also media types that provide privacy and/or integrity protection
internally.

The point here is to expose what concerns there are and how they may be
addressed.

> "All form processing software should treat user supplied form-data with
> sensitivity, as it often contains confidential or personally identifying
> information.  Multipart/form-data does not supply any features for checking
> integrity, ensuring confidentiality; those concerns must be addressed by the
> form-filling and form-data-interpreting applications."

Looks good to me.

				Ned

---

From: t.petch <[email-masked]>
Date: Thu, 27 Nov 2014 10:45:44 +0000

----- Original Message -----
From: "Ned Freed" <[email-masked]>
To: "Larry Masinter" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "Ned Freed"
<[email-masked]>; "Salvatore Loreto"
<[email-masked]>; "IETF Apps Discuss"
<[email-masked]>; "Sam Ruby" <[email-masked]>
Sent: Wednesday, November 26, 2014 5:11 PM

> > I'm reluctant to say something that seems useless and not really the
domain
> > of the form encoding at all.
>
> > How about:
>

And would address my concern as well,

Tom Petch