Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04

[Charlie Kaufman <[e-mail]>]

Making a completely breaking change to a protocol - where no new implementation will interoperate with any existing implementation - seems like a bad idea under almost all circumstances. Am I reading the document correctly and that is the implication of implementing the features labelled "SHOULD"?

At the very least, if you are going to break interoperability, I would think you would introduce a new version number to the protocol rather than (and do I have this right?) make this change to all versions of TLS so that there will be a new TLS 1.0, TLS 1.1, and TLS 1.2 with this extension but none of them will interoperate with old implementations of any version of TLS?

And worst of all, if you are going to completely break interoperability without introducing a new version number, you should warn people about it in dramatic terms in the introduction to the RFC rather than have it be something that alert people will figure out when reading the spec and others will discover only when they try to deploy it.

The vulnerability that this extension addresses affects a tiny fraction of scenarios. I would expect that most people would decline to upgrade their implementation of TLS to fix that vulnerability if the cost were to break everything.

In the best case, people will ignore the fact that the step in the algorithm that breaks interoperability is labelled SHOULD and will instead deploy it such that the mitigation is effective only after both ends are upgraded, with a configuration switch allowing the mitigation to be required in scenarios where a single customer controls both ends of the connection. It would be reasonable to require the more secure behavior in TLS v1.3 (assuming that is the next version), since implementations not supporting it will negotiate down to a lower version.

But specifying a SHOULD behavior and hoping implementers will have the good sense to ignore it seems like we're looking for trouble.

	--Charlie

-----Original Message-----
From: secdir [mailto:[e-mail]] On Behalf Of Watson Ladd
Sent: Thursday, April 16, 2015 8:33 AM
To: Karthikeyan Bhargavan
Cc: [e-mail]; [e-mail]; The IESG
Subject: Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04

On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan <[e-mail]> wrote:
> Hi Radia,
>
> Thanks for the comments. I made many of the smaller changes, and have 
> some questions about the interop concerns.
>
>> In particular, section 5.2 paragraph 4 & 5 say:
>>
>> "If the server receives a ClientHello without the extension, it 
>> SHOULD abort the handshake. If it chooses to continue, then it MUST 
>> NOT include the extension in the ServerHello."
>>
>> "If a client receives a ServerHello without the extension, it SHOULD 
>> abort the handshake.”
>
> The style we chose was to say that the client/server SHOULD abort the 
> handshake, but we also say in paragraph 7:
>
> "If the client or server choose to continue a full handshake without the extension, they use the legacy master secret derivation for the new session. In this case, the considerations in section 5.4 apply.”
>
> That is, we do offer them the choice of opting out of this draft for 
> interoperability, by following the recommendations in 5.4.
>
> We could make this forward pointer more explicit by saying instead:
>
> “In order to interoperate with legacy peers, some lients and servers 
> may choose to  to continue a full handshake without the extension. In 
> this case, they use  the  legacy master secret derivation for the new 
> session, and the  considerations in section 5.4 apply.”
>
> Would this assuage the security/interoperability concern?
>
>
>> In section 5.3, there is similar language to disable session 
>> resumption when the extension is not present. While this may be more 
>> acceptable because it will not break interoperability, it *will* 
>> cause a significant performance degradation in some important 
>> scenarios. I would again recommend that it be a configuration 
>> parameter so that no one will refuse to deploy this change because of performance concerns.

I seem to recall a discussion about this, where my minority position was that breaking renegotiation instead was more acceptable. We need to break one, and renegotiation is not used nearly as commonly for browsers.

>
> During resumption we use similar language to point forward to section 
> 5.2 if the client or server chooses to continue without the extension.
>
>> Section 5.4 also mandates breaking behavior (and here it is a MUST) 
>> in scenarios where there is most likely to be a triple handshake vulnerability.
>> Given that there are cases with no such vulnerability and given that 
>> people will be reluctant to deploy software that turns a subtle 
>> security vulnerability into non-interoperability, I believe this 
>> should be a matter of configuration.
>
> This case seems most difficult, because section 5.4 is the defense of 
> last resort. Weakening the MUST requirements here would, in our mind, 
> be tantamount to disabling the extension altogether.

Web browsers have adopted a more minimal solution, namely not permitting renegotiation to change certificates. I doubt that the stricter defense in 5.4 will cause interoperability issues, and it may have been adopted by some of them. Input from browser writers would be greatly appreciated.

Sincerely,
Watson Ladd

>
> Recall that in  the triple handshake attack, the man-in-the-middle is 
> a valid peer who is trying to fool both the client and the server. 
> Hence, we cannot rely on this man-in-the-middle sending the extension. 
> If we allow handshakes without the extension, the attack cannot be prevented, only mitigated.
> The MUSTs in this section try to enforce these mitigations.
>
> Best regards,
> Karthik
>
>
>>
>> Section 5.4 paragraph 4 seems to be undermining earlier requirements, 
>> saying that it MAY be safe (to break rules stated earlier). Taking 
>> this to heart, I would propose that the "MUST abort" clauses in 
>> sections 5.2 and 5.3 be softened to at least allow - and perhaps 
>> recommend - implementations to support this scenario.
>>
>> -------
>>
>> Nits:
>>
>> In section 6.2, it is claimed that the security of TLS depends on the 
>> hash function used being collision resistant, use of MD5 and SHA1 is 
>> NOT RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. 
>> While a worthy goal, I don't believe this enhancement makes migration 
>> away from TLS 1.0 and TLS 1.1 any more urgent. I also don't believe 
>> that TLS depends on the hash function being collision resistant (but 
>> only that it is second preimage resistant).
>>
>> P9: "each other identity" -> "each other's identities"
>> P10: "that where hence" -> "that were hence"
>> P11: "server/ Hence," -> "server. Hence,
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview