Chris Newman wrote:
--On December 2, 2009 15:19:53 +0100 Martin Rex <mrex(_at_)sap(_dot_)com>
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(_at_)ietf(_dot_)org, 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf