Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Kemp, David P. wrote:
>> Martin's text contradicts the AD's decision ...
> 
> I do not fully agree with the AD's determination of rough consensus.
> 
> For the MCSV signaling, the real rough consensus is different from
> what Pasi wrote:
> 
> http://www.ietf.org/mail-archive/web/tls/current/msg05306.html

That email is Michael Gray of IBM saying "I do not believe a technical
objection to the CipherSuite method has been presented" which is not
remotely the same as a real lack of "rough consensus".

> A mandatory Client->Server signaling through cipher suite may
> have less fanatic followers by the count of numbers,

Fanaticism is orthogonal to cardinality.

> but technical
> advantages and _no_ technical objections have been raised against it.

Let me re-state them then.

Making SCSV mandatory means that it no longer is the equivalent of an
empty extension, which raises the question of exactly what it does mean.
Saying it means "I'm updated" is simply begging the question.

Sending SCSV with no extension in a renegotiation Hello is a very
questionable thing to do. That combination of values is needed for
clients that wish to send an _initial_ hello and interoperate with
extensions-intolerant servers! Overloading to also mean (and be
ambiguous) with "I'm intentionally _renegotiating_ in a manner known to
be insecure" is bad. And that is a technical objection.

> The current either cipher suite or empty TLS extension RI signaling
> may have more "pro", but has significant objections against it
> because of the ambiguity,

"MUST send this and/or that" is not an ambiguity and you know it.

> increased complexity,

I disagree, see below.

> a 4x code size
> burden for old non-rengotiating servers

How can a TLS client prove in advance that the server could not have
been enticed to renegotiate by a MitM? It is not possible to do in
general, and thus no general implementation of the protocol can rely on
it for security.

I just don't see any explanation other than you are pushing this to save
a few lines of code in your own particular circumstance.

> and additional testing
> complexity.

Yes. These additional test cases are unfortunate, but nearly all vendors
agreed that it was necessary to have an SCSV option to avoid hitting
slow failures connecting to the extensions intolerant servers seen in
the wild.

If you were so concerned with testing complexity you wouldn't be pushing
to make simplifying assumptions in your implementation. Testing all
cases is certainly more work than the minimal code to support the one
and/or requirement.

> So as far as rough consensus is concerned, it is definitely
> with the approach I described.

The "mandatory SCSV" scheme seems primarily useful if your solution
works by modifying the PRF inputs on renegotiation and letting the
Finished hash comparisons detect the attack. That method had some merit
and was given serious consideration by myself and many others.

But again, the reason I could not ultimately support it is because it
involved changing the cryptographic calculations. Regardless of whether
you or I think that it was done correctly, it is a very very big deal to
some important users. It will invoke a formal cryptographic review
process which will prevent this solution from being usable by many
important sites any time soon.

Retro-fitting a "mandatory SCSV" requirement to the RI extension
proposal is what introduces the complexity and ambiguity without a
well-defined benefit.

Here are all the things that have to happen in order for a mandatory
SCSV requirement to be of benefit:

1. Client has to be in compatible/insecure mode.
2. Mitm has to impersonate a server of interest to the client.
3. Client does not check Mitm's cert on the initial handshake.
4. Client must be willing to conduct a server-initiated renegotiation
(from anonymous server).
5. Legit target server has to be in compatible/insecure mode.

If all these things happen, then the complicated protocol change
prevents one attack variant but leaves others.

In addition, another necessary condition for this to actually be a
useful improvement is:

6. Mitm can find no unpatched server of equal or greater value with
which to attack the connection of this client.

The additional complexity and ambiguity that the "mandatory SCSV" scheme
introduces for no real benefit is my technical objection against it.

- Marsh