Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
draft-ietf-mmusic-comedia-tls-06

Sent a reminder to Jonathan yesterday that it's been a week
since the revision request and that 1. the BFCP docs are
waiting in the RFC queue 2. they and this are great and
other will use when approval of this comes 3. want to get
this done before AD transitions.  Asked his ETA on revision.

[Ballot discuss]
Section 6.1 has a funny structure.  The second paragraph says that one
  of the bullets MUST be used.  Then, each of the bullets contains a MAY
  statement.  I think that the following structure is more appropriate:

    The identity presented in the endpoint certificate MUST include an
    IP address, a DNS name, or a URI.  The use of URIs is appropriate
    when the SDP session description was transmitted over a protocol
    (such as SIP [16]) for which the identities of session participants
    are defined by uniform resource identifiers (URIs).  The SDP session
    description MUST present the same identity form, and:

    o  When an IP address is used, the certificate MUST include an
      iPAddress subjectAltName which exactly matches the IP address in
      the connection-address in the 'c' line of the session description.

    o  When a fully-qualified domain name is used, the certificate MUST
      includes a dNSName subjectAltName which exactly matches the DNS
      name in the connection-address in the 'c' line of the session
      description.  DNS names MUST NOT include wildcard patterns.

    o  When an URI is used, the certificate MUST include an
      uniformResourceIdentifier subjectAltName that matches .
      The details of what URIs are appropriate depend on the
      transmitting protocol. See Section 7 for more details on
      URI matching.

[Ballot discuss]
In section 3.2, the document claims that an attacker who can inject
packets is not a threat for the advertized mode of SDP.  I'm confused
why this is true; it seems that such an attacker could claim to be an
someone other than they actually are.  It seems that TLS's
authentication (at least if client certificates are used) could
provide authentication in this case.  I guess I'm just not seeing how
you get from session advertized to the world to not caring about who
sends traffic to it/who joins it.


Section 6.1 requires that the identities of certificates be matched
even if valid integrity-protected fingerprints are available.  I
believe this will create usability problems and will not increase
security.  The identity information may influence whether the
certificate is stored for ssh-style leap of faith authentication in
the future.

The document needs to clarify how an existing ssh-style cache entry
works with situations where integrity-protected fingerprints are
provided.  Whatever we say we should make sure that we do not make it
hard for people to generate ephemeral certs that are refreshed often
in the case where fingerprints are used.



The security considerations section strongly recommends
confidentiality.  What in this protocol requires confidentiality?  I
think integrity is sufficient.

Additional IANA Comments:
We also understand that there will be a RFC-Editor/IANA Note to create an
att-field value sub-registry.  Please make sure registration rules are included as well as any initial registrations.

IANA Comments:
Upon approval of this document the IANA will register 2 SDP Parameters in the following registry:
http://www.iana.org/assignments/sdp-parameters
SDP proto value: 'TCP/TLS'
SDP session and media level attribute: 'fingerprint'

[Ballot discuss]
I'm concerned that the document does not describe more fully the relationship between the SDP in offer/answer mode and the subsequent TLS negotiation.  It describes well the endpoint identification problem, but does not tackle what happens if the TLS negotiation does not (or should not) succeed.  If, for example, the stream cipher offered is TLS_NULL_WITH_NULL_NULL, the protection offered by using TLS would not meet the goals set out in 3.2 of this document.  Deciding whether or not a particular stream cipher or MAC algorithm is acceptable to meet these goals has to happen in the interaction between the application layered above this and the tls connection used.  I think that needs to be called out explicitly in the Security Consideration, to reinforce the idea that the idea that agreeing to TCP/TLS creates the obligation for the application to manage this during the TLS negotiation, rather than relieving it.

[Ballot comment]
Section 1:
  s/privacy/confidentiality/
  s/certificate authority/certification authority/ (2 places)

  Section 3.3:
  s/certificate authority/certification authority/

  Section 6.1:
  s/X.509 certificates/An X.509 certificate/
  s/certify identities/binds an identity and a public key/
  s/needs to certify/MUST include/

  Section 7:
  s/IPSec/IPsec/

[Ballot discuss]
My Last Call comment was not addressed.  I said:
  >
  > The definition of the fingerprint attribute includes:
  >
  >    hash-func          =  "sha-1" / "sha-224" / "sha-256" /
  >                          "sha-384" / "sha-512" /
  >                          "md5" / "md2" / token
  >                          ; Additional hash functions can only come
  >                          ; from updates to RFC 3279
  >
  > RFC 3279 does not define the short strings used here.  RFC 3279
  > provides ASN.1 object identifiers, which are not suitable here.
  > Please say how these identifiers will be assigned.  Will IANA
  > maintain a registry?
  >
  The alternative would be to use the object identifiers from RFC 3279.
  However, this seems like a less attractive way forward...

  Section 6.1 has a funny structure.  The second paragraph says that one
  of the bullets MUST be used.  Then, each of the bullets contains a MAY
  statement.  I think that the following structure is more appropriate:

    The identity presented in the endpoint certificate MUST include an
    IP address, a DNS name, or a URI.  The use of URIs is appropriate
    when the SDP session description was transmitted over a protocol
    (such as SIP [16]) for which the identities of session participants
    are defined by uniform resource identifiers (URIs).  The SDP session
    description MUST present the same identity form, and:

    o  When an IP address is used, the certificate MUST include an
      iPAddress subjectAltName which exactly matches the IP address in
      the connection-address in the 'c' line of the session description.

    o  When a fully-qualified domain name is used, the certificate MUST
      includes a dNSName subjectAltName which exactly matches the DNS
      name in the connection-address in the 'c' line of the session
      description.  DNS names MUST NOT include wildcard patterns.

    o  When an URI is used, the certificate MUST include an
      uniformResourceIdentifier subjectAltName that matches .
      The details of what URIs are appropriate depend on the
      transmitting protocol. See Section 7 for more details on
      URI matching.

Review by Russ Housley on mmusic list in relation to bfcp, resulted in Last Call comment about the hash-func registry.  Have written, also on mmusic list, to Jonathan Lennox, asking him to generate text to create this list.

In November I wrote to Sam asking him for pre-review:  whether md2 was a downref (didn't get that answer...I probably will have to re-last call), whether to draw tls WG's attention to the IETF LC...I didn't see Sam's reply, because of mh filter vagaries, and now am asking for the TLS review late having just spotted the reply

I'm not going to do the downref procedure for MD2, it's going to be removed from the spec - why would you include it, since it's deprecated.  And surely the SHA spec is not a downref; it's been referenced normatively by RFC 4055.

Sent mail to Russ and Sam asking about TLS-related review and downref in Last Call.  Would like to Last Call and do AD/TLS review in parallel.  Would like to start the Last Call asap