Subject: draft-hammer-hostmeta-08: HTTPS requirement

From: Christian Schmidt <[email-masked]>
Date: Fri, 14 May 2010 21:45:11 +0200

Hi,

I'm new to this list. I recently became aware of the host-meta draft 
while studying Google's description of OpenID discovery 
<http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery>. 
I have a few comments on draft-hammer-hostmeta-08, section 4.

>    Clients obtain the host-meta document for a given host by making an
>    HTTPS [RFC2818] GET request to the host's port 443 for the
>    "/.well-known/host-meta" path.  If the request fails to produce a
>    valid host-meta document, clients make an HTTP [RFC2616] GET request
>    to the host's port 80 for the "/.well-known/host-meta" path.
In brief: Try fetching the host-meta file via HTTPS. If that fails, fall 
back to HTTP. I don't understand this requirement.

The usual reason for preferring HTTPS over HTTP is the need for secrecy 
(using encryption) and/or identification of the server (using 
certificates signed by a trusted authority). AFAICT the host-meta is 
intended to published to everybody without any access control, so 
secrecy is not an issue. If identification of the server is considered 
important to the client, it should only accept a host-meta document 
fetched via HTTPS. If an adversary is able to make a man-in-the-middle 
attack against a HTTP connection, he would usually also be able to 
prevent a HTTPS connection from being made to the same host, so AFAICT 
HTTPS doesn't offer any additional security if the client may just fall 
back to HTTP. It's like a border patrol officer asking to see a 
traveler's passport, but if the traveler refuses to show a passport or 
shows one that has been tampered with, the officer just lets him pass 
anyway.

If the client finds it acceptable to fetch the host-meta document via 
HTTP, it would seem easier and just a secure to simply try HTTP first 
and then possibly fall back to HTTPS. Or did I miss something?

>    If a representation is successfully obtained, but is not in the
>    format described above, clients should infer that the path is being
>    used for other purposes, and not process the response as a host-meta
>    document.
There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to 
mean "SHOULD", or is the client encouraged to be fault-tolerant against 
invalid or non-wellformed XML?

>    To aid in this process, authorities using this mechanism
>    SHOULD correctly label host-meta responses with the
>    "application/xrd+xml" internet media type.
It is now explained how that aids in inferring that a path is used for 
other purposes than a host-meta document. What is a client expected to 
do, if the Content-Type is not application/xrd+xml, or if the 
Content-Type *is* application/xrd+xml, but the host-meta document itself 
is not in the described format?

>    If the server response indicates that the host-meta resource is
>    located elsewhere (a 301, 302, or 307 response status code), the
>    client SHOULD try to obtain the resource from the location provided
>    in the response.  This means that the host-meta document for one host
>    MAY be retrieved from a another host.
There seems to be a conflict between "SHOULD" and "MAY". "MAY" indicates 
that following a cross-host redirect is completely optional, but I 
assume this is not intended. The last sentence seems to be a 
clarification rather than a normative statement, so perhaps "MAY" should 
be replaced with just "may"?

Christian

---

From: Christian Schmidt <[email-masked]>
Date: Sat, 15 May 2010 00:27:25 +0200

> and then possibly fall back to HTTPS. Or did I miss something?
s/just a secure/just as secure/

> It is now explained how that aids in inferring that a path is used for
s/now/not/

> be replaced with just "may"?
s/normative statement/separate requirement/

Christian

---

From: John Panzer <[email-masked]>
Date: Fri, 14 May 2010 16:44:23 -0700

On Fri, May 14, 2010 at 12:45 PM, Christian Schmidt <[email-masked]>wrote:

> Hi,
>
> I'm new to this list. I recently became aware of the host-meta draft while
> studying Google's description of OpenID discovery <
> http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery>. I
> have a few comments on draft-hammer-hostmeta-08, section 4.
>
> (using encryption) and/or identification of the server (using certificates
> signed by a trusted authority). AFAICT the host-meta is intended to
> published to everybody without any access control, so secrecy is not an
> issue. If identification of the server is considered important to the
> client, it should only accept a host-meta document fetched via HTTPS.

There are two ways to identify documents:  Make sure every hop in the
retrieval path used TLS, with appropriate server certificate vetting
(checking CRLs, etc); or, if it is a signed XRD, implement XML-DSig
verification (with appropriate certificate vetting etc.)

