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

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 01:05:39 +0100 (MET)

Peter Gutmann wrote:
> 
> Martin Rex <[email-masked]> writes:
> 
> >That implementors should ignore at least half of the MUSTs and SHOULDs
> >in IETF documents, because they don't make any sense, create unnecessary
> >interop problems or are otherwise harmful -- and should not be in the
> >document in the first place?
> 
> <aside>That's been the standard for PKIX RFCs for at least ten years
> (actively acknowledged by WG mmembers), although perhaps its spread
> to other groups should be discouraged.</aside>

I fully agree.

That may be attributed to the fact that a large part of PKIX is dealing
with policy issues with the objective to prevent/prohibit interoperability.

When providing software (updates) to an installed base, it is not
exactly easy to "sell" them interoperability problems, which is one
reason why the adoption speed for some PKIX features is poor.

And then there are the serious security problems created by some
of the PKIX features themselves, like AIA (Authority Identifier Access).
But basically it applies to all URLs in certs that you can use
to coerce a server in order to perform a network access of
resources according to the desire of the presenter of the certificate.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Jan 2010 08:33:10 +0100

> with policy issues with the objective to prevent/prohibit interoperability.

On the contrary. I believe allowing the sending of both SCSV and extension
might harm interoperability instead. Consider the case of most popular client
implementations are sending both SCSV and extension (it's easier to do so).
A developer of a server might then consider checking only for SCSV (since all
of the popular ones he tested with send both). Thus interoperability with less
popular clients that only send extension stops.

This scenario might not be very likely, but this kind of issues were
not rare in
TLS for quite long :)

best regards,
Nikos

---

From: "Rex, Martin" <[email-masked]>
Date: Wed, 27 Jan 2010 15:19:34 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nikos 
> Mavrogiannopoulos
> Sent: Wednesday, 27. January 2010 08:33
> To: Rex, Martin
> Cc: Peter Gutmann; [email-masked]; [email-masked]
> Subject: Re: [TLS] Metadiscussion on changes in 
> draft-ietf-tls-renegotiation
> 

The above was a comment about PKIX, not SCSV.

> 
> On the contrary. I believe allowing the sending of both SCSV 
> and extension might harm interoperability instead. Consider the
> case of most popular client implementations are sending both SCSV
> and extension (it's easier to do so).
> A developer of a server might then consider checking only for 
> SCSV (since all of the popular ones he tested with send both).
> Thus interoperability with less popular clients that only send
> extension stops.

I'm somewhat confused what makes you saying this.
Support for SCSV is *required* for initial handshakes in the
-03 document -- if it wasn't, SCSV could be removed from the
document entirely.  The reason for this is that otherwise
existing usage scenarios would be susceptible to downgrade
attacks (which is what the confusing reference in section 4.2
refers to).

What I am opposing is the MUST NOT for the secure renegotiation.

Secure renegotiation requires that both, server and client
verify the contents of the "renegotiation_info".  If some
implementor forgets that without the SCSV MUST NOT, then you
have much more serious issues to worry about than SCSV semantics.

If _some_ implementors, without this MUST NOT, would really accidentally
forget to verify the verify_data of the renegotiation_info for
secure renegotiation, then we should dump TLS extension RI and
go for the approach draft-mrex-tls-secure-renegotiation, because
it is fairly unlikely that you get an implementation of this
draft to interoperate in regular interop scenario _without_
getting the secure renegotiation working correctly.

> not rare in TLS for quite long :)

I would have loved to get rid of the empty TLS extension RI entirely,
(making SCSV the mandatory to use signaling method) just like
Eric Rescorla proposed here:

http://www.ietf.org/mail-archive/web/tls/current/msg04794.html

because it would the most robust approach, but it had severe
aesthetical acceptance problems (not a single technical
problem is on record).

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Jan 2010 09:45:07 +0100

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.
It makes no sense to abort a TLS handshake just because it contains an SCSV
if everything else is OK. So This "MUST NOT" requirement will likely be
ignored by some implementations.

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.

/Stefan

On 10-01-27 8:33 AM, "Nikos Mavrogiannopoulos" <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Fri, 29 Jan 2010 09:53:05 -0600

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

> 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

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.

> 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

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 30 Jan 2010 00:54:15 +0100

Good points Marsh, but a few comments in line:

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

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

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

> designed it that way from the beginning.

And here we totally agree :)

/Stefan

---

From: Steve Checkoway <[email-masked]>
Date: Fri, 29 Jan 2010 16:24:31 -0800

> hurt security, and that is a tricky balance act.

I'm not sure why you say that. Marsh's example of HTML shows interop issues that came from being liberal that had nothing to do with security. Allowing SCSV + RI doesn't hurt security, but that's not an argument for allowing it.

> security problem is introduced by allowing the renegotiation (i.e. Not

None.

> understand the real benefits of this requirement.

I'm not convinced that there is a real benefit one way or the other. People have been disagreeing about which is better, but none of the arguments on either side have been very convincing.

> interop problems while maintaining the security of the protocol.

It seems rather unlikely that disallowing SCSV + RI is going to cause interop problems. An implementor who hasn't bothered to read the 1700+ emails about this is going to determine pretty quickly that SCSV + RI is not in spec during normal testing if the MUST NOT was overlooked in the spec.

Given that there are no security concerns and the interop concerns seem pretty minor at best, it makes sense to me to publish and get the fix out sooner rather than spending another month arguing about something, that in the end, doesn't change the security guarantees of TLS.

-- 
Steve Checkoway

---

From: Marsh Ray <[email-masked]>
Date: Sat, 30 Jan 2010 16:08:47 -0600

> understand the real benefits of this requirement.

In a sense it allows a consistent definition of the semantics of SCSV:
The presence of SCSV is equivalent to an empty RI extension. Under such
a definition, the presence of multiple conflicting RIs (especially an
empty RI during a renegotiation) is clearly an abort-able offense!

This "permitted, though NOT RECOMMENDED" practice of sending SCSV during
insecure renegotiation can be (charitably) thought of as not changing
the semantics of SCSV, but instead being a sneaky manipulation in order
to probe the target server to double check that he's still not upgraded.
 This probably does not add any real security (MitM could just drop the
RI from the Server Hello and the client might not be able to detect it
until after he sent his Finished message). Seems like implementations
wishing to use this kind of trickery could do so without it having been
explicitly permitted by the spec.

> I don't think being accountable to the market is a very strong threat

Seriously, got anything better in mind? Security researchers dropping
0-days maybe?

> if a

At one time some there seemed to be some ambiguity in the specs (or at
least some interpreted it that way) as to whether or not extension data
on the Hellos was actually to included in calculations for the Finished
message verify_data. Perhaps some vendors included it and some did not,
and no one noticed at the time because there were no extensions defined.
I vaguely recall somebody suggesting on this list that (for
interoperability of course) some implementation calculated the
verify_data both ways and accepted either one that matched.

If this is in fact the case, it seems plausible that there might be
implementations (of older specs like SSLv3) out there for which
extension data can be dropped or changed by MitM.

I wonder if considerations for these systems has anything to do with it?

- Marsh