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

On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan
<karthik.bhargavan@gmail.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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