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

From: Jonathan Lennox <[email-masked]>
Date: Mon, 2 Jan 2006 20:09:12 -0500

On Monday, January 2 2006, "Eric Rescorla" wrote to "[email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]" 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
[email-masked]

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 15:22:59 -0500

Especially in the case where a fingerprint is present I think that the
requirements for identity matching would introduce usability problems
with no security benefit.  So I strongly argue for relaxing the
identity checking in the case where a fingerprint is available in an
integrity protected SDP exchange.

In the case where the cert is being matched against a trust anchor
through the process described in RFC 3280, the identity constraints
given in this document (or similar constraints) are absolutely
essential.

In the case where you are doing ssh-style leap of faith you do need to
decide what identity you are binding the leap of faith entry to in
your cache.  In that case the identity requirements may be helpful but
are not strict security requirements.

If you are going to support ssh-style leap of faith you do need to be
careful not to make rekeying/changing a cert harder than it needs to
be.  In particular, the user should not get a warning because there is
a leap of faith cache entry with a different certificate in it and a
valid fingerprint is presented in an integrity protected SDP session.
I'm not sure updating the cache entry would be good in that case, but
presenting a warning to the user because the cert changed would
definitely be a bad idea because it would discourage rekeying.

Now you do need to present the warning in the case where the SDP
session is not integrity protected.

--Sam

P.S. If I was too terse I can expand.