Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps

Yakov Shafranovich <yakov@nightwatchcybersecurity.com> Mon, 13 July 2020 00:56 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 7EFFE3A0063 for <saag@ietfa.amsl.com>; Sun, 12 Jul 2020 17:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 08IYk8euuhcT for <saag@ietfa.amsl.com>; Sun, 12 Jul 2020 17:56:13 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 5B4D43A0044 for <saag@ietf.org>; Sun, 12 Jul 2020 17:56:13 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id w2so5267175pgg.10 for <saag@ietf.org>; Sun, 12 Jul 2020 17:56:13 -0700 (PDT)
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=yrBfrlNAn7kodCLF7T0HGjPVsl+YWJu2k6Z/p41MADI=; b=U7uv/v9gQiHnp5kSi+an6WtoQnkLPbmZyiNCs1L2Ud6SwwLOwlEDR94FdBfX4Y5IVr Mfn6Mx0uREjCvc7haomHZCwx6ZiXzy9oJTGFLQ200VGhZMpc0JKdzDQd89iXViUy8A/h QKh7d44u0N5C4e3bFSfHbWf1eMXUqKojqKY8Pjf/fdab/KwmPPZacdhG6+8/q8IXJT07 fYmKyzBe6b9/32jMN572uY8eSkhOcYyUCCsYAR5wn8o+XKCTEmQSBa7PKzmPlEilnu2g 7FMHDyCUceE0OfD4yUNEcOyEdCzDhOW/TDHSStxoSCVH0Hx/+GdWD/lUBThph8wIZEQH X3wA==
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=yrBfrlNAn7kodCLF7T0HGjPVsl+YWJu2k6Z/p41MADI=; b=PEKu/Tfwj+CKU1+npgWdIiBrRQTnfFngjRHxkwORde1yvaIR2V8hpPN8mlLy6IM9vN SD3uSloZ+RC8E9YIS3uAAc0a139K3Oz4SrWdKdkiGLHjjVywXXuYDZBOfLfZkcM5vPWu VFlAzu+a7bwmBe/bqeLeudJKhhihvXYX4YG3BdhoH3mRhMgakkwKN+2/wdwhypeVv5OG B59+v/ZI47r0Rj+UtyF8MIuQdQxPSLwkLqZP7xAVCHuE901UGBjbeO1+Ubggbbr9XZO2 71ULi8sEid7mG1YPKumFZelYEBt1jVOhp0Df2sf3xaaj6aHzyM2hCyxTlNTCMvNl0GWd AfaA==
X-Gm-Message-State: AOAM530ycDEWMi8/iWGjMewhr7BT6JJlFoCUk9ze0OexPQ6YRL1tP40s /WowcxH+yzu8xbwPO7K1TEkKFHmszzf/Gc/f3wymUg==
X-Google-Smtp-Source: ABdhPJyxdz4pF5fgp1iLDufcx1kPhIiOThdItzffDxmbm35Vlz+Nk73hm+FabSxWxmwJzX6Woz0efPM7G4xV/YxBhKY=
X-Received: by 2002:aa7:9630:: with SMTP id r16mr68938466pfg.144.1594601772728; Sun, 12 Jul 2020 17:56:12 -0700 (PDT)
MIME-Version: 1.0
References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> <5953.1593706347@localhost> <20200702222032.GG16335@kduck.mit.edu> <29760.1593757978@localhost>
In-Reply-To: <29760.1593757978@localhost>
From: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>
Date: Sun, 12 Jul 2020 20:55:36 -0400
Message-ID: <CAAyEnSPRKk-grcUfps7EUKmZjdQKu4bvFrrMn3uMEHAVY5ERmw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-foudil-securitytxt@ietf.org, Security Area Advisory Group <saag@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/pvhFFJNYUDlaI4nZAFj71Li_tys>
Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps
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: Mon, 13 Jul 2020 00:56:14 -0000

On Fri, Jul 3, 2020 at 2:33 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Benjamin Kaduk <kaduk@mit.edu> wrote:
>     >> >> My take:
>     >> >> We can't get publically anchored certificates for devices without DNS names,
>     >> >> such as those that might be found in your home on RFC1918 addresses.  The
>     >> >> teddy cam can still have a securitytxt on it to report issues.
>     >>
>     >> > That seems pretty aligned with my best guess, involving cases where https
>     >> > was not possible (whether because it's going via filesystem access and not
>     >> > web, or the device only has an IP address and not a name, or whatever).
>     >>
>     >> Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can
>     >> only apply for reporting vulnerabilities in *that* TeddyCam, since other
>     >> Teddy Cams would be at different addresses, according to section 3.1.
>
>     > Yes ... but any vulnerabilities in that one would also be expected to be
>     > present in other instances of the same model, and if the contact point is
>     > at the manufacturer, the manufacturer can do the right thing?
>     > I feel like you have a downside in mind that I'm failing to spot...
>
> If a security.txt applies *only* to the web resource where you found it,
> then that means it doesn't generalize to the other instances of that device.
> That sounds dumb, and it is, but that's what I'm reading in section 3.1
>

The concern was that in a case where different parts of a website may
be owned by different customers, we didn't want customer A claiming
authority over customer B. This is well illustrated by Amazon's setup
for S3 where "domain.s3.amazonaws.com" is the same thing as
"s3.amazonaws.com/domain/".

With that being said, the intent is that the "Policy" directive can
point to an expanded policy document that would add more information
about scope. So in the case of the Teddy Cam, the "security.txt" file
would provide the absolute minimum but the policy directive can add
additional information.

Thanks