[secdir] SECDIR review: draft-hammer-hostmeta

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Fri, 16 July 2010 14:17 UTC

Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC683A6A1C; Fri, 16 Jul 2010 07:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIjs881w4FK1; Fri, 16 Jul 2010 07:17:38 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D77853A696E; Fri, 16 Jul 2010 07:17:36 -0700 (PDT)
Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TEBqCgADGx0V@rufus.isode.com>; Fri, 16 Jul 2010 15:17:47 +0100
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
Date: Fri, 16 Jul 2010 07:17:44 -0700
Message-Id: <19622F34-F03E-4DE6-AB8F-711B99CCAECE@Isode.com>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: draft-hammer-hostmeta@tools.ietf.org, IESG IESG <iesg@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: [secdir] SECDIR review: draft-hammer-hostmeta
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 16 Jul 2010 14:17:38 -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 should treat these comments just like any other last call comments.

I have a number of security-related concerns with this specification.

First, I'm concerned by assumptions in the document that each of:
	http://example.com
	http://example.com:8080
	https://example.com
	https://example.com:8443

identify resources under the control of same entity.   It is fairly common to there to be multiple http/https services running on a single host, each service possibly operated by different entities as delegated by the "host" administrator.  I think it would be better (from a security perspective) to have "service"-level metadata, not "host" level meta data.  That is, make no assumption that the above URIs are under control of the same entity, or even if so, that it desirable to a single policy/metadata covering multiple services.

And I think it very important to always fetch the meta data from the service one is accessing.  The document calls for client to fetch https://example.com/.well-known/host-meta even when https://example.com:8443 is URI wants policy for.  

Even worse, the document calls for the client to, if the above fetch does not produce a "valid" hostmeta document, for the client to fetch http://example.com/.well-known/host-meta.  An attacker could easily cause https://example.com/.well-known/host-meta to fail to produce a "valid" hostmeta document, and serve its own hostmeta document in response to the client's http://example.com/.well-known/host-meta, without supplanting the https://example.com:8443 service.

The document fails to discuss such attacks.

I recommend reworking this document to provide service-level, not host-level, metadata.  In particular, the metadata document should always be retrieved through the service the client is interested in using, such as by fetching "/.well-known/metadata".

If the authors rather continue pursuing a "host-based" solution, the security considerations should include a discussion of the above issues.

Regards, Kurt