Re: [GNAP] Signature Methods

Nicolas Mora <nicolas@babelouest.org> Mon, 21 June 2021 19:02 UTC

Return-Path: <nicolas@babelouest.org>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2073A15E8 for <txauth@ietfa.amsl.com>; Mon, 21 Jun 2021 12:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.537
X-Spam-Level:
X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=babelouest.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruAQIsviBh8k for <txauth@ietfa.amsl.com>; Mon, 21 Jun 2021 12:02:14 -0700 (PDT)
Received: from perceval.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C10F3A1614 for <txauth@ietf.org>; Mon, 21 Jun 2021 12:01:55 -0700 (PDT)
Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-13-70-50-158-193.dsl.bell.ca [70.50.158.193]) by perceval.babelouest.org (Postfix) with ESMTPSA id AE6831FE1A; Mon, 21 Jun 2021 15:01:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=babelouest.org; s=mail; t=1624302113; bh=qqCEMzz1JchFCcnkl0tGXicWhLWqyF4FtNcEP6Nh88E=; h=To:References:From:Cc:Subject:Date:In-Reply-To:From; b=HqP2lSIhWOKdbpFIMUef/CNBbvp7Mq9rhTnmuhPxFbmQScb8DHvAA67geOsswYtJs 4VN8cRHFypp78nrHDLX0Ks+SaVdrPqEJ958zi6sNrCVVYhQC9KWgfp6PS+YRToP7jR JhsAR0ZiEMI1eA6/XwKRZvoWpfQDe/oGzcINc8PKh75WyzP0uX3KobjEyR1z8dBSXz KW+7xrq7ZX8KrHzlsCFcxHTxJ9Yz1HBfCUtEuTWb88Zsboi7m2v+o9he1IxSHL+qlw Vn377YWzAzKjghJFmzSd6LkCM5bbizON7MPsrPKp6I3k71No5A1gHrlt7whomHJAzZ uI4yCM2ADcgjA==
To: txauth@ietf.org
References: <EFDB08A5-51F5-4261-A6E8-A718D07937E5@mit.edu> <d1967b45-cb8e-27df-02e8-2a521dadf31b@babelouest.org> <20CF0679-B898-442F-89D3-902644A4C85A@mit.edu>
From: Nicolas Mora <nicolas@babelouest.org>
Autocrypt: addr=nicolas@babelouest.org; keydata= xsFNBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABzSVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+wsF3BBMBCAAhBQJZiaq/AhsDBQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEP6CE5RAvSK5ZTkP/3PN+SPKLKOcgG/C3ZI9KxM93y4AKZ0z UCBtr2QJDt8viFKq3jPsSo6+Rw1UuY2oDx4wWUXqlsp3NKnvoKWMip6UVVH0XB48iLe4Tiu0 PVqIfHB/MIdE/QSYLFZzX0n4AgTlrho7Hd+S7TZMtf15FKF4/8y5lLVXK86cbZhaOEPcJyb9 taT4IVkU5M22aNfuZAUjexeCsn/em4pjEyREilht8Fo9tND9Nr/w2SOJNAKWZp+JlKR1ok3z sFvEN5rAEsdA9gvQ/5ubs8iXM0KfBHLa0wp/YWRLRrDFoCEqrkZdBetGxJn4G+wNdhb4TTsX HTfb/0Je179uF2jcFawr/DhJb/bKJUB236u2+0e53QufYq8brBqA4aONDCfOVAHVNjazruCK Wli2E2lHvJLVQeFkBP2Mo9IiWO8uNdXpK5QUjcipW5t6fxN1beNzJdZLiHVjjVKskVueoLDY tHt0TzPY75I6Bgy/oRz5e1sP6UjYsZs5+ZUFOw7Zii5kXcPDrhXb1sEd9ZvB4f9XdvxtE91h aUz9EW63XIvsUYsnjqdTznojBVeLVVnZJKp3RlWFw0o0xT90JuOkA5Pw8oL0GpBRA9vaPi1p hs2DCbCRe/U188HkNmhiH1C9dY+J/4h8IvicjIgTI0+27FPFxp6nMlkH4OgjUHZrbvE9E8Sr zonrzsFNBFmJqr8BEADrI5lstjLaS6IXxH37GWvfPLdjLyTFK5kJqyZkhGNMWHmwmRU3BVrz 0M0Tva/a3Z1B+fXJGzKevQhKMBsrpYhkbKkbMg7vreiWhZjQyy5nvbKA4aMhZ1ckmYWExOk2 QiUpTDoLDBN7VEZG+FV9Hw5ZVeH1k5LnbIxxxIGdzK1mxcCBgJodvzHsp1SZefVIKBKLH+y+ scAZDbnDfSUo/1pPgruogskpg67XrtDP/mZxgf7GB0wlrQrrJt9eBuCD5NXIjtl8KvEIPKTx AlYf/Gu8ZCuu0cwHLl/79WUH6wT35XByAsBMtuG8dHDidj50/XkpP2L6GE52KYTNoQVv5XoA IzpuwXDxcTML0JjE1EKAfRFeyuuiMncX9dgtRdJGMgN/4HYzIiSvWsjYkgVUFrh/ZlENbE6D hy4NLqDEBQb5RMIWrO7VVaAKosRysY72G3Z1FmS2m2dPAlNNLGHESlcLp3nwnNFFneQif4Kf 1ZdFMZJCy8D6n+TbuZmY8eMC624Ot5h18an0yBWFE8E/XU4yQR6savhhinY1Yc4EKjcNiP4c Trphh4cE7XgMitX+0yc1D9s7umuiBdqw9VAsyA20NfLZCMxieiGYcgda1WPA5V7jQc3m8G+C Jyg762Tb3XyPGBPy4TDfghpw1RqYf8wYAi8e74wKHck/uAP6R1lc7wARAQABwsFfBBgBCAAJ BQJZiaq/AhsMAAoJEP6CE5RAvSK5Y4AP/Rb0F2lmB6uDu66BhCYX7Z2hcnt4/LZK1hYb6fRO 3mnW8XClntYOGbKoAGAQDS3PrIx2EJkUr5FiWMpnneQPcwfNuL7VlSqlcFfwN+kkjTcsIjrw 3KMgGNbjjQ83jCUzidyQ4eg18AKKaxb0NrA8UNRTvtK0ozSThxnzLZ20nu/mU9NJhcMVx2Qz IEUiJK5ag3uXli/r52ILle5Wq9LPxjPEsl0oGlqNMGcCZLr20tHXm0XLrSVEenWKL8hjaEud PNdcKMLBWVsp0VIS/di1fsQgwhuJ9C+fwhtqaGsL5DsKDYhrUo1iKi4avX0f8IdzenQSKFso Jf+t+kHIm5/ZdZ8jMN081RznIvz8p8BxWOzbg+BZCCkOIsCxypmU9WgMMJ3hXgRa2OIhQZQ3 AnBc/U843uU/7HVRMhd4efzjNw/v1joDd4KEJEHnS/jT/s9jxEyikOtQW9otJBLgZpoEG+9R FCKPu4TV8RB9kZCHOM5lwSwq7CIwwVltF1pMRokm6X7lyclZ4iCEtfZAM6ZuvN/fh1GbIJxf t+hIWqDPiG9bPtoXZMArUi1zCaSmFdzba/15+P+B3EyaadYiSjVn9WBhe6syxZ8WYo0ehvJE e42BLGcGRcQl+l2Jt57D3FPDYYJEUkl72sGhhKbrg4YBVfCoWuchD0wXvR9ARXtLK5H4
Cc: Justin Richer <jricher@mit.edu>
Message-ID: <30079bea-b511-a208-8db1-51af3a04de4f@babelouest.org>
Date: Mon, 21 Jun 2021 15:01:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20CF0679-B898-442F-89D3-902644A4C85A@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Be1qIcDrVtgCNeg35IKp1MP3GpSPDvaVw"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/XqEa0rb7f4CKUmEYUao2Szeh9as>
Subject: Re: [GNAP] Signature Methods
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 19:02:20 -0000

