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

From: Alex Rousskov <[email-masked]>
Date: Tue, 4 May 2004 16:21:32 -0600 (MDT)

The Purple Streak, Hilarie Orman wrote:

> It's fairly tricky to negotiate cryptographic protection.

Yes. Fortunately, there are known solutions, and we do not have to
reinvent the wheel :-).

> How can you switch from a non-SSL connection to an SSL connection
> during negotiation, for example?

See negotiation examples in OCP Core (the current snapshot) for an
example. This kind of switch is pretty standard. All HTTP CONNECT
transactions use it. You simply start encrypting after you
send/receive an un-encrypted response to un-encrypted CONNECT
(accepted negotiation offer in our case).

> Wouldn't you have to start all over again, repeating everything that
> led up to the discovery that the two sides needed a particular
> protection suite?

It's an option. Usually, it is recommended that encryption negotiation
happens first, but it does not have to be that way if parties do not
care if a previous traffic is not encrypted. If/when we document
encryption for OCP, we should RECOMMEND that it happens first, IMO.

We do not document a way to do a switch from encrypted to unencrypted
connection, but I believe such a switch is technically possible. If
you look at SSL library, for example, it has an interface that is 100%
independent from the notion of a "transport connection". It is simply
an encryption of a [portion of a] dialog. You feed it an unencrypted
buffer, you get an encrypted buffer (or request for more data) back.

> Do they also negotiate the authentication requirements?

Optionally, and probably after they negotiate and establish encrypted
transport medium.

> if you were already using SSL you might decide during negotiation
> that the transport had already established a sufficient degree of
> security and accept it.  What of that case?

If I understand the question correctly, agents would simply not
negotiate encryption is the case of already established and
satisfactory encryption for the connection they use. Recall that OCP
does not require connections to be encrypted. It makes it possible for
any party to insist on encryption (or terminate the connection).

> I think that the IESG may take issue with the idea that the
> extensions can change anything, including the syntax.

We only need to convince a single person who actually seemed to
misinterpret the (now-polished) text. I would give it a shot. Do you
object?

> It would seem difficult to analyze an implementation for correctness
> given such wide latitude in dynamic behavior.

Agreed. It would be even more difficult to predict all profile needs
for OCP profiles we do not even know about at this time. The intent
here is to give those profiles enough flexibility while counting on
their good faith approach. I do not expect IETF standard-track OCP
profiles to seriously alter OCP Core, but minor modifications may be
essential.

A better argument might be that it makes writing pure OCP Core proxies
impossible. Perhaps that's a good thing though? Is there any value of
a pure OCP Core proxy? Can it do anything that a TCP proxy cannot?

We can put syntax out of scope if that makes any difference, but I am
not sure it does.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 4 May 2004 23:52:59 -0600

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

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 4 May 2004 23:54:50 -0600

Putting the syntax out of scope would be a very good idea.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 May 2004 00:38:50 -0600 (MDT)

> 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

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

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

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

> doesn't make sense to start encrypting and then establish

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.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 May 2004 02:00:09 -0600 (MDT)

> Putting the syntax out of scope would be a very good idea.

OK. Here is the revised section:

15.1  Extending OCP Core

   OCP extensions MUST NOT change OCP Core message format, as defined by
   ABNF and accompanying normative rules in Section 3.1. The intent of
   this requirement is to allow OCP message viewers, validators, and
   "intermediary" software to at least isolate and decompose any OCP
   message, even a message with unknown to them (i.e., extended)
   semantics.

   OCP extensions are allowed to change normative OCP Core requirements
   for OPES processors and callout servers. However, OCP extensions
   SHOULD NOT make such changes and MUST require on a "MUST"-level that
   such changes are negotiated prior to taking effect. Informally, this
   specification defines compliant OCP agent behavior until changes to
   this specifications (if any) are successfully negotiated.

   For example, if an RTSP profile for OCP requires support for offsets
   exceeding 2147483647 octets, the profile specification can document
   appropriate OCP changes while requiring that RTSP adaptation agents
   negotiate "large offsets" support before using large offsets. Such
   negotiation can be bundled with negotiating another feature (e.g.,
   negotiating an RTSP profile may imply support for "large offsets").

   As implied by the above rules, OCP extensions may dynamically alter
   the negotiation mechanism itself, but such an alternation would have
   to be negotiated first, using the negotiation mechanism defined by
   this specification. For example, successfully negotiating a feature
   might change the default "Offer-Pending" value from false to true.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 5 May 2004 10:12:14 -0600

