Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDB41200B7 for ; Mon, 20 Jan 2020 10:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dEBzRWty3g0D for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B89C1201DC for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id w15so483619wru.4 for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=oYPQzqeu2SzQnyRJ8RNIbHSBYAtnne1JxkkKbYLYxo1kgvFxC4xg4qxaeX+dvawllY +7JPCxMHccI9LAgL82XG4x/eN2PQNfNfc1jKqKdFBejedvlToO+z075ZB7i534eKs4PY NJ1N6z3SIC3pAuMGYOuwCpx/96oFAAoJL/fc7//8UXWUwSh6cG1TiQrO3jvqGWZJx4fa PfJ7RmStA+ygd5+hiB60qI98n7GHsejYATjvJPL1lowBES1o8fnkXYWhzH0pc5LgDwfU JyvR8t0XajbQCfuGL28NEE20ViSczubU7yRGWTm0Pkof6VT95WnVBErUW7DhDmSf0PBh R/2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=RvgSGFBNHl5brRuuMPsYaxvw4YuXpeDLZo5sdH5Wtu/vi2tb+y1AltpeOPFiQmPQsX Nlc85C/B5w+WBhIm11DFvnFxjoL4SsVCguKhDxHRIPXAhvTAdCIh1Tg3Na+1qygiXlCg p8JK6BwXdBUqUQfuWEr6PgVz8bVX6wWQMkI1tlq3meJyMwMaEWnvbx++zO84FywL9FRb 9hBKN8+5/m20GKbhXvbNqVkzO+BBEVvWW079Zq/v+MvROsg5xZ8lHr5DG/+Cjb/SUUUs e+kikrJSIETGsJyhcPjOJJv656IOgZa5DgJbgAB74A2vdDv/z0hSD/c7uDFCbKiFCPvi iQgw== X-Gm-Message-State: APjAAAV6tqHqq1YlWQcbkPNcPV16icLNaJzu6+991hQ9PG9WNzsWBU/V T0bG74VlLZvtfjGZPi7W1NA= X-Google-Smtp-Source: APXvYqzsLsP7jK6NftoNAlfQlsOBMB8YuDaDm2VAh9iM1nAUa1lWxgw74j/kBZY1+0lF6lvm+8py9g== X-Received: by 2002:a05:6000:1047:: with SMTP id c7mr742062wrx.341.1579544294513; Mon, 20 Jan 2020 10:18:14 -0800 (PST) Received: from ?IPv6:2a02:a443:c7cb:1:6daa:a695:f46c:5b08? ([2a02:a443:c7cb:1:6daa:a695:f46c:5b08]) by smtp.gmail.com with ESMTPSA id w17sm48658445wrt.89.2020.01.20.10.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 10:18:13 -0800 (PST) From: Rob Cordes Message-Id: <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 20 Jan 2020 19:18:12 +0100 In-Reply-To: <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com> Cc: Rifaat Shekh-Yusef , oauth To: "Richard Backman, Annabelle" References: <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver X-BeenThere: oauth@ietf.org 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: Mon, 20 Jan 2020 18:18:19 -0000 --Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Sorry for me answering in this direct manner instead of via the OAUTH = mailing list or so. I would like to point a practical issue out wrt the HTTP signature spec. = I have got practical experience with the spec through my work for ING in = our PSD2 (European electronic banking scheme) platform. We have = implemented this spec (cavage-10) in our platform as well. We experience = lots of issues with 3rd party developers who have issues getting their = code right. It is the canalisation that is troubling the adoption in = practice. People are continuously making mistakes with setting up the = payload for signatures / body digest. This can only be solved by making available ready made libraries. That = might be done through vendors and their solutions and one would = encounter probably less interoperability issues.=20 However until then still troubles is what people have with this spec. = Apart form that, the spec is very much draft and as I understood from = one of the draft members and still not security tested ands so perhaps = still not secure. Before one can adopt another spec into, in this case OAuth 2.0 it would = be wise to tackle this first. While HTTP signing does help in better = authenticating and safeguarding messages/token requests, this will make = key management even more important. =20 The risk that HTTP signing in OAUTH might mitigate, could very well be = far easier solved by TLS 1.2 or 1.3. That is even better because the = implementations are security tested (TLS 1.2 or depending on the = supplier/implementer in the process of (TLS 1.3) due to their importance = and can be implemented in a turn key manner.=20 These are I believe important attention points that one might think over = before extending the OAUTH 2.0 spec even further with perhaps too little = gain? Best regards, Rob Cordes Feature Engineer / InfoSec specialist @ ING bank > On 20 Jan 2020, at 18:33, Richard Backman, Annabelle = wrote: >=20 > I would like to discuss HTTP Message Signatures = = as a proof-of-possession mechanism for OAuth. A draft will be available = (either as an update to draft-ietf-oauth-signed-http-request or as a new = individual submission). > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Rifaat Shekh-Yusef = > Date: Monday, January 20, 2020 at 7:34 AM > To: oauth > Subject: [OAUTH-WG] OAuth Topics for Vancouver > =20 > All,=20 > =20 > Please, let us know if you have any topics that you would like to = present and discuss in Vancouver. > =20 > Regards, > Rifaat & Hannes > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,


Sorry for me answering in this direct = manner instead of via the OAUTH mailing list or so.

I would like to point a = practical issue out wrt the HTTP signature spec. I have got practical = experience with the spec through my work for ING in our PSD2 (European = electronic banking scheme) platform. We have implemented this spec = (cavage-10) in our platform as well. We experience lots of issues with = 3rd party developers who have issues getting their code right. It is the = canalisation that is troubling the adoption in practice. People are = continuously making mistakes with setting up the payload for signatures = / body digest.
This can only be solved by making = available ready made libraries. That might be done through vendors and = their solutions and one would encounter  probably less = interoperability issues. 

However until then still troubles is = what people have with this spec. Apart form that,  the spec is very = much draft and as I understood from one of the draft members and still = not security tested ands so perhaps still not secure.

Before one can adopt = another spec into, in this case OAuth 2.0 it would be wise to tackle = this first. While HTTP signing does help in better authenticating and = safeguarding messages/token requests, this will make key management even = more important.  

The risk that HTTP signing in OAUTH might mitigate, could = very well be far easier solved by TLS 1.2 or 1.3. That is even better = because the implementations are security tested (TLS 1.2 or depending on = the supplier/implementer in the process of (TLS 1.3) due to their = importance and can be implemented in a turn key manner. 

These are I believe important attention points = that one might think over before extending the OAUTH 2.0 spec = even further with perhaps too little gain?

Best regards,

Rob = Cordes
Feature Engineer  / InfoSec specialist @ ING = bank


On 20 = Jan 2020, at 18:33, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

I would = like to discuss HTTP Message Signatures as a proof-of-possession = mechanism for OAuth. A draft will be available (either as an update to = draft-ietf-oauth-signed-http-request or as a new individual = submission).
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Monday, January 20, = 2020 at 7:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Topics = for Vancouver
 
All, 
 
Please, let us know if you have any = topics that you would like to present and discuss in Vancouver.
 
Regards,
 Rifaat & Hannes
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E--