Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-uks

[Martin Thomson <[e-mail]>]

Thanks Adam,

I realize that I failed to push the update, but you should be able to
preview the changes here:

https://martinthomson.github.io/sdp-uks/draft-ietf-mmusic-sdp-uks.html

Thanks for clarifying on the signaling integrity point.  That helps a lot.

On Wed, Oct 31, 2018 at 6:00 AM Adam Roach <[e-mail]> wrote:
> That's the headline point, and why I suggest a move from session ID to
> PASSPoRT.

This might be asking for a bigger change that what I've implemented,
and I might not be able to do that sort of change quickly.  Are you
suggesting that the identity bindings stuff (WebRTC and PASSPoRT) be
made the primary focus of the document?  I think that I agree, but
I'll need a bit more time to knock this into shape.  I've taken ill,
so I'm working at reduced capacity, even if there weren't the usual
pre-meeting deluge to deal with.  I can tweak things to shift the
emphasis more if that helps.

> (Are these bits of institutional knowledge being collected anywhere? I
> reviewed TLS 1.3, and don't recall seeing this principle described.)

No, this design choice is an extension of the ideas from
https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-00 and
other places.

I should be less trite in my explanation.  Cryptographic agility is
still hugely important.  Being able to deploy new crypto is a critical
design consideration.

However, the view is that where existing, well-tested mechanisms can
be used to deploy new crypto, we should rely on that as much as
possible rather than adding new secondary points of articulation that
might fail when we need them.

In this case, I expect SHA-256 to remain in use a very long time.  If
we added a new field for the hash algorithm, that would be a new
extension point.  That extension point is unlikely to see any use in
the foreseeable future (it's SHA-256 all the time!).  Come the time we
want to change it to Kangaroo Twelve or whatever the next hot thing
is, we might find that implementations choke.  That makes a new
extension point more of a liability than an asset.

In this particular case, new extension codepoints aren't scarce enough
to worry about having to burn another one when the time comes to
update the algorithm.  So that's the best option.

Sadly, RFC 7696 doesn't capture this idea well, it even seems to
discourage the practice.  But there you go.

(Sorry, that was long.  Hot-button topic, I guess.)