Re: [secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01

Ted Lemon <mellon@fugue.com> Fri, 21 December 2018 18:37 UTC

Return-Path: <mellon@fugue.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 3F6EF12875B for <secdir@ietfa.amsl.com>; Fri, 21 Dec 2018 10:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 lgh-FeRJ74ek for <secdir@ietfa.amsl.com>; Fri, 21 Dec 2018 10:36:59 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 40A3B1277BB for <secdir@ietf.org>; Fri, 21 Dec 2018 10:36:57 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id t33so6753601qtt.4 for <secdir@ietf.org>; Fri, 21 Dec 2018 10:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vScUtWcO63Kk6fgzR6OtX5YktEufXekPMkVqsre7SbE=; b=qUzg4LKu5skBWBYuMSdw7l7foBfk9i4wMTTfoohaNkv0/TELme+lnpFqLUo/VLziH2 WgXDBNu6j3v8nnJx/NxV04VAI1rWm0TCWubiUwEt5A7m7J7n3kLxeHe9Ls9/lfmHEmtE svEUJ7XZoO4UTSOpK7cVsMcVV4lFjG4ApTDlmOXWYA6hLB2AXz8rlW9DQWtGBr3XSXkc K0KtoyBqWMFdCa4reVxGYKKMV3wMJS9sb67IVuqWndZJGc0JwvEywIg03owT5bOJxRui ohlNb5GSdXhVwX/ZLfe5I2Yl9c+HFS97oBCWkK7tTj/MTJOA6cZhHYAi0VmVD/Q1aNX+ X1Sg==
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=vScUtWcO63Kk6fgzR6OtX5YktEufXekPMkVqsre7SbE=; b=aAIj7oe7hXuk6GH6nmNgvK8w8xEISF6bVv7aMZSKvHYelGvhI8XdkgZ9H42o9p2awb UgGDMfJXbRyy65wtVfiPTp0Y63CqWsVmPosqZFiDPNvnqNKlkGxTAi2t9Ho1EpuriJ5t +KFUpkNI0h1lWrQnXpsvmPiHLNPxkr+3d391IEZTCYCfVPmOgr3DOpPo+z2H4/OdGyK3 Ik97J+GEhul/YtkoEIDENQLaVzZCpNsDp/tc/NpQkW+dEBVpxTRVMaR2gw4yJKtV7Seo lQ/8m1PAHnOcWlyh0kXIqxd1zNSGci8S6gdYdwvBq+V59j8ALK/hFMSSPNMzXgTt7hqP 0FSw==
X-Gm-Message-State: AJcUukfpnkTPBEzjaKMXrcQ8pXwNHQh7xHXKnRBQscT9+5gPnXB1RzTA xWSEOLaUMhjWIt/pJ5T2+WS7nV6MPVyHFVq8fcclQQ==
X-Google-Smtp-Source: ALg8bN55KRLl38VW5jUVOA9MaF2CjyMW2SEP0pIeS3ZLYLU4cgGbEbu0nLsbpeTMKzN7Kdv7wHPMVGJxXjzjsjad8Mo=
X-Received: by 2002:aed:2be7:: with SMTP id e94mr2871309qtd.203.1545417416298; Fri, 21 Dec 2018 10:36:56 -0800 (PST)
MIME-Version: 1.0
References: <sjmefaavmxf.fsf@securerf.ihtfp.org>
In-Reply-To: <sjmefaavmxf.fsf@securerf.ihtfp.org>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 21 Dec 2018 13:36:20 -0500
Message-ID: <CAPt1N1=Buuzg6V4aYRabhUhhdwF5T0Jgie8ecPK+7bTtn8aMqg@mail.gmail.com>
To: Derek Atkins <derek@ihtfp.com>
Cc: The IESG <iesg@ietf.org>, Security Directorate <secdir@ietf.org>, dnssd-chairs@ietf.org, Stuart Cheshire <cheshire@apple.com>
Content-Type: multipart/alternative; boundary="00000000000020e765057d8c8893"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zLx01n23dJIocd4LXv5lzyxjZ6c>
Subject: Re: [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 18:37:01 -0000

Thanks, Derek!   These are both good points.   I think that the
authorization question is a bit hard to answer because it depends on how
this is used, but we have a clearer picture of that now than we did when
the document was last updated, so I'll see if I can address this in a
useful way.   I think it doesn't really make sense for a relay client to
also be a relay server for the same link(s).   You could argue that there
might be a case where a single host could be both a relay client and a
relay server, but I am not coming up with any use cases for that off the
top of my head.   So I think some clarification might be in order.   I
would be inclined to say that it's possible for a relay client and relay
server to coexist on the same host, but that it doesn't make sense for a
relay server to serve links for which it's a client.   I guess the one use
case that is now occurring to me is that it might be useful when there
isn't end-to-end connectivity from the client of this server to the server
it's a client of.

On Fri, Dec 21, 2018 at 11:56 AM Derek Atkins <derek@ihtfp.com>; wrote:

> 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
>