Good points Marsh, but a few comments in line:
On 10-01-29 4:53 PM, "Marsh Ray" <marsh(_at_)extendedsubset(_dot_)com> wrote:
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.
I'm just speaking out of personal experience during my 5 years working with
developers of PKI and internet security protocols. It was constant battle of
taking all non compliant implementations into account and to break as few of
them as possible IF it could be done without reducing security.
I could give you a long list of interesting examples :)
The key is though that being liberal is only an option when this does not
hurt security, and that is a tricky balance act.
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.
I totally agree in principle. However, if a renegotiating client sends a
full RI extension with valid data AND the client also sends SCSV, then what
security problem is introduced by allowing the renegotiation (i.e. Not
aborting)
No matter how hard I try, I can't find the security problem and I can't find
the interoperability advantage.
Hence, the "MUST abort" requirement seems like an unmotivated restriction.
I'm not saying that we have to change the current draft, I'm just curious to
understand the real benefits of this requirement.
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.
Again, based on what I have seen, I would not be surprised.
I don't think being accountable to the market is a very strong threat if a
safe adjustment to a more liberal processing helps customers to avoid
interop problems while maintaining the security of the protocol.
Hence, if there IS a security threat that motivates this, then it is
extremely important to spell it out in the clear.
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.
And here we totally agree :)
/Stefan
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