Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

[Stefan Santesson <[e-mail]>]

Good points Marsh, but a few comments in line:


On 10-01-29 4:53 PM, "Marsh Ray" <[e-mail]> 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