Martin Rex wrote:
> Chris Newman wrote:
>> Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
>>
>> Kudos to Martin Rex for producing such a good alternate proposal.  The 
>> introductory text up to and including section 4.1 is very good and would 
>> improve draft-ietf-tls-renegotiation.  While I would support a consensus to 
>> publish the mrex document as the solution, I presently prefer 
>> draft-ietf-tls-renegotiation-01 for four reasons:
>>
>> 1. Running code: multiple implementations and interop testing was
>>    performed on an earlier version of draft-ietf-tls-renegotiation.
> 
> Even EKR admitted that implementing the update is an insignificant
> amount of work.
> 
> Pushing this point, that there were interoperable implementations
> when this proposal was made in the IETF smells very much like
> a request for rubber stamping. 

My goal had been to present a usable solution along with the disclosure
of the vulnerability. When it comes to closing exploitable security
holes, a usable solution today is better than a perfect solution next
year. If that's rubber stamping to you, well sorry.

>> 2. Impact to core protocol handshake: The mrex proposal alters the 
>>    handshake to include data that is not exchanged in-protocol.
>>    If this impacts PKCS#11 hardware tokens or other SSL accelerators
>>    (an issue mentioned by Dr Stephen Henson on the TLS list on
>>    that could severely impact deployment.
> 
> Crypto hardware in general and PKCS#11 are not affected.  What I am
> changing is the plaintext input to a hash or hash-like function.

Agree.

> What might be affected is hardware implementations of SSL/TLS
> or hardware-support for SSL/TLS in TLS endpoints.  It might be
> a firmware rather than hardware issue there.
> 
> So far, I haven't seen any vendor/implementor that is facing such
> difficulties raising such concerns.
> 
> Which could mean two things:
>  1. there is no problem
>  2. those vendors/implementors have not looked at / evaluated
>     the current proposals.
> 
> (1) would make it a non-issue and (2) would indicate than a decision
> in the IETF is _premature_, we would have to ask some of those
> vendors/implementers for feedback before making a decision.

I am a bit disappointed that we have not had better participation from
the vendors, particularly hardware. My suspicion is that they're
reticent to discuss what they're up against either publicly or privately.

We can't delay the solution for the large percentage of affected
deployments that are represented by vendors who did choose to
participate in the discussion for the sake of those who did not.

>> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some 
>>    circumstances.  That approach is untested in the field and I have
>>    concerns it will negatively impact middleboxes.
> 
> Huh?  That sounds extremely unbelievable.

I suspect that some inspecting firewall or IDS box somewhere is going to
take issue with the new cipher suite value and have to be reconfigured.
I also believe that it's a minimal concern and it's the least-breaking
of all the possible signaling methods.

> Do any of the browser vendors cut down on ciphersuites in their
> current reconnect fallbacks -- and remove ciphersuites like
> those with AES?
> 
> A quick glance indicates that Firefox 3.0.15 happily sends
> a list of 18 ciphersuites, including Camellia, in an SSLv2 ClientHello
> on reconnect fallback.

My experiments were showing that some clients would advertise a reduced
list of cipher suites in the renegotiation hello.

>>    As draft-ietf-tls-renegotiation allows use of either the cipher suite
>>    value or the extension for C->S signaling, that mitigates the concern -- 
>>    the field can choose the mechanism that works best.
> 
> I consider this a defect in draft-ietf-tls-renegotiation-01.
> There should be exactly **ONE** signaling mechanism for the initial
> ClientHello on a connection so that extensions-tolerant but
> extensions-free Servers will not be force to wade through lists
> of extensions sent by clients.

It's a three-to-five line 'for' loop.

> The existing fallbacks or conservative approaches give you a hint
> where you may expect interop problems.  TLS extensions are a known
> interop problem.

Those servers need to be patched or you wouldn't want to trust
connecting to them anyway. Client implementations can use the MCSV
(magic cipher suite value) on the initial hello if they prefer.

>> My take on some controversial issues:
>>
>> * There may not be a sufficient number of "extension intolerant" SSL/TLS 
>> servers in operation to justify the added complexity of 
>> TLS_RENEGO_PROTECTION_REQUEST.  However, I do not object to inclusion as 
>> it's possibly helpful for some alleged extension intolerant servers 
>> compliant with early drafts of SSLv3 and it helped move closer to WG 
>> consensus.
> 
> That cipher suite value is definitely not added complexity.
> On the contrary, it is significantly reduced complexity.

Well, there are now three ways to signal in an initial client hello. The
extension, the MCSV, or both.

Some implementations will find the MCSV simpler, some the extension.

> We are not discussing about a new optional feature here, but instead
> about something that should be patched into as many old clients and
> servers as possible.  And a number of clients MUST remain interoperable
> with servers that will _not_ be patched.  Therefore requiring anything
> that will break interop in the productive installed base is completely
> inacceptable when it can be avoided (which it easily can be).

+1

- Marsh