On Tue, Nov 24, 2009 at 12:43 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
> Pasi.Eronen@nokia.com wrote:
>> Earlier Eric noted that if no application data is exchanged between the
>> initial and renegotiation handshake (i.e. no application data is sent
>> using the 1st session), this would be safe even without protocol
>> changes. Should this be included in this section, too?
>
> In order for that scenario to be 'safe' we would need to find some
> language in the TLS spec, there since the beginning, which says that an
> application MUST NOT attribute any semantics to the successful
> authentication of the remote party. I don't believe the spec has any
> such language.
>
> There is probably some application out there which interprets a
> connection from an authenticated client (or to an authenticated server)
> as an "event" with real semantics.
>
> Using SSH as an analogy, sometimes a login shell is set to, say, a
> backup program. Commands get launched when the user authenticates.
>
> Back with TLS, Microsoft IIS, for example, has a
> client-certificate-to-user mapping facility. It's certainly possible
> that the connection from such authenticated clients could trigger
> certain "non-idempotent" activities, even if just adding false log records.
>
> - Marsh

I still want the ability to negotiate using an ephemeral suite, and
only then (in the
protected-from-eavesdropping-but-not-yet-authenticated channel) offer
the certificates.  In my view, this is a rather serious
information-disclosure vulnerability in the original protocol, where
the Certificate messages are sent before ChangeCipherSuite.  This is
simply not possible without renegotiation.

The TLS library has the ability to detect when application data has
come in -- and one of the ways to mitigate this might be for the TLS
library to maintain an additional flag to prevent any application data
from being sent out or accepted while a (re)negotiation is taking
place.  (There's already a requirement that application data not be
sent with NULL-NULL-NULL, the initial state of the connection... and
the one value which is illegal to negotiate.)  If it does, the server
could fatal-alert either unexpected_value, protocol_error, or
insufficient_security.  (If a patched server *requires* that the
client be patched, insufficient_security or protocol_version would be
appropriate.)

Since there is already one magic value that must not be negotiated as
a cipher suite, there's precedent to use that mechanism... and since
this is a problem that affects all current versions of SSL3/TLS
implementations, it is important that we not change the semantics of
any of the messages that those implementations would normally see.
This means that we must use the only extension mechanism defined in
all SSL/TLS specifications -- the ability to add new cipher suites.
Because of this, I see no way to avoid adding a second "it is an error
if this suite is negotiated" tag to the cipher suite list.

Thus, I support the idea of using a new magic value in the cipher list
to indicate that a client has been patched (with the patch including
"must not negotiate this cipher suite, but including it means that the
server knows that the client can do the new renegotiation semantics").
 I also support the idea of standards action with all due haste (once
things are agreed upon) to update TLS 1.0, 1.1, and 1.2 with new
semantics (and the Standards Action necessary to allocate a new cipher
suite tag), with a recommendation to also update SSL 3.0
implementations.  (SSL 2 is just bad in the first place, and I see no
reason to try to improve it.)

The only downside I see to this is the eventual possibility of
branches of the protocol like Limewire did... using magic strings in
what essentially amounted to the User-Agent string to identify extra
capabilities.  I believe that this problem is much more effectively
and efficiently solved using TLS Extensions, so I am loath to add any
additional magic values unless something else comes up that requires
additional *retroactive* changes to the protocols that need to be
signalled.

(Using a cipher suite tag essentially leaves the protocol untouched
for unpatched clients, and the workarounds on the server side ('no
renegotiation' or 'server-initiated renegotiation only') will still
work.  If a server demands that the client be patched, I've discussed
above what the appropriate response would appear to be, to my eyes
(based on the definitions in RFC 5246 -- I haven't looked at earlier
versions).)

Once the signal has been sent by the client that it has been patched,
both the patched client and server implementations could then branch
into a different Finished calculation.  I do like the idea of adding
the hash from the last Finished message that the client sent --
initial state as all bits off -- to a renegotiated Finished handshake
calculation.  Since a client is not considered authenticated until the
server has verified that the certificate is valid, the key to that
certificate is held by the entity at the other end of the connection,
and the ChangeCipherSpec and Finished messages check out... well,
there's no worry of a client being improperly authenticated and
triggering anything other than at most a 'bad login' attempt.  Though
I would prefer to see that one not be 'bad login' (since that could be
a non-idempotent action that, for example, locks the user account),
but 'attack detected'.)

I also support the creation of a Renegotiation Indication extension,
so that TLS servers that support extensions won't have to set a
connection-context flag during processing of the cipher list.  RI
should also include the magic cipher code, or even have its tag *be*
the magic 'patched cipher' code.

(I do hate special-casing code -- in this case, during the cipher list
processing, and then during the Finished message calculation -- but I
don't really see much of a choice if we want to maintain some limited
backward compatibility with the world that already exists, which the
AD has stated is a priority.)

-Kyle H