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

[Marsh Ray <[e-mail]>]

While there are limitations of this approach, at least for the current TLS protocol versions users of client certs need renegotiation to avoid sending the client cert in the clear. Hopefully something better will be possible for TLS 1.3.

As a data point, the 5 year experience with the Renegotiation Indication extension [RFC 5746] shows that we have achieved something like (100-2.9) = 97.1% coverage of sites that refuse insecure renegotiation, the vast majority of which support of the new extension.
https://www.trustworthyinternet.org/ssl-pulse/

Thanks,

- Marsh

-----Original Message-----
From: Watson Ladd [mailto:[e-mail]] 
Sent: Thursday, April 16, 2015 8:33 AM
To: Karthikeyan Bhargavan
Cc: Radia Perlman; [e-mail]; The IESG; [e-mail]
Subject: Re: [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.