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

[Karthikeyan Bhargavan <[e-mail]>]

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.

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. 

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,