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

Matthew Kerwin <matthew.kerwin@qut.edu.au> Wed, 07 December 2016 01:03 UTC

Return-Path: <matthew.kerwin@qut.edu.au>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938B512955B; Tue, 6 Dec 2016 17:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-YTVWSUVf7y; Tue, 6 Dec 2016 17:03:00 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0080.outbound.protection.outlook.com [104.47.38.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB74129628; Tue, 6 Dec 2016 17:02:59 -0800 (PST)
Received: from MWHPR01MB2670.prod.exchangelabs.com (10.172.165.8) by MWHPR01MB2669.prod.exchangelabs.com (10.172.165.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Wed, 7 Dec 2016 01:02:56 +0000
Received: from MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) by MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) with mapi id 15.01.0761.017; Wed, 7 Dec 2016 01:02:56 +0000
From: Matthew Kerwin <matthew.kerwin@qut.edu.au>
To: Barry Leiba <barryleiba@computer.org>, "draft-ietf-appsawg-file-scheme.all@ietf.org" <draft-ietf-appsawg-file-scheme.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: SecDir review of draft-ietf-appsawg-file-scheme-14
Thread-Topic: SecDir review of draft-ietf-appsawg-file-scheme-14
Thread-Index: AQHSSnFPod93FrypBEOZkfp7dGkXSKD7s1Ve
Date: Wed, 7 Dec 2016 01:02:56 +0000
Message-ID: <MWHPR01MB26702B8461E6E04ED1DEC5E9BE850@MWHPR01MB2670.prod.exchangelabs.com>
References: <CALaySJKTA9QXpm8JDzBdPKFuHGazqarHBryV7k3hZA+ObKjRCA@mail.gmail.com>
In-Reply-To: <CALaySJKTA9QXpm8JDzBdPKFuHGazqarHBryV7k3hZA+ObKjRCA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.kerwin@qut.edu.au;
x-originating-ip: [25.164.163.132]
x-ms-office365-filtering-correlation-id: f2be8dee-e67b-4400-8a64-08d41e3cc7d1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR01MB2669;
x-microsoft-exchange-diagnostics: 1; MWHPR01MB2669; 7:8B2sYjm6q9XJSukdHbD1Mbh7cl1qtexKNcpcNemkHa92T01p0LVyTbyLDzrHVerGOdAVKMPXl70Y8lk8SUDbiPQuycrXJloLzrbV0qVvfmK3GzFZJisJ/Mxe7cDR2VdDZKvLFj0oxy662mbGEG4puQmKxLke0M/ehujS+faNi1Q/UGyztcGyvxeyLb+r5WnXMLdIdrgTycBOA9GWdzr/ohskJAEGSretaY7WgNPTXwwp0143vi8gmARh1sA7CIBB+0qHLjmnQVazfjWYMGEVLlbGSLn7DJWTAfh3hdOoihnTbUDrmOa9QHNGXFzJt9TiIOjqvM2ZmRxXF0YQQttk/is1ep/xDnSZ+czPVKk0wm0AQ6YtEylo3u93bD+p16ekJs9yV7Zbz5+8OZm8KXNw8lmro55SPtV6cRHbtAK2lRbOnyYGLJqLrszH6c1aeEI4HwbU68St+jaXKup4UQduQg==
x-microsoft-antispam-prvs: <MWHPR01MB2669FC851196606F1FF905F3BE850@MWHPR01MB2669.prod.exchangelabs.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(54900358751275);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR01MB2669; BCL:0; PCL:0; RULEID:; SRVR:MWHPR01MB2669;
x-forefront-prvs: 01494FA7F7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51694002)(199003)(189002)(39410400001)(97736004)(229853002)(5001770100001)(2950100002)(106356001)(189998001)(101416001)(74482002)(4326007)(42882006)(81156014)(66066001)(2906002)(8936002)(38730400001)(106116001)(92566002)(105586002)(6116002)(122556002)(3846002)(88552002)(102836003)(33656002)(81166006)(2201001)(86362001)(2900100001)(8676002)(39450400002)(77096006)(74316002)(68736007)(305945005)(7736002)(5660300001)(6506006)(39860400001)(7696004)(230783001)(2501003)(39840400001)(3280700002)(54356999)(76176999)(39850400001)(9686002)(50986999)(7846002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR01MB2669; H:MWHPR01MB2670.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: qut.edu.au does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: qut.edu.au
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 01:02:56.3800 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB2669
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SokPfHkXhZi8LreDgVlj_Ojvcxg>
Cc: "art@ietf.org" <art@ietf.org>, IETF discussion list <ietf@ietf.org>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 01:03:04 -0000

Thanks Barry (and Paul), 

I agree with everything you've written here, and I don't think any of it's too controversial,  so I'll work it all in to my copy pretty much exactly as you've suggested. 

The acknowledgements is hung over from the very first versions of the draft, which cribbed a lot from Paul's old draft. I'm pretty sure it's been completely rewritten several times since then, so I will definitely redo the acks. 

Cheers
--
Matthew Kerwin  |  Queensland University of Technology  |  matthew.kerwin@qut.edu.au  |  CRICOS No 00213J
________________________________
From: barryleiba@gmail.com <barryleiba@gmail.com> on behalf of Barry Leiba <barryleiba@computer.org>
Sent: 30 November 2016 04:49:12
To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org
Cc: IETF discussion list; art@ietf.org
Subject: SecDir review of draft-ietf-appsawg-file-scheme-14

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.’

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 <art@ietf.org>” ?  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.)

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

Barry