Re: 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp

On 27 April 2017 at 15:48, Christer Holmberg
<[email protected]> wrote:
> Is that supported by DTLS? Shouldn¹t it be considered an error if you
> receive a ClientHello that you shouldn¹t receive?

DTLS can handle all sorts of abuse, but I think that Christer is right
in that we shouldn't tolerate a ClientHello if the answer contains
'passive'.

The question as to whether we should mandate this is a tougher one.
All the discussion about unauthenticated media and so forth has
convinced me that the best we get here is an optimization.  I would
prefer to keep any recommendations about how to optimize out of the
specifications.

DTLS will re-send the ClientHello.  The only risk here is that the
DTLS client will give up before the answer arrives.  Frankly, that
doesn't seem particularly likely unless the answerer has insane delays
and glacial signaling.  I really don't want to cater to this to the
extent of mandating special behaviour for handling this corner case.

I'd be OK with a suggestion.  With ICE, it can't send the ServerHello
until it has an ICE password, so the process stalls there.  An offerer
could save a ClientHello and process it when it receives the answer.
That saves some time.

If we want to acknowledge the absence of ICE as well, we could say
that it could allow the handshake to complete, but delay reporting
success until it can validate the remote certificate.

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic