Chris Newman wrote: > > --On December 2, 2009 15:19:53 +0100 Martin Rex <mrex@xxxxxxx> wrote: > >> 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. > > The IETF's motto is "rough consensus and running code". So "running code" > matters. > "rubber stamping" is only a problem if incompatible changes are refused, > but the fact such changes were made makes that straw man moot. I remember the IETF discussions when S/MIME was brought to the IETF. "Running code" for new implementations is _NOT_ an issue for the decision we're doing here, since we agreed that the implementation effort for either proposal is insignificant. "Running code" as the installed base that draft-ietf-tls-renegotiation-01 might impair is _what_really_counts_. The software logistics around shipping a hotfix for a huge and in some instances very old installed base is the running code that needs to be relevant for the IETF decision. > > >> 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. > > First, I'll reiterate that I found both proposals acceptable, so the four > points I made were all matters of design preference for this situation and > not issues I find strongly compelling. You asked me directly to write up my proposal in an I-D on Nov 16th: http://www.ietf.org/mail-archive/web/tls/current/msg04400.html I agreed to writing an I-D here: http://www.ietf.org/mail-archive/web/tls/current/msg04410.html The WG-Chairs summary for EKRs draft on Nov 18th: http://www.ietf.org/mail-archive/web/tls/current/msg04464.html WG-Chairs consensus call for EKRs draft on Nov 20th (Friday) http://www.ietf.org/mail-archive/web/tls/current/msg04571.html to which I replied that I will post my new I-D on Monday Nov. 23rd (which I did), followed by a cleanup submission on Wed, Nov 25th. Considering that EKR had been involved in Project Mogul a few weeks before I realized the MITM-suceptibility of the TLS renegotiation and posted about it to tls@xxxxxxxx, that he has been previously authoring and co-authoring documents around TLS, I think it's unfair to complain that my proposal is "late". It's my first I-D and and I'm not a TLS implementer myself (only responsible for maintenance, support and updates of the OEM SSL/TLS implementation that my company is shipping). > > The issue with middleboxes was raised by others and is a straw man. There > are government standards that have a fixed list of cipher suites and most > clients can be configured to comply with those standards today. You mean stuff like this here: http://iase.disa.mil/stigs/stig/index.html If you look at this governmental spec in particular (page 50): http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf then you should realize two things: - it requires support for SSLv2, which is mutually exclusive with a TLS extension (but fine with my proposal) - it refers to the configuration of cipher suites, and _NOT_ to the presence of ciphersuite IDs in ClientHello. - the explicit list in that document is to illustrate which of the _weak_ ciphersuites are not allowed, the underlying security requirement is strong encryption (128-bit). Middleboxes aborting on the cipher suite selection on the server is _much_ easier to implement and perfectly reliable. Changes to filtering middle boxes (like intrusion detection systems) is a moot point, because these are constantly updated anyway (which is quite different from several of the SSLv2 Servers that are still used in some places). No one would be using AntiVirus-Software with signatures that are several months or even several years old. > > Given the TLS standards available at the time, a middlebox which enforced > the presence of just those cipher suites and no others in the TLS handshake > would reasonably be expected to be forwards compatible. Use of a > mandatory-to-implement cipher suite value will require such middleboxes to > be upgraded, thus slowing deploying. I'm not a fan of middleboxes, but we > shouldn't break them gratuitously. If you look at the unix-stig-v5r1 standard, it does _not_ list AES ciphersuites (RFC-3268, June 2002). One would expect that those middle-boxes, if they care about the cipher_suites in the _list_ of the ClientHello rather than the negotiated cipher suite in ServerHello, should check the fixed short list of known-to-be-weak cipher suites listed in the above document rather than get in the way of future development (the latter does not seem to be the intention of that spec). > > >> 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. > > I'd be fine with one signaling mechanism as long as it's the mechanism > that's been standardized since 2006 and backwards-compatible with correct > implementations since 1999 (TLS 1.0). TLS extensions is _not_ a signaling mechanism, and the "backwards-compatibility" amounts to "should be safely ignored when present, but we never actually tested that". It has been an optional and generic extension mechanism which the IETF never cared to make attractive until November 2009. Suddenly some folks want to make a hardly used optional feature a mandatory-to-implement functionality for all SSLv3 and TLS protocol versions back to 1994. (oh no, wait -- until ~nov 17th they were determined to simply kill all interop with SSLv3 and extensions-intolerant implentations of TLSv1.0). The original SSLv3 spec from Netscape did _not_ have the forward compatibility in ClientHello necessary for the installed base to not choke on the presence of TLS extension. Only the updated I-D document for SSLv3 that was produced in the IETF TLS working group (18-Nov-1996) had such a forward compatibility provision, however the TLS WG did _not_ care to publish that document as an informational RFC back then (so it was expired from the I-D repository 6 month after publication). And Netscape continued to provide the pretty PostScript & HTML spec of their SSLv3 spec without extensibility _much_ more prominently than the abandoned SSLv3 draft from the IETF TLS WG. TLS extensions (rfc-3546, June 2003) was a hardly-used option that came several years after TLSv1.0 (rfc-2246, Jan 1999) and was still a pure option in TLSv1.1 (rfc4346, April 2006) and not part of the TLSv1.1 base spec. > If we're misusing a cipher suite > value as a protocol extensibility flag, an issue I'm willing to compromise > on despite the lack of strong evidence it's necessary, we unfortunately > need two signaling mechanisms: one that's standard that we know will work > with modern correct implementations, and one a kludge that works with very > old software, but might break good-faith modern implementations (like the > middlebox straw man above). I'm sorry to disagree, but if a "modern correct implementation" has a problem with a signaling mechanism based on a cipher suite value in the ClientHello.cipher_suites list, then this implementation is neither modern nor correct! > > > The existing fallbacks or conservative approaches give you a hint > > where you may expect interop problems. TLS extensions are a known > > interop problem. > > While I've seen evidence of bugs in TLS extension handling, and backwards > compatibility fallback code that's been present in browsers since 1999, > I've seen no evidence that extensions are an interoperability problem for > correct standards-compliant TLS implementations or that such fallback code > is necessary in operation today. The IETF is fully aware that - the TLS rengotiation problem affects all protocol version of TLS including SSLv3 and in exactly the same fashion - it is extremely important that as many of the installed base is patched so that the number of servers and clients that need to tolerate and provide backwards interoperability with unpatched TLS peers can be reduced to a minimum. It is completely irrelevant how nicely this update fits with the most recents TLS implementations from the fancy new features department. What is extremely important is the interoperability with the RUNNING CODE out there maintained by the poor souls from the dirty old cruft department -- and how much hazzle it means for them to adopt this update. And it is much more about risk management for backwards-incompatible changes of a protocol and software in a potentially disruptive fashion for a productive installed base than it is about testing new features in a limited amount of new test installations where interop issues can be addressed and fixed with no time pressure whatsoever. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf