Re: SecDir review of draft-ietf-appsawg-file-scheme-14

"Paul Hoffman" <> Tue, 29 November 2016 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 479D4129C31; Tue, 29 Nov 2016 11:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cc6Tz4Kvsk04; Tue, 29 Nov 2016 11:04:28 -0800 (PST)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64471129C29; Tue, 29 Nov 2016 11:04:28 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id uATJ44VU008806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Nov 2016 12:04:05 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Paul Hoffman <>
To: Barry Leiba <>
Subject: Re: SecDir review of draft-ietf-appsawg-file-scheme-14
Date: Tue, 29 Nov 2016 11:04:25 -0800
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <>
Cc:,, IETF discussion list <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Nov 2016 19:04:30 -0000

On 29 Nov 2016, at 10:49, Barry Leiba wrote:

> 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.
> Thanks for finally getting this through.  I think the document is
> ready with nits; my detailed comments are below.
> It’s a tiny thing, but where the abstract says “replacing the
> definition in RFC 1738,” one may be led to think (I was) that 1738 
> has
> a more robust definition than it does.  D’you mind changing that to
> something like this: ‘This document provides a full specification of
> the "file" Uniform Resource Identifier (URI) scheme, replacing the
> very brief definition in Section 3.10 of RFC 1738.’

Agree. (Humorously, I have some standing here; see below.)

> The Security Considerations section is well thought out; thanks.  The
> only thing I can think of that might be added is a few words about
> non-local file URIs.  Section 3 says two significant things that
> should be highlighted in a security consideration:
> 1. A file URI can be dependably dereferenced or translated to a local
> file path only if it is local.
> 2. This specification neither defines nor forbids any set of
> operations that might be performed on a file identified by a non-local
> file URI.
> Given those two things, I think it would be worth explicitly saying
> that treating a non-local URI as local or otherwise attempting to
> perform local operations on a non-local URI can result in security
> problems.


> Matthew’s name and address will be on the RFC, of course, but is 
> that
> really the best choice for contact information for the scheme in the
> registry?  Or would it be better to point people to “Applications 
> and
> Real-Time Area <>” ?  In general, we seem to have mixed
> feelings about listing individuals as contact points for things
> registered by working group documents (and I fall on the “avoid 
> using
> specific individuals” side, because individuals often come and go 
> over
> relatively short time).


> The “References” in the registry template should just be “this 
> RFC”,
> and this RFC number will appear in the registry.
> A bit of process geekery:
> In the Acknowledgments, you say…
>    This specification is derived from [RFC1738], [RFC3986], and
>    [I-D.hoffman-file-uri] (expired); the acknowledgements in those
>    documents still apply.
> I don’t imagine there’s actually text from 1738 in here (is 
> there?).
> How much text is here from 3986?  I’m not talking about concepts, 
> but
> actual text that was brought over.  If there is, have you made sure
> that all authors of the documents you got text from agree to the terms
> of BCPs 78 & 79 ?  If not, there might need to be a pre-5378
> disclaimer in the boilerplate.  I suspect we’re OK, because we’re
> mostly talking about Larry, Roy, and TimBL, but I just wanted to
> check.
> (I personally think the acknowledgments text above is a bit much,
> unless you’ve really copied a lot of text from those RFCs.  But 
> that’s
> your section to do with as you think best.)

I remember that draft-hoffman-file-uri copied from 1739 and 3986. I also 
remember running away sobbing from the draft, so I appreciate that 
someone with more fortitude took it up again.

> References:
> I don’t think BCP35 is normative, and I’d move it to informative.
> I don’t think UAX15 is normative, and I’d move it to informative.
> I think UTF-8 is normative (as you have it), but UNICODE is not.
> Others might disagree with that.

I agree with all those.

> I think I would make RFC 6454 normative, only because it’s listed as 
> a
> reference for “the most secure option” in the Security 
> Considerations.


--Paul Hoffman