Re: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)

[Paul Kyzivat <[e-mail]>]

Alissa,

On 5/28/19 3:35 PM, Alissa Cooper via Datatracker wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 8.2.8:
> 
> "In the RFC specifications that register new values for SDP "media",
>     "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
>     authors MUST include the following information for IANA to place in
>     the appropriate registry:"
> 
> It doesn't look like all the fields that are listed after this text actually
> appear in the registries. For some of these I don't see why the information
> would be put into the registries (e.g., contact name, contact email address,
> since those appear in the RFCs themselves). I think this needs to be clarified.

OK. There are two things going on here: the information that must be 
provided when registering a new value, and then which of those items 
need to appear in the registry. The distinction isn't clear.

For items where the registration requirements are less that "document 
required" the information must be in the registry since there is no 
place else for it to appear. But when a document is required then in 
principle the name of the item and a reference to the document is all 
that is *necessary* in the registry, and any additional information is 
for convenience of access.

I've found that this distinction often isn't clearly made, especially in 
older stuff.

I can look into this further for all the SDP registries.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 5.1:
> 
> Since both this document and RFC 4566 specify version 0 and this version makes
> semantic and syntactic changes, does that mean the protocol versioning is
> non-functional? Or if not, what kinds of changes would require a new version
> number?

It appears that the version field was included in SDP without much 
thought. There are no normative procedures defined for how to deal with 
differing version numbers, so I expect that the result of attempting to 
change the version number is unknown. Probably many implementations 
would not notice, while some might reject a version other than zero.

Given that we have gone 20 years without a version number change, I 
wouldn't attempt one now. Along the way the rule with changes has always 
been to do them in a backward compatible way. AFAIK that is true with 
the changes in this document as well.

> Section 7:
> 
> "Use of the "k=" line poses a significant security risk, since it
>     conveys session encryption keys in the clear.  SDP MUST NOT be used
>     to convey keying material, unless it can be guaranteed that the
>     channel over which the SDP is delivered is both private and
>     authenticated.  Moreover, the "k=" line provides no way to indicate
>     or negotiate cryptographic key algorithms.  As it provides for only a
>     single symmetric key, rather than separate keys for confidentiality
>     and integrity, its utility is severely limited.  The "k=" line MUST
>     NOT be used, as discussed in Section 5.12."
> 
> It's odd to me that this text was retained from RFC 4566 as-is, except for the
> last sentence. I would have expected this to lead with something like 'Use of
> the "k=" line is obsolete due to security risk.' And then perhaps some of the
> rest of the text could remain by way of explanation why it was obsoleted.

IIRC the existing text was the result of security review comments and 
subsequent discussions. Do you want us to revisit those?

> Section 8.2.8:
> 
> "IANA may refer any registration to the IESG for review, and may
>     request revisions to be made before a registration will be made."
> 
> This is trivially true and would be better left out, using RFC 8126 as the
> definitive guidance instead.

I never noticed this. I checked, and it has been present in exactly this 
form since RFC2327 in 1998. I don't recall seeing any language like this 
in any other IANA considerations section. I'm inclined to simply remove it.

	Thanks,
	Paul