Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--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.

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.

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. 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.

   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). 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.

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.

		- Chris

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]