Re: [saag] Comments on draft-foudil-securitytxt-04

Paul Wouters <pwouters@redhat.com> Thu, 10 January 2019 14:45 UTC

Return-Path: <pwouters@redhat.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 E2AF9130EEF for <saag@ietfa.amsl.com>; Thu, 10 Jan 2019 06:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IZx-29KrctMD for <saag@ietfa.amsl.com>; Thu, 10 Jan 2019 06:45:56 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EB2130E69 for <saag@ietf.org>; Thu, 10 Jan 2019 06:45:56 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0B64396A; Thu, 10 Jan 2019 14:45:55 +0000 (UTC)
Received: from bofh7.nohats.ca (ovpn-204-54.brq.redhat.com [10.40.204.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id E893E5D76B; Thu, 10 Jan 2019 14:45:53 +0000 (UTC)
To: Randy Bush <randy@psg.com>
Cc: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>, "saag@ietf.org" <saag@ietf.org>
References: <MMXP123MB1423DD96BF73BBAE4AEAE121D3BE0@MMXP123MB1423.GBRP123.PROD.OUTLOOK.COM> <CAAyEnSOe3W5CZwajXk9qZk8vtiHC8P2AUOeP9atpr_6ZJtoLBw@mail.gmail.com> <LOXP123MB141659AE0F5B8D514A8F4CB5D3B20@LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM> <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <ac942953-9820-c041-6f6c-726ef224e7d8@redhat.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> <m2zhscnw6c.wl-randy@psg.com> <BN6PR14MB11062151603BBCA7D5EBEC7783890@BN6PR14MB1106.namprd14.prod.outlook.com> <CAAyEnSP4iu3aN2KaXsZafTjWw=X6oiyd44a5bzpaAupLGCRJzQ@mail.gmail.com> <m21s5nofaa.wl-randy@psg.com> <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> <m25zuymyfg.wl-randy@psg.com>
From: Paul Wouters <pwouters@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <e46c38e3-6402-9263-6276-79d2cc754b99@redhat.com>
Date: Thu, 10 Jan 2019 09:45:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <m25zuymyfg.wl-randy@psg.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 10 Jan 2019 14:45:55 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg>
Subject: Re: [saag] Comments on draft-foudil-securitytxt-04
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: Thu, 10 Jan 2019 14:45:59 -0000

On 01/08/2019 08:06 PM, Randy Bush wrote:
>> If http://example.com is compromised, and you grab
>> http://example.com/security.txt,
> 
> don't do that
> 
> and, in anything but trivial environments, it is foo.example.com that
> is compromised and the security.txt is on example.com

First, in _most_ domains, APEX and www. are all there is, and usually the same server. So you have no choice but to grab it from the compromised host. Are you
saying this method should not be used at all for the majority of websites because of this limitation? So what if www.nohats.ca is bad and you want to find my
security.txt? Turns out www.nohats.ca is the same as nohats.ca. You cannot just curl for the security.txt because you might get redirected to the bad server.
And what do you if those are the same? Should the draft talk about this?

Also, to me it had not been clear that the intend was to only put it on the main domain and not on each server within the domain. I thought the problem being
addressed was that there is ams.nl.service.example.com and that a contact from whois/rdap for the whole example.com would not lead to the right contact, and so
instead the server itself would publish a security.txt. But it seems now that people would need to crawl for zonecuts because it is planned to only appear at
the apex or "subdomains" as I read it now:

   The file is named "security.txt", and this file SHOULD be placed
   under the /.well-known/ path ("/.well-known/security.txt") [RFC5785]
   of a domain name or IP address for web properties.

[Note I had not realised the subtlety of "of a domain name". I think the draft should make it very clear how to handle reporting hosts within a domain using the
 top level domain. If the idea is that for www.example.com you go to a example.com/.well-known/security.txt it should be made more clear. And then talk about
the problem of the apex and www. being the same host]


   Some examples appear below:

   # The following only applies to example.com.
   https://example.com/.well-known/security.txt

   # This only applies to subdomain.example.com.
   https://subdomain.example.com/.well-known/security.txt

   # This security.txt file applies to IPv4 address of 192.0.2.0.
   http://192.0.2.0/.well-known/security.txt

[note: this ending in .0 is very confusing. Is it mean to cover the whole /24 ?]

   # This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
   http://[2001:db8:8:4::2]/.well-known/security.txt

   # This security.txt file applies to the /example/folder1 directory.
   /example/folder1/security.txt


Here, the "subdomain.example.com" hides the problem of not knowing administrative cuts. Is toronto.bank.site a domain or subdomain? What about
paul.lawyers.website? what about example.gc.ca ? or example.gc.com ?



So where do you now find a security.txt for  ams.nl.service.example.com ? It seems the draft now dictates you:

- look for a subdomain zonecut for nl.service.example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for a subdomain zonecut for service.example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for a subdomain zonecut for example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for server named .com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt

And that's before we start talking about how to handle HTTP vs HTTPS resources which could end up on different VHOST configurations.

As for the examples for the IP address, I'm also confused. If 193.110.157.66 needs to be reported on, and I should not go to the compromised
host itself, so not try  http://193.110.157.66/.well-known/security.txt? Do I have to try http://193.110.157.0/.well-known/security.txt or
do I try http://157.110.193.in-addr.arpa/.well-known/security.txt ? Also if the /24 is malicious and I want to go "one level up" that's also
a really hard problem, because now you need to do DNS queries to see if this is a /24 from a /16 or straight from the RIR.

The document should really elaborate on these scenarios. The examples only illustrate more problems, and more possible unclear locations of where
to find these. I doubt any of these will ever see a real use because of the problems I cited above.

Paul