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

Ted Lemon <> Fri, 21 December 2018 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F6EF12875B for <>; Fri, 21 Dec 2018 10:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.701
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lgh-FeRJ74ek for <>; Fri, 21 Dec 2018 10:36:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40A3B1277BB for <>; Fri, 21 Dec 2018 10:36:57 -0800 (PST)
Received: by with SMTP id t33so6753601qtt.4 for <>; Fri, 21 Dec 2018 10:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Fri, 21 Dec 2018 13:36:20 -0500
Message-ID: <>
To: Derek Atkins <>
Cc: The IESG <>, Security Directorate <>,, Stuart Cheshire <>
Content-Type: multipart/alternative; boundary="00000000000020e765057d8c8893"
Archived-At: <>
Subject: Re: [secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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
>        Computer and Internet Security Consultant