On 2009-12-02 09:08 PST, Chris Newman wrote:
--On December 2, 2009 15:19:53 +0100 Martin Rex <mrex(_at_)sap(_dot_)com>
wrote:
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).
+1
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).
The existing fallbacks or conservative approaches give you a hint where
you may expect interop problems. TLS extensions are a known interop
problem.
... for servers that have never been conformant with the standards that
require them to ignore unknown extensions, yes. Another way to say this is:
non-conformant servers are a known interop problem for conformant clients.
That fact is manifestly obvious now, as we see attempts to retroactively
codify the behavior of those non-conformant servers as we try to fix this
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.
+1.
- Chris
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf