On 2009-12-02 09:08 PST, Chris Newman wrote: > --On December 2, 2009 15:19:53 +0100 Martin Rex <mrex@xxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf