[secdir] SecDir review of draft-ietf-appsawg-file-scheme-14
Barry Leiba <barryleiba@computer.org> Tue, 29 November 2016 18:49 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3505129649; Tue, 29 Nov 2016 10:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UvcAzOXa4q8N; Tue, 29 Nov 2016 10:49:17 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 7B26A1294A2; Tue, 29 Nov 2016 10:49:14 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id n6so164909653qtd.1; Tue, 29 Nov 2016 10:49:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=oD2dW2R/MbUfjYzRoRDgKKXSuCIeAhVmx7LQ4D9PM1cdNg8iN84Nv22N3cVZpf0bdR E2sPmsC3azx6A8zfmRhiw3cOwxYBmYSkCmxSbdMkOumr238QaNInWZOQR7VRMgxLUfB9 fw1+i44k4WN+G4zd9TXyYTfgt+xNkM4EsPy97XU6nRPemmxs1VC8JJOd61OOzPIVaZVw fcfR3gq8Mo3vfXFY8KJ+YnDvXYTQXlsIctzjKmM0Iu6iABzYqB3O3IQn9epfpJT2Rkm7 U8JW6cu+/amJ66WayvN9hVXZg0wO/79t+W578Gt8MR00eKw/4pdLU+g2PBBEfitvbbCB 4mGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=mlgnSmMMfs91j3uWiB5PnZLtWX9qCFDs0CdDJKFVGvHaFdIT2GHc2S7zUSkgGm29Lr YLygzFNfFSkSbvPbcjjwTZqZtsfsqekH6xYxP9UKT5KY9i5KYLOKl+Rizi1H8mrdvXY+ AKHRdRifAXLNzQOEQQYr8u6zW2gf0HLemL6gCad5Fo9Y17GDie92tfnGWmKk8rBqF8Uw 36+DwzuKJ9L4owGazVHagJczwXMkw+FpRuw2AEULBX1W6mAbqJauQTq03TYb6rWK2JYr NKn44ir+Z7KVzyHPf4utxfkwzgMVpDwpSwe1ZtF4uAczhjFAb30hkJWe/6wGtQMQpPwM +0nw==
X-Gm-Message-State: AKaTC01oy4mFqkDzpDgMcGCtb197m4GuHGnWxABHUtdqHB67QSIzuVrzD+mTN4a4NEOqKNKICbwcOTQrIiNpVg==
X-Received: by 10.200.38.239 with SMTP id 44mr26470724qtp.91.1480445353329; Tue, 29 Nov 2016 10:49:13 -0800 (PST)
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 10.140.41.177 with HTTP; Tue, 29 Nov 2016 10:49:12 -0800 (PST)
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 29 Nov 2016 13:49:12 -0500
X-Google-Sender-Auth: Y_oH2YhpFtKbsQknNx-7fFQEDCE
Message-ID: <CALaySJKTA9QXpm8JDzBdPKFuHGazqarHBryV7k3hZA+ObKjRCA@mail.gmail.com>
To: draft-ietf-appsawg-file-scheme.all@ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3OboD_9zAw20Z8NQk-7KW00wwYk>
Cc: art@ietf.org, IETF discussion list <ietf@ietf.org>
Subject: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2016 18:49:24 -0000
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
- [secdir] SecDir review of draft-ietf-appsawg-file… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Paul Hoffman
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Matthew Kerwin
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Larry Masinter
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Larry Masinter
- Re: [secdir] [art] SecDir review of draft-ietf-ap… Allistair Brown
- Re: [secdir] SecDir review of draft-ietf-appsawg-… Matthew Kerwin