Skip to main content

WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-20

Revision differences

Document history

Date Rev. By Action
2021-01-14
20 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-06-29
20 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-03-16
20 (System) RFC Editor state changed to RFC-EDITOR from REF
2019-10-30
20 (System) RFC Editor state changed to REF from EDIT
2019-08-16
20 (System) RFC Editor state changed to EDIT from MISSREF
2019-08-15
20 (System) RFC Editor state changed to MISSREF from EDIT
2019-08-15
20 (System) RFC Editor state changed to EDIT from MISSREF
2019-08-07
20 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-08-06
20 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-08-01
20 Tero Kivinen Assignment of request for Last Call review by SECDIR to Taylor Yu was marked no-response
2019-07-25
20 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-07-25
20 (System) IANA Action state changed to In Progress from On Hold
2019-07-24
20 (System) IANA Action state changed to On Hold from In Progress
2019-07-22
20 (System) RFC Editor state changed to MISSREF
2019-07-22
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-07-22
20 (System) Announcement was received by RFC Editor
2019-07-22
20 (System) IANA Action state changed to In Progress
2019-07-22
20 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-20.txt
2019-07-22
20 (System) New version approved
2019-07-22
19 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-07-22
19 Cindy Morgan IESG has approved the document
2019-07-22
19 Cindy Morgan Closed "Approve" ballot
2019-07-22
20 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2019-07-22
20 Eric Rescorla Uploaded new revision
2019-07-22
19 Cindy Morgan Ballot approval text was generated
2019-07-22
19 Adam Roach IESG state changed to Approved-announcement to be sent from IESG Evaluation::External Party
2019-07-22
19 Adam Roach RFC Editor Note was changed
2019-07-22
19 Adam Roach RFC Editor Note for ballot was generated
2019-07-22
19 Adam Roach RFC Editor Note for ballot was generated
2019-07-22
19 Adam Roach Last call announcement was generated
2019-07-12
19 Benjamin Kaduk
[Ballot comment]
Thanks for addressing my Discuss points!
I'll leave the original Comment section below, as I note that at least one
issue remains (I …
[Ballot comment]
Thanks for addressing my Discuss points!
I'll leave the original Comment section below, as I note that at least one
issue remains (I spot-checked the SDP Offer/Answer reference, that still
points to RFC 6454, which is "the Web Origin Concept".  I didn't make any
attempt to trim points that did get addressed.

Section 3

(My comment about TCB and the other browser from the companion document
is probably relevant here, too.)

Section 4.1

  This message is sent to the signaling server, e.g., by XMLHttpRequest
  [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS
  [RFC5246].  The signaling server processes the message from Alice's

This is the optimistic "best security" case, and we already say we're
talking to the signaling server over HTTPS, so it should be safe to just
say "over TLS" and drop the "preferably".  (Also, s/5246/8446.)

  call and to Alice's identity.  In this case, Alice has provided an
  identity assertion and so Bob's browser contacts Alice's identity
  provider (again, this is done in a generic way so the browser has no
  specific knowledge of the IdP) to verify the assertion.  This allows
  the browser to display a trusted element in the browser chrome
  indicating that a call is coming in from Alice.  [...]

I think I'm confused.  We're displaying trusted browser chrome based on
an assertion from some IdP that we have no relationship with and no
reason to trust?

Section 4.3

  Once the ICE checks have completed [more specifically, once some ICE
  checks have completed], [...]

nit: that's not really more specific.  Maybe "Once the requisite ICE
checks have completed"?

Section 5

I see that the 4566  includes the pad characters, though
sometimes we will mention explicitly whether they are or are not
included.

  Note that long lines in the example are folded to meet the column
  width constraints of this document; the backslash ("\") at the end of
  a line and the carriage return that follows shall be ignored.

leading whitespace, too, right?

Section 5.1

  This section defines the SDP Offer/Answer [RFC6454] considerations
  for the SDP 'identity' attribute.

6454 is "the Web Origin Concept"; presumably this is supposed to be
4566 (or 3264?).

Section 5.1.3

I feel like we need some text here about the (non?)trustworthiness of
the IdP.

Section 5.1.4

I'm a bit confused at what's going on here.  Is "MAY send the same"
supposed to prevent changing it?  If I don't send it, does that identity
continue to apply to the existing DTLS connections but not any new ones
generated by the session modification?  Am I allowed to send a different
one?

                  Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
  requires that each media section use the same set of fingerprints for
  every media section.

nit: is this "each media section"/"every media section" redundant?

Section 6.1

  Also note that the security architecture depends on the keying
  material not being available to move between origins.  But, it is
  assumed that the identity assertion can be passed to anyone that the
  page cares to.

There may be some (weak) privacy considerations if this is literally
anyone, since it would allow some observers (with weird
abilities/restrictions) to associate "real" identities with keys in a
way that they couldn't otherwise do.

Section 6.2

  Because HTTP origins cannot be securely established against network
  attackers, implementations MUST NOT allow the setting of permanent
  access permissions for HTTP origins.  Implementations MUST refuse all
  permissions grants for HTTP origins.

Just to check: this last sentence applies for one-time requets, too?

                                          The semantics of this request
  are that the media stream from the camera and microphone will only be
  routed through a connection which has been cryptographically verified
  (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
  handshake) as being associated with the stated identity.  [...]

Does this need to be an exhaustive list or can we leave it open-ended?
Also, it may be appropriate to mention some concept of "IdP trusted to
authenticate the stated identity".

  API Requirement:  The API MUST provide a mechanism for the requesting
      JS to relinquish the ability to see or modify the media (e.g., via
      MediaStream.record()).  [...]

Do we need to say anything about that state transition being visible to
the peer, here?

  UI Requirement:  If the UI indication of camera/microphone use are
      [...]
      camera and microphone input when the indication is hidden.  [Note:
      this may not be necessary in systems that are non-windows-based
      but that have good notifications support, such as phones.]

nit: s/windows/window/?

  Clients MAY permit the formation of data channels without any direct
  user approval.  Because sites can always tunnel data through the
  server, further restrictions on the data channel do not provide any
  additional security.  (though see Section 6.3 for a related issue).

Is there anything to say about why clients might not opt to do so (and
what such approval might look like)?

(My comments about "verified user" including the IdP in some way will
apply here as well.)

Section 6.3

  While continuing consent is required, the ICE [RFC8445]; Section 10
  keepalives use STUN Binding Indications which are one-way and
  therefore not sufficient.  The current WG consensus is to use ICE

Is the "the current WG consensus" language going to age well?

  Binding Requests for continuing consent freshness.  ICE already
  requires that implementations respond to such requests, so this
  approach is maximally compatible.  A separate document will profile
  the ICE timers to be used; see [RFC7675].

Is there a WIP draft for this separate document?

Section 6.4

  API Requirement:  The API MUST provide a mechanism to allow the JS to
      suppress ICE negotiation (though perhaps to allow candidate
      gathering) until the user has decided to answer the call [note:
      determining when the call has been answered is a question for the
      JS.]  This enables a user to prevent a peer from learning their IP
      address if they elect not to answer a call and also from learning
      whether the user is online.

nit: maybe make it more clear that this only applies for incoming calls?

Section 6.5

                                                          Media traffic
  MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
  implementations MUST NOT negotiate cipher suites with NULL encryption
  modes.  [...]

It's not clear to me that the "that is" reflects a strict equivalence;
would "in particular" be more appropriate?
(Also, "cipher suite" is a DTLS term, but do we want to disambiguate
explicitly?)

[obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note]

  Implementations MUST NOT implement DTLS renegotiation and MUST reject
  it with a "no_renegotiation" alert if offered.

"MUST NOT implement" isn't really something that 2119 language can
enforce; "MUST NOT use" is the best we can get.

  Endpoints MUST NOT implement TLS False Start [RFC7918].

(7918 doesn't claim to be applicable to DTLS anyway)


  API Requirement:  Unless the user specifically configures an external
      key pair, different key pairs MUST be used for each origin.  (This
      avoids creating a super-cookie.)

nit: might be appropriate to note why we care about a super-cookie (and
what it is)

      *  The "security characteristics" MUST indicate the cryptographic
        algorithms in use (For example: "AES-CBC".)  However, if Null
        ciphers are used, that MUST be presented to the user at the
        top-level UI.

I'm not sure I see anywhere that we allow the usage of null ciphers.

Section 7

  Recently, a number of Web-based identity technologies (OAuth,
  Facebook Connect etc.) have been developed.  While the details vary,
  what these technologies share is that they have a Web-based (i.e.,
  HTTP/HTTPS) identity provider which attests to your identity.  For
  instance, if I have an account at example.org, I could use the
  example.org identity provider to prove to others that I was
  alice@example.org.  [...]

I agree with Alissa that the first person is not needed here.

Section 7.1

  Third-Party:  IdPs which don't have control of their section of the
      [...]
      identity space.  Probably the best-known example of a third-party
      identity provider is SSL/TLS certificates, where there are a large
      number of CAs all of whom can attest to any domain name.

This probably needs some qualifier, given recent developments with CAA
and similar mechanisms.

  If an AP is authenticating via an authoritative IdP, then the RP does
  not need to explicitly configure trust in the IdP at all.  The

The RP still needs to establish somehow that the IdP in use is in fact
an authoritative IdP, though!

Section 7.2

  In order to provide security without trusting the calling site, the
  PeerConnection component of the browser must interact directly with
  the IdP.  The details of the mechanism are described in the W3C API
  specification, but the general idea is that the PeerConnection

A reference to that W3C API spec might be handy.

Section 7.3

  There are two parts to this work:

  o  The precise information from the signaling message that must be
      cryptographically bound to the user's identity and a mechanism for
      carrying assertions in JSEP messages.  This is specified in
      Section 7.4.

nit: the grammar is a bit weird here, as the "information from the
signaling message" isn't really a part of this work, but rather the
specification for what information that is.

Section 7.4

The indentation of the line with "}, {" is a bit confusing.

  This object is encoded in a JSON [RFC8259] string for passing to the
  IdP.  The identity assertion returned by the IdP, which is encoded in

I'm a little confused what this "encoded in a JSON string" is supposed
to mean.

  This structure does not need to be interpreted by the IdP or the IdP
  proxy.  It is consumed solely by the RP's browser.  The IdP merely
  treats it as an opaque value to be attested to.  Thus, new parameters
  can be added to the assertion without modifying the IdP.

The IdP probably wants to know enough about its structure to not turn
into a signing oracle for other protocols, though.

Section 7.4.1

(RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention
that.)

It's a little surprising to see sha-1 fingerprint in use (since
"examples are recommendations"), though I didn't find anything that
would actually formally deprecate such usage yet.

  Note that long lines in the example are folded to meet the column
  width constraints of this document; the backslash ("\") at the end of
  a line and the carriage return that follows shall be ignored.

leading whitespace, too, right?

Section 7.5.2

(Still need to say how it's know than authoritative assertions are in
fact authoritative for what they claim.)

Section 7.6

  The input to identity assertion is the JSON-encoded object described
  in Section 7.4 that contains the set of certificate fingerprints the
  browser intends to use.  This string is treated as opaque from the
  perspective of the IdP.

(IdP still doesn't want to become a signing oracle.)

  For use in signaling, the assertion is serialized into JSON,
  Base64-encoded [RFC4648], and used as the value of the "identity"
  attribute.

nit: it's unclear that "serialized into JSON" adds any value, since the
thing is defined to be a JSON object.

Section 7.7

I think that the framing of HTTP Basic (7617) here is not great.
RFC 7235 might be a better link for HTTP Authentication in general, and
of course there are mechanisms that don't include sending the password
in plaintext, like SCRAM (RFC7804).

Section 8

  The IdP proxy verifies the assertion.  Depending on the identity
  protocol, the proxy might contact the IdP server or other servers.
  For instance, an OAuth-based protocol will likely require using the
  IdP as an oracle, whereas with a signature-based scheme might be able
  to verify the assertion without contacting the IdP, provided that it
  has cached the relevant public key.

IMPORTANT: Do we need a freshness property for the assertion?  Some of
these schemes do not provide freshness.

  Figure 6 shows an example response formatted as JSON for illustrative
  purposes.

(Doesn't the W3C API spec need to say how the response is formatted?  Is
the JSON formatting actually "illustrative" then, or is this just an
example output?)

Section 8.1

  2.  If the domain portion of the string is not equal to the domain
      name of the IdP proxy, then the PeerConnection object MUST reject
      the assertion unless:

Reading closely, I think this is supposed to be "unless either", but
it's easy to assume it should be read as "unless both", so I think
clarification is in order.

  Any "@" or "%" characters in the "user" portion of the identity MUST
  be escaped according to the "Percent-Encoding" rules defined in

We just said in the first paragraph that "user" has "any character
except '@'", so this is a bit redundant.

Section 9.1

            Users who wish to assure themselves of security against a
  malicious identity provider can only do so by verifying peer
  credentials directly, e.g., by checking the peer's fingerprint
  against a value delivered out of band.

I suppose an "untrustworthy" IdP is basically a malicious one, though
there are perhaps some subtleties that could be distinguished here.

  In order to protect against malicious content JavaScript, that
  JavaScript MUST NOT be allowed to have direct access to---or perform
  computations with---DTLS keys.  For instance, if content JS were able
  to compute digital signatures, then it would be possible for content
  JS to get an identity assertion for a browser's generated key and
  then use that assertion plus a signature by the key to authenticate a
  call protected under an ephemeral Diffie-Hellman (DH) key controlled
  by the content JS, thus violating the security guarantees otherwise
  provided by the IdP mechanism.

I don't think I fully understand the scenario described in this last
sentence.  Is "compute digital signatures" supposed to be with some
specific secret key, and/or is "a browser's generated key" one that is
covered under the fingerprint in the IdP assertion?

Section 9.2

  Otherwise, the other side will learn linkable information.

nit: "linkable information that would allow them to correlate the
browser across multiple calls".

Section 9.3

  Consider the case of a call center which accepts calls via WebRTC.
  An attacker proxies the call center's front-end and arranges for
  multiple clients to initiate calls to the call center.  Note that
  this requires user consent in many cases but because the data channel
  does not need consent, he can use that directly.

I think I'm missing a step here.  How is the attacker using the data
channel directly when the point is to get the multiple browsers to send
the data on the data channel?

              Muxing multiple media flows over a single transport makes
  it harder to individually suppress a single flow by denying ICE
  keepalives.  Either media-level (RTCP) mechanisms must be used or the
  implementation must deny responses entirely, thus terminating the
  call.

nit: "must be used to suppress the misbehaving flow", I think.

Section 9.4.3

  The "origin" field of the signature request can be used to check that
  the user has agreed to disclose their identity to the calling site;
  because it is supplied by the PeerConnection it can be trusted to be
  correct.

I don't see an "origin" field in the signature request; is this supposed
to be the "domain"?

Section 9.4.5.1

nit: it might be friendlier to the reader to prefix this with "When
popup blocking is in use, ".

Section 13.2

It's perhaps debatable that JSEP is only an informative reference.
2019-07-12
19 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-07-12
19 Adam Roach IESG state changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup
2019-07-12
19 Adam Roach Waiting until July 22 to put in RFC Editor Queue, per https://mailarchive.ietf.org/arch/msg/rtcweb/n-WNLc5_9qAITUECgxJpe6C__hY
2019-07-12
19 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS.
2019-07-12
19 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2019-07-07
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-07-07
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-07-07
19 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-19.txt
2019-07-07
19 (System) New version approved
2019-07-07
19 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2019-07-07
19 Eric Rescorla Uploaded new revision
2019-03-10
18 Tim Chown Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. Sent review to list.
2019-03-07
18 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-03-07
18 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-03-06
18 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2019-03-06
18 Benjamin Kaduk
[Ballot discuss]
The question of when an IdP is trustworthy, whether at all (even for
"authoritative" IdPs) or for a specific user, is a pretty …
[Ballot discuss]
The question of when an IdP is trustworthy, whether at all (even for
"authoritative" IdPs) or for a specific user, is a pretty core topic for
the identity assertion scheme presented here.  These topics do get
explained in localized sections of the document, but there seem to be
other portions of the text that do not really acknowledge the risks.
I've tried to note these in the COMMENT section (though having finished
reading the document, perhaps I am overzealous about determination that
an authoritative IdP is indeed authoritative).

I also think that we need to be more careful about having the IdP know
the semantics of what it's signing (or otherwise attesting to), so that
it does not turn into a signing oracle, etc..

The "Modifying the Session" treatment for the SDP "identity" attribute
seems incompletely specified.

I'm a bit unclear about how the port in the IdP URI's Authority (Section
7.5) would get discovered.  If it can be remotely supplied, there may be
risks in just trusting blindly whatever value is received.

It seems like there are some unstated privacy considerations in allowing
the IdP proxy to automatically generate an assertion (that reveals the
user's identity) at the request of javascript from the calling
application, as described in Section 7.7.

Section 9.4 talks about how the IdP is attesting to the binding of the
user identified in the assertion with the key fingerprints, but in
Sections 7.4 and 7.6 we claim that this assertion is "opaque to the
IdP"; these statements appear to be in conflict with each other.
2019-03-06
18 Benjamin Kaduk
[Ballot comment]
Section 3

(My comment about TCB and the other browser from the companion document
is probably relevant here, too.)

Section 4.1

  This …
[Ballot comment]
Section 3

(My comment about TCB and the other browser from the companion document
is probably relevant here, too.)

Section 4.1

  This message is sent to the signaling server, e.g., by XMLHttpRequest
  [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS
  [RFC5246].  The signaling server processes the message from Alice's

This is the optimistic "best security" case, and we already say we're
talking to the signaling server over HTTPS, so it should be safe to just
say "over TLS" and drop the "preferably".  (Also, s/5246/8446.)

  call and to Alice's identity.  In this case, Alice has provided an
  identity assertion and so Bob's browser contacts Alice's identity
  provider (again, this is done in a generic way so the browser has no
  specific knowledge of the IdP) to verify the assertion.  This allows
  the browser to display a trusted element in the browser chrome
  indicating that a call is coming in from Alice.  [...]

I think I'm confused.  We're displaying trusted browser chrome based on
an assertion from some IdP that we have no relationship with and no
reason to trust?

Section 4.3

  Once the ICE checks have completed [more specifically, once some ICE
  checks have completed], [...]

nit: that's not really more specific.  Maybe "Once the requisite ICE
checks have completed"?

Section 5

I see that the 4566  includes the pad characters, though
sometimes we will mention explicitly whether they are or are not
included.

  Note that long lines in the example are folded to meet the column
  width constraints of this document; the backslash ("\") at the end of
  a line and the carriage return that follows shall be ignored.

leading whitespace, too, right?

Section 5.1

  This section defines the SDP Offer/Answer [RFC6454] considerations
  for the SDP 'identity' attribute.

6454 is "the Web Origin Concept"; presumably this is supposed to be
4566 (or 3264?).

Section 5.1.3

I feel like we need some text here about the (non?)trustworthiness of
the IdP.

Section 5.1.4

I'm a bit confused at what's going on here.  Is "MAY send the same"
supposed to prevent changing it?  If I don't send it, does that identity
continue to apply to the existing DTLS connections but not any new ones
generated by the session modification?  Am I allowed to send a different
one?

                  Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
  requires that each media section use the same set of fingerprints for
  every media section.

nit: is this "each media section"/"every media section" redundant?

Section 6.1

  Also note that the security architecture depends on the keying
  material not being available to move between origins.  But, it is
  assumed that the identity assertion can be passed to anyone that the
  page cares to.

There may be some (weak) privacy considerations if this is literally
anyone, since it would allow some observers (with weird
abilities/restrictions) to associate "real" identities with keys in a
way that they couldn't otherwise do.

Section 6.2

  Because HTTP origins cannot be securely established against network
  attackers, implementations MUST NOT allow the setting of permanent
  access permissions for HTTP origins.  Implementations MUST refuse all
  permissions grants for HTTP origins.

Just to check: this last sentence applies for one-time requets, too?

                                          The semantics of this request
  are that the media stream from the camera and microphone will only be
  routed through a connection which has been cryptographically verified
  (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
  handshake) as being associated with the stated identity.  [...]

Does this need to be an exhaustive list or can we leave it open-ended?
Also, it may be appropriate to mention some concept of "IdP trusted to
authenticate the stated identity".

  API Requirement:  The API MUST provide a mechanism for the requesting
      JS to relinquish the ability to see or modify the media (e.g., via
      MediaStream.record()).  [...]

Do we need to say anything about that state transition being visible to
the peer, here?

  UI Requirement:  If the UI indication of camera/microphone use are
      [...]
      camera and microphone input when the indication is hidden.  [Note:
      this may not be necessary in systems that are non-windows-based
      but that have good notifications support, such as phones.]

nit: s/windows/window/?

  Clients MAY permit the formation of data channels without any direct
  user approval.  Because sites can always tunnel data through the
  server, further restrictions on the data channel do not provide any
  additional security.  (though see Section 6.3 for a related issue).

Is there anything to say about why clients might not opt to do so (and
what such approval might look like)?

(My comments about "verified user" including the IdP in some way will
apply here as well.)

Section 6.3

  While continuing consent is required, the ICE [RFC8445]; Section 10
  keepalives use STUN Binding Indications which are one-way and
  therefore not sufficient.  The current WG consensus is to use ICE

Is the "the current WG consensus" language going to age well?

  Binding Requests for continuing consent freshness.  ICE already
  requires that implementations respond to such requests, so this
  approach is maximally compatible.  A separate document will profile
  the ICE timers to be used; see [RFC7675].

Is there a WIP draft for this separate document?

Section 6.4

  API Requirement:  The API MUST provide a mechanism to allow the JS to
      suppress ICE negotiation (though perhaps to allow candidate
      gathering) until the user has decided to answer the call [note:
      determining when the call has been answered is a question for the
      JS.]  This enables a user to prevent a peer from learning their IP
      address if they elect not to answer a call and also from learning
      whether the user is online.

nit: maybe make it more clear that this only applies for incoming calls?

Section 6.5

                                                          Media traffic
  MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
  implementations MUST NOT negotiate cipher suites with NULL encryption
  modes.  [...]

It's not clear to me that the "that is" reflects a strict equivalence;
would "in particular" be more appropriate?
(Also, "cipher suite" is a DTLS term, but do we want to disambiguate
explicitly?)

[obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note]

  Implementations MUST NOT implement DTLS renegotiation and MUST reject
  it with a "no_renegotiation" alert if offered.

"MUST NOT implement" isn't really something that 2119 language can
enforce; "MUST NOT use" is the best we can get.

  Endpoints MUST NOT implement TLS False Start [RFC7918].

(7918 doesn't claim to be applicable to DTLS anyway)


  API Requirement:  Unless the user specifically configures an external
      key pair, different key pairs MUST be used for each origin.  (This
      avoids creating a super-cookie.)

nit: might be appropriate to note why we care about a super-cookie (and
what it is)

      *  The "security characteristics" MUST indicate the cryptographic
        algorithms in use (For example: "AES-CBC".)  However, if Null
        ciphers are used, that MUST be presented to the user at the
        top-level UI.

I'm not sure I see anywhere that we allow the usage of null ciphers.

Section 7

  Recently, a number of Web-based identity technologies (OAuth,
  Facebook Connect etc.) have been developed.  While the details vary,
  what these technologies share is that they have a Web-based (i.e.,
  HTTP/HTTPS) identity provider which attests to your identity.  For
  instance, if I have an account at example.org, I could use the
  example.org identity provider to prove to others that I was
  alice@example.org.  [...]

I agree with Alissa that the first person is not needed here.

Section 7.1

  Third-Party:  IdPs which don't have control of their section of the
      [...]
      identity space.  Probably the best-known example of a third-party
      identity provider is SSL/TLS certificates, where there are a large
      number of CAs all of whom can attest to any domain name.

This probably needs some qualifier, given recent developments with CAA
and similar mechanisms.

  If an AP is authenticating via an authoritative IdP, then the RP does
  not need to explicitly configure trust in the IdP at all.  The

The RP still needs to establish somehow that the IdP in use is in fact
an authoritative IdP, though!

Section 7.2

  In order to provide security without trusting the calling site, the
  PeerConnection component of the browser must interact directly with
  the IdP.  The details of the mechanism are described in the W3C API
  specification, but the general idea is that the PeerConnection

A reference to that W3C API spec might be handy.

Section 7.3

  There are two parts to this work:

  o  The precise information from the signaling message that must be
      cryptographically bound to the user's identity and a mechanism for
      carrying assertions in JSEP messages.  This is specified in
      Section 7.4.

nit: the grammar is a bit weird here, as the "information from the
signaling message" isn't really a part of this work, but rather the
specification for what information that is.

Section 7.4

The indentation of the line with "}, {" is a bit confusing.

  This object is encoded in a JSON [RFC8259] string for passing to the
  IdP.  The identity assertion returned by the IdP, which is encoded in

I'm a little confused what this "encoded in a JSON string" is supposed
to mean.

  This structure does not need to be interpreted by the IdP or the IdP
  proxy.  It is consumed solely by the RP's browser.  The IdP merely
  treats it as an opaque value to be attested to.  Thus, new parameters
  can be added to the assertion without modifying the IdP.

The IdP probably wants to know enough about its structure to not turn
into a signing oracle for other protocols, though.

Section 7.4.1

(RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention
that.)

It's a little surprising to see sha-1 fingerprint in use (since
"examples are recommendations"), though I didn't find anything that
would actually formally deprecate such usage yet.

  Note that long lines in the example are folded to meet the column
  width constraints of this document; the backslash ("\") at the end of
  a line and the carriage return that follows shall be ignored.

leading whitespace, too, right?

Section 7.5.2

(Still need to say how it's know than authoritative assertions are in
fact authoritative for what they claim.)

Section 7.6

  The input to identity assertion is the JSON-encoded object described
  in Section 7.4 that contains the set of certificate fingerprints the
  browser intends to use.  This string is treated as opaque from the
  perspective of the IdP.

(IdP still doesn't want to become a signing oracle.)

  For use in signaling, the assertion is serialized into JSON,
  Base64-encoded [RFC4648], and used as the value of the "identity"
  attribute.

nit: it's unclear that "serialized into JSON" adds any value, since the
thing is defined to be a JSON object.

Section 7.7

I think that the framing of HTTP Basic (7617) here is not great.
RFC 7235 might be a better link for HTTP Authentication in general, and
of course there are mechanisms that don't include sending the password
in plaintext, like SCRAM (RFC7804).

Section 8

  The IdP proxy verifies the assertion.  Depending on the identity
  protocol, the proxy might contact the IdP server or other servers.
  For instance, an OAuth-based protocol will likely require using the
  IdP as an oracle, whereas with a signature-based scheme might be able
  to verify the assertion without contacting the IdP, provided that it
  has cached the relevant public key.

IMPORTANT: Do we need a freshness property for the assertion?  Some of
these schemes do not provide freshness.

  Figure 6 shows an example response formatted as JSON for illustrative
  purposes.

(Doesn't the W3C API spec need to say how the response is formatted?  Is
the JSON formatting actually "illustrative" then, or is this just an
example output?)

Section 8.1

  2.  If the domain portion of the string is not equal to the domain
      name of the IdP proxy, then the PeerConnection object MUST reject
      the assertion unless:

Reading closely, I think this is supposed to be "unless either", but
it's easy to assume it should be read as "unless both", so I think
clarification is in order.

  Any "@" or "%" characters in the "user" portion of the identity MUST
  be escaped according to the "Percent-Encoding" rules defined in

We just said in the first paragraph that "user" has "any character
except '@'", so this is a bit redundant.

Section 9.1

            Users who wish to assure themselves of security against a
  malicious identity provider can only do so by verifying peer
  credentials directly, e.g., by checking the peer's fingerprint
  against a value delivered out of band.

I suppose an "untrustworthy" IdP is basically a malicious one, though
there are perhaps some subtleties that could be distinguished here.

  In order to protect against malicious content JavaScript, that
  JavaScript MUST NOT be allowed to have direct access to---or perform
  computations with---DTLS keys.  For instance, if content JS were able
  to compute digital signatures, then it would be possible for content
  JS to get an identity assertion for a browser's generated key and
  then use that assertion plus a signature by the key to authenticate a
  call protected under an ephemeral Diffie-Hellman (DH) key controlled
  by the content JS, thus violating the security guarantees otherwise
  provided by the IdP mechanism.

I don't think I fully understand the scenario described in this last
sentence.  Is "compute digital signatures" supposed to be with some
specific secret key, and/or is "a browser's generated key" one that is
covered under the fingerprint in the IdP assertion?

Section 9.2

  Otherwise, the other side will learn linkable information.

nit: "linkable information that would allow them to correlate the
browser across multiple calls".

Section 9.3

  Consider the case of a call center which accepts calls via WebRTC.
  An attacker proxies the call center's front-end and arranges for
  multiple clients to initiate calls to the call center.  Note that
  this requires user consent in many cases but because the data channel
  does not need consent, he can use that directly.

I think I'm missing a step here.  How is the attacker using the data
channel directly when the point is to get the multiple browsers to send
the data on the data channel?

              Muxing multiple media flows over a single transport makes
  it harder to individually suppress a single flow by denying ICE
  keepalives.  Either media-level (RTCP) mechanisms must be used or the
  implementation must deny responses entirely, thus terminating the
  call.

nit: "must be used to suppress the misbehaving flow", I think.

Section 9.4.3

  The "origin" field of the signature request can be used to check that
  the user has agreed to disclose their identity to the calling site;
  because it is supplied by the PeerConnection it can be trusted to be
  correct.

I don't see an "origin" field in the signature request; is this supposed
to be the "domain"?

Section 9.4.5.1

nit: it might be friendlier to the reader to prefix this with "When
popup blocking is in use, ".

Section 13.2

It's perhaps debatable that JSEP is only an informative reference.
2019-03-06
18 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-03-06
18 Alissa Cooper
[Ballot comment]
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." alice@example.org is used there …
[Ballot comment]
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." alice@example.org is used there so the pronouns are mixed.

Same comment for 9.1 -- I would suggest replacing "your" with "the user's."
2019-03-06
18 Alissa Cooper Ballot comment text updated for Alissa Cooper
2019-03-06
18 Eric Rescorla [Ballot comment]
I am an author
2019-03-06
18 Eric Rescorla [Ballot Position Update] New position, Recuse, has been recorded for Eric Rescorla
2019-03-06
18 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-03-05
18 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-03-05
18 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-03-05
18 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-03-05
18 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2019-03-05
18 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-03-05
18 Alexey Melnikov
[Ballot discuss]
Thank you for a well written document!

My apologies for filing a procedural DISCUSS on this, but I am looking at:

7.5.  Determining …
[Ballot discuss]
Thank you for a well written document!

My apologies for filing a procedural DISCUSS on this, but I am looking at:

7.5.  Determining the IdP URI

  3.  The path, starting with "/.well-known/idp-proxy/" and appended
      with the IdP protocol.  Note that the separator characters '/'
      (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field,
      lest an attacker be able to direct requests outside of the
      controlled "/.well-known/" prefix.  Query and fragment values MAY
      be used by including '?' or '#' characters.

"idp-proxy" is not registered in the IANA's  registry and this document doesn't register it either. If I missed where this is registered, please point me to the right document. If I haven't, please register it in this document.
2019-03-05
18 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2019-03-04
18 Ben Campbell
[Ballot comment]
Update to the Update: As Adam mentioned in email; while t= vs c=0 ordering is correct in 7.4.1, t= vs a= is not. …
[Ballot comment]
Update to the Update: As Adam mentioned in email; while t= vs c=0 ordering is correct in 7.4.1, t= vs a= is not. (Capturing it here for the ballot record.)

Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example.

I'm balloting "yes", but have a few minor comments and editorial comments:

§1:
- (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?)

- (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.)

(nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG.

§4.1:
(nit) - '... button next to Bob’s name which says "Call".':
s/which/that

- "The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI."

This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention.

§5.1.4:
- "In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints."

Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this?

§6.2:
- "Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins. Implementations MUST refuse all
permissions grants for HTTP origins."

(nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong?

(nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment.
(nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert).

(maybe nit) - "Clients MAY permit the formation of data channels without any direct
user approval."
Is the switch from talking about "the browser" to "Clients" intentional?

§6.4:
(nit) - "Note that these requirements are NOT intended..."
"NOT" in all caps is likely to be confused with 2119/8174 language.

§6.5:
(nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST
implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement [RFC8261]."

Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261?

§7.2:
(nit) - First paragraph: Can there be a citation for the W3C API spec?

(My bad, the draft is correct. Comment removed.) §7.1.4, SDP example:


(nit) §11: The first sentence is a fragment.

§13.1 (normative references)

(nit) - There's a reference to RFC 5234, but it is not cited in the text.

- Is there a reason to reference 5246 rather than 8446, which obsoleted it?

§13.2:
- seems like the jsep reference should be normative.
2019-03-04
18 Ben Campbell Ballot comment text updated for Ben Campbell
2019-03-04
18 Ben Campbell
[Ballot comment]
Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example.

I'm balloting "yes", but …
[Ballot comment]
Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example.

I'm balloting "yes", but have a few minor comments and editorial comments:

§1:
- (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?)

- (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.)

(nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG.

§4.1:
(nit) - '... button next to Bob’s name which says "Call".':
s/which/that

- "The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI."

This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention.

§5.1.4:
- "In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints."

Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this?

§6.2:
- "Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins. Implementations MUST refuse all
permissions grants for HTTP origins."

(nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong?

(nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment.
(nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert).

(maybe nit) - "Clients MAY permit the formation of data channels without any direct
user approval."
Is the switch from talking about "the browser" to "Clients" intentional?

§6.4:
(nit) - "Note that these requirements are NOT intended..."
"NOT" in all caps is likely to be confused with 2119/8174 language.

§6.5:
(nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST
implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement [RFC8261]."

Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261?

§7.2:
(nit) - First paragraph: Can there be a citation for the W3C API spec?

(My bad, the draft is correct. Comment removed.) §7.1.4, SDP example:


(nit) §11: The first sentence is a fragment.

§13.1 (normative references)

(nit) - There's a reference to RFC 5234, but it is not cited in the text.

- Is there a reason to reference 5246 rather than 8446, which obsoleted it?

§13.2:
- seems like the jsep reference should be normative.
2019-03-04
18 Ben Campbell Ballot comment text updated for Ben Campbell
2019-03-04
18 Ben Campbell
[Ballot comment]
I'm balloting "yes", but have a few minor comments and editorial comments:

§1:
- (nit) The first sentence will not age well; I …
[Ballot comment]
I'm balloting "yes", but have a few minor comments and editorial comments:

§1:
- (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?)

- (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.)

(nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG.

§4.1:
(nit) - '... button next to Bob’s name which says "Call".':
s/which/that

- "The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI."

This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention.

§5.1.4:
- "In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints."

Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this?

§6.2:
- "Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins. Implementations MUST refuse all
permissions grants for HTTP origins."

(nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong?

(nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment.
(nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert).

(maybe nit) - "Clients MAY permit the formation of data channels without any direct
user approval."
Is the switch from talking about "the browser" to "Clients" intentional?

§6.4:
(nit) - "Note that these requirements are NOT intended..."
"NOT" in all caps is likely to be confused with 2119/8174 language.

§6.5:
(nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST
implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement [RFC8261]."

Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261?

§7.2:
(nit) - First paragraph: Can there be a citation for the W3C API spec?

§7.1.4, SDP example:
We just had a report against draft-ietf-mmusic-sdp-simulcast claiming that putting "t=" after "c=" is not legal. 4566 and 4566bis seem to support that. (I realize that, if that's in fact an error, we've got it all over the place.)

(nit) §11: The first sentence is a fragment.

§13.1 (normative references)

(nit) - There's a reference to RFC 5234, but it is not cited in the text.

- Is there a reason to reference 5246 rather than 8446, which obsoleted it?

§13.2:
- seems like the jsep reference should be normative.
2019-03-04
18 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2019-02-28
18 Mirja Kühlewind
[Ballot comment]
1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't fully understand the split between those two documents, as section …
[Ballot comment]
1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't fully understand the split between those two documents, as section 4.2 seems to introduce a normative reference to draft-ietf-rtcweb-security:

  "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media
  consent verification is provided via ICE. "

However, given that section 6.3 actually normatively (re-)states the ICE requirements as well, I would maybe recommend to instead say:

  "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) and stated in section 6.3 media
  consent verification is provided via ICE. "

and then move the reference to draft-ietf-rtcweb-security to informative.

2) I would have also expected some discussion in the security considerations sections about the risks to the user if the browser gets corrupted, as indicated by the trust model presented in sec 3.

3) In Sec 9.2: "Combined WebRTC/Tor
  implementations SHOULD arrange to route the media as well as the
  signaling through Tor. Currently this will produce very suboptimal
  performance."
Maybe make these sentences a bit more general, e.g.
"Combined WebRTC/anonymity service
  implementations SHOULD arrange to route the media as well as the
  signaling through the anonymity network. Currently with e.g. Tor this will produce very suboptimal
  performance.
2019-02-28
18 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-02-21
18 Cindy Morgan Placed on agenda for telechat - 2019-03-07
2019-02-21
18 Adam Roach IESG state changed to IESG Evaluation from Waiting for Writeup
2019-02-21
18 Adam Roach Ballot has been issued
2019-02-21
18 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2019-02-21
18 Adam Roach Created "Approve" ballot
2019-02-21
18 Adam Roach Ballot writeup was changed
2019-02-15
18 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-02-14
18 Sabrina Tanamal IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-02-14
18 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Not OK
2019-02-14
18 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-rtcweb-security-arch-18. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-rtcweb-security-arch-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the att-field (session level) registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a single, new registration is to be made as follows:

Type: identity
SDP Name: identity
Mux Category: NORMAL
Reference: [ RFC-to-be; Section 5 ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-14
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Taylor Yu
2019-02-14
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Taylor Yu
2019-02-14
18 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Withdrawn'
2019-02-14
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2019-02-14
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2019-02-10
18 Tobias Gondrom Assignment of request for Last Call review by SECDIR to Tobias Gondrom was rejected
2019-02-09
18 Russ Housley Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Russ Housley. Sent review to list.
2019-02-07
18 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2019-02-07
18 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2019-02-07
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2019-02-07
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2019-02-05
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-02-05
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-02-01
18 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-02-01
18 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-02-15):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, …
The following Last Call announcement was sent out (ends 2019-02-15):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, sean@sn3rd.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC Security Architecture) to Proposed Standard


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC
Security Architecture'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines the security architecture for WebRTC, a
  protocol suite intended for use with real-time applications that can
  be deployed in browsers - "real time communication on the Web".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7918: Transport Layer Security (TLS) False Start (Informational - IETF stream)



2019-02-01
18 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-02-01
18 Adam Roach Last call was requested
2019-02-01
18 Adam Roach Last call announcement was generated
2019-02-01
18 Adam Roach Ballot approval text was generated
2019-02-01
18 Adam Roach Ballot writeup was generated
2019-02-01
18 Adam Roach IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-02-01
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-01
18 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-18.txt
2019-02-01
18 (System) New version approved
2019-02-01
18 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2019-02-01
18 Eric Rescorla Uploaded new revision
2018-11-27
17 Adam Roach Waiting for new version to resolve https://github.com/rtcweb-wg/security-arch/issues/82
2018-11-27
17 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2018-11-17
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-11-17
17 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-17.txt
2018-11-17
17 (System) New version approved
2018-11-17
17 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2018-11-17
17 Eric Rescorla Uploaded new revision
2018-10-30
16 Adam Roach See AD review at https://mailarchive.ietf.org/arch/msg/rtcweb/ieVu9QV3cIazGjZQaBPBJtrefwU
2018-10-30
16 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-10-30
16 Adam Roach IESG state changed to AD Evaluation from Publication Requested
2018-10-22
16 Sean Turner
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean …
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean Turner is the document shepherd and Adam Roach is our Über Area Director!

2. Review and Consensus

This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings.  It’s been amended numerous times based on WG feedback and it reflects the WG consensus.

3. Intellectual Property

The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

DOWNREFs: There is one DOWNREF to RFC 2818, but it's been in the DOWNRE registry forever.  It should be called out during the IETF LC, but it's really just a formality.

IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in s8.2.4 of RFC 4566.
2018-10-22
16 Sean Turner IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2018-10-22
16 Sean Turner IESG state changed to Publication Requested from AD is watching
2018-10-22
16 Sean Turner Tag Revised I-D Needed - Issue raised by WGLC cleared.
2018-10-22
16 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-16.txt
2018-10-22
16 (System) New version approved
2018-10-22
16 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2018-10-22
16 Eric Rescorla Uploaded new revision
2018-09-10
15 Adam Roach Waiting on merge of https://github.com/rtcweb-wg/security-arch/pull/77
2018-07-17
15 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-15.txt
2018-07-17
15 (System) New version approved
2018-07-17
15 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2018-07-17
15 Eric Rescorla Uploaded new revision
2018-04-12
14 Sean Turner Tag Revised I-D Needed - Issue raised by WGLC set.
2018-04-12
14 Sean Turner IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2018-03-12
14 Sean Turner Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway cleared.
2018-03-12
14 Sean Turner IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2018-03-12
14 Cindy Morgan New version available: draft-ietf-rtcweb-security-arch-14.txt
2018-03-12
14 (System) Secretariat manually posting. Approvals already received
2018-03-12
14 Cindy Morgan Uploaded new revision
2018-03-10
13 Sean Turner
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean …
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean Turner is the document shepherd and Adam Roach is our Über Area Director!

2. Review and Consensus

This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings.  It’s been amended numerous times based on WG feedback and it reflects the WG consensus.

3. Intellectual Property

The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

DOWNREFs: There is one DOWNREF to RFC 2818, but it's been in the DOWNRE registry forever.  It should be called out during the IETF LC, but it's really just a formality.

IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in s8.2.4 of RFC 4566.
2018-03-10
13 Sean Turner Changed consensus to Yes from Unknown
2018-02-27
13 Sean Turner
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean …
1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean Turner is the document shepherd and Adam Roach is our Über Area Director!

2. Review and Consensus

This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings.  It’s been amended numerous times based on WG feedback and it reflects the WG consensus.

3. Intellectual Property

The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

DOWNREFs: There are a lot of references to IDs but they’re all bound for standards track.

IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in RFC 4566.
2018-01-22
13 Adam Roach Shepherding AD changed to Adam Roach
2017-11-21
13 Sean Turner Notification list changed to Sean Turner <sean@sn3rd.com>
2017-11-21
13 Sean Turner Document shepherd changed to Sean Turner
2017-11-12
13 Adam Roach IESG state changed to AD is watching from Dead
2017-10-30
13 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-13.txt
2017-10-30
13 (System) New version approved
2017-10-30
13 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla
2017-10-30
13 Eric Rescorla Uploaded new revision
2016-12-10
12 (System) Document has expired
2016-06-08
12 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-12.txt
2016-04-08
11 (System) Document has expired
2016-04-08
11 (System) IESG state changed to Dead from AD is watching::External Party
2016-04-07
11 Alissa Cooper IESG state changed to AD is watching::External Party from Publication Requested
2015-10-14
11 (System) Notify list changed from rtcweb-chairs@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, draft-ietf-rtcweb-security-arch.ad@ietf.org, turners@ieca.com, draft-ietf-rtcweb-security-arch.shepherd@ietf.org to (None)
2015-10-08
11 Tero Kivinen Request for Early review by SECDIR Completed: Has Issues. Reviewer: Tobias Gondrom.
2015-07-02
11 Tero Kivinen Request for Early review by SECDIR is assigned to Tobias Gondrom
2015-07-02
11 Tero Kivinen Request for Early review by SECDIR is assigned to Tobias Gondrom
2015-04-02
11 Sean Turner Tag Revised I-D Needed - Issue raised by WGLC set.
2015-04-02
11 Sean Turner IETF WG state changed to Waiting for WG Chair Go-Ahead from Submitted to IESG for Publication
2015-03-25
11 Cindy Morgan Shepherding AD changed to Alissa Cooper
2015-03-19
11 Sean Turner
How’s this for the proto write-up?  I tend to either go for funny or very short - this one is short ;)

1. Summary

This …
How’s this for the proto write-up?  I tend to either go for funny or very short - this one is short ;)

1. Summary

This document defines the security architecture for WebRTC.  This draft is bound standards track because it includes protocol for web-based peer authentication.

Sean Turner is the document shepherd and Alissa Cooper is going to be our über Area Director!

2. Review and Consensus

This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings.  It’s been amended numerous times based on WG feedback and it reflects the WG consensus.

3. Intellectual Property

The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

DOWNREFs: There are a lot of references to IDs but they’re all bound for standards track.

IANA Considerations: There’s one SDP attribute registration and it follows the procedures specified in RFC 4566.
2015-03-19
11 Sean Turner State Change Notice email list changed to rtcweb-chairs@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, draft-ietf-rtcweb-security-arch.ad@ietf.org, turners@ieca.com, draft-ietf-rtcweb-security-arch.shepherd@ietf.org
2015-03-19
11 Sean Turner Responsible AD changed to Richard Barnes
2015-03-19
11 Sean Turner IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2015-03-19
11 Sean Turner IESG state changed to Publication Requested
2015-03-19
11 Sean Turner IESG process started in state Publication Requested
2015-03-19
11 Sean Turner Intended Status changed to Proposed Standard from None
2015-03-19
11 Sean Turner Changed document writeup
2015-03-07
11 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-11.txt
2014-08-14
10 Sean Turner Tag Doc Shepherd Follow-up Underway set.
2014-08-14
10 Sean Turner IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2014-07-10
10 Sean Turner IETF WG state changed to In WG Last Call from WG Document
2014-07-04
10 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-10.txt
2014-07-02
09 Sean Turner Document shepherd changed to Sean Turner
2014-02-14
09 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-09.txt
2014-01-23
08 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-08.txt
2014-01-10
07 Magnus Westerlund Document shepherd changed to Ted Hardie
2013-07-15
07 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-07.txt
2013-01-22
06 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-06.txt
2012-10-22
05 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-05.txt
2012-10-22
04 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-04.txt
2012-07-16
03 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-03.txt
2012-06-05
02 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-02.txt
2012-03-12
01 Eric Rescorla New version available: draft-ietf-rtcweb-security-arch-01.txt
2012-01-23
00 (System) New version available: draft-ietf-rtcweb-security-arch-00.txt