Subject: [jose] JWS Signing of HTTP attachments

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 12 May 2017 13:59:21 +0100

Hi All,

I've experimented in our project with having HTTP attachment parts 
protected using JWS with Detached Content and Unencoded Payload options [1].

This approach appears to be quite effective to me. It also appears to me 
that the data as shown in the example at [1], can, in principle, be 
produced and processed by any HTTP stack that can work with multiparts, 
assuming a JOSE library supporting the detached and unencoded content is 
also available.

I'd appreciate if the experts could comment on 1) do you see some 
weaknesses in the proposed approach and 2) can someone see a point in 
drafting some text around it (I can contribute if it is of interest) ?

Thanks, Sergey

[1] 
http://cxf.apache.org/docs/jax-rs-jose.html#JAX-RSJOSE-SigningandVerificationofHTTPAttachments

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 May 2017 18:52:48 +0300

On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote:
> Hi All,
> 
> I've experimented in our project with having HTTP attachment parts protected
> using JWS with Detached Content and Unencoded Payload options [1].
> 
> that the data as shown in the example at [1], can, in principle, be produced
> and processed by any HTTP stack that can work with multiparts, assuming a
> JOSE library supporting the detached and unencoded content is also
> available.
> 
> I'd appreciate if the experts could comment on 1) do you see some weaknesses
> in the proposed approach and 2) can someone see a point in drafting some
> text around it (I can contribute if it is of interest) ?

It look from the text that the implementation can produce output before
the entiere signature (or tag in case of encryption) has been verified.
This is very dangerous if so.

Then there are the standard attacks against JOSE (the JOSE library must
not be vulernable to these):

- The JWS HMAC versus signature confusion
- The JWE ECDH-ES invalid curve attack.

-Ilari

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 12 May 2017 17:03:51 +0100

Thanks for the initial feedback. I'm not following at the moment how any 
of these attacks can affect it. Perhaps I'll need to work on making it 
more obvious how it is all implemented.

It is simply a concrete implementation of JWS with Detached Content.
The content is written out and by the time it's finished the JWS payload 
will be finished and will accompany this content.

On the receiving end the verification provider will be instantiated 
(with the proper care, example, the server will not support the dynamic 
verification provider selection process - i.e - will be expected to 
process only RSA or HMAC etc signatures). Once this provider is 
available it will then get all the data which is being read passing 
through the verification process and finally compare the signatures

Cheers, Sergey

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 May 2017 19:24:00 +0300

On Fri, May 12, 2017 at 05:03:51PM +0100, Sergey Beryozkin wrote:
> Thanks for the initial feedback. I'm not following at the moment how any of
> these attacks can affect it. Perhaps I'll need to work on making it more
> obvious how it is all implemented.

Well, from the description I gathered that (partial) output is passed
to application before the signature is verified. This is bad. But
perhaps the description is just a bit misleading, and all input is
buffered until signature is verified, and only then is the signed
content sent to the application.

JWS has an issue where signatures and MACs can be confused, leading to
signature forgery if JWS implementation is not careful.

JWE when used with ECDH-ES with NIST curves has an issue that
compromises the private decryption key if JWE implementation is not
careful.

-Ilari

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 12 May 2017 17:41:10 +0100

Right, the reference to the incoming signed data (the protected payload) 
is indeed available but the read process will fail to complete if the 
verification process fails.

I'll need to make it more obvious in the docs.

Thanks, Sergey

---

From: Jim Schaad <[email-masked]>
Date: Fri, 12 May 2017 09:45:55 -0700

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Friday, May 12, 2017 9:04 AM
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [jose] JWS Signing of HTTP attachments

On the receiving end the verification provider will be instantiated (with
the proper care, example, the server will not support the dynamic
verification provider selection process - i.e - will be expected to process
only RSA or HMAC etc signatures). Once this provider is available it will
then get all the data which is being read passing through the verification
process and finally compare the signatures

[JLS] To be clear here, the question that is being asked is - are we going
to show content to the user, and perhaps start executing script, before we
have finished verifying the signature.  This is normal for browsers as they
do incremental display as things are processed.  And then, what happens to
the display if the signature fails to verify.

Cheers, Sergey

On 12/05/17 16:52, Ilari Liusvaara wrote:
>> This approach appears to be quite effective to me. It also appears to 
>> me that the data as shown in the example at [1], can, in principle, 
>> be produced and processed by any HTTP stack that can work with 
>> multiparts, assuming a JOSE library supporting the detached and 
>> unencoded content is also available.
>>
> It look from the text that the implementation can produce output 
> before the entiere signature (or tag in case of encryption) has been
verified.
> Then there are the standard attacks against JOSE (the JOSE library 
> must not be vulernable to these):
>

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 12 May 2017 20:14:56 +0100

