Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

Dave Cridland <dave@cridland.net> Thu, 21 March 2013 13:46 UTC

Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA96121F9067 for <apps-discuss@ietfa.amsl.com>; Thu, 21 Mar 2013 06:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIrYwDXnOqZC for <apps-discuss@ietfa.amsl.com>; Thu, 21 Mar 2013 06:46:19 -0700 (PDT)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3957921F9037 for <apps-discuss@ietf.org>; Thu, 21 Mar 2013 06:46:19 -0700 (PDT)
Received: by mail-oa0-f45.google.com with SMTP id o6so3119434oag.32 for <apps-discuss@ietf.org>; Thu, 21 Mar 2013 06:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=WS7+JAR5PXsMuPcfhUVbsAU92VbwwYHyRGfkBWmb4K0xfM2rQ9caBZAoHLAquchtG1 6RLDOK+yP1HkZve/LArmmgXV7+jpfe5cPYXDqfa4AyANRRtSyf1PJpH7cC/wVeFqXyLy yfbWxLVNfpOhb1DEfsUszmxql9jQ5VesCj9tI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=kNBflFku2A1soPfgPGvs7J11McNv4QLsGDQnVAo5OKb/dCTkEFbmDN057+lWxln+Kt R7oPECS0DV5wbLuxedVpMrQnRT8OJRsFjAv0Y3FWz2CsOsFhhcirW/RbOoIfkgPczvkx Ryf3oUbgRsOi7eYWyvBCWE3Rjxl+ETEfh+8jh9XvR2zsXaaqAO9i37pzucqSlEH0JWzn hb7Nuzmp+bJseK4R2Z/Hywum8bBXXK10zqrpBPe7THn4ROV4C2ZywtMw83RHjJ1lO4fd BH5eIRH4NdWcOOZQCqnea0HExAp3ocRp9Hln+n4iSDZjwdp5qq4S5f86kZtk52jjU9zR msoQ==
MIME-Version: 1.0
X-Received: by 10.60.29.72 with SMTP id i8mr6643636oeh.93.1363873571279; Thu, 21 Mar 2013 06:46:11 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT)
In-Reply-To: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com>
References: <CAKHUCzxc8_Ye6M__t9y-+fYAKRVWi8q5hcMGopzE3nKhMywiyQ@mail.gmail.com> <053c01ce25cc$8cca5730$a65f0590$@packetizer.com>
Date: Thu, 21 Mar 2013 13:46:11 +0000
Message-ID: <CAKHUCzxPxrN5rAkkEpJGTk+nOt9QbNWXCfGgCPZerRRm=XOv=w@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: multipart/alternative; boundary="e89a8fb1f806bc7f9604d86f8f96"
X-Gm-Message-State: ALoCoQmLzmNNmZDyIdPMG9ksc4OvWyvM0L9j90cUQjv+Lkzha5R+mk6sq+jeROFTlLR4cIqN/35Y
Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org
Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 13:46:20 -0000

On 21 Mar 2013 00:39, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Dave,
>
> My apologies for the belated reply.  Please see my comments below.
>
> > Please resolve these comments along with any other Last Call comments
> > you may receive. Please wait for direction from your document shepherd
> > or AD before posting a new version of the draft.  Document:
> > draft-ietf-appsawg-webfinger-11
> > Title: Webfinger
> > Reviewer: Dave Cridland
> > Review Date: 2013/03/11
> > IESG Telechat Date: 2013/03/28
> > Summary: Close to ready for publication as standards track; some
> > comments which suggest a new version may be required and/or technical
> > discussion needed.
> >
> > Minor Comments:
> >
> > 1) There's some suggestions that webfinger could be used for email
> > autoconfig; I suspect this is at best going to cause confusion
> > especially when there's a BOF tomorrow on the subject. This feels like
> > text that doesn't need to be present.
>
> This particular example provides a useful illustration of the "properties"
> construct in the JRD format.  It's there purely as an example and is not
> otherwise adopted as a provisioning mechanism.  Would this have presented
> confusion if the aggsrv BoF had not been scheduled?  I think there are
some
> good ideas in the aggsrv proposal, but I do not think that that work or
this
> example will cause confusion.  In the end, the IETF will adopt some
> mechanism for provision email servers and this small example in the WF
> document should not be a source of confusion.
>
> So, I do think the text should be there, but if you really think it might
> cause some confusion, perhaps we insert a note to make it clearer that
this
> is only an example and not the way client devices should be provisioned?
>

As stated elsewhere, I think this is very confusing, and already generating
the confusion I'm concerned about, in relation to RFC 6186 rather than
AggSrv, in fact.

I'd strongly prefer this example were removed, and replaced with something
else.

