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

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

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
Precedence: list

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
>

[secdir] sec-dir review of draft-ietf-dnssd-mdns-… Derek Atkins
Re: [secdir] sec-dir review of draft-ietf-dnssd-m… Ted Lemon