Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-sdp-uks-06: (with DISCUSS and COMMENT)

["Martin Thomson" <[e-mail]>]

Pruning aggressively.  PR updated for the easy stuff that didn't require commentary.

On Wed, Aug 7, 2019, at 05:32, Benjamin Kaduk wrote:
> > > Similarly, the current text for the last sentence of Section 3.2 ("In
> > > TLS 1.3, the "external_id_hash" extension MUST be sent in the
> > > EncryptedExtensions message.") can be (mis)read as implying that all
> > > EncryptedExtensions messages sent by TLS servers that implement this
> > > specification must include this extension, which would violate the TLS
> > > extension-negotiation model since it mandates the server sending an
> > > extension without regard to the client having indicated support for the
> > > extension.  Perhaps "MUST NOT be sent in the TLS 1.3 ServerHello message"
> > > conveys the restriction more clearly?
> > > (A similar comment applies to the corresponding statement in Section
> > > 4.3, which interestingly enough already has a "In TLS 1.3, the
> > > "external_session_id" extension MUST NOT be included in a ServerHello."
> > > disclaimer in addition to the problematic sentence.)
> 
> (I'm not sure we quite got all of these in the linked pull request.)

I think that I caught these now.  It seems obvious to me - to the point it doesn't warrant mention - that a server can't send an extension that a client didn't send...  Hence the omission.

> Thanks for helping flesh this out.  Looking back at the text I quoted from
> the document, there are two things that I might want to change (still not
> 100% confident): (1) "unless it is assumed", which is potentially vague
> about who/what is doing the assuming.  Perhaps "unless there is additional
> data exchanged under the assumption that" or similar.  (2) "unless they also
> validate the identity of peers at both layers".  This document describes
> how to validate the identity of the peer at the TLS layer, but I wonder if
> we want some extra reference/guidance on validating the peer's identity at
> the signalling layer.

I've done part of that.  But the latter requires an existence proof.  I don't believe that any signaling system provides the necessary bindings.

In thinking about this, you need channel bindings.  That is, the signaling need to be able to assert not that the peer is the same as the peer at the media layer, but also that the media layer is in the correct place.  So I'm going to say that this is out of scope:

"Such a signaling system, while out of scope for this document, requires that the
signaling layer is authenticated and bound to the TLS connections."

I'm not aware of any such system, as much as it might be desirable.  SIP is still wrestling with the concept of caller identity.  Proper channel bindings seems like a bit much to expect.