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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
>
> 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".

you got this wrong.  It shows that up to date at least 3 independent
people have not noticed that anyone has raised a technical issue
against a mandatory SCSV.  This particular semantics has always
been part of my proposal.

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

http://www.ietf.org/mail-archive/web/tls/current/msg05372.html


>
> Sending SCSV with no extension in a renegotiation Hello is a very
> questionable thing to do.

Nope.  The purpose of that cipher suite value, which EKR has cloned
from my I-D (including its name), has always been defined as a
simple signal Client->Server "Hi, I'm updated", and is meant to
imply that an updated server should apply the strict rules of
secure renegotiation.


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

Now you're trying to make something up in a haste.

I'm wondering which vendors are this that have already shipped
an implementation based on the original TLS extension RI proposal
and are now trying hard to prevent any changes to the document
that would require them to patch again.


You are aware that the wording that I proposed does _not_ say
that sending a TLS extension RI as the only extension would
not be allowed.  It is allowed, its up to the vendor.

Yes, it would happen that some updated clients send only SCSV and
expect the server to understand that.  I don't think that is a problem.
That update would be with much less time pressure, and then I was
assured so many times that sending extensions was so standard and
just everybody was doing it already, that I can not believe this
to become an unsurmountable problem for early adopters.


> 
> 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'm sorry, I have no idea what you're talking about.

Fixing security problems is not about fixing particular attack scenarios.
it is about fixing the defect in the underlying architecture.

If there is a unique and uncoditional signal from the client in
every ClientHello handshake message that the client is updated
and requests the handshake to be performed according to the strict
rules of secure renegotiation, then it will be completely impossible
for an attacker, independent of any attack scenarios, to make an
updated client perform an old handshake with an updated server.

That is what fixing the vulnerability at an abstract level is about,
and makes the architecture so much simpler and robust, because you do
not have to distinguish scenarios.  And it is also completely independent
of which peer allows which kind of backwards interop.


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

Everyone can save those lines!  you can remove a lot of conditionals
in the code.

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

No, it is universally useful, and saves everyone code and test complexity.


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

It just doesn't apply and ist _MUCH_ to complicated for a simple
design, anyway.

-Martin