If a library retrieves via http first, it presumably won't try https, so if
the document has no signature the client is out of luck, even though it may
well be verifiable if retrieved with TLS.  If on the other hand you try TLS
first, and that fails, you know there was no TLS available and the only
recourse is to check document signatures.

> If an adversary is able to make a man-in-the-middle attack against a HTTP
> connection, he would usually also be able to prevent a HTTPS connection from
> being made to the same host, so AFAICT HTTPS doesn't offer any additional
> security if the client may just fall back to HTTP. It's like a border patrol
> officer asking to see a traveler's passport, but if the traveler refuses to
> show a passport or shows one that has been tampered with, the officer just
> lets him pass anyway.
>

You'd either fail (because you don't know how to do XML-DSig) or you'd fail
(because the MITM modified the DSig protected content too) or you'd succeed
(because the MITM realized he can't modify DSig protected content).  I think
the only possibilities are total failure -- same as if the MITM blocked your
access, which of course they can do no matter what -- and secure success.

>
> If the client finds it acceptable to fetch the host-meta document via HTTP,
> it would seem easier and just a secure to simply try HTTP first and then
> possibly fall back to HTTPS. Or did I miss something?
>
>
> There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to mean
> "SHOULD", or is the client encouraged to be fault-tolerant against invalid
> or non-wellformed XML?
>
>
> other purposes than a host-meta document. What is a client expected to do,
> if the Content-Type is not application/xrd+xml, or if the Content-Type *is*
> application/xrd+xml, but the host-meta document itself is not in the
> described format?
>
>
> that following a cross-host redirect is completely optional, but I assume
> this is not intended. The last sentence seems to be a clarification rather
> than a normative statement, so perhaps "MAY" should be replaced with just
> "may"?
>
>
> Christian
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: John Panzer <[email-masked]>
Date: Fri, 14 May 2010 16:45:04 -0700

s/identify documents/verify documents/ in my prior email.  Thanks.

On Fri, May 14, 2010 at 4:44 PM, John Panzer <[email-masked]> wrote:

>> HTTP, it would seem easier and just a secure to simply try HTTP first and
>> then possibly fall back to HTTPS. Or did I miss something?
>>
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 May 2010 14:03:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Christian Schmidt
> Sent: Friday, May 14, 2010 12:45 PM

> In brief: Try fetching the host-meta file via HTTPS. If that fails, fall back to
> HTTP. I don't understand this requirement.
> 
> issue. If identification of the server is considered important to the client, it
> should only accept a host-meta document fetched via HTTPS. If an adversary
> is able to make a man-in-the-middle attack against a HTTP connection, he
> would usually also be able to prevent a HTTPS connection from being made
> to the same host, so AFAICT HTTPS doesn't offer any additional security if the
> client may just fall back to HTTP. It's like a border patrol officer asking to see a
> traveler's passport, but if the traveler refuses to show a passport or shows
> one that has been tampered with, the officer just lets him pass anyway.

It is only used for server identification. Falling back to HTTP is a matter of protocol policy. It depends on what you use the document for. Also, there might be other ways to identify the server (such as signed documents over HTTP). The security consideration section includes this:

"Protocols MAY restrict document retrieval to HTTPS based on their security needs."

If you think it is not enough, please suggest text.

> If the client finds it acceptable to fetch the host-meta document via HTTP, it
> would seem easier and just a secure to simply try HTTP first and then possibly
> fall back to HTTPS. Or did I miss something?

The two options are not to specify an order to preference, leaving it up to each protocol to decide, or specify an order in which case HTTPS should come first.

> invalid or non-wellformed XML?

Changed to MUST NOT use invalid documents.
 
> It is now explained how that aids in inferring that a path is used for other
> purposes than a host-meta document. What is a client expected to do, if the
> Content-Type is not application/xrd+xml, or if the Content-Type *is*

What matters is that the document is a valid XRD document obtained from that location. This is just a suggestion to make things easier to spot faster. If the media type is different, it is up to the client to decide what to do (for example, it might be another extension format the client understands and knows how to convert into XRD). I think this is fine as is with the above change.

> There seems to be a conflict between "SHOULD" and "MAY". "MAY"
> indicates that following a cross-host redirect is completely optional, but I
> assume this is not intended. The last sentence seems to be a clarification
> rather than a normative statement, so perhaps "MAY" should be replaced
> with just "may"?

First, if the host-meta response redirects elsewhere, the client SHOULD follow it. It is a SHOULD because there are security issues with crossing authority lines. Server are allowed to do this, which is what the MAY is about.

EHL