Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC
Yakov Shafranovich <yakov@nightwatchcybersecurity.com> Sun, 29 December 2019 03:59 UTC
Return-Path: <yakov@nightwatchcybersecurity.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77B312023E for <saag@ietfa.amsl.com>; Sat, 28 Dec 2019 19:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 TA-uYKzhEwHh for <saag@ietfa.amsl.com>; Sat, 28 Dec 2019 19:59:10 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 0E76C120232 for <saag@ietf.org>; Sat, 28 Dec 2019 19:59:10 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id b137so16458414pga.6 for <saag@ietf.org>; Sat, 28 Dec 2019 19:59:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oe4HFKcceQOBF9N2Obb3eKMfAJjW1m1hEZb0x29gUgY=; b=M1Dzo1o9ucwQ4q+o3h5dXpXhrR17IGadujqQG8mHCSNc8zoFms0d/VVSSGUlClg9e8 aF+PNaWZ9n99lC8kdhoFm7MLQr8kgo6h7J2Ve1okzg/oxjC9OscAGehbOxU/m8VInnBW l4BmQB+UXTudvuzk6DrWbmB17UW0YpkEAF5y6I49tGUDpSO//1Wl/6KnqP5cc0PgWFIB CCYNRgc1OFJyHZ9dDq0NYJ+Dgdz7PvYAMnxcTK6GokBmz6FSXxJbXPbGsBjrcauWPfq5 SKlfB+00H0lughdgt1vQDrAwmMzxu5LoM0CGq3SgMXpE5mrFQASLaoyE41qcRVCRZ+Qu dNxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oe4HFKcceQOBF9N2Obb3eKMfAJjW1m1hEZb0x29gUgY=; b=QeHXkk11evr2TFvCQ0+elGe4hHDzWY8KkbwnsxsP5jZeY4+uNPejtTjXjrOFnlkLmw i2zypP+sBmz+uSmLAfelTrpiSxoOkTuPMDS3UoMF2AvOI/PDE74DrSZBhveGP8XlvhoP g9ncT3ua3NRsIxlCOTtFlEOCvz7wfOR7t9zrUx6ULgNtREAgZsuE1GQblKliKjq4WpWp 9g4JtCunkzIDVx6EeL2q2M9UQHRdtcankzTfZjAZwP32iawE9Xe8TtAw1wJuDveCYH5c 2RQiDjsmM1sHI8HTusR4zvry+x6SFiFj/1O7GrISUex14CH6XBfeH8qiWgd1iIYh1gWE iEqw==
X-Gm-Message-State: APjAAAUx0runFh0tb3azEGLxybShiELUJT7BE7IgSM35CbpEMp6x9+mo rYZl9QG5p6+cBzb9ETcAavT5X3oKED9aFKGEm8iI6w==
X-Google-Smtp-Source: APXvYqx5V76zQsnlkMWbrfiSUWu578wMmaKbv1qGmLQXwcWJs5r0JKjpVljNFwbIAyLvQ6AMMbhbFylZwG7lRg+J1yo=
X-Received: by 2002:a63:954f:: with SMTP id t15mr62917134pgn.137.1577591949278; Sat, 28 Dec 2019 19:59:09 -0800 (PST)
MIME-Version: 1.0
References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com>
In-Reply-To: <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com>
From: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>
Date: Sat, 28 Dec 2019 22:58:33 -0500
Message-ID: <CAAyEnSM3TCnLzif1PV4Zs9YOi2p4hj7_MgaCW5rMTE1mFXoxcQ@mail.gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Cc: Security Area Advisory Group <saag@ietf.org>, draft-foudil-securitytxt@ietf.org, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, last-call@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/HL9aJret6Wmmx6A6yDWAJv_eHDU>
Subject: Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Dec 2019 03:59:12 -0000
On Sat, Dec 28, 2019 at 1:02 PM S Moonesamy <sm+ietf@elandsys.com> wrote: > > Section 1.1 of the draft states that it is about helping > organizations to communicate information about their security > disclosure policies. Is the field defined in Section 3.5.6 optional? > All fields are optional except for the "Contact" directive so at a minimum, there is a way to contact the organization even without a published policy. > Section 3 sets a requirement for the file (security.txt) to be > accessible via HTTP and references RFC 1945. Does it mean that the > file must be accessible using HTTP/1/0? > Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would argue that HTTP 1.0 must be allowed. > Section 3.1 specifies that the file would only apply to the domain in > the URI. The examples given in that section states that the file > also applies to to IPv4 and IPv6 addresses. > Being that it is referencing the URI format, the intent is the host as per section 3.2.2 of RFC 3986. That would include both domain names and IP addresses. We would need to clarify the language to match. > There is a requirement in Section 3.3 for the line separator to be > either CRLF or LF. Have the authors considered using only one > convention for specifying the end of line? > > Have the authors considered line limits given that the specification > defines a machine-parsable format? > There is an ongoing issue with some systems supporting CRLF and some only LF, which is why we defined in a more fluid way. This is somewhat similar to section 3.5 in RFC 7230 (HTTP 1.1): Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. > Why does the robustness principle require capital letters? (Section 4)? > I am not sure about this question - can you clarify? > How will the designated expert determine whether a proposed > registration (Section 7.2) provides value? What is the "wider > Internet community"? > Well, from the various feedback received so far, there are certainly strong opinions expressed whether the proposal itself and many of its parts provide value at all :) All jokes aside, we didn't want the registry to be a free for all via "First Come First Served" on the one extreme, and be completely restricted ("IESG Approval") on the other extreme. We felt an expert review would provide the right amount of oversight so something crazy doesn't get shoved into the registry. A good example of this would be a proposal of a directive indicating that the researcher doesn't have permission to test any of the assets - something we couldn't reach consensus on earlier. This would be something that would benefit from a review by someone versed in security and standards. The wider community would be the researchers and organizations using this format. > How should "MAY assume that English is the default language to be > used" be interpreted (Section 3.5.7)? RFC 2777 states that > "i-default" is not a specific language. > The reference is to the following language in RFC 2277: When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language. And: Messages in Default Language MUST be understandable by an English- speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers. Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations. Basically, we wanted to come up with a safe default and that was the best reference that seemed to indicate that English may be used in this case. > As an overall comment, there are a lot of requirements and > recommendations (please see RFC 2119) in the draft. There is, for > example, a restatement of a requirement: "The value MUST follow the > URI syntax described in [RFC3986]. This means that "mailto" and > "tel" URI schemes MUST be used when specifying email addresses and > telephone numbers, as defined in [RFC6068] and [RFC3966]". Does that > comply with the ABNF defined in Section 5? > The earlier versions of the draft allowed contact information without the full URI which is why the current draft calls this out. In the ABNF grammar (section 5), URI references RFC 3986. The assumption is that this reference also includes the IANA and all relevant RFCs that define URIs, since it would be impractical to list all of them out in our draft. Perhaps, the use of RFC 2119 keywords in this specific section may not be needed, since the MUST for URI syntax would be sufficient. Thanks
- [saag] Fwd: Last Call: <draft-foudil-securitytxt-… Yakov Shafranovich
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… S Moonesamy
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… Yakov Shafranovich
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… Carsten Bormann
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… S Moonesamy
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… Yakov Shafranovich
- Re: [saag] Last Call: <draft-foudil-securitytxt-0… Yakov Shafranovich