Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@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: In-Reply-To: From: Barry Leiba Date: Wed, 07 Dec 2016 01:42:43 +0000 Message-ID: To: Matthew Kerwin , "draft-ietf-appsawg-file-scheme.all@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c034bfcb3a70b054307a3cc Archived-At: Cc: "art@ietf.org" , IETF discussion list , "paul.hoffman@vpnc.org" Subject: Re: [art] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:42:57 -0000 --94eb2c034bfcb3a70b054307a3cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Matthew! b On Tue, Dec 6, 2016 at 7:03 PM Matthew Kerwin 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 be= en > 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 on behalf of Barry > Leiba > 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=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing= the > definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 173= 8 has > a more robust definition than it does. D=E2=80=99you mind changing that = to > something like this: =E2=80=98This 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.=E2=80=99 > > 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=E2=80=99s 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 =E2=80=9CApplications= and > Real-Time Area =E2=80=9D ? In general, we seem to have mix= ed > feelings about listing individuals as contact points for things > registered by working group documents (and I fall on the =E2=80=9Cavoid u= sing > specific individuals=E2=80=9D side, because individuals often come and go= over > relatively short time). > > The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D, > and this RFC number will appear in the registry. > > A bit of process geekery: > In the Acknowledgments, you say=E2=80=A6 > This specification is derived from [RFC1738], [RFC3986], and > [I-D.hoffman-file-uri] (expired); the acknowledgements in those > documents still apply. > > I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (= is there?). > How much text is here from 3986? I=E2=80=99m 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=E2=80=99re OK, because we=E2= =80=99re > 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=E2=80=99ve really copied a lot of text from those RFCs. But t= hat=E2=80=99s > your section to do with as you think best.) > > References: > I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to info= rmative. > I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to info= rmative. > 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=E2=80=99s listed= as a > reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Co= nsiderations. > > Barry > --94eb2c034bfcb3a70b054307a3cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Matthew!

b

On Tue, Dec 6, 2016 at 7:03 PM Matt= hew Kerwin <matthew.kerwin@= qut.edu.au> wrote:
Thanks B= arry (and Paul),

I agree with everything you've written here, and I don't think any = of it's too controversial,=C2=A0 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=C2=A0 |=C2=A0 Queensland University of Technology=C2=A0 |=C2= =A0 matthew.kerwin@qut.edu.au=C2=A0 |=C2=A0 CRICOS No 00213J ________________________________
From: barryleiba@gmail.com <barryleiba@gmail.com> on be= half 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.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br class=3D"gmail_msg"> these comments just like any other last call comments.

Thanks for finally getting this through.=C2=A0 I think the document is
ready with nits; my detailed comments are below.

It=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing t= he
definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 1738 = has
a more robust definition than it does.=C2=A0 D=E2=80=99you mind changing th= at to
something like this: =E2=80=98This document provides a full specification o= f
the "file" Uniform Resource Identifier (URI) scheme, replacing th= e
very brief definition in Section 3.10 of RFC 1738.=E2=80=99

The Security Considerations section is well thought out; thanks.=C2=A0 The<= br class=3D"gmail_msg"> only thing I can think of that might be added is a few words about
non-local file URIs.=C2=A0 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=E2=80=99s name and address will be on the RFC, of course, but is th= at
really the best choice for contact information for the scheme in the
registry?=C2=A0 Or would it be better to point people to =E2=80=9CApplicati= ons and
Real-Time Area <art@ietf.org>=E2=80=9D ?=C2=A0 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 =E2=80=9Cavoid usi= ng
specific individuals=E2=80=9D side, because individuals often come and go o= ver
relatively short time).

The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D,
and this RFC number will appear in the registry.

A bit of process geekery:
In the Acknowledgments, you say=E2=80=A6
=C2=A0 =C2=A0This specification is derived from [RFC1738], [RFC3986], and =C2=A0 =C2=A0[I-D.hoffman-file-uri] (expired); the acknowledgements in thos= e
=C2=A0 =C2=A0documents still apply.

I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (is= there?).
How much text is here from 3986?=C2=A0 I=E2=80=99m not talking about concep= ts, but
actual text that was brought over.=C2=A0 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 ?=C2=A0 If not, there might need to be a pre-5378
disclaimer in the boilerplate.=C2=A0 I suspect we=E2=80=99re OK, because we= =E2=80=99re
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=E2=80=99ve really copied a lot of text from those RFCs.=C2=A0 Bu= t that=E2=80=99s
your section to do with as you think best.)

References:
I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to inform= ative.
I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to inform= ative.
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=E2=80=99s listed a= s a
reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Cons= iderations.

Barry
--94eb2c034bfcb3a70b054307a3cc--