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

Takahiko Kawasaki <> Sat, 26 September 2020 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 793863A084D for <>; Sat, 26 Sep 2020 05:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p2Z47kdqWsqr for <>; Sat, 26 Sep 2020 05:46:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 617643A084A for <>; Sat, 26 Sep 2020 05:46:09 -0700 (PDT)
Received: by with SMTP id k15so6797620wrn.10 for <>; Sat, 26 Sep 2020 05:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WfkduaNsMGbCxYWrUS6vkQnPxC8dGW9h6dSEihomNcs=; b=NfPC86AUWNdZDItubJhoglZitu2uUdS+RGliwAJARDkSgicBCaIOp7auceFsrhbVTq hs8P4AP/CIC63ZTAIWYTu7JJZxg4+B/nFLA9vTE0zJcpLsYdWkI4JFMyDSyukknzmG8y rKIWnVDh5wwKclc8PL08qfkx3DGAVYCCCjH1d4qiAfR/0TLa7Ijhs0LBAkOh4EYZUkyv IjEdN3bQ7zgWucC4KTiFly6P+b0/BuMn8ALBMN7FyZUwmiUOMrcae7+2mVyuhI6ShPIG 2ffaIhs9oeNm3lEgA08ZDfqkgkmjgN809QumJIvOKjr62qL2IfoMWc8xf9NCUNGSinyK hhow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WfkduaNsMGbCxYWrUS6vkQnPxC8dGW9h6dSEihomNcs=; b=R+WqJLjccsk8g2HRkFNwZUbRU5f6DxoYru+h3JTqEGZ7QLjfj3wcNKIh4wimyObxks 8mBH4iEU0fUo7a+Dc/tWIy//FMTVk8gsgz76FPZyimoJvytZK+HvLZw0wf49IqQu75ru VLb1JjBU1IsiXXPVZd+s5ywnvs3Hl2D3V5rd71RCsEbrvE38RWMrCWfJrap5MQwkk+64 G9ajfzX2HWM5DucaGDMm5Cg2CMf8Clq7IvFsQI+IESrlygo3tMP57XCGUV5M9UW67U9k GC83yzitzAVsQAfQZIAcpFrWTaIcj/KNX13ha8Z0t29wLkdj5omgvzn8EdIueQ7itTLc YP0A==
X-Gm-Message-State: AOAM532EKfGhnz0H4WVMBkOKDpUsdLUt2tDgemzu8IgLtGmvLPsrBE5M oosWlEzPIjcxV7b4C6FRqyViD4HCBWCT3Pwmx+xWSg==
X-Google-Smtp-Source: ABdhPJxg54/w8MuF4dB9o7+ZKCsSI+VVXcRLsjMUebLZuqeghr/iT8cx1QjmMt2KHzXabZFMnbb1PEQiBRLkTRvt7CA=
X-Received: by 2002:a5d:660f:: with SMTP id n15mr10073860wru.103.1601124367455; Sat, 26 Sep 2020 05:46:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Takahiko Kawasaki <>
Date: Sat, 26 Sep 2020 21:45:56 +0900
Message-ID: <>
To: Watson Ladd <>
Cc:,, oauth <>,
Content-Type: multipart/alternative; boundary="00000000000029f12905b036d10f"
Archived-At: <>
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Sep 2020 12:46:12 -0000

>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 <> 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