I think there's a misunderstanding about the encryption requirement.
The IAB guidance was for OPES-processor-to-OPES-processor.  There's no
such onus on OCP.

I know a little about security protocols, and I don't see how OCP
defines a secure way to interface to transport security features.
I strongly advise ditching it rather than trying to repair it.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 5 May 2004 10:25:42 -0600

Is "negotiated" used to mean a protocol operation in the second sentence,
and as a action within a standards body in the third sentence.

I think that the IESG concern about negotiation is that if the state
machine for the core negotiaion changes as a result of negotiation (in
the protocol sense), you can easily get a resulting state machine that
is unmanageable.  Infinite loops, deadlocks, etc.  Can you add verbiage
that indicates why those bad things are not possibilities?

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 May 2004 11:02:04 -0600 (MDT)

> The IAB guidance was for OPES-processor-to-OPES-processor.  There's no

IAB guidance is end-to-end, which includes processor-to-processor and
processor-to-callout_server. Since callout servers may be remote, it
is pointless to ensure processor-to-processor encryption without
processor-to-callout_server encryption!

If IAB did not mention callout servers, it's becuase they did not know
about them or rightly considered them equivalent to other processors
as far as IAB considerations are concerned.

> defines a secure way to interface to transport security features.

You are absolutely correct:

	(a) OCP Core allows for a common (HTTP, BEEP, other?)
	    interface to transport security.

	(b) OCP Core does not define an interface to transport
	    security.

> I strongly advise ditching it rather than trying to repair it.

	(c) We are not reparing anything specific to transport
	    security.

So, in a way, we have already ditched it long time ago when we removed
encryption-related profiles from OCP Core. We are not trying to add
them now. We are simply addressing a very valid comment by Steve
Bellovin that is not really secific to security (it applies to _any_
OCP negotiation).

Hope this clarifies,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 May 2004 11:19:49 -0600 (MDT)

On Wed, 5 May 2004, The Purple Streak, Hilarie Orman wrote:

> Is "negotiated" used to mean a protocol operation in the second
> sentence, and as a action within a standards body in the third
> sentence.

The meaning of negotiation does not change from the second sentence to
the third. If something implies that it does, please be specific what
that something is or suggest a different wording. Note that the third
sentence is not normative. Basic OCP negotiations mechanisms are
defined in Section 6 "Negotiation".

> machine for the core negotiaion changes as a result of negotiation
> (in the protocol sense),

The state always changes as a result of a successful negotiation.
Otherwise, we did not negotiated anything!

> you can easily get a resulting state machine that is unmanageable.
> Infinite loops, deadlocks, etc.  Can you add verbiage that indicates
> why those bad things are not possibilities?

I cannot prove protocol correctness; it is possible that OCP Core
negotiation is flawed.

Unknown bugs notwithstanding, Section 6 "Negotiation", Section 11.18
"Negotiation Offer (NO)", and Section 11.19 "Negotiation Response
(NR)" contain specific rules/requirements that are meant to avoid
wrong state as a result of a negotiation. Note that specific feature
definitions (OCP Core does not define any features) may contain
additional requirements.

The section you quoted from above is about OCP extensions that may use
OCP Core negotiation mechanisms to adjust some OCP Core rules to
better fit their needs. The section has one example to illustrate the
need.

Thanks,

Alex.