Hello Justin, thanks for your comments,

If I wasn't clear, my point is to keep attached and detached methods in 
the core GNAP protocol, in addition to the other available signatures 
methods mentioned.

Although, DPoP and PoP signatures can be dropped from the core specs, 
their complexity and security levels are covered with other methods.

My objective is to have an easy-to-use signature method in GNAP core, to 
allow more app and services to adopt GNAP.
Although there might have drawbacks in such methods, it would be the 
administrator's responsibility to allow or not some methods with some 
resources and some clients.

Le 2021-06-21 à 09 h 51, Justin Richer a écrit :
>>
>> - step 1: build the request as a JSON object
>> - step 2: serialize a JWS in compact mode using the private key
>> - step 3: send the request to the AS
> 
> The attached method is deceptive like that. While it seems that simple on the surface, there are a couple of major drawbacks to this approach:
> 
> - It only works for requests to JSON-based APIs. What about XML, Form, CBOR, or anything else? JWS would still work but you’d need a different encoding for the body.
You can specify a header typ or cty for that, and state some typ/cty 
values that are acceptable for GNAP requests for example.

> - It only works when you have a message body, so it only works for POST and PUT in practice. You need a detached method for GET, HEAD, OPTIONS, and DELETE anyway.
I concur, and yes, I don't see detached method usable for every use case.

