Subject: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 17:15:19 -0800

Change paragraph 2 of section 5.1 to read:

WebFinger client software MUST accept as input a boolean parameter which
for the purposes of this discussion will be referred as "allow-fallback".
If this parameter is not provided, client software MUST behave as if it
were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfinger
using the HTTPS protocol.  If an HTTPS connection is made, and the server
has an invalid certificate, or returns an HTTP status code indicating an
error, the client software MUST report an error and cease attempting to
retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection
to the server, behavior depends on the value of the
allow-fallbackparameter.  If the value of allow-
fallback is true, the client software MAY fall back to unencrypted HTTP in
an attempt to retrieve /.well-known/webfinger.  If allow-fallback is false,
client software MUST report an error and cease attempting to retrieve the
resource.

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>wrote:

> Folks,****
>
> ** **
>
> I published another version of the WebFinger spec trying to bring closure
> to the two open issues I see (resource representation and transport).  The
> new version is here:****
>
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07****
>
> ** **
>
> With respect to resource representation, I fully described the JSON
> Resource Descriptor within the document.  There are no external references
> to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly
> simple format and I believe this text documents it sufficiently.  Combined
> with the visual examples, I think this makes it pretty clear.  Have a look
> at the JRD documentation in section 5.2 and provide your comments. ****
>
> ** **
>
> With respect to HTTPS, it seems there is strong preference for “HTTPS
> only”, but some a fair bit of insistence for allowing HTTP.  I changed the
> wording in 5.2 to try to capture opinions.  Previously, the text led with a
> requirement to try HTTPS first.  That is still there.  I just added some
> extra conditions that make it clearer that there are some instances where a
> client must not utilize HTTP.  This might need further refinement, but I
> think there is a balance we can strike here between the two camps without
> introducing a lot of complex language.****
>
> ** **
>
> I made some editorial changes through the document.****
>
> ** **
>
> Comments are welcome, as always.  Seems I don’t need to say that to this
> group, though :-)****
>
> ** **
>
> Paul****
>
> ** **
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 02:19:21 -0500

Where are you suggesting this be placed exactly?  Should we have a separate
client or library behavior section?

From: Tim Bray [mailto:[email-masked]] 
Sent: Sunday, December 02, 2012 8:15 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Draft -07 mod proposal: HTTPS with fallback parameter

WebFinger client software MUST accept as input a boolean parameter which for
the purposes of this discussion will be referred as "allow-fallback".  If
this parameter is not provided, client software MUST behave as if it were
present with a value of false.

If the WebFinger client software is unable to establish an HTTPS connection
to the server, behavior depends on the value of the allow-fallback
parameter.  If the value of allow-fallback is true, the client software MAY
fall back to unencrypted HTTP in an attempt to retrieve
/.well-known/webfinger.  If allow-fallback is false, client software MUST
report an error and cease attempting to retrieve the resource.

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>
wrote:

Folks,

I published another version of the WebFinger spec trying to bring closure to
the two open issues I see (resource representation and transport).  The new
version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

With respect to resource representation, I fully described the JSON Resource
Descriptor within the document.  There are no external references to RFC
6415 now, no need to go read the XRD spec, etc.  It's a fairly simple format
and I believe this text documents it sufficiently.  Combined with the visual
examples, I think this makes it pretty clear.  Have a look at the JRD
documentation in section 5.2 and provide your comments. 

With respect to HTTPS, it seems there is strong preference for "HTTPS only",
but some a fair bit of insistence for allowing HTTP.  I changed the wording
in 5.2 to try to capture opinions.  Previously, the text led with a
requirement to try HTTPS first.  That is still there.  I just added some
extra conditions that make it clearer that there are some instances where a
client must not utilize HTTP.  This might need further refinement, but I
think there is a balance we can strike here between the two camps without
introducing a lot of complex language.

I made some editorial changes through the document.

Comments are welcome, as always.  Seems I don't need to say that to this
group, though :-)

Paul

---

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 23:44:51 -0800

Discretion of the editor. Assuming people are OK with the language. -T

On Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jones <[email-masked]>wrote:

> Where are you suggesting this be placed exactly?  Should we have a
> separate client or library behavior section?****
>
> ** **
>
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Sunday, December 02, 2012 8:15 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Draft -07 mod proposal: HTTPS with fallback parameter****
>
> ** **
>
> If the WebFinger client software is unable to establish an HTTPS
> connection to the server, behavior depends on the value of the
> allow-fallback parameter.  If the value of allow-fallback is true, the
> client software MAY fall back to unencrypted HTTP in an attempt to retrieve
> ****
> wrote:****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 03:25:31 -0500

I think we can write this without introducing the word "fallback".  I'll
just insert the text and figure out how to work it into that section, etc.
But, we still need to settle on the HTTPS vs HTTP issue in general first.

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 2:45 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: Draft -07 mod proposal: HTTPS with fallback parameter

On Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jones <[email-masked]>
wrote:

Folks,

Paul

---

From: Matthias Pfefferle <[email-masked]>
Date: Mon, 3 Dec 2012 00:32:39 -0800 (PST)

Is it important to talk about "fallbacks"? Wouldn't it be enough to define 
"MUST USE" HTTP for "harmless" queries like OExchange, E-Mail to Profile 
mapping or OStatus, and "MUST USE" HTTPS for OpenID Connect or OAuth?

