Signature Link Relation for Cryptographic Resource Verification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Signature Link Relation for Cryptographic Resource Verification

Sean B. Palmer
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signature Link Relation for Cryptographic Resource Verification

softwatt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/08/2015 05:42 PM, Sean B. Palmer wrote:
> https://www.ietf.org/id/draft-palmer-signature-link-relation-00.txt
>
>
This draft has great potential if expanded.
I propose three additions. The rationale for each of them is explained
in the next section.

1 - Why limit this to PGP? Simple hashes like SHA1 should also be
possible.

2 - Inlining a checksum should be possible.
<a href="/download/example.tar.gz"
rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
Click here to download</a>

3 - This should also work for <img> tags.
<img src="/static/hello.png"
rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
Click here to download</a>


Rationale:

1 - SHA1 is shorter. Allowing compact inlining. This makes "2" feasible.

2 - Inlining means less page requests, this would allow signatures to
be used on multiple <img> tags without performance degradation. This
makes "3" feasible for websites with many images.

3, a - Websites often have images which are fetched from external
websites. Currently, these images are not verified at all, and the
external server can modify them at will. Adding this mechanism
resolves this.

3, b - Currently, https-encrypted sites which use external CDNs for
images must employ some certificate witchcraft. With this change,
https sites can safely link to images hosted in unencrypted servers.
Those images will be verified by the checksum. Of course, this
shouldn't be done for an image whose URL is supposed to be secret.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWaBCKAAoJENivoBfRYOGKW40QAJPOuMefsYLjOg3B7Wep3zWN
yxkh3K2OJgKiuKzljpQPJGmo7LsAjYCxV2MMjcGAI5NpoDNN+mhmI0M8WZPkFAqB
DhAGa1iaT4Zbz4zyCXPUtpmIhStf4gcv090ij+iJAceH3to9Ac6M4fz60pVEv+iR
/d0NgVPQKBRY4tsO5yKXKlz8BrUsg9YY/heENC41+M9UXW7rL3EtLlMMiKvT0XZw
YCbRGF2FmtQFA5DisL/2/k1qX1wAeRBXNG5hRkEGCFYj0Xm1uGziNsshj0jE19b+
1UTS8dM9HM0jl7IlfYjwrvO8rBArmW1PdQWYZFOA201qoplWvy7Wl2HZyqy1Wxrn
gJTToFoId4aKUNNyM2zkPLBHgYzQOyIQuN31bWzTwNeXuyY2ffeYSHVvu36pJVvP
rVGRoRDOvLXK6hpbcAMp0mhtbNf3ZPLX9sTFY9tPy3thIQW2M4SZNAld4H30Feab
PuxgKtH888LJxbthYXhxfvcQMP+3DxU9H8auFB7FDfaIdZVMlTo4On4IMfcJJzby
V8sncw8bQkcxmp4jgRBbq9jbJMVyDX8RsXA/tQFvBs5s2qmK8Gm4NrvtLgA2kQ/G
fRsrXIxKw/YAsbCjEZ++GJhNdyDYZv+ieDqZBBqmBISJqitPT9DdwJIzucaNzCeC
m2aNv4vdaKpVh4e1q0O/
=624t
-----END PGP SIGNATURE-----

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signature Link Relation for Cryptographic Resource Verification

softwatt
In reply to this post by Sean B. Palmer


Some further elaboration:

Regarding SHA1: Download links often work under the assumption that the
local (ideally https-encrypted) site is secure, since it is controlled
by the same person who is offering the download link, while the external
download server is considered untrusted. In such cases, there's often a
checksum and not a fully-fledged PGP signature.
Currently, while some downloads include a digital signature, others just
use a hash. There isn't a reason not to support both methods.

Regarding images and UX: An image with a failed checksum should probably
not be displayed (and perhaps display a warning). An image with a
successful checksum should display normally.

Regarding regular downloads and UX: If it's a signature, showing
signature information makes sense. If it's a simple checksum and the
check succeeds, the download simply proceeds transparently without
displaying any cryptographic info. If the check fails, an error is shown.


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signature Link Relation for Cryptographic Resource Verification

Sean B. Palmer
In reply to this post by softwatt
There are several issues here:

* SHA-1 is no longer secure. "In 2005, cryptanalysts found attacks on
SHA-1 suggesting that the algorithm might not be secure enough for
ongoing use. NIST required many applications in federal agencies to
move to SHA-2 after 2010 because of the weakness." (Wikipedia, SHA-1)
* The values of link relations must be links, not arbitrary data. You
would have to use a hash URI scheme of some kind, and of course to do
so would be a trivial change.
* Hashes for the integrity of content are already being investigated
by the Subresource Integrity group. http://www.w3.org/TR/SRI/

Since the work of the SRI team is so similar to that suggested by my
Internet-Draft, I am starting to discuss the use case with them. Some
further information can be found here:

https://github.com/w3c/webappsec/issues/449#issuecomment-163279813

And there has been discussion on the WebAppSec mailing list.

