[secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01
Derek Atkins <derek@ihtfp.com> Fri, 21 December 2018 16:56 UTC
Return-Path: <derek@ihtfp.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 DBE1F12894E; Fri, 21 Dec 2018 08:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 2qhaaDkjn0Al; Fri, 21 Dec 2018 08:56:38 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE3D130DFE; Fri, 21 Dec 2018 08:56:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1F4E0E2047; Fri, 21 Dec 2018 11:56:34 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21636-09; Fri, 21 Dec 2018 11:56:33 -0500 (EST)
Received: from securerf.ihtfp.org (unknown [8.46.76.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 703BBE2044; Fri, 21 Dec 2018 11:56:31 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1545411393; bh=QfHInGnY3E9j90ypGdCkHmcQGT6slvqB/WihuRXeK54=; h=From:To:Cc:Subject:Date; b=metB0QUrXMEXG3NbWbpgNdKc+Wvmed8DlUphxQrptP5qFQX93OB5xZ0I3GFkvDDgP IXYocQ/BEhWztFZHrNL2YUdaSJ0m+QRTQCcicCQyqBaUgUo8Ra0aByVUl14ZihteSJ N/JWbAjMw+PcBqndCty3x2vNfGvC9AHkzl1RyEL0=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id wBLGuFO9006576; Fri, 21 Dec 2018 11:56:15 -0500
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Cc: dnssd-chairs@ietf.org, mellon@fugue.com, cheshire@apple.com
Date: Fri, 21 Dec 2018 11:56:12 -0500
Message-ID: <sjmefaavmxf.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/s1WzyDTZZIWVgYNmyGXAFwqmtiw>
Subject: [secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 21 Dec 2018 16:56:41 -0000
Hi,
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 with the intent of improving
security requirements and considerations in IETF drafts. Comments
not addressed in last call may be included in AD reviews during the
IESG review. Document editors and WG chairs should treat these
comments just like any other last call comments.
Summary:
* Ready to publish, but nits remain
Details:
* The specific authorization details between the Client and Relay is
elided. Specifically, how does a proxy get configured for specific
client connections? The spec does say it needs to get configured
(section 9), and talks at length about configuring the relay for the
available networks, but doesn't say much else about how to authorize
clients.
* Can a Relay be a client to another Relay? It's unclear what would
happen if someone tried to configure it that way; the specification
does not talk to that possibility (or prohibit it), as far as I can
tell.
-derek
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant