Thanks for the review.
I will add these points to the security consideration section, but will keep it
as a host level document, not service level. This well-known document is
appropriate when looking for host metadata, and application choosing to use it,
must consider the implications. By itself, host-meta means very little.
Applications need to "buy-into" the document (and spell out how to use it) in
order for it to have meaning. When doing so, they must consider its
implications.
EHL
-----Original Message-----
From: Kurt Zeilenga [mailto:Kurt(_dot_)Zeilenga(_at_)Isode(_dot_)com]
Sent: Friday, July 16, 2010 7:18 AM
To: IETF
Cc: draft-hammer-hostmeta(_at_)tools(_dot_)ietf(_dot_)org; Security Area
Directorate; IESG
IESG
Subject: SECDIR review: draft-hammer-hostmeta
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors should treat these comments just like any other
last call comments.
I have a number of security-related concerns with this specification.
First, I'm concerned by assumptions in the document that each of:
http://example.com
http://example.com:8080
https://example.com
https://example.com:8443
identify resources under the control of same entity. It is fairly common to
there to be multiple http/https services running on a single host, each
service
possibly operated by different entities as delegated by the "host"
administrator. I think it would be better (from a security perspective) to
have "service"-level metadata, not "host" level meta data. That is, make no
assumption that the above URIs are under control of the same entity, or
even if so, that it desirable to a single policy/metadata covering multiple
services.
And I think it very important to always fetch the meta data from the service
one is accessing. The document calls for client to fetch
https://example.com/.well-known/host-meta even when
https://example.com:8443 is URI wants policy for.
Even worse, the document calls for the client to, if the above fetch does not
produce a "valid" hostmeta document, for the client to fetch
http://example.com/.well-known/host-meta. An attacker could easily cause
https://example.com/.well-known/host-meta to fail to produce a "valid"
hostmeta document, and serve its own hostmeta document in response to
the client's http://example.com/.well-known/host-meta, without
supplanting the https://example.com:8443 service.
The document fails to discuss such attacks.
I recommend reworking this document to provide service-level, not host-
level, metadata. In particular, the metadata document should always be
retrieved through the service the client is interested in using, such as by
fetching "/.well-known/metadata".
If the authors rather continue pursuing a "host-based" solution, the security
considerations should include a discussion of the above issues.
Regards, Kurt
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf