Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

>And now for the thorny isssues with this draft. Signatures and encryption
are different. And encrypting a signed blob doesn't mean the signer
encrypted it.

Who encrypts data doesn't matter. Especially, when the encryption algorithm
is asymmetric, anyone who has a "public" key, which anyone can get, can
encrypt data. What matters is who can decrypt the encrypted data. It is
only the party who has the corresponding "private" key that can decrypt the
encrypted data.

Best Regards,
Takahiko Kawasaki

On Sat, Sep 26, 2020 at 9:47 AM Watson Ladd via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Watson Ladd
> Review result: Serious Issues
>
> I generated this review of this document as part of the security
> directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These
> comments were written with the intent of improving security requirements
> and
> considerations in IETF drafts.  Comments not addressed in last call may be
> included in AD reviews during the IESG review.  Document editors and WG
> chairs
> should treat these comments just like any other last call comments.
>
> Two minor issues: On page 4, "This offers an additional degree of privacy
> protection." should be reworded. I don't think it makes sense in context,
> where
> authenticity was discussed.
>
> It took me a while to understand what the by reference method is: maybe the
> intro should say via URL instead of by reference.
>
> And now for the thorny isssues with this draft. Signatures and encryption
> are
> different. And encrypting a signed blob doesn't mean the signer encrypted
> it.
> Then there are a plethora of methods specified in the draft  to
> authenticate
> the blob, which will give different results in maliciously constructed
> examples. The security considerations section should discuss what the
> encrypted
> vs signed choices give in the way of security, and it doesn't. This makes
> me
> worry.
>
> Looking at the cited reference for attacks, I see the fix is to include
> information about which IPD was used by the RP. But the draft before us
> doesn't
> mandate that. It's not clear than how the cited attack is prevented by the
> draft. Saying that the communication through the user-agent is subject to
> manipulation, and this prevents it, ignores that the attacker in that
> position
> sees a lot more. The user-agent as resource owner modifying the requested
> resources is a very funny sort of attack: can't they do what they want
> with the
> resources since they control the access?
>
> Key management is ignored. This is a very important issue, especially
> considering the potential problems with the reuse of JWT. I'd like to see a
> recommendation that keys be separated by intended uses, rather than
> limiting
> particular fields in an ad-hoc manner.
>
> Then we have section 11. What section 11 introduces is an entire new
> dramatis
> personae, the Trust Framework Provider, with no prior discussion of what
> it is
> or a reference to where it is defined and a good number of statements
> about how
> it works that aren't really  clear what they mean from the document to me.
>
> My biggest concern is that these issues are signs that the problem this
> draft
> is trying to solve and the mechanisms to solve it haven't been analyzed as
> thoroughly as they should have been. Without that sort of thorough analysis
> it's not certain that the mechanisms actually solve the problem and it's
> not
> clear what the recommendations to implementors have to be to preserve those
> properties.
>
> Obviously this draft has had a long and tortured history with multiple
> reviews,
>  and what I'm suggesting needs to happen is a lot of work. But it's
> essential
> in any security protocol to do this analysis and be clear about what is,
> and
> what is not, protected by the protocol.
>
> Sincerely,
> Watson Ladd
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>