> > Major Comments:
> >
> > 1) I note that §4.4.4.1 describes a 'rel' such that it redefines and
> > repeats RFC 5988's §4; I think this should be deferred explicitly to RFC
> > 5988 in entirety, rather than specifically only for registered link
> > relation types.
> >
> > The good news is that this should simplify the text rather a lot:
> >
> > """
> > The value of the "rel" member is a string containing a link relation
> > type (see RFC 5988 [4]). Both registered and extended relation types are
> > permitted.
> >  """
>
> I do not think we can simplify the text so much.  There is an explicit
> limitation in the WebFinger draft that a "rel" value must either be a
single
> absolute URI or a registered link relation type.  RFC 5988 allows for
> multiple values like 'rel="shortcut icon"', but WebFinger does not.  RFC
> 5988 also allows URIs with fragments, but WebFinger does not.  Valid URIs
> must conform to Section 4.3 of RFC 3986 (Absolute URIs).  These decisions
> were intended to avoid ambiguity.

Link relation types are a single one of those values, the <relation-type>
ABNF production, as opposed to the rel, which contains a <relation-types>.
I'm entirely with you on why you want to restrict your rel to a single link
relation type. Worth calling it out the difference, but it's not a
deviation from RFC 5988.

However, if you're changing the definition of link relation types, then:

a) I'm deeply concerned. Redefining a standards-track specification seems
worryingly close to NIH. There's horrible confusion lurking when someone
says "Link relation type" and then has to qualify which definition.

b) You need to make this absolutely clear in the document; it reads like
you're restating, not redefining.

c) The only distinction you claim above that appears to me to be an actual
distinction is that fragments are disallowed. Yet no such restriction
exists in the current draft.

> Much of the text you removed talks about the other members of the link
> relation object, which include "type", "href", "titles", and "properties".
> The value of the "rel" member dictates how the other members are
interpreted
> and so I think that text needs to remain.

Yes, I've probably trimmed too much there.

> > 2) The use of webfinger with arbitrary URIs is something I had not
> > previously realised. This raises some concerns for me, as it's not clear
> > whether this is either genuinely desirable or whether it introduces
> > considerations (security and otherwise) beyond those discussed within
> > the document.
> >
> > I would in general rather the mechanism were restricted to acct, http,
> > https, and perhaps mailto.
>
> I don't think use of one URI scheme vs. another makes any difference in
> terms of security.  However, it was definitely the desire of the group to
be
> able to use any URI scheme, including some URIs like 'tel'.  Use of 'tel'
> would mean the exact resolution mechanism would have to be defined, but
> people did not want to preclude its use.  For others that have a domain
> part, the desire is to be able to go to the server and request a JRD for
> that URI.  There may or may not be information available for a given URI,
> but the procedures for one URI or another would be exactly the same.

I did say "security and otherwise". I'm not saying that any given URI
scheme should be discounted forever more, I am suggesting the document
should limit the schemes which have a defined behaviour for now.

I have no clue what the possible impacts of using webfinger on a message id
URI might be, nor do I wish to even think about it.

I'm pretty sure that mailto has some corner cases we've not yet thought
about; it's not just an email address after all.

> > 3) There is no use of SRV here; I would prefer an SRV resolution step
> > for at least acct and mailto scheme URIs, and possibly http/https as
> > well. My concern is that a corporate webserver is typically unlikely to
> > be capable of providing webfinger services (being often externally
> > hosted), and while this could be solved by handling redirects, or by
> > reverse proxying, SRV feels like a more stable solution here.
> >
> > I'd be curious as to whether this has been discussed.
>
> This was discussed at length, yes.  We also discussed the use of the URI
> resource record type.
>
> SRV records will tell you what host to go to, but not what URI.
> URI records will tell you more precisely what URI to query.
>
> However, both mechanisms build a dependency on DNS that will not work in
web
> browsers.  One of the first uses of WebFinger (for which there are
already a
> few libraries available) is to query for information about people directly
> from JavaScript in a browser.  Thus, it was preferred to use a .well-known
> location rooted at the given host.

That sucks.

It's a shame that browsers are holding back use of SRV and other decade-old
technology for things like this.

But I accept that this has been discussed and blocked by browser brokenness.

> Here's what I propose:
>
> -----------------
> 8.3 Abuse Potential
>
> Service providers should be mindful of the potential for abuse using
> WebFinger.
>
> As one example, one might query a WebFinger server only to discover
> whether a given URI is valid or not.  With such a query, the person
> may deduce that an email identifier is valid, for example.  Such an
> approach could help spammers maintain a current list of known email
> addresses and to discover new ones.
>
> WebFinger could be used to associate a name or other personal
> information with an email address, allowing spammers to craft more
> convincing email messages.  This might be of particular value in
> phishing attempts.
> -----------------

That seems sensible.

Dave.