Hi,

> the display if the signature fails to verify.

Right, I understand what the concern is, thanks.

I believe this is a general security issue to be considered for JWS With 
Detached Content - the secured data and their signature have reached the 
destinations via the different channels, where the data has already been 
obtained (possibly read completely), and now is passed to the JOSE 
library to verify the data are still OK.

I guess it should be noted that JWS With Detached Content should be used 
with care when it is expected that the data will be made available to 
the user's display or similar. Perhaps I'll send another email to keep 
the issue tracked ?

For my project I think I'll introduce an optional (possibly enabled by 
default) buffering of the attachments on the receiving end - so it will 
be 50%  (sender-only) streaming friendly in this case :-).

FYI my primary goal has been to ensure the client application, Java 
based or browser-based, can post the secured attachments to the HTTP 
service - say a service will need to copy InputStream to the disk - in 
this case, even though the code will access the stream immediately, the 
copy process will fail to complete, etc. I suspect it could be 
acceptable in some cases especially if the task is to protect 1MB.etc 
attachments.

However I do understand that if such data are started immediately acted 
upon before the read process is even complete, either on the server, or 
especially on the UI-aware client side then there could be the 
side-effects and as I noted I'll optionally support the caching of the 
attachment parts before they are submitted to the service code.

Thanks very much, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 15 May 2017 13:39:25 +0100

I've implemented the optional buffering of the attachment streams on 
receiving end, and prototyped the following text, I don't have the 
experience to drive it further, nor do I expect it to make it to the 
draft stage, but I thought I'd type in some prototype.

Thanks, Sergey

Using Json Web Signature (JWS) to sign HTTP Multipart payloads

Abstract.

JSON Web Signature (JWS) represents content secured with digital
signatures or Message Authentication Codes (MACs) using JSON-based
data structures, with the content being optionally detached [RFC7515].
The content can also be secured without it being Base64URL-encoded 
[RFC7797].
HTTP Multipart payloads are HTTP messages constructed according to HTTP 
multipart
media type rules [RFC1341]. This specification describes how HTTP 
multipart payloads
can be signed using JWS With Detached and Unencoded Content mechanism.

Introduction.

HTTP Multipart data structure, in combination with JWS With Detached and 
Unencoded Content mechanism,
can provide for the end to end integrity protection of HTTP Multiparts.

The sender of such secured payloads will stream and have no need to 
buffer the data while the receiver may optionally continue
streaming the data (see Security Considerations).

Implementation.

Implementations supporting this specification will need to intercept 
HTTP Multipart write and read processes.

When request or response attachment parts are about to be submitted to 
the HTTP Multipart serialization provider, JWS Multipart Output Filter 
initializes a JWS Signature object which can dynamically build up a 
signature. Next every parts's output stream is replaced with the 
filtering output stream which updates the signature object on every 
write operation. Finally this multipart filter adds one more attachment 
part to the list of the attachments to be written - this part holds a 
reference to JWS Signature. When this last part is written, JWSSignature 
produces the signature bytes which are encoded using either JWS Compact 
or JWS JSON format, with the detached and unencoded content already 
being pushed to the output stream.

When the attachment parts are about to be read by the Multipart 
deserialization provider, their signature carried over in the last part 
will need to be verified. Just before the parts are about to be read in 
order to be made available to the application code, JWS Multipart Input 
Filter checks the last part and initializes a JWS Verification Signature 
object which can dynamically build up a signature. Next for every 
attachment but the last one it replaces the input stream with the 
filtering input stream which updates the signature verification object 
on every read operation. Once all the data have been read it compares 
the calculated signature with the received signature.

Example.

JWS-signed HTTP Multipart payload captured on the wire

Security Considerations.

Using JWS to validate Detached Content implies that the content and the 
signature have been obtained
via the different channels with the receiver starting the signature 
verification process once both the
data and the signature have been received.

In the case of this specification the references to the attachment data 
can become available to the receiving code
before the data have been validated, with the data read process failing 
to complete in case of the signature verification failure.

However, if, as part of the read process, the receiver copies the data 
to the medium which can pro-actively interpret the copied bytes,
example, the client receiver copies the data to the embedded browser 
window, then, in order to avoid the side-effects, the receiver of signed 
HTTP multipart payload MUST buffer and validate the multipart data first 
before making it available to the application code.

References.

https://tools.ietf.org/html/rfc7515
https://tools.ietf.org/html/rfc7797
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

See also:

https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-09

On 12/05/17 20:14, Sergey Beryozkin wrote:
>> process