Am Montag, 3. Dezember 2012 02:15:19 UTC+1 schrieb Tim Bray:
> connection to the server, behavior depends on the value of the allow-
> fallback parameter.  If the value of allow-fallback is true, the client 
> software MAY fall back to unencrypted HTTP in an attempt to retrieve 
> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]<javascript:>
> > wrote:
>
>> Folks,****
>>
>> ** **
>>
>> [email-masked] <javascript:>

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 3 Dec 2012 17:59:49 +0100

I agree there are clear use cases for both. However it may be difficult to state exhaustively which case would fit with http, and which not, so I’d recommend staying generic and not mention specific examples.
https should be considered as a should, but there are very valid use cases for which it is not needed.
Yet in other cases as I stated earlier, https cannot work at first: in most mobile network identification systems, the user identity (phone number) can only be recognized over plain http. This often requires to issue a first http request (sort of probe) to get the server set a cookie, a only then send the https request to the same endpoint with the previous cookie for associating them.

Da: [email-masked] [mailto:[email-masked]] Per conto di Matthias Pfefferle
Inviato: lunedì 3 dicembre 2012 9.33
A: [email-masked]
Cc: [email-masked]
Oggetto: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter

Is it important to talk about "fallbacks"? Wouldn't it be enough to define "MUST USE" HTTP for "harmless" queries like OExchange, E-Mail to Profile mapping or OStatus, and "MUST USE" HTTPS for OpenID Connect or OAuth?

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".  If this parameter is not provided, client software MUST behave as if it were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.  If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.  If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]<javascript:>> wrote:
Folks,

I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport).  The new version is here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

With respect to resource representation, I fully described the JSON Resource Descriptor within the document.  There are no external references to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly simple format and I believe this text documents it sufficiently.  Combined with the visual examples, I think this makes it pretty clear.  Have a look at the JRD documentation in section 5.2 and provide your comments.

With respect to HTTPS, it seems there is strong preference for “HTTPS only”, but some a fair bit of insistence for allowing HTTP.  I changed the wording in 5.2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS first.  That is still there.  I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP.  This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language.

Comments are welcome, as always.  Seems I don’t need to say that to this group, though :-)

Paul

_______________________________________________
apps-discuss mailing list
[email-masked]<javascript:>
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 11:03:38 -0600

I'd rather say that the user of WF (an app, or a user through a
user-agent) MUST decide whether it needs TLS.

Having a fallback creates problems: we must then say that the user of
WF must find out whether TLS was used and decide whether to continue
or change how it handles the result.  It seems easier to say that the
user/app must know a priori whether it needs TLS.

Nico
--

---

From: John Panzer <[email-masked]>
Date: Mon, 3 Dec 2012 09:29:16 -0800

I dislike the assumption that contact information is "harmless if hacked".

One attack scenario:  Imagine I can poison the DNS of a small company.  I
ask for a password reset for Tim Bray, but tell them my email is down.  I
return my own telephone number and IM contact info instead of Tim's via
Webfinger.  Support personnel call me on "Tim's" number and I verify I'm
him.  I gain control of his account, use that to bootstrap to gain
information about other accounts... etc.

It's less likely than an interception attack at an internet cafe.  I don't
feel competent to say how much less likely.
 On Dec 3, 2012 8:39 AM, "Matthias Pfefferle" <[email-masked]>
wrote:

>> /.well-known/webfinger.  If allow-fallback is false, client software
>> MUST report an error and cease attempting to retrieve the resource.
>>
>>
>>
>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>wrote:
>>
>>> Folks,****
>>>
>>> ** **
>>>
>>> I published another version of the WebFinger spec trying to bring
>>> closure to the two open issues I see (resource representation and
>>> transport).  The new version is here:****
>>>
>>> http://tools.ietf.org/html/**draft-ietf-appsawg-webfinger-**07<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07>
>>> ****
>>>
>>> ** **
>>>
>>> ______________________________**_________________
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>>
>>>
>>

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 11:37:30 -0600

> I dislike the assumption that contact information is "harmless if hacked".

Indeed.  That doesn't mean that WF is useless w/o TLS.

> information about other accounts... etc.

Support personnel are a type of user/app that must use TLS for
fetching any resources involved in authenticating a customer.

> feel competent to say how much less likely.

I'd say it's more likely, not less.

Nico
--

---

From: John Panzer <[email-masked]>
Date: Wed, 5 Dec 2012 13:43:27 -0800

On Wed, Dec 5, 2012 at 1:35 PM, Nick Jennings <[email-masked]> wrote:

> On Mon, Dec 3, 2012 at 6:29 PM, John Panzer <[email-masked]> wrote:
> I think that, in this case, the security hole is the fact that the the
> "company" uses public WF records as their customer contact database,
> and use it as part of their security procedure... However if they were
> to decide this is how they wanted to run their infrastructure, they
> could simply make the calls to Tim's WF using HTTPS.
>

As long as their Webfinger client gives them that option, and that they are
aware of the option.  If it does HTTPS with HTTP fallback they would not
have that choice, and if they aren't aware of the option they wouldn't know
they had the choice.

(The most secure option is to mandate HTTPS only by default on clients but
they may be configured to explicitly use HTTP.  I don't know how a protocol
would spec that.)

> -Nick

---

From: Nick Jennings <[email-masked]>
Date: Wed, 5 Dec 2012 22:35:35 +0100

-Nick