Stefan Santesson wrote: > This makes no sense to me. > > Developers tend to live by the rule to be "liberal in what you accept" as it > tends to generate less interop problems. Not in my experience. HTML is perhaps the ultimate example of a liberal implementation of a spec. To this day, many years later, it's common to find pages that render badly with one or more implementations. Whenever an application is actively being "liberal in what it accepts", the sending application is in fact relying on undocumented behavior. This is what causes the ineterop problems, not strictness. In practice, if protocol receiving applications are consistently strict about what they accept, then mutant protocol sending applications do not get out to pollute the ecosystem. > It makes no sense to abort a TLS handshake just because it contains an SCSV > if everything else is OK. This is a cryptographic data security protocol for which interoperability must be secondary to security. If anything is malformed or suspicious, the handshake should be aborted. > So This "MUST NOT" requirement will likely be > ignored by some implementations. They should expect the market to hold them accountable if problems result. The implementers on this list have indicated they could produce interoperable implementations of this spec. And they appear to have proven it by demonstrating implementations which actually interoperate. > 03 gives SCSV somewhat double and conflicting semantics. > > 1) Present in an initial handshake it signals client support for secure > renegotiation. > > 2) Present in a renegotiation handshake it signals that the client DOES NOT > support secure renegotiation (Handshake MUST be aborted). > > I think this is asking for trouble. Yep, it's an inelegant hack. None of this is how any of us would have designed it that way from the beginning. I would recommend that clients always send a proper RI extension and don't even mess with sending SCSV. Extensions-intolerant servers should just go away. Servers just treat SCSV like an empty RI (clearly wrong for a renegotiation) without adding much complexity. As for "[Upgraded] Clients which choose to renegotiate [] with an un-upgraded server", they deserve whatever they get. SCSV is just for those implementers that want to make insecure connections with old and broken peers. That task has always involved added complexity and they know the work they're buying for themselves. - Marsh _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf