Marsh Ray wrote:
Martin Rex wrote:
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.
I know _you_ were very open-minded about the SSLv3 interop issue from
the beginning and I really value _your_ feedback in the discussion.
I wrote up my proposal after realizing that some people just did
not care about the obvious and serious disruptive nature for the
interoperability in productive environments and existing usage scenarios
of the original proposal which contained this:
4.3. SSLv3
SSLv3 does not support extensions and thus it is not possible to
securely renegotiate with SSLv3.
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.
One vendor that contacted me has just started to evaluate the
proposals. I could conceive that there are a number of vendors/suppliers
that would not know how to participate the discussion or voice their
concerns. Sometimes it is as simple as there is nobody sufficiently
experienced and with sufficient time available and permission from
his management to enter the discussion on tls(_at_)ietf(_dot_)org(_dot_)
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.
I know that the vendors (and in particular their customers) who
had been actively using the TLS renegotiation for delayed client
authentication want to get a solution out there.
The short-term solution to the security problem would be to
disable renegotiation and request the certificate on initial
handshake only. This impairs the user experience slightly,
but would not kill interop completely (hmmm, it could, due to
an interop-problem in WinHTTP, but I reported that in 2005...)
... unlike a requirement for a TLS extension in initial ClientHellos
for a number of existing usage scenarios.
So if we lack feedback from vendors, we should actively reach
out and collect this feedback. The sooner the better. It's
not like those vendors all live on alpha-centauri.
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.
maybe you missed the "extensions-free" part. Just like it is possible
now for a significant amount of the servers out there to simply
disable renegotiation, the hotfix for those servers should allow
them to ship an update entirely without TLS extensions support and
renegotiation still disabled. There, a single REQUIRED signaling
option that does not need generic extensions support makes
a HUGE difference. Search for the cipher suite (that code exists),
append a short static string to ServerHello and be done with it.
You are not seriously suggesting that such servers should become
extensions-intolerant in order to be served the easy-to-recognize
magic cipher suite value, are you?
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.
It simply makes no sense to create a new protocol feature with
more than one signaling mechanism. This is unnecessary complexity
for the implementations and for the interop testing.
The magic cipher suite signaling needs to be a MUST,
the inclusion of an empty TLS extension in the ClientHello
probably a SHOULD NOT.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf