Re: [TLS] Updated draft

[Marsh Ray <[e-mail]>]

Robert Dugal wrote:
> Oops, you're right. I misstated what I'd like the draft to allow. 
> What I'd like is the option to always send the SCSV in the
> ClientHello and on renegotiation requests send the SCSV + RI
> extension in the ClientHello.

That certainly sounds like a reasonably minor change to make...but it isn't.

I don't recall seeing anyone propose wording changes that would allow
such behavior, except in the context of the other proposals which are
fundamentally different in that they modify the inputs to the PRF. It's
possible that some concrete wording was suggested and is in one of the
1340 emails in my TLS folder.

Currently, the SCSV achieves its primary objective with a very simple
definition. It has "exactly the same semantics as an empty
'renegotiation_info' extension".

IMHO, proponents of other semantics for SCSV should be able to produce
an equally straightforward description of what they are, or show
something truly magical to justify complicating the description. Saving
an 'if' statement somewhere, partially fixing a multiply-broken
scenario, or avoiding extensions handling in some non-general case don't
sound like they justify the extra complexity.

Personally, I'd prefer that we don't propose (and re-propose) design
features at this point. We have to ship a fix for this open security
vulnerability, and I think the current design is squarely in the "good
enough" department. I.e. it fixes the problem and doesn't make anything
else significantly worse.

If anyone sees a security flaw or attack against a correct
implementation of draft-ietf-tls-renegotiation-02, please please speak up.

- Marsh