On Wed, Dec 9, 2015 at 11:29 AM, Safwat <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 12/08/2015 05:42 PM, Sean B. Palmer wrote:
>> https://www.ietf.org/id/draft-palmer-signature-link-relation-00.txt
>>
>>
> This draft has great potential if expanded.
> I propose three additions. The rationale for each of them is explained
> in the next section.
>
> 1 - Why limit this to PGP? Simple hashes like SHA1 should also be
> possible.
>
> 2 - Inlining a checksum should be possible.
> <a href="/download/example.tar.gz"
> rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
> Click here to download</a>
>
> 3 - This should also work for <img> tags.
> <img src="/static/hello.png"
> rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
> Click here to download</a>
>
>
> Rationale:
>
> 1 - SHA1 is shorter. Allowing compact inlining. This makes "2" feasible.
>
> 2 - Inlining means less page requests, this would allow signatures to
> be used on multiple <img> tags without performance degradation. This
> makes "3" feasible for websites with many images.
>
> 3, a - Websites often have images which are fetched from external
> websites. Currently, these images are not verified at all, and the
> external server can modify them at will. Adding this mechanism
> resolves this.
>
> 3, b - Currently, https-encrypted sites which use external CDNs for
> images must employ some certificate witchcraft. With this change,
> https sites can safely link to images hosted in unencrypted servers.
> Those images will be verified by the checksum. Of course, this
> shouldn't be done for an image whose URL is supposed to be secret.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWaBCKAAoJENivoBfRYOGKW40QAJPOuMefsYLjOg3B7Wep3zWN
> yxkh3K2OJgKiuKzljpQPJGmo7LsAjYCxV2MMjcGAI5NpoDNN+mhmI0M8WZPkFAqB
> DhAGa1iaT4Zbz4zyCXPUtpmIhStf4gcv090ij+iJAceH3to9Ac6M4fz60pVEv+iR
> /d0NgVPQKBRY4tsO5yKXKlz8BrUsg9YY/heENC41+M9UXW7rL3EtLlMMiKvT0XZw
> YCbRGF2FmtQFA5DisL/2/k1qX1wAeRBXNG5hRkEGCFYj0Xm1uGziNsshj0jE19b+
> 1UTS8dM9HM0jl7IlfYjwrvO8rBArmW1PdQWYZFOA201qoplWvy7Wl2HZyqy1Wxrn
> gJTToFoId4aKUNNyM2zkPLBHgYzQOyIQuN31bWzTwNeXuyY2ffeYSHVvu36pJVvP
> rVGRoRDOvLXK6hpbcAMp0mhtbNf3ZPLX9sTFY9tPy3thIQW2M4SZNAld4H30Feab
> PuxgKtH888LJxbthYXhxfvcQMP+3DxU9H8auFB7FDfaIdZVMlTo4On4IMfcJJzby
> V8sncw8bQkcxmp4jgRBbq9jbJMVyDX8RsXA/tQFvBs5s2qmK8Gm4NrvtLgA2kQ/G
> fRsrXIxKw/YAsbCjEZ++GJhNdyDYZv+ieDqZBBqmBISJqitPT9DdwJIzucaNzCeC
> m2aNv4vdaKpVh4e1q0O/
> =624t
> -----END PGP SIGNATURE-----



--
Sean B. Palmer, http://inamidst.com/sbp/

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signature Link Relation for Cryptographic Resource Verification

softwatt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Both the specific hash algorithm and the exact implementation details
are trivial changes. My points were focused on the conceptual side.

Thanks for the links!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWaEfwAAoJENivoBfRYOGKXwsP/0G3832n7UzXgY8kJoD5YIOw
+KHj8cetntdmTQQ4ptIqHOp2SIx/3XHSz6TGyFCKZL3dvkL5Qa1Srrpfb0r6T3Hj
JTA7ge5KQZorZBrqNkC1sqqvFN0mg08DivN1rbFh3OEUAEni7EUilIRUKuXPiK+3
06Te7EYBo49tS71N3qofNX6nGWmKmxNDIeN0JPWP5xX4FplBj9eeJLnmgrdTZILm
KYvvrjpeHktZwvasA1Mznr27eFW8CbhDTpbbc29jhJ4TiRV3uk0tDffumJ0nUwa1
KSo9lm6C3eOvMK088Uu2K1LEK9Piyzgn6vWbmSrfY6j/CaXkjtTe9Z0VwtjY8W8R
637lY3CYyBwLkTFTpeWwhOCuJu2CyokXDQA1UvQ/pWBfHFCA3teMtNp0RPM4Q5PC
Q2rRqTbf1lxkBO5vh1iwmpJCBng+Dy77JJ7vKEKIL+s9NFZ+knOYCcWtMHuTwKDH
t/n8IRuM7p8HFfSWk570KrkEWlxvwVKD42+QfPumrA9zFIV+HhfDChH6ZwcR4qVH
M2fwhA0reMvMhmvwUCHUFfJiVev7enMxmJIidQwVnebfMdWp52FWyzzKOFPHe+cC
wK0CwPo0uFQmdCV/GGWs1fIq0ZitfUrl0SdiJpHBZ9UJuuN3EgJVZ7g8gpLuB4uT
JX4wCk8BDzy+aVnSO4jY
=PILp
-----END PGP SIGNATURE-----

Loading...