Re: [jose] JWS Signing of HTTP attachments

[Sergey Beryozkin <[e-mail]>]

Hi,

On 12/05/17 17:45, Jim Schaad wrote:
>
>
> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Sergey Beryozkin
> Sent: Friday, May 12, 2017 9:04 AM
> To: Ilari Liusvaara <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [jose] JWS Signing of HTTP attachments
>
> 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
>
> [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.

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
>
>
>
> Cheers, Sergey
>
> On 12/05/17 16:52, Ilari Liusvaara wrote:
>> 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].
>>>
>>> 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) ?
>>
>> 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
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>