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

Barry Leiba <barryleiba@computer.org> Wed, 07 December 2016 01:42 UTC

Return-Path: <barryleiba@gmail.com>
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 732EC129625; Tue, 6 Dec 2016 17:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 GwJSPBqUba7N; Tue, 6 Dec 2016 17:42:54 -0800 (PST)
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71771295C1; Tue, 6 Dec 2016 17:42:54 -0800 (PST)
Received: by mail-qk0-f171.google.com with SMTP id x190so399808042qkb.0; Tue, 06 Dec 2016 17:42:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fj8EEAA6BJEvgOwYRd7ysEYlaeXmuvOaML/ZDWTxcVQ=; b=ILhd/XLHbz3TqpqxBKLHgjSBnvpwl0jdFbuV6RZnDn+YusiMimaziIbKaGtv159Niv huR9d53leN9RO2/ejQI+4t8/hKsqVeY8r14xDF/098eo1jsb7UEbU/89vWDmreyEkOOT eNhVO7LJ6q6yii9gClDjdIqc7X+6LdHP0pAH3FhStyGPnP0TbfPKAzk35RSnyFigmBTw S4aV+6ZsncOK5K5PbAVQKaHP3VE8aj/BSU7zjzpqfcnPWZZIdVuL22fQfgZQ2xbs2TEu 9Y1RUM3SUAqq2GqwqosBmvYFgC71/OelQ/105B5S+5XTanVAbFJSdHA0pHchclJeIxlO nJ4Q==
X-Gm-Message-State: AKaTC02j8rL6UvMV1gPGgx3svztYcmJYZ0fIxUoWSOHKw19ePOG0V/kTZKWAsR/BSk1DbcjJzoFnT1UU9sU52g==
X-Received: by 10.233.232.133 with SMTP id a127mr62773570qkg.235.1481074973843; Tue, 06 Dec 2016 17:42:53 -0800 (PST)
MIME-Version: 1.0
References: <CALaySJKTA9QXpm8JDzBdPKFuHGazqarHBryV7k3hZA+ObKjRCA@mail.gmail.com> <MWHPR01MB26702B8461E6E04ED1DEC5E9BE850@MWHPR01MB2670.prod.exchangelabs.com>
In-Reply-To: <MWHPR01MB26702B8461E6E04ED1DEC5E9BE850@MWHPR01MB2670.prod.exchangelabs.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 07 Dec 2016 01:42:43 +0000
Message-ID: <CALaySJ+HA2vMieap--+47pqk8gjxvnGz7sa0qckDbA8qaJH4EA@mail.gmail.com>
Subject: Re: SecDir review of draft-ietf-appsawg-file-scheme-14
To: Matthew Kerwin <matthew.kerwin@qut.edu.au>, "draft-ietf-appsawg-file-scheme.all@ietf.org" <draft-ietf-appsawg-file-scheme.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c034bfcb3a70b054307a3cc
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/I5wCw8zi5GvvLODrShWE_iQzDt4>
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:42:57 -0000

Thanks, Matthew!

b

On Tue, Dec 6, 2016 at 7:03 PM Matthew Kerwin <matthew.kerwin@qut.edu.au>
wrote:

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