Security Threats and Risks for Open Pluggable Edge Services (OPES)
draft-ietf-opes-threats-03

The problem is the references in the document to doing hop-by-hop
encryption instead of end-to-end.  That's reasonable enough, since opes
can't peek through encryption.  But how does the user request such a
thing, or how do you trick the browser into believing it?

A bad way -- a very bad way -- would be to have fake certificates
issued by some CA the browser probably trusts.  It might be possible to
do it -- in some cases -- by (consensually) rewriting the page that
points to the https:// content (assuming, of course, that the user
doesn't get the URL from somewhere else).  This rewriting isn't a great
solution, but it might be acceptable.  Of course, it does carry the
risk of confusing any user who looked at the status bar to see what URL
was next, or who looked at the URL of the nominally-secure page and
found some opes server's name.  Nevertheless, it's a scheme that can be
deployed without changes to browsers.

Ned quite correctly pointed out that this is an analysis document, not
a requirements or protocol document (though it does use SHOULD and MUST
in a few spots -- you may want to change that).  I do think that some
discussion of my concerns is warranted, if only to rule out fake
certificates -- that's a path we MUST NOT (to borrow from 2119) go down.