Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core]

I think that the proposed amplification will become an IESG target
that will hold up the document.

What requirement is being satisfied by introducing a discussion of
encryption negotiation?  I'd much prefer to simply say that if you
require confidentiality you must be using a secure transport before
beginning any OCP negotiations.

I think that what the document is trying to say is that if there's
some support for encryption in the underlying protocol, then OCP has
support for turning it on, however meaningless it may be.  But what
about authentication, what about integrity?  I think there must be
some discussion of integrity and authentication in the main body, and
there must be more explication in security considerations.
Particularly, having opened this can of worms, the document should at
least note that a thorough analysis of security is needed for any
particular OCP mapping.

How do these HTTP CONNECT transactions determine a key to use for
their encryption, how do they represent encrypted data?

Unless there is a prior basis for authentication and integrity, it
doesn't make sense to start encrypting and then establish
authentication.

etc.

Hilarie