> - The receiving end needs to be able to handle application/jose instead of application/json. For most application frameworks, this means putting in a filter that translates the incoming JOSE object to a JSON payload that the underlying system can then parse into native objects for the API to consume. While of course it’s possible to do all the parsing by hand inside your handler methods, it’s not a good for adoption if we presume everything will need to be special-cased by hand.
> 
That will the responsibility of the client or client library.
I can only speak for myself but I don't see it more difficult to call a 
  parse method with the JWS payload and a JSON library than calling a 
getClaims() method on a JWT.

Also, an advantage of using a JWS is that you can compress its payload. 
The "ZIP: def" header is defined in the JWE RFC only, not the JWS RFC, 
but the JWS RFC doesn't explicitly forbids it.
I didn't even thought of it before I saw it in the smarthealth JWS 
format specification [1]. Now I would like it everywhere! :-)

> These aspects alone are incredibly limiting for the attached method, but there’s even more than that. You have to replicate parts of the HTTP message inside the JWS somewhere in order to have them covered by the signature. The GNAP definitions currently do this inside the JWS header, but other proposals use the JWS payload itself. This is extra work for the client and leads to error cases that the server needs to explicitly detect by looking for information in multiple places (ie, a signed POST request was sent with a GET).
>   
I agree with you, but then I have a question regarding that: why does 
the HTTP parameters must be part of the header or the payload in 
addition to the HTTP request?
I asked myself this question when I read an earlier GNAP specification. 
I assumed the goal is to add entropy and another check for the client to 
make before sending a request, i.e. are you sure you're asking the 
proper question? Isn't is a duplicate from a previous request?

I told myself such parameters (uri and htm) could be replaced by a jti, 
but, again, this idea is from a limited point of view and I'm pretty 
sure I don't see the big picture.

> Unsigned JWS is explicitly forbidden, as is “alg:none”. If you’re going to send an unsigned request, just send the plain JSON.
> 
My bad, thanks for the clarification

> 
> Other methods will still be available, but this discussion is about what goes in the core document. The registry will allow for extension of other signing methods, and the core spec will put parameters on what any new signing methods need to cover.
> 
That's what I'm afraid of: having attached and detached signatures 
methods in an extension.

I'd rather have those methods in the core document. So the core GNAP 
spec would cover most use cases: SPA, website, app, fridge, TV, embedded 
sensor, satellite, etc.
All those use cases will have the same goal, but can choose one 
signature method that fit its needs, and its security requirements.

>>
>> I wasn't there at that time but I've read that OAuth1 and SAML had this problem, and OAuth2 was made to avoid too much complexity.
> 
> The complexity is part of the story, for sure — but OAuth 2 is currently adding higher levels of protection through MTLS, DPoP, and HTTP Signatures, among a bunch of others. It’s really awkward in OAuth 2 because we need to work around an infrastructure that didn’t anticipate things. We :tried: to anticipate them, but it’s still a bit awkward. Avoiding complexity is actually one of the reasons the editors are suggesting dropping the GNAP-specific methods from the core and keeping the general-purpose methods of HTTP Message Signing and MTLS, which will find implementation and use elsewhere. OAuth 1 used a very fiddly custom signature scheme based around URL parameters, and it was really hard to get it right. That scheme also assumed shared secrets, which made it hard to secure properly.

I agree, I chose to implement all those oauth2 client authentication 
schemes, and it's quite complex.
The most difficult part is that all those methods are extensions, so 
they know the core specs but not each other, therefore I have to make 
choices for all of those to work together.

That's the reason I prefer the detached and attached methods in the core 
specs.

/Nicolas

[1] https://spec.smarthealth.cards/#health-cards-are-small