Draft: draft-ietf-rtcweb-security-arch

Commentary:  noted some outdated references . 
 These are dealing with I - D nit complaints .
Paragraph (version A):
Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel or
channels.  This is performed via DTLS RFC4347 and DTLS-SRTP RFC5763
keying for SRTP RFC3711 for the media channel and SCTP over DTLS I-
D.ietf-tsvwg-sctp-dtls-encaps for data channels.  Specifically, Alice
and Bob perform a DTLS handshake on every channel which has been
established by ICE.  The total number of channels depends on the
amount of muxing; in the most likely case we are using both RTP/RTCP
mux and muxing multiple media streams on the same channel, in which
case there is only one DTLS handshake.  Once the DTLS handshake has
completed, the keys are exported RFC5705 and used to key SRTP for the
media channels.
Paragraph (version B):
Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel or
channels.  This is performed via DTLS RFC4347 and DTLS-SRTP RFC5763
keying for SRTP RFC3711 for the media channel and SCTP over DTLS
RFC8261 for data channels.  Specifically, Alice and Bob perform a
DTLS handshake on every channel which has been established by ICE.
The total number of channels depends on the amount of muxing; in the
most likely case we are using both RTP/RTCP mux and muxing multiple
media streams on the same channel, in which case there is only one
DTLS handshake.  Once the DTLS handshake has completed, the keys are
exported RFC5705 and used to key SRTP for the media channels.
Paragraph (version A):
Implementations MUST implement SRTP RFC3711.  Implementations MUST
implement DTLS RFC4347 and DTLS-SRTP RFC5764 for SRTP keying.
Implementations MUST implement I-D.ietf-tsvwg-sctp-dtls-encaps.
Paragraph (version B):
Implementations MUST implement SRTP RFC3711.  Implementations MUST
implement DTLS RFC4347 and DTLS-SRTP RFC5764 for SRTP keying.
Implementations MUST implement RFC8261.
Paragraph (version A):
This object is encoded in a RFC4627 string for passing to the IdP.
Paragraph (version B):
This object is encoded in a RFC7159 string for passing to the IdP.
Paragraph (version A):
The identity assertion is a JSON RFC4627 encoded dictionary that
contains two values.  The "assertion" attribute contains an opaque
string that is consumed by the IdP.  The "idp" attribute is a
dictionary with one or two further values that identify the IdP, as
described in sec.idp-uri.
Paragraph (version B):
The identity assertion is a JSON RFC7159 encoded dictionary that
contains two values.  The "assertion" attribute contains an opaque
string that is consumed by the IdP.  The "idp" attribute is a
dictionary with one or two further values that identify the IdP, as
described in sec.idp-uri.
Paragraph (version A):
In order to generate an identity assertion, the IdP needs proof of
the user's identity.  It is common practice to authenticate users
(using passwords or multi-factor authentication), then use RFC6265 or
RFC2617 for subsequent exchanges.
Paragraph (version B):
In order to generate an identity assertion, the IdP needs proof of
the user's identity.  It is common practice to authenticate users
(using passwords or multi-factor authentication), then use RFC6265 or
RFC7617 for subsequent exchanges.
Paragraph (version A):
Additionally, any identifier which persists across multiple calls is
potentially a problem for privacy, especially for anonymous calling
services.  Such services SHOULD instruct the browser to use separate
DTLS keys for each call and also to use TURN throughout the call.
Otherwise, the other side will learn linkable information.
Additionally, browsers SHOULD implement the privacy-preserving CNAME
generation mode of I-D.ietf-avtcore-6222bis.
Paragraph (version B):
Additionally, any identifier which persists across multiple calls is
potentially a problem for privacy, especially for anonymous calling
services.  Such services SHOULD instruct the browser to use separate
DTLS keys for each call and also to use TURN throughout the call.
Otherwise, the other side will learn linkable information.
Additionally, browsers SHOULD implement the privacy-preserving CNAME
generation mode of RFC7022.