Re: [rtcweb] JSEP: Why always offer actpass?

[Roman Shpount <[e-mail]>]

On Fri, Nov 28, 2014 at 10:00 AM, Christer Holmberg <
[e-mail]> wrote:

> RFC 7345 (UDPTL-DTLS) says the following:
>
>         "Once an offer/answer exchange has been completed, either endpoint
> MAY
>         send a new offer in order to modify the session.  The endpoints can
>         reuse the existing DTLS association if the key fingerprint values
> and
>         transport parameters indicated by each endpoint are unchanged.
>         Otherwise, following the rules for the initial offer/answer
> exchange,
>         the endpoints can negotiate and create a new DTLS association and,
>         once created, delete the previous DTLS association, following the
>         same rules for the initial offer/answer exchange.  Each endpoint
>         needs to be prepared to receive data on both the new and old DTLS
>         associations as long as both are alive."
>
> So, I guess that can be read in a way that the setup attribute as such
> does not impact previously negotiated TLS roles - unless the key
> fingerprint values and/or transport parameters are modified.
>
> The SCTP-SDP draft currently says that a subsequent offer must not change
> the previously negotiated roles. But, I guess we could say something
> similar as in RFC 7345.
>

I have struggled with this language quite a bit from the implementation
perspective. I think we need to explicitly state that endpoints MUST reuse
the existing association if the key fingerprint values and transport
parameters indicated by each endpoint are unchanged. The way this language
reads to me is that endpoints can reuse the existing association if they
want to, but they can create a new one if they don't. Also, when this new
association is created, it is unclear if old setup roles MUST be preserved
or if they MUST be selected based on the current offer/answer exchange. It
seems the current specification language is not strong or clear enough on
this topic.

Another implementation issue, unless I am greatly mistaken, is that the web
browsers will not currently handle creating a new DTLS association unless
they expect it to be created. I believe this to be a very critical issue
with DTLS implementations which will not only affect DTLS association
setup, but will also break re-key. I think, we should state that webrtc
end-point should expect new DTLS association with exiting setup roles and
key fingerprint to be created at any time.
_____________
Roman Shpount