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

From: Allison Mankin <[email-masked]>
Date: Mon, 02 Jan 2006 08:44:37 -0800

The Multiparty Multimedia Session Control (MMUSIC) WG 
has completed IETF Last Call on a document related to TLS
called :

 Connection-Oriented Media Transport over the TLS
 Protocol in the Session Descriptoin Protocol (SDP)
  draft-ietf-mmusic-comedia-tls-05.txt

comedia stands for connected media

We (Sec ADs, TSV ADs) realized we should have the TLS WG
give a quick review of the document, since there hasn't
been a look by this working group, though there
have been reviews by security experts with some TLS
expertise.

This document is a dependency for three others, and
it is being reviewed by the IESG on Thursday.  In the
busy-ness of the holidays I wrote this message on Dec
26th, but did not notice when an SMTP hiccup caused the 
email not to go before I went with my family for some
email-free holiday (just back).  If it's possible for
someone give the draft a read this week despite the short
notice, that would be appreciated.

Allison

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Jan 2006 08:54:14 -0800

> notice, that would be appreciated.

I'll take the action item to do this by COB Wed.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Jan 2006 11:36:18 -0800

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?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Jan 2006 17:21:58 -0800

Jonathan Lennox <[email-masked]> writes:
> Good point.
> The other motivation is that the fingerprint be usable by the recipient so
> long as the certificate itself is.

Understood. I just think you need to explain this in the ID :)

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

Sorry, I still don't understand how this requires having a valid
identity. If you're doing ssh doesn't that imply that the cert
isn't signed by a valid signer, in which case whatever's in
the cert DN or subjectAltName is pretty meaningless, right?

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

I don't see anywhere in RFC 2246 which restricts you from sending
bad_certificate outside the handshake, so I think you would probably
use that alert.

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

Well, as far as TLS goes, we only use integer code points, so this
wouldn't buy us anything, but speaking personally I think this
would be a good idea.

-Ekr

---

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.