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

["Paul E. Jones" <[e-mail]>]

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?
 
> Also, it's a cursed subject anyway; see ACAP. :-)

Yeah, I'll give you that.  The outcome of the BoF seemed to be no clearer
than it was going in.
 
> 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.

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.
 
> 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.
 
> 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.
 
> 4) It would make §8 more readable if it were split into subsections. I
> think the first three paragraphs form a discussion about the transport
> security, the middle paragraphs discuss privacy, and the final paragraph
> discusses information reliability.

That's a good suggestion.  I'll make the changes (and adapt as I get through
other reviewers' comments).
 
> I suspect there is one more case to be concerned about, which is that it
> may be possible for an attacker to use webfinger resources to test the
> existence of a hypothetical user; that is, one might use webfinger as a
> harvesting mechanism.

Again, a valid point.  I'll insert text into a new sub-section just above
"Information Reliability" and call it "Abuse Potential".

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

Paul