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

On Tue, 4 May 2004, The Purple Streak, Hilarie Orman wrote:

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

What do you mean by "proposed amplification"?

We already know the two "IESG targets", which the current revision is
trying to address. Unless Bill Fenner ads more DISCUSS items, we know
what we need to address.
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1201&filename=draft-ietf-opes-ocp-core

> What requirement is being satisfied by introducing a discussion of
> encryption negotiation?

The negotiation example is desirable to illustrate that OCP Core has
adequate mechanisms to negotiate transport encryption. Note that we
are not introducing anything new at this point; the example was always
there! In his insightful IESG review comment, Steve Bellovin
specifically asked to clarify how OCP Core mechanisms are used in the
example context. He correctly identified lack of documentation for
when exactly the negotiated encryption (or any negotiated feature!) is
enabled. The current revision of the draft attempts to address Steve's
comments.

Please see the URL above for the actual DISCUSS comment.

> I'd much prefer to simply say that if you require confidentiality
> you must be using a secure transport before beginning any OCP
> negotiations.

To be practical and compliant with IAB considerations, OCP has to
provide a native mechanism for enabling encryption. HTTP has it. BEEP
has it. Out-of-band encryption is possible, but if OCP cannot natively
negotiate encryption it is simply incomplete as a communication
protocol for two OPES agents. If anything, _that_ would cause IESG
objections.

However, OCP Core itself does not document encryption or
authentication features. We have already discussed that such features
should probably be documented, after we recharter.

At any rate, we are past the point of WG Last Call for this draft. We
are _not_ adding anything new or removing anything old here. We are
simply addressing Steve Bellovin's comments by detailing existing
requirements and polishing the existing example.

> 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.

Kind of. OCP Core says that if two agents agree on transport
encryption, they know exactly when to turn it on. Just like with HTTP
CONNECT and UPGRADE methods or BEEP encryption negotiation.

> 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.

OCP Core does not define encryption or authentication mechanisms. It
does have a few simple integrity checks that are discussed. Thorough
coverage of all security-related aspects should be done in separate
drafts as it will depend on specific
encryption/authentication/integrity mechanisms being documented.

> 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.

A thorough analysis of security is needed for any standards track
specification, including OCP mappings.

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

Depends on the encryption algorithm, which is totally out of HTTP
CONNECT scope. HTTP CONNECT is simply a way to establish a [possibly
secure] tunnel through a proxy. HTTP and BEEP have other means of
negotiating encryption and authentication, including means for
negotiating encryption parameters. However, details are usually kept
outside of HTTP or BEEP core as they are specific to each feature
being negotiated.

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

Integrity checks are often embedded into encryption schemes.
Authentication over vulnerable (insecure) transport does not sound
useful to me, but I am not a security expert. FWIW, SSH encrypts the
transport first and only then authenticates the user.

Fortunately, we do not care about this now. All these issues are
outside of OCP Core scope, and that scope has been frozen already!

Hope this clarifies,

Alex.