Re: [apps-discuss] Webfinger goals doc

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

John,

Personally, I would place a requirement in the OpenID Connect specs that
says that only TLS can be used when issuing a WF query.  This allows WF to
be used where security is important and where it's not, but ensures that
when used for OpenID Connect, security is not compromised.

Having said that, is there no visible means for the user to know with
absolute certainty when using OpenID Connect that he is interacting with his
Provider?  With OpenID 2.0, for example, I only enter my credentials in a
page that I know is my Provider and I know for certain that it is, since the
Provider page opens in a browser window that is secured with TLS.  I can
visually inspect that it's right.

Assuming OpenID Connect does the same, then even if the URL is modified in
flight, the user could see it's the wrong destination when they get there.

(Sorry for being ignorant.  I've still not read through the OpenID Connect
specs to understand how it works.  OpenID was fairly trivial to implement; I
did the Provider server implementation in an afternoon.  I was moderately
stunned by the number of documents related to OpenID Connect... so I read
none.)

Paul

> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of John Bradley
> Sent: Wednesday, November 28, 2012 8:50 AM
> To: [e-mail]
> Cc: [e-mail] Discuss
> Subject: Re: [apps-discuss] Webfinger goals doc
> 
> I agree that TLS will be hard to impossible for many people off their
> main domain.  That was one of the reasons for having a subdomain so that
> you could delegate it via DNS to a server that can support it.
> 
> That idea seems to be dead however.
> 
> The question is if publishing a WF document that can't safely support a
> number of protocols is:
> a) worth it.
> b) may encourage many RP to ignore the TLS requirement for some
> protocols and create unmanageable security issues.
> 
> Letting clients do the wrong thing is hard to put back in the box from
> experience.
> 
> The safest thing is to only allow the WF service over TLS.
> 
> I know that in opposition to the social linking use case.  That is one
> of the problems of trying to solve two similar but not the same problems
> with one solution.
> 
> This is an important issue and we should close on it one way or the
> other.   I hate having to have clients try https and fall back to http
> for some relations.   I see it going very wrong sometimes.
> 
> John B.
> 
> 
> 
> On 2012-11-28, at 5:41 AM, Joseph Anthony Pasquale Holsten
> <[e-mail]> wrote:
> 
> > Big folks will have no problem. Privileged folks with vanity domains
> like myself will get over it.
> >
> > The main use case it screws up is delegation, since you can't
> bootstrap from a cheap domain.
> >
> > On 2012-11-28, at 00:34 , "Paul E. Jones" <[e-mail]>
> wrote:
> >
> >> Dick,
> >>
> >> Here's my list of reasons why we should not mandate HTTPS:
> >> 1) TLS certificates are difficult to deploy by many
> >> 2) Many hosting providers do not support TLS because they do not
> >> support the relatively new SNI extensions for TLS (even my own server
> >> did not support SNI until recently and some deployed browsers still
> >> do not)
> >> 3) TLS certificates cost more money than the domain name.  This is a
> serious issue for many, especially in developing countries.  Few people
> support DNSSEC and RFC 6698.  If the world supported DNSSEC and people
> could create self-signed certificates, TLS could be widely embraced by
> everyone, I suspect.
> >> 4) If everything I'm sharing via WF is accessible via HTTP, what's
> the point of protecting the WF query with HTTPS?  It definitely makes
> sense for OpenID or other sensitive services, but not for more "public"
> applications like "where's Paul's blog" and "where's Paul's avatar"?
> >>
> >> Are there encryption restrictions in some countries that make TLS
> illegal?  If so, we could add that as reason #5.
> >>
> >> All that said, I don't care if it was mandated, but I just don't see
> the reason for it in some instances and I am concerned that it will
> limit deployment of the service.
> >>
> >> If we could get the world to implement DNSSEC and RFC 6698. problems
> solved.  By the time that is done, SNI issues will be long gone, too.
> >>
> >> Paul
> >>
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Dick Hardt
> >> Sent: Wednesday, November 28, 2012 12:04 AM
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> Subject: Re: [apps-discuss] Webfinger goals doc
> >>
> >> Let's be brave and say HTTPS-only.
> >>
> >> Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth 1.0
> >> (yes, a little apples and oranges comparison, but there was a similar
> >> requirement conversation that had the same goal of pushing complexity
> >> to the server from the client -- it also simplifies the security
> >> model)
> >>
> >> -- Dick
> >>
> >> On Nov 27, 2012, at 6:17 PM, Brad Fitzpatrick <[e-mail]>
> wrote:
> >>
> >>
> >> I just had a chat with Blaine after his recent "I'm out!" email.  I
> don't think he's actually out--- he's been working on WebFinger for as
> long as I have and cares a lot about it.  I think he was just grumpy
> about the process, speed, and confused about goals and decisions.
> >>
> >> Anyway, we had a very productive conversation on chat and wrote a doc
> together to clarify thought processes and decisions:
> >>
> >> https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7
> >> XcY99pjQWs/edit#
> >>
> >> The doc is open for comments.  I'll try to keep the doc edited and
> neutral.  It outlines requirements (aka goals for webfinger),
> assumptions, and decisions with pros & cons for each and what decision
> was ultimately made and why.
> >>
> >> The decisions are I'm sure subject to change, but hopefully not too
> much.
> >>
> >> Let me know what I missed.
> >>
> >> My apologies if you don't like the document's medium or fluidity, but
> it's the tool I have to work with, and better than nothing.  If you
> object to the fluidity and want something concrete to reply to in email,
> I've snapshotted the document to http://goo.gl/fTMC1 but I won't accept
> comments or make changes there.  Use whatever mechanism you prefer.
> >>
> >> - Brad
> >>
> >>
> >> Copy of doc for posterity:
> >>
> >> WebFinger Goals, Assumptions, and Decisions (SNAPSHOT1)
> >>
> >> aka background reading on understanding the WebFinger spec
> >>
> >> Requirements
> >>
> >>
> >> 	. given just a string that looks like "[e-mail]", find a
> machine-readable metadata document.
> >> 		. background: since the death of the "finger" protocol (from
> which webfinger gets its name), email-looking identifiers like
> "[e-mail]" have been write-only: you can email it (maybe, if it
> speaks SMTP), but you can't do any read/discovery operations on it.  You
> can't find its supported or preferred protocols, its name, its avatar,
> its public key, its identity/social/blog server, etc.
> >> 		. the format of the identifier matters because people
> ("regular users") effortlessly identify with their email addresses, and
> already use them for sharing outside (and inside) of social networks
> >> 			. corollary: WebFinger is not about doing discovery
on
> URLs or URIs or IRIs or XRIs or any other "dorky" identifier.  Webfinger
> is about doing a discovery (read) operation on something a non-technical
> user would write on a napkin or give you on a business card.
> >> 	. clients can be implemented in browsers in JavaScript
> >> 		. corollary: CORS shout-out in spec
> >> 		. corollary: no DNS component
> >> 	. delegation to webfinger-as-a-service by larger providers from
> self-hosted or organisational domains is possible (cf. DNS NS records)
> >> 	. latency of updates must be low (unlike DNS)
> >> 	. no service provider (no company) is special-cased.
> >> Assumptions
> >>
> >>
> >> 	. the string "[e-mail]" is NOT necessarily an email address,
> even though most people today associate it with an email address.
> >> 		. corollary: the "acct:" URI scheme and draft-ietf-appsawg-
> acct-uri-01 etc
> >> 	. complexity in specs leads to few and/or poor implementations and
> ultimately hinders adoption
> >> 		. corollary: value simplicity wherever possible, even if it
> means some things are harder or not possible for some parties.
> >> 		. i.e. we'd rather have a 3 page spec that makes 90% of
> people happy rather than a 30 page spec that makes 95% of people happy,
> especially if such a smaller spec means a much improved chance of
> adoption.
> >> 	. obvious, but: optional parts in specs need to be optional for
> only one party (client or server) and required for the other.
> >> 		. i.e. there needs to always be an intersection of features
> in the spec that both parties support.  e.g. can't have both clients and
> servers decide to only speak
> >> 	. there will be more clients than servers
> >> 		. corollary: it should be easier to write/run a client than
> a server
> >> 	. few users own their own domain name and will run their own
> identity server
> >> 		. . and those that do own their own domain name will mostly
> want to delegate management of their webfinger profiles or will know
> what they're doing and therefore don't need to be catered to.
> >> 		. further assumption: most will be running Wordpress or some
> such software already.
> >> 		. corollary: we don't have to cater to this small audience
> much.. they'll know what they're doing, or their hosting software will.
> >> 	. should be easy to do both client and server. Ideal solution
> balances both (delegation for simpler servers)?
> >> 	. standards MUST be programmer-friendly Decisions
> >>
> >>
> >> 	. HTTP vs DNS
> >> 		. DNS (SRV, TXT, etc) precludes JavaScript clients (as of
> 2006-2012), so rejected. HTTP instead.
> >> 	. JSON vs XML
> >> 		. Per assumption above, we needed to pick at least one as
> required.  We chose JSON.  If both parties advertise (via HTTP headers)
> that they prefer XML, that's fine.  JSON is easier for JavaScript
> clients, as one advantage.  It's also simpler to read on the page (per
> the complexity argument).  But both are small arguments and not worth
> arguing about.  At the end of the day a decision had to be made, and it
> was.
> >> 	. HTTP-ish (Accept / Link headers, etc) vs well-known path
> >>
> >> 		. HTTP-ish is more proper, but viewed as too hard for
> servers to route (routing on headers, rather than request paths) and
> more importantly too hard for clients to send (setting headers).
> >> 		. well-known URLs (like /favicon.ico) are gross, though.
> >> 		. Decision: use a well-known URL.
> >> 		. We defined RFC 5785 first instead, to make using a well-
> known path less offensive.
> >> 	. One HTTP request vs two.
> >> 		. Two requests: clients first fetch /.well-known/host-meta
> (to find where to do a webfinger query), then fetch that.
> >> 			. PRO: the host-meta document can be a static file,
> which makes delegation to other webfinger service providers easier for
> custom domains.
> >> 			. CON: twice the latency, especially for mobile
> >> 			. CON: extra client complexity
> >> 		. One request: clients just do a query immediately to
> /.well-known/webfinger, without consulting host-meta.
> >> 			. PRO: half the latency
> >> 			. PRO: less client complexity
> >> 			. CON: service providers may need to reverse-proxy
the
> query to the right backend.
> >> 			. CON: harder for small domain names with static
> webservers to delegate.
> >> 		. Decision: Just one HTTP requests, because we care more
> about client simplicity than server simplicity.
> >> 	. HTTPS-only vs HTTPS-recommended
> >> 		. HTTPS-only:
> >> 			. PRO: secure
> >> 			. PRO: simpler for clients (one round-trip)
> >> 			. CON: hard for some servers to setup (config,
certs,
> etc)
> >> 		. HTTPS-recommended:
> >> 			. CON: added client complexity.  But at least good
> clients can opportunistically fetch both in parallel and only use HTTP
> if they're feeling trusting, once they see the HTTPS one fails. If HTTPS
> succeeds, no added latency.
> >> 			. PRO: easier
> >> 		. Decision: HTTPS-recommended.  Clients may choose to only
> do HTTPS, as can servers, which means in practice almost all servers
> will probably only be HTTPS.
> >> 		. Debate: this seems inconsistent with our policy of caring
> about clients and simplicity more than servers.  And it seems like a
> failure to decide, since we say both are optional for either party,
> counter to the assumption above that specs need requirements for either
> client or server.
> >> 		.
> >>
> >
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss