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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf