Re: [dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)

Ted Lemon <> Tue, 18 July 2017 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0366712F092 for <>; Tue, 18 Jul 2017 09:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q5IF9yyiDhmi for <>; Tue, 18 Jul 2017 09:56:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 954B612EC37 for <>; Tue, 18 Jul 2017 09:56:01 -0700 (PDT)
Received: by with SMTP id v190so15885400pgv.2 for <>; Tue, 18 Jul 2017 09:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YkCKd17O9C+mZWqYuyAvNfG+3QK/YGNvXsr3o6jzhu8=; b=bCFUemgGUO6ceLpypxQFZN9DCn/lVDOnyMsmgBZvdibNwCKeELa+u6Fj3d634hfWSe WU4X0D4zJ/zYYoOSOi9oLpk8BAw6g6pbfV/VLCgjubfTKcWSrxJUwa1IXyFmZr7rAnp9 Z3jUERxZe9MurCZLa/OTF06i1LT17i+f0iAECJjH5uO0bEsI05XHzZm/WNPmo3jUmuU6 4jPzrPU98ly5SiXgWp/Ct3/mQrtbqwqpxkfKBtI48ocxROA7bJTTGW4M3dZ6WGsSZhr/ q53nwfCpxtE8OuKF32p/x3Nzlk0wJTzTZOi87nHUY7ltzkDoOd5e5f/JzS6jq6WsZlHn FJAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YkCKd17O9C+mZWqYuyAvNfG+3QK/YGNvXsr3o6jzhu8=; b=ZtbtYo0yy41Ba3FtzntYSBYOE6Bg1Gw46BSCYhwFBa1YJBTmYqnGcz47hqqF83UltC LVYVNnJrxrhr3/7z+Qgh5tstpe74YhIdFj2eh66XKiQ84fuB1SylTFsz/IShNa45Ak65 744n5o4/3ckjauowo/SalucxjJIIubGpkLwabQjerFCZtkT9Y3SirwIYcqbemG9QkjNL eONxPtpOKH3I8D3VBboeEuhChTxhpLjHBo/Wx059eR6WgizyvOAhHR/gHv8cJM9rbOhS ttBrM2GiKhmXEhiT3lqbj+Dbn8pNQVVMCc/uBwItZsKO6z9EPC2s9YOoyIKVJG7AzZso IX8Q==
X-Gm-Message-State: AIVw1100gvy5/eMqEm4fGyxz+2dSpwZnHqWbKYt64cPD4oWcKY7tfCMy 9JrdgFwWkoBYCXmrfcuKG/lD9m/atDCe
X-Received: by with SMTP id f16mr2743799plk.131.1500396961023; Tue, 18 Jul 2017 09:56:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jul 2017 09:55:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Lemon <>
Date: Tue, 18 Jul 2017 18:55:20 +0200
Message-ID: <>
Content-Type: multipart/alternative; boundary="f40304360182e25b4805549a6335"
Archived-At: <>
Subject: Re: [dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 16:56:04 -0000

Okay, having now read sections 2 and 3, I still believe they should be in a
separate document.   This isn't just because of what I said in the previous
message, which I still think is true.   It's also that this document
actually will serve as a useful jumping-off point for further work on
authentication in homenet.   So separating out the informational portion of
the document from the technical specification makes both documents more
useful (at least, selfishly, to me).

On Tue, Jul 18, 2017 at 4:18 PM, Ted Lemon <> wrote:

> I agreed to review this document before the next meeting, and it is still
> (barely) before the next meeting, so here's my review:
> In the abstract, paragraph 2, s/relation/relationship/ unless we are
> talking about an rdbms. :)
> In the introduction, point 1, "disclose its presence" seems like the wrong
> thing to say, since merely sending a packet on the network discloses the
> device's presence.   I think, possibly incorrectly, that what you mean here
> is "reveal information that could be used to identify it."
> Skipping to section 4, because I want to see if the document works without
> sections 2 and 3:
> In the first paragraph of section 4, you don't say which device serves as
> a server and which as a client.   Presumably the client is the one where
> the user initiates the pairing, which is arbitrary and doesn't really
> matter?   Might be worth saying so explicitly.
> In 4.1, the QR code scanning seems like it's a separate protocol.   Might
> be less confusing to leave it out of this doc and do a follow-on doc that
> describes how to do it in more detail.   It feels like a distraction.
> This is true as QR codes come up later in the discussion.
> Also in 4.1, it might be good to go into a bit more detail about the
> service records that should be published.   I think that this may be
> incomplete.   If you want, I can look into this in more detail and propose
> text if I still think it's a problem.   E.g., I assume class and weight in
> the SRV record are 0 and are ignored by the client.   I assume that the
> text record is empty.   It would be good to say this, and to say that the
> client ignores these fields.   This observation may also apply to the
> private service discovery document--I didn't think of this when I was
> reviewing it.
> p. 18, first full paragraph, SHOULD .. MAY doesn't make sense.   Either
> this is important, or it's not.   If it's important, then you need to give
> the implementer clear guidance on what to do if the API doesn't let them
> figure out which hash algorithm was used.   The MAY seems content-free.   I
> would think you would want "SHOULD/MUST use the strongest mutually
> available hash algorithm."   Personally, I'd just say MUST, and if the API
> doesn't support this, they need to use a different API.  That way you are
> trusting that the infrastructure is going to make the best decision
> possible based on the situation at the time that software was released,
> rather than hard-coding a suggestion for a hash that we think is strong now
> but may not think is strong later.
> In the second paragraph of section 5, time frames are discussed in very
> vague terms.   It might be a good idea to be less vague.   If we don't know
> how to be less vague, I don't really know how to implement this.
> I haven't tried to implement this, so I don't know for sure if this is
> true, but based on reading the document I believe I could implement it, and
> it's not hard to implement.   I think the additional clarity I asked for
> above in section 4.1 would make interop more likely, but as a potential
> implementer I would make the assumptions I suggested requiring, and I think
> that would work.
> Going back:
> I now definitely agree with the suggestion to separate this into two
> drafts.   The document without sections 2&3 gives enough information to
> implement, and there is enough motivational information in the introduction
> (I haven't read sections 2&3 yet).   Having just scrolled back over
> sections 2&3, I think leaving these in the document will discourage
> potential implementers.
> [actually, I'm just going to send this in two parts--I might not get to
> the rest of the review for a while, and hopefully this part is useful.]