W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2014

[Bug 25721] extractable keys should be disabled by default

From: <bugzilla@jessica.w3.org>
Date: Mon, 28 Jul 2014 15:55:12 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25721-7213-mD3xfBhbMe@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

Harry Halpin <hhalpin@w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hhalpin@w3.org

--- Comment #18 from Harry Halpin <hhalpin@w3.org> ---

Quick note Elijah and any others interested in this bug,

Per Virginie's comment, if we formally bring this larger issue up with the Web
Security Model up to the WebAppSec (Web Application Security Model) WG, would
that satisfy the reviewer?

   cheers,
      harry

(In reply to virginie.galindo from comment #17)
> Hi all,
> 
> Provided the balanced discussions Web Crypto WG had with respect to the key
> extractability – how it is needed, how it can be used, what are the
> limitations. 
> Provided the fact that implementers, developers and users are made clearly
> aware of the security expectation for the Web Crypto API [1] and extractable
> key in particular (see [extract] below). 
> Provided that user interaction (suggested in the bug discussion as a
> possible technical answer to security concerns) is something that is usually
> out of scope of the W3C domain and does not have a real security value
> proposition. 
> I suggest that we close this bugn with WONTFIX. 
> 
> Regards,
> Virginie
> Chair of the Web Crypto WG
>  
> [1]
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.
> html#security-developers 
> [extract] Applications may share a CryptoKey object across security
> boundaries, such as origins, through the use of the structured clone
> algorithm and APIs such as postMessage. While access to the underlying
> cryptographic key material may be restricted, based upon the extractable
> attribute, once a key is shared with a destination origin, the source origin
> can not later restrict or revoke access to the key. As such, authors must be
> careful to ensure they trust the destination origin to take the same
> mitigations against hostile script that the source origin employs. Further,
> in the event of script injection on the source origin, attackers may post
> the key to an origin under attacker control. Any time that the user agent
> visits the attacker's origin, the user agent may be directed to perform
> cryptographic operations using that key, such as the decryption of existing
> messages or the creation of new, fraudulent messages.
>
(In reply to virginie.galindo from comment #17)
> Hi all,
> 
> Provided the balanced discussions Web Crypto WG had with respect to the key
> extractability – how it is needed, how it can be used, what are the
> limitations. 
> Provided the fact that implementers, developers and users are made clearly
> aware of the security expectation for the Web Crypto API [1] and extractable
> key in particular (see [extract] below). 
> Provided that user interaction (suggested in the bug discussion as a
> possible technical answer to security concerns) is something that is usually
> out of scope of the W3C domain and does not have a real security value
> proposition. 
> I suggest that we close this bugn with WONTFIX. 
> 
> Regards,
> Virginie
> Chair of the Web Crypto WG
>  
> [1]
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.
> html#security-developers 
> [extract] Applications may share a CryptoKey object across security
> boundaries, such as origins, through the use of the structured clone
> algorithm and APIs such as postMessage. While access to the underlying
> cryptographic key material may be restricted, based upon the extractable
> attribute, once a key is shared with a destination origin, the source origin
> can not later restrict or revoke access to the key. As such, authors must be
> careful to ensure they trust the destination origin to take the same
> mitigations against hostile script that the source origin employs. Further,
> in the event of script injection on the source origin, attackers may post
> the key to an origin under attacker control. Any time that the user agent
> visits the attacker's origin, the user agent may be directed to perform
> cryptographic operations using that key, such as the decryption of existing
> messages or the creation of new, fraudulent messages.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 28 July 2014 15:55:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:23 UTC