Listed below are the relevant excerpts from the IAB RFC 3238 on OPES
considerations on the subject of encryption. I'd like to solicit
comments on these topics. I think it would help to begin with a
simple security model.
Encryption, for this discussion, is a mechanism for protecting
the privacy of material on an open communication channel. In order
to discuss privacy for OPES-handled content, we need to understand
the parties who have a stake in the privacy. If the privacy is
between the content publisher and the end-user, and both parties
believe they have a stake in that privacy, then neither should delegate
their rights, and they should use an end-to-end authentication and
encryption protocol that prevents any intermediary from seeing
the content. OPES is "compatible" with that notion of end-to-end
encryption in the sense that it does not prevent such usage.
I'd like to call the end-user and the publisher the primary parties
for the trust model. The publisher may not actually be in the
end-to-end path, and I think there are cases where the end-user
isn't there either, at least immediately, but eventually there either
will be an end user involved in the protocol or else the content is
irrelevant for our purposes here.
The trust becomes more complicated if the parties can delegate
their rights. I think that the IAB considerations are assuming
that the initial parties can delegate some aspects of their
data privacy to third parties, as in the case of a publisher delegating
privacy to a content delivery service, but it also considers further
delegation of privacy along the delivery path. The mechanism for
this is "hop-by-hop" or "link" encryption. I believe that RFC3238
means to say that link encryption is "compatible" with end-to-end
encryption if all IP-address-terminated links use encryption
and there is a well-founded delegation path for each link. This
introduces the intermediaries as new parties to the security model.
These intermediaries may be trusted for some functions, but not
others. True end-to-end encryption should be used by the primary
parties for data for which intermediaries are not trusted; some
intermediaries may impose this themselves.
We may want to extend the notion above to encompass callout
servers, but I'm not sure.
A topic for discussion, I believe, is whether or not "transparent"
delegation is allowed, and if not, how fine-grained should the
delegation policy be, i.e., should each primary party be aware of all
delegations, should one party be aware, should each party require
explicit approval for all delegations, etc.
Should the OPES callout servers be visible parts of the delegation
mechanism?
In the consideration 2.2 below, it appears to me that that the only
OPES intermediaries permitted would be one "hop" away from the end-user,
effectively preventing any publisher-authorized intermediaries.
Further, while this language would seem to preclude chained
intermediaries, later language specfically overrides this notion,
apparently allowing trusted chains of intermediaries, possibly without
explicit trust relationships (?).
I would like to solicit help on interpreting the sentence below about
services requiring data in the clear.
=== excerpts from RFC 3238 ==========
... the OPES working group will also have to
explicitly decide and document whether the OPES architecture must be
compatible with the use of end-to-end encryption by one or more ends
of an OPES-involved session. If OPES was compatible with end-to-end
encryption, this would effectively ensure that OPES boxes would be
restricted to ones that are known, trusted, explicitly addressed at
the IP layer, and authorized (by the provision of decryption keys) by
at least one of the ends. Compatibility with end-to-end encryption
would also help to prevent the widespread deployment of yet another
set of services that, to benefit from, require one to keep one's
packet contents in the clear for all to snoop.
(2.1) One-party consent: An OPES framework standardized in the IETF
must require that the use of any OPES service be explicitly
authorized by one of the application-layer end-hosts (that is, either
the content provider or the client).
(2.2) IP-layer communications: For an OPES framework standardized in
the IETF, the OPES intermediary must be explicitly addressed at the
IP layer by the end user.