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

[Jonathan Lennox <[e-mail]>]

On Monday, January 2 2006, "Eric Rescorla" wrote to "[e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]" saying:

> 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.

Good point.

The other motivation is that the fingerprint be usable by the recipient so
long as the certificate itself is.

> 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.

The motivation here was to allow SSH-style security (per-endpoint credential
cacheing) if the SDP isn't secured, or is only secured hop-by-hop.  Perhaps
this isn't useful?

> 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.

This is an editing error -- earlier versions of the draft allowed
fingerprints to be optional.  

>    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?

I'm not sure.  Perhaps this should be re-worded as "it MUST NOT assume the data
transmitted over the TLS connection is valid until it has received a
matching fingerprint in the SDP answer.  If the received fingerprint is
invalid, the TLS connection SHOULD be torn down."  (Is there an appropriate
TLS message for "I just discovered your certificate is invalid"?)

One other question -- in the IESG review, the issue was raised that there's
not currently an IANA registry for textual names of hash functions.  I
agreed to add an IANA considerations section for this purpose, but I was
wondering if there's interest in having this registry be more broadly scoped
than just for comedia-tls?

-- 
Jonathan Lennox
[e-mail]

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic