Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls

Review of draft-ietf-mmusic-comedia-tls-05

SUMMARY
This draft describes how to use SDP to describe TLS
connection-oriented media sessions. The major new thing is putting
certificate fingerprints in the SDP m-line so that as long as you have
signalling integrity you can prevent MITM attacks without 3rd party
certificates.  This draft seems like a good idea and the
implementation seems basically solid, modulo the comments below.

S 5:
I agree that it's fine to use the same hash as was used to
generate the certificate, but I think you need to explain
why it's OK here or in the security considerations section.
The key point is that the same security properties are required
of the hash here as in the certificate signature.

S 6.1:
This text seems to imply that you need to have a valid identity
in the certificate even if it's self-signed and used with a 
fingerprint. From a security perspective, that doesn't really
add any value, since it's the fingerprint, not the identity,
that provides security.

S 6.2:

   certificate does not match the provided fingerprint, or, if there was
   no fingerprint, the certificate identity is incorrect, the server
   endpoint MUST either notify the user or terminate the media
   connection with a bad certificate error.

I assume you mean "bad_certificate" here. Also, why are you
generating that if no fingerprint is provided? That's not a 
TLS-level error, it's an error at the upper layer protocol. You
shouldn't even be negotiating TLS if there's no fingerprint.

   Note that when the offer/answer model is being used, it is possible
   for a media connection to outrace the answer back to the offerer.
   Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
   role, it MUST (as specified in the Connection-Oriented Media
   specification [2]) begin listening for an incoming connection as soon
   as it sends its offer.  However, because its peer's media connection
   may outrace its answer, it MUST NOT definitively accept the peer's
   certificate until it has received and processed the SDP answer.

What does "definitively accept" mean here. What I would assume would
be that you would let the TLS handshake complete but then defer
some other action till you had the fingrerprint. But what action?

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls