[rfc-i] draft-iab-html-rfc-03.txt

[dhc at dcrocker.net (Dave Crocker)]

On 7/1/2016 10:02 AM, Paul Hoffman wrote:
> On 1 Jul 2016, at 8:06, Russ Housley wrote:
>> The security considerations say:
>>
>> Since RFCs are sometimes exchanged outside the normal Web
>> sandboxing mechanism (such as using the "rsync" program to a
>> mirror site) then loaded from a local file, more care must be taken
>> with the HTML than is ordinary on the web.
>>
>> Is that care already factored into the specification?  If so,
>> please say that.  If not, what additional care is needed?
>
> It is not factored in. It is impossible to say what additional care
> would be needed because we cannot anticipate what errors in browsers
>  would cause problems with random HTML.

Although motivated by a real and constructive issue, unfortunately this
is representative of quite a bit of secondary (operational, and the
like) "guidance" in RFCs and especially Security Considerations.  In
effect it states an obligation that is vague and therefore satisfaction
of the guidance can't be evaluated meaningfully.

RFCs are supposed to define details.  If a requirement or expectation is
listed, it needs to state or cite the requirement with enough detail to
for the average, non-participant reader to know what is meant exactly
and it needs to specify or cite the details that will permit satisfying it.

For example when a citation is made, such as reference to "Web
sandboxing",  there needs to be an explanation of what it is, or a
citation to that explanation.  On the average in a Security
Considerations section, there also should be some comment about the
basis for claiming that what is cited will suffice, since the average
reader of an average RFC cannot be expected to be an expert in the cited
mechanism.

Sometimes it isn't possible to provide the necessary detail, but the
issue is still important enough to state.  In those cases, the text
needs to admit to the vagueness explicitly.




On 7/2/2016 12:00 AM, Brian E Carpenter wrote:
> On 02/07/2016 07:44, Paul Hoffman wrote:
>> On 1 Jul 2016, at 12:37, Russ Housley wrote:
> It might be more meaningful to say something like:
>
> Since RFCs are sometimes exchanged by various file transfer
> mechanisms (such as using the "rsync" program to a mirror site) that
> are not subjected to specific checks for malicious HTML content,
> users should ensure that these checks are carried out prior to
> opening such transferred files.

An RFC specification for user behavior is pretty much always
inappropriate, absent careful UX analysis of its feasibility and
efficacy.

Brian's effort is a good example.  It is well-intentioned, looks
reasonable, but will be entirely useless.

An average user isn't going to know of the requirement or how to satisfy
it.  So text such as Brian is offering will seduce us into thinking 
we've specified something helpful for improving security, but it won't 
actually help produce improved security.

If the user's operating environment has been modified to attend to this
issue usefully, then it will be an automated mechanism, not an end-user
behavior.

Really, we need to write text that is substantive, contains details that
are helpful for folks other than the working group participants, and
avoids assertions about human behavior absent an empirical testing of
those assertions.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net