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.