Subject: [rtcweb] Possible identity security vulnerability

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 10:04:42 +0100

Hi all,

After passing the weekend playing with the webrtc identity, I have a 
doubt regarding a potential security issue.

The generateAssertion contents contains only the DTLS-SRTP fingerprint 
attributes used by the peerconnection. The idp only has to options to 
generate the assertion, either hash/encrypt the contents and the user 
identity or create  record server side and return an unique token 
associated to it.

In case the hash/encrypt option is used, as there is no nonce or 
similar, it is a deterministic operation, and a <user,fingerprint> will 
always produce the same assertion. So, it should be possible for a 
malicious app to store the RTCCertificate  and the generated assertion 
and reuse it afterwards for an un-authenticated user.

Am I missing anything or this could be potentially exploitable?

Best regards

Sergio

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 09:37:59 +0000

Two things:

This is a bearer-token design, which is inherently vulnerable to
theft.  The usual technique for containing the damage there is to
include a timestamp.

https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-uks
addresses the question of theft differently.

On Mon, Mar 19, 2018 at 9:04 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
> Hi all,
>
> After passing the weekend playing with the webrtc identity, I have a doubt
> regarding a potential security issue.
>
> identity or create  record server side and return an unique token associated
> to it.
>
> In case the hash/encrypt option is used, as there is no nonce or similar, it
> is a deterministic operation, and a <user,fingerprint> will always produce
> the same assertion. So, it should be possible for a malicious app to store
> the RTCCertificate  and the generated assertion and reuse it afterwards for
> an un-authenticated user.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 10:53:41 +0100

Hi Martin,

I saw the reference to the sdp-uks but was not sure if it covered my 
scenario or not, so thanks for clarifying it.

Generating an ExternalSessionId per peerconnection which is passed to 
the generate assertion function would make much sense and protect 
against theft. Shouldn't we add support for it? (at least if identity is 
used)

Best regards
Sergio

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 10:05:15 +0000

> Generating an ExternalSessionId per peerconnection which is passed to the
> generate assertion function would make much sense and protect against
> theft. Shouldn't we add support for it? (at least if identity is used)

 Based on the discussion at the hackathon this week, the time scope of the
authentication is anticipated to be very short-lived, i.e. on the order of
the 
length of time it takes to set up the call.  So I can't see a valid use case
for
re-using the bearer token.  If it fails the first time, simply restart the
protocol.
Indeed, I believe that is what Harald was doing in his proof of concept.

Therefore, I'd personally suggest that the rtcweb-id require that the tokens
be one time use, and perhaps even specify a reasonable mechanism to
prevent unnecessary "innovation" in this space.  Preventing replay is a 
basic security goal, and it would be unfortunate to leave it up to Identity
Providers to notice that and get it right.  Someone please correct me if
that requirement already exists somewhere that I didn't notice.  I read
all these documents and Cullen's excellent overview slides with only about
5%
of my brain cells functioning.

BTW, I'd like to thank the rtcweb-id hackathon members for answering all
my questions in my extremely sleep deprived and jet lagged state.  It was
an absolutely wonderful experience being able to discuss the draft with them
and dig down into all the technical details about how it would actually work
in practice.

There are actually a number of other interesting things about the design 
from a security standpoint that I hopefully will have time to expound upon 
further in a couple of days.

-Tim

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 11:20:32 +0100

On 19/03/2018 11:05, Tim Hollebeek wrote:
> the length of time it takes to set up the call.  So I can't see a valid use case
> for re-using the bearer token.  If it fails the first time, simply restart the
> protocol.
> 5% of my brain cells functioning.

I agree that the tokens should be one time use, but the I think that the 
only way of enforcing it is by generating and unique opaque nonce (the 
ExternalSessionId exchanged on the DTLS setup) and couple it to be 
consumed only by the PC.

Without a similar mechanism, we would delegate the correct 
implementation to the IDP, which would be forced to store the "contents" 
server side a return an unique token and ensure that it is deleted after 
first use. Note that even in that case, there is no way of certifying 
that the assertion was consumed by the right call, that is, a malicious 
attack could generate the one time assertion on a valid user, but do not 
establish the call or faking it has failed, and use the token later on 
non legitimate call.

> further in a couple of days.

Indeed, it has been a exhausting but awesome experience! Looking forward 
to sharing feedback from the hackathon!

Best regards
Sergio

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 10:58:01 +0000

> > Therefore, I'd personally suggest that the rtcweb-id require that the
> > tokens be one time use, and perhaps even specify a reasonable
> > mechanism to prevent unnecessary "innovation" in this space.
> > Preventing replay is a basic security goal, and it would be
> > unfortunate to leave it up to Identity Providers to notice that and
> > get it right.  Someone please correct me if that requirement already
> > exists somewhere that I didn't notice.  I read all these documents and
> > Cullen's excellent overview slides with only about 5% of my brain cells
> functioning.
> 
only
> way of enforcing it is by generating and unique opaque nonce (the
consumed
> only by the PC.

Yup, after understanding your concern, modifying the API to add a required
nonce 
would  be my suggestion, as it expresses the security requirement in a
simple 
way that's hard to get wrong.

-Tim

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 19 Mar 2018 11:05:58 +0000

> On Mar 19, 2018, at 10:58, Tim Hollebeek <tim.hollebeek=[email-masked]> wrote:

While I agree that adding a nonce would make the assertion stronger (assuming the nonce value has enough entropy).

But who is going to create the nonce in these scenarios?
I would guess that often the nonce would get created by the signaling server. But as far as I understand the potential attack here, the stealing of the assertion would have to happen exactly on that signaling path. So if you don’t trust that part of your setup, you should not trust it to create a unique nonce to improve things.

Best
  Nils Ohlmeier

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 19 Mar 2018 11:05:58 +0000

Best
  Nils Ohlmeier

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 11:09:24 +0000

I would think the IDP would create the nonce, and verify non-reuse.  The IDP 
is a trusted component in this system.

There are almost certainly details that have to be worked out about how
exactly that changes the APIs, and that may expose future problems, but
that's what I'm currently thinking.

Happy to help figure this stuff out since I happen to be familiar with it now.

-Tim

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Nils Ohlmeier
> Sent: Monday, March 19, 2018 11:06 AM
> To: Tim Hollebeek <tim.hollebeek=[email-masked]>
> Cc: RTCWeb IETF <[email-masked]>
> Subject: Re: [rtcweb] Possible identity security vulnerability
> 
> 
> 
> > On Mar 19, 2018, at 10:58, Tim Hollebeek
> <tim.hollebeek=[email-masked]> wrote:
> > Yup, after understanding your concern, modifying the API to add a
> > required nonce would  be my suggestion, as it expresses the security
> > requirement in a simple way that's hard to get wrong.
> 
> While I agree that adding a nonce would make the assertion stronger
> (assuming the nonce value has enough entropy).
> 
> I would guess that often the nonce would get created by the signaling server.
> But as far as I understand the potential attack here, the stealing of the
> assertion would have to happen exactly on that signaling path. So if you don’t
> trust that part of your setup, you should not trust it to create a unique nonce
> to improve things.
> 
> Best
>   Nils Ohlmeier

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 11:09:24 +0000

-Tim

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 11:10:22 +0000

> way that's hard to get wrong.

FWIW, in the common case, there is a nonce: the certificate.  That is
generally unique to a RTCPeerConnection instance.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:10:21 +0100

On 19/03/2018 12:05, Nils Ohlmeier wrote:
>>> I agree that the tokens should be one time use, but the I think that the only way of enforcing it is by generating and unique opaque nonce (the ExternalSessionId exchanged on the DTLS setup) and couple it to be consumed only by the PC.
>> Yup, after understanding your concern, modifying the API to add a required nonc would  be my suggestion, as it expresses the security requirement in a simple way that's hard to get wrong.
The nonce should generated internally by the PC and exchanged on the 
dtls setup via the ExternalSessionId field from the sdp-uks draft. That 
way the remote PC will be able to access the nonce and pass it to the 
validate assertion call.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:10:21 +0100

Best regards
Sergio

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 11:21:27 +0000

Well, generally unique ... but not enforced, right?  The fact that it is 
unique in
the common case does not give me warm fuzzies when analyzing its security
properties.  We have to think about not only uncommon cases, but malicious
cases.

That said, your point is interesting, and I think it may at least limit what 
you can
do with token re-use, for example, only re-create a connection back to the 
original
originator instead of an arbitrary one, as no one else has the right 
fingerprint.

But even that seems like something worth preventing.

-Tim

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Monday, March 19, 2018 11:10 AM
> To: Tim Hollebeek <[email-masked]>
> Cc: Sergio Garcia Murillo <[email-masked]>; RTCWeb IETF
> <[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:23:56 +0100

> generally unique to a RTCPeerConnection instance.

But it can be saved and reused:

https://www.w3.org/TR/webrtc/#dom-rtcconfiguration

     This option allows applications to establish key continuity. 
An|RTCCertificate|can be persisted in [INDEXEDDB 
<https://www.w3.org/TR/webrtc/#bib-INDEXEDDB>] and reused. Persistence 
and reuse also avoids the cost of key generation.

Best regards

Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:30:31 +0100

On 19/03/2018 12:10, Sergio Garcia Murillo wrote:
>>>> I agree that the tokens should be one time use, but the I think 
>>>> that the only way of enforcing it is by generating and unique 
>>>> opaque nonce (the ExternalSessionId exchanged on the DTLS setup) 
>>>> and couple it to be consumed only by the PC.
>>> required nonc would  be my suggestion, as it expresses the security 
>> I would guess that often the nonce would get created by the signaling 
>> server. But as far as I understand the potential attack here, the 
>> stealing of the assertion would have to happen exactly on that 
>> signaling path. So if you don’t trust that part of your setup, you 
>> should not trust it to create a unique nonce to improve things.
>>
> dtls setup via the ExternalSessionId field from the sdp-uks draft. 
> That way the remote PC will be able to access the nonce and pass it to 
> the validate assertion call. 

By the way, there was already an open issue at w3c webrtc tracker 
regarding adding a peerconnection id for a different use case:

https://github.com/w3c/webrtc-pc/issues/1775

We could reuse that id as dtls external session id/assertion nonce

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:30:31 +0100

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 11:30:41 +0000

So, concretely, the attack that would be enabled is that an origin
that operates a service could cause a user to present any of the
identities that it presented for use with that same service.

Thus, if I visit example.com and it is permitted to generate an
assertion for [email-masked], then the associated assertion could be
used by example.com for any call that I initiate until the assertion
expired.

On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
>     This option allows applications to establish key continuity. An
> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence and
> reuse also avoids the cost of key generation.
>
> Best regards
>
> Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 12:36:44 +0100

Yep, exactly.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 11:54:31 +0000

Hmm, that's not that interesting.  The number and disposition of
RTCPeerConnection instances in a page, and the way in which they are
used, is not something that is particularly visible.

On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
>>> required

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 12:02:33 +0000

Wait, what?  The details of how a particular page is implemented is pretty 
easy
to discover for even a moderately sophisticated technical person.

Where in the security model does it say that attackers can only use 
information
visible on the page?

If I'm going through the trouble of re-using assertions, I will have certainly 
have
figured out how the target page uses RTCPeerConnections before trying to
re-use assertions.

-Tim

> Sent: Monday, March 19, 2018 11:55 AM
> To: Sergio Garcia Murillo <[email-masked]>
> Cc: Tim Hollebeek <[email-masked]>; RTCWeb IETF
> <[email-masked]>
> RTCPeerConnection instances in a page, and the way in which they are used, 
> is
> not something that is particularly visible.
>
> >> assertion for [email-masked], then the associated assertion could
> >> be used by example.com for any call that I initiate until the
> >> assertion expired.
> >>
> >>> FWIW, in the common case, there is a nonce: the certificate.  That
> >>> is generally unique to a RTCPeerConnection instance.
> >>>
> >>> RTCCertificate can be persisted in [INDEXEDDB] and reused.
> >>> Persistence and reuse also avoids the cost of key generation.
> >>>
> >>> Best regards
> >>>
> >>> Sergio
> >
> >
> >

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 13:29:54 +0100

BTW, note that it is not "any call that I initiate until the assertion 
expired" but "any call that the browser initiates until the assertion 
expired".

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 13:40:37 +0000

It's anything that *the site* initiates (not so much the browser).
Certificates are origin-scoped.

---

From: westhawk <[email-masked]>
Date: Mon, 19 Mar 2018 13:45:56 +0000

> On 19 Mar 2018, at 13:40, Martin Thomson <[email-masked]> wrote:
> 

Are they? is the private key needed in the re-use of the assertion?
(I haven’t looked at this for ages)
If not the you could push the ASN1 of the public cert somewhere not scoped to the
origin and have another site re-use it. (e.g. transfer it to an advert iframe with postmessage)

T.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 14:46:30 +0100

Yes, that's what I meant (although not correctly expressed). The 
assertion can only be reused by the same browser (keying is stored 
securely and can't be exported) on same site.

Most probably not a huge problem after all, but if the solution is 
simple maybe we should address it now.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 14:57:52 +0100

> origin and have another site re-use it. (e.g. transfer it to an advert iframe with postmessage)

After checking if further, that may not be clearly explicit on the 
webrtc w3c spec:

    For the purposes of this API, the[[Certificate]]
    <https://w3c.github.io/webrtc-pc/#dfn-certificate>slot contains
    unstructured binary data. No mechanism is provided for applications
    to access the[[KeyingMaterial]]
    <https://w3c.github.io/webrtc-pc/#dfn-keyingmaterial>internal slot.
    Implementations/MUST/support applications storing and
    retrieving|RTCCertificate|objects from persistent storage. In
    implementations where an|RTCCertificate| might not directly hold
    private keying material (it might be stored in a secure module), a
    reference to the private key can be held in the[[KeyingMaterial]]
    <https://w3c.github.io/webrtc-pc/#dfn-keyingmaterial>internal slot,
    allowing the private key to be stored and used.

So it is not clear to me if certificates are origin-scoped or if the key 
materials could be exported outside of the browser. Worst case, 
certificate could be exported and identity assertion reused even by a 
different service.

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 14:37:38 +0000

Yes, you can't use an assertion without being able to prove control
over the private key (this is transitively ensured via the
fingerprints and certificate).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 14:43:00 +0000

As a practical matter, if the browser were to use the same certificate
for multiple origins, then it would create a massive privacy problem
that enables linkability (aka user tracking).  I couldn't find that
written down, but I thought it was.  If it isn't written down, then we
should correct that.

On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo
<[email-masked]> wrote:
> After checking if further, that may not be clearly explicit on the webrtc
> w3c spec:
>
> For the purposes of this API, the [[Certificate]] slot contains unstructured
> binary data. No mechanism is provided for applications to access the
> [[KeyingMaterial]] internal slot. Implementations MUST support applications
> storing and retrieving RTCCertificate objects from persistent storage. In
> implementations where an RTCCertificate might not directly hold private
> keying material (it might be stored in a secure module), a reference to the
> private key can be held in the [[KeyingMaterial]] internal slot, allowing
> the private key to be stored and used.
>
> materials could be exported outside of the browser. Worst case, certificate
> could be exported and identity assertion reused even by a different service.
>
> Best regards
> Sergio
>

---

From: westhawk <[email-masked]>
Date: Mon, 19 Mar 2018 14:57:51 +0000

> On 19 Mar 2018, at 14:43, Martin Thomson <[email-masked]> wrote:
> 

As currently implemented you can’t move a cert from one origin to another.
I just had a discussion with Bernard about the language here - since it also
means that certs can not be backed up. - lose your phone, lose your certs.

https://github.com/w3c/webrtc-pc/issues/1694 <https://github.com/w3c/webrtc-pc/issues/1694>

Tim.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 16:03:55 +0100

Found it, they are not origin bounded:

The|RTCCertificate|object can be stored and retrieved from persistent 
storage by an application. When auser agent 
<https://www.w3.org/TR/webrtc/#dfn-user-agent>is required to obtain a 
structured clone [HTML51 <https://www.w3.org/TR/webrtc/#bib-HTML51>] of 
an|RTCCertificate|object, it performs the following steps

And on HTML5 spec:

Cloneable objects 
<https://www.w3.org/TR/html51/infrastructure.html#cloneable-objects>support 
being cloned acrossevent loops 
<https://www.w3.org/TR/html51/webappapis.html#event-loop>. That is, they 
support being cloned across|Document 
<https://html.spec.whatwg.org/multipage/dom.html#document>|and|Worker 
<https://www.w3.org/TR/workers/#worker>|boundaries, including 
across|Document 
<https://html.spec.whatwg.org/multipage/dom.html#document>|s of 
differentorigins 
<https://www.w3.org/TR/html51/browsers.html#concept-cross-origin>. Not 
all objects arecloneable objects 
<https://www.w3.org/TR/html51/infrastructure.html#cloneable-objects>and 
not all aspects of objects that arecloneable objects 
<https://www.w3.org/TR/html51/infrastructure.html#cloneable-objects>are 
necessarily preserved when cloned.

So you can perfectly do the following:

RTCPeerConnection.generateCertificate({
     name: 'RSASSA-PKCS1-v1_5',
     hash: 'SHA-256',
     modulusLength: 2048,
     publicExponent: new Uint8Array([1, 0, 1])
}).then(function(cert) {
     windowInOderDomain.postMessage(cert,"*")
});

And the other window will able to reuse it. However, the certificate 
won't be serialized in anyway that could be extracted from the browser.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 16:05:35 +0100

On 19/03/2018 15:57, westhawk wrote:
>
>
>> On 19 Mar 2018, at 14:43, Martin Thomson <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> https://github.com/w3c/webrtc-pc/issues/1694
>
You can't export/import them (at least from js), but you can move it 
between origins (or to a web worker) via postMessage within the same 
browser.

Best regards

Sergio

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 15:47:22 +0000

I was told over the weekend that the current spec required no validation other
than the expiration date.  Is that right?  It certainly appeared so from the section
I was shown.  It made sense at the time, since it was argued these were ephemeral
certificates that were only used to encapsulate a (public key, expiration date) pair,
along with TLS security parameters.  After hearing more discussion (including Sergio's
point that the certificate may be long lived), I'm not so sure that's wise.

I agree that if the lifetime of the certificates isn't truly ephemeral, the requirements
around certificate validation should probably be tightened up.  If name validation 
were being done on the DTLS connection (my understanding was it wasn't), that would 
certainly help reduce the number of silly things you could do, perhaps to the point 
where the risk is low.

Though I think it still would be wise simply to enforce the no-reuse policy.  It's
simpler and easier to evaluate, instead of trying to rely on other properties of the
algorithm to guarantee the risk is low.  I'm afraid that approach will be fragile, and
other vulnerabilities may be introduced in the future when those properties of the
algorithm change.

Anyway, just some things to think about.

-Tim

> From: rtcweb [mailto:[email-masked]] On Behalf Of Martin
> Thomson
> Sent: Monday, March 19, 2018 2:43 PM
> As a practical matter, if the browser were to use the same certificate for
> multiple origins, then it would create a massive privacy problem that enables
> linkability (aka user tracking).  I couldn't find that written down, but I thought
> it was.  If it isn't written down, then we should correct that.
> 
> > If not the you could push the ASN1 of the public cert somewhere not
> > scoped to the origin and have another site re-use it. (e.g. transfer
> > it to an advert iframe with postmessage)
> >
> >
> > For the purposes of this API, the [[Certificate]] slot contains
> > unstructured binary data. No mechanism is provided for applications to
> > access the [[KeyingMaterial]] internal slot. Implementations MUST
> > support applications storing and retrieving RTCCertificate objects
> > from persistent storage. In implementations where an RTCCertificate
> > might not directly hold private keying material (it might be stored in
> > a secure module), a reference to the private key can be held in the
> > [[KeyingMaterial]] internal slot, allowing the private key to be stored and
> used.
> >
> > So it is not clear to me if certificates are origin-scoped or if the
> > key materials could be exported outside of the browser. Worst case,

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 17:23:37 +0000

That was never the intent.  The reason for marking this cloneable is
to enable storage in indexedDB.  We should close that option.  There
is no good reason to allow this usage.

On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo
<[email-masked]> wrote:
> The RTCCertificate object can be stored and retrieved from persistent
> storage by an application. When a user agent is required to obtain a
> structured clone [HTML51] of an RTCCertificate object, it performs the
> following steps
>
> And on HTML5 spec:
>
> Cloneable objects support being cloned across event loops. That is, they
> support being cloned across Documentand Worker boundaries, including across
> Documents of different origins. Not all objects are cloneable objectsand not
> all aspects of objects that are cloneable objects are necessarily preserved
> when cloned.
>
> And the other window will able to reuse it. However, the certificate won't
> be serialized in anyway that could be extracted from the browser.
>
> Best regards
> Sergio
>
>
>

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 19 Mar 2018 17:31:51 +0000

I would agree, that would solve several of my concerns.

-Tim

> Sent: Monday, March 19, 2018 5:24 PM
> That was never the intent.  The reason for marking this cloneable is to enable
> storage in indexedDB.  We should close that option.  There is no good reason
> to allow this usage.
> 
> > Cloneable objects support being cloned across event loops. That is,
> > they support being cloned across Documentand Worker boundaries,
> > including across Documents of different origins. Not all objects are
> > cloneable objectsand not all aspects of objects that are cloneable
> > objects are necessarily preserved when cloned.
> >

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 19 Mar 2018 19:23:43 +0100

I can confirm that it works in firefox, you can check it with the 
following html:

<html>
     <body><iframe id="other"></iframe></body>
<script>
     var data = "data:text/html," + 
encodeURI('<script>window.addEventListener("message", 
(event)=>{alert(event.data);window.top.postMessage(event.data,"*")}, 
false);\r\nwindow.top.postMessage("ready","*");<'+'/script>');

     window.addEventListener("message",(event)=>{
         if (event.data==="ready")
             RTCPeerConnection.generateCertificate({
                 name: 'RSASSA-PKCS1-v1_5',
                 hash: 'SHA-256',
                 modulusLength: 2048,
                 publicExponent: new Uint8Array([1, 0, 1])
             }).then(function(cert) {
                 console.log("sending cert with expires at"+ cert.expires)
                 other.contentWindow.postMessage(cert,"*");
             });
         else
             console.log("got ",event.data);
     });

     other.src = data;
</script>
</html>

Note that data: urls creates their own domain, so we are sending the 
generated certificate back and forth between domain without issues.

Best regards
Sergio

---

From: westhawk <[email-masked]>
Date: Mon, 19 Mar 2018 20:13:06 +0000

Storage or cloning ?

> On 19 Mar 2018, at 17:23, Martin Thomson <[email-masked]> wrote:
>

---

From: westhawk <[email-masked]>
Date: Mon, 19 Mar 2018 22:43:41 +0000

> On 19 Mar 2018, at 20:13, westhawk <[email-masked]> wrote:
> 
> Storage or cloning ?

Because I have a _very_ good use for storage and re-use of certs.
I have no desire to post message them around though.

T.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Mar 2018 08:14:03 +0000

I want to enable storage (that's the point of the feature), but not
cross-origin transfers.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 20 Mar 2018 09:39:37 +0100

Leaving the identity assertion implications, what would be the risks of 
sharing a certificate between different origins.

I think you mentioned user tracking already, how that would be done?

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Mar 2018 11:41:31 +0000

Cooperating origins can always ensure linkability, so it's not a real risk.

The exposure here is that it enables portability of the identity assertion.

On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
>>>>>> they
>>>>>> won't
>>>>>> scoped
>>>>>> to the
>>>>>> webrtc
>>>>>> unstructured
>>>>>> key
>>>>>> certificate

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 20 Mar 2018 12:45:27 +0100

That was also my understanding.

So, we could solve the the identity assertion identity by supporting the 
dtls external session id so it is unique per peerconnection and add it 
as nonce to the assertion generation (which seems like a nice to have 
anyway) and leave the postMessage support for certificates as it is 
(there could even be a valid usage for porting certificates across origins)?

Would that work?

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Mar 2018 11:46:33 +0000

Others have expressed the fact that this portability - within an
origin - is a feature, not a bug.  We should discuss more.

On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
> dtls external session id so it is unique per peerconnection and add it as
> nonce to the assertion generation (which seems like a nice to have anyway)
> and leave the postMessage support for certificates as it is (there could
> even be a valid usage for porting certificates across origins)?
>
> Would that work?
>
> Best regards
> Sergio
>
>
>>>>>>>> origin and have another site re-use it. (e.g. transfer it to an
>>>>>>>> advert
>>>>>>>> iframe with postmessage)
>>>>>>>>
>>>>>>>>
>>>>>>>> storing and retrieving RTCCertificate objects from persistent
>>>>>>>> storage.
>>>>>>>> In

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 20 Mar 2018 15:16:17 +0100

Sure.

Would be interesting to know what are the arguments in favor of identity 
assertion reusability and portability (even within the same domain) vs 
requesting a new assertion each time.

Best regards
Sergio

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 20 Mar 2018 14:55:08 +0000

Yeah, I'm not getting why people are so strongly in favor of maintaining the
ability to re-use identity assertions, given that there doesn't seem to be a 
practical use case and it adds complexity and risk.  Generate/Verify should
come in 1-1 pairs.  It's simpler to analyze that way.

If the original design assumption was no identity assertion re-use (it seems 
it wasn't even contemplated before the replay attack was suggested), enforce 
it technically.  It isn't that hard to do.

Also, if a small hackathon surfaces an previously unknown replay scenario like
this one, it's worth doing a bit of extra analysis to try to find any other gremlins
that might be lurking in the identity mechanism.

-Tim

> From: rtcweb [mailto:[email-masked]] On Behalf Of Sergio Garcia
> Murillo
> Sent: Tuesday, March 20, 2018 2:16 PM
> To: Martin Thomson <[email-masked]>
> >> So, we could solve the the identity assertion identity by supporting
> >> the dtls external session id so it is unique per peerconnection and
> >> add it as nonce to the assertion generation (which seems like a nice
> >> to have anyway) and leave the postMessage support for certificates as
> >> it is (there could even be a valid usage for porting certificates across
> origins)?
> >>
> >> Would that work?
> >>
> >> Best regards
> >> Sergio
> >>
> >>
> >>>> Leaving the identity assertion implications, what would be the
> >>>> risks of sharing a certificate between different origins.
> >>>>
> >>>>> I want to enable storage (that's the point of the feature), but
> >>>>> not cross-origin transfers.
> >>>>>
> >>>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson
> >>>>>>>> <[email-masked]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> That was never the intent.  The reason for marking this
> >>>>>>>> cloneable is to enable storage in indexedDB.  We should close
> >>>>>>>> that option.  There is no good reason to allow this usage.
> >>>>>>>>
> >>>>>>>>> The RTCCertificate object can be stored and retrieved from
> >>>>>>>>> persistent storage by an application. When a user agent is
> >>>>>>>>> required to obtain a structured clone [HTML51] of an
> >>>>>>>>> RTCCertificate object, it performs the following steps
> >>>>>>>>>
> >>>>>>>>> And on HTML5 spec:
> >>>>>>>>>
> >>>>>>>>> Cloneable objects support being cloned across event loops.
> >>>>>>>>> That is, they support being cloned across Documentand Worker
> >>>>>>>>> boundaries, including across Documents of different origins.
> >>>>>>>>> Not all objects are cloneable objectsand not all aspects of
> >>>>>>>>> objects that are cloneable objects are necessarily preserved
> >>>>>>>>> when cloned.
> >>>>>>>>>
> >>>>>>>>> And the other window will able to reuse it. However, the
> >>>>>>>>> certificate won't be serialized in anyway that could be
> >>>>>>>>> extracted from the browser.
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>> Sergio
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> As a practical matter, if the browser were to use the same
> >>>>>>>>> certificate for multiple origins, then it would create a
> >>>>>>>>> massive privacy problem that enables linkability (aka user
> >>>>>>>>> tracking).  I couldn't find that written down, but I thought
> >>>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson
> >>>>>>>>> <[email-masked]>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> (I haven’t looked at this for ages) If not the you could push
> >>>>>>>>> the ASN1 of the public cert somewhere not scoped to the origin
> >>>>>>>>> and have another site re-use it. (e.g. transfer it to an
> >>>>>>>>> advert iframe with postmessage)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> After checking if further, that may not be clearly explicit on
> >>>>>>>>> the webrtc w3c spec:
> >>>>>>>>>
> >>>>>>>>> For the purposes of this API, the [[Certificate]] slot
> >>>>>>>>> contains unstructured binary data. No mechanism is provided
> >>>>>>>>> for applications to access the [[KeyingMaterial]] internal
> >>>>>>>>> slot. Implementations MUST support applications storing and
> >>>>>>>>> retrieving RTCCertificate objects from persistent storage.
> >>>>>>>>> In
> >>>>>>>>> implementations where an RTCCertificate might not directly
> >>>>>>>>> hold private keying material (it might be stored in a secure
> >>>>>>>>> module), a reference to the private key can be held in the
> >>>>>>>>> [[KeyingMaterial]] internal slot, allowing the private key to
> >>>>>>>>> be stored and used.
> >>>>>>>>>
> >>>>>>>>> So it is not clear to me if certificates are origin-scoped or
> >>>>>>>>> if the key materials could be exported outside of the browser.
> >>>>>>>>> Worst case, certificate could be exported and identity
> >>>>>>>>> assertion reused even by a different service.
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>> Sergio
> >>>>>>>>>
> >>>>>>>>>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Mar 2018 16:50:14 +0000

So here's the view, as I understand it.

More complex sites frequently generate multiple RTCPeerConnection
instances for their communications, especially for group
conversations.  If the browser requests an assertion once and they use
that value for every RTCPeerConnection, then that's OK.  From my
perspective, I would be happy modifying the protocol to include an
identifier and prevent that; for this the IdP can use caching or its
local storage.

On Tue, Mar 20, 2018 at 2:16 PM, Sergio Garcia Murillo
<[email-masked]> wrote:
>>>>>>>>>> persistent
>>>>>>>>>> support being cloned across Documentand Worker boundaries,
>>>>>>>>>> including
>>>>>>>>>> across
>>>>>>>>>> written down, but I thought it was.  If it isn't written down,
>>>>>>>>>> then
>>>>>>>>>> we
>>>>>>>>>> should correct that.
>>>>>>>>>>
>>>>>>>>>> keying material (it might be stored in a secure module), a
>>>>>>>>>> reference
>>>>>>>>>> to the
>>>>>>>>>> could be exported and identity assertion reused even by a
>>>>>>>>>> different
>>>>>>>>>> service.
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Sergio
>>>>>>>>>>
>>>>>>>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Mar 2018 09:04:29 +0100

> identifier and prevent that; for this the IdP can use caching or its

If I were an IdP, and worried about server load, I'd authenticate the
user once (via login / cookies) and then use the cookies to generate
fresh assertions whenever they're asked for.

If I remember the spec correctly, it's unclear whether calling
createOffer() twice on the same PC will generate two requests for
identity assertions or only one; I don't remember seeing two requests
when I was debugging my identity provider and calling createAssertion
followed by a createOffer - but debugging IdP is hard in Firefox because
console is not available in the IdP context (I think this is a bug), so
it might have happened.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 25 Mar 2018 01:04:48 +0100

> console is not available in the IdP context (I think this is a bug), so

Also, I don't get where the server load comes from when the hashing can 
be done client side, so there is no significant extra load for 
generating new identities.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 25 Mar 2018 01:08:01 +0100

On 25/03/2018 1:04, Sergio Garcia Murillo wrote:
> Also, I don't get where the server load comes from when the hashing 
> can be done client side, so there is no significant extra load for 

Moreover, adding the external session id and supporting it by the 
assertion API doesn't mean that it must be used by the IDP to generate 
the assertion and validate it afterwards. So it is still possible to 
cache identities assertions if the idp decides so.

Best regards
Sergio

---

From: Sean Turner <[email-masked]>
Date: Fri, 30 Mar 2018 19:04:31 -0400

I think this might somewhat be addressed here:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1

spt

> On Mar 19, 2018, at 10:43, Martin Thomson <[email-masked]> wrote:
>