Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

John Bradley <> Mon, 30 April 2018 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 344FF127201 for <>; Mon, 30 Apr 2018 15:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 dJzRB4dyMPP5 for <>; Mon, 30 Apr 2018 15:11:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87A5A126DED for <>; Mon, 30 Apr 2018 15:11:13 -0700 (PDT)
Received: by with SMTP id j42-v6so12766155qtj.12 for <>; Mon, 30 Apr 2018 15:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j3Ry+r/1yfo6OZVAUViXSSHeeRv8AnpL2GXQiMhBUDI=; b=WvkFbrh2y7QVZMQFzGADiCFxSi4UsbL/U4k5tUuT+afk6AHkOs8+mUAjbhABIDSkRi Wqk3WE7D9tf29iAukzwp9rV0/7ISCO5DP/6uVeLR13xnvDdweTwnh44ZbgiqXOpyFYzX BAlIYClFl8DvZ3bKyJM7y3Xj4a6BGVXTNDIl1Q1tI1UQqXXWjtcc0s8JOzfYovassuNg D3porVZj26pF6/HI77wXW9/ORE9UdBPAXPzHtZpDrgPs1hnkv+FKhEbMlTFAhlagZKG5 hzyx7zyG9OvZoD4arjY0yiU6OSnTadvp9AFO2gLbCbe0WIxx2pVSt/0OCF8xyZob1FCV lglA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j3Ry+r/1yfo6OZVAUViXSSHeeRv8AnpL2GXQiMhBUDI=; b=PqpY/yeWUfZNM5Go1hryoSv2hzp+mluexXP8TVlLQH0//Dl8TfVij3OMHsY6TALIom OnyO4s31xFQ1Azg99F6gsOFwkOy/NT8UxW7bazkY1jKuAxdxesLo3NzZq5GzNwazcAkr ePy3/w+xkhQK+gvL7bP/Jv0s9ePQcGqvfhrk/JZEd19c9pGyLaULHK+Y2YbUJnhkGPMh EAkPghljKS0aNPGmKhULSTgKnfSoCG5JTA+UfXqecd8h34tywsr8vFakMXBCjNIoPmTt 30IEvf52drblOjcnNAQsdqRjYpHB+nnoma073lo/F3BWficEDOYrua2u4d2Bb8ZDHolr /uQA==
X-Gm-Message-State: ALQs6tAqGktwHBkMBKNyozigQxah5tbthBcAvDRCM0mQW7r44tS6dl1k 43rlQqLvzwni8raaKgrVpiFdkQ==
X-Google-Smtp-Source: AB8JxZrw4PRTK97spv6rE/lgW/hEneMfofTRA/TfCWFqRJ+TxeZVElBx6ctmW2N3sKd/7l3QeB1zQQ==
X-Received: by 2002:ac8:2d6e:: with SMTP id o43-v6mr11579295qta.316.1525126272136; Mon, 30 Apr 2018 15:11:12 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id z50-v6sm7278732qtj.74.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 15:11:11 -0700 (PDT)
From: John Bradley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED8A37F-1CEE-4327-A136-9D602FC40D36"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 30 Apr 2018 19:11:05 -0300
In-Reply-To: <>
Cc: Neil Madden <>, oauth <>
To: Brian Campbell <>
References: <> <> <> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Apr 2018 22:11:16 -0000

Yes that is an issue.  

I think one of the things that kicked this off was a question of will this make it pointless for people to use algs such as AES GCM256 when it is perceived that our choice of hash somehow limits overall security to 128bits.

Let me take another run at this.

Things like block cyphers need to have long term secrecy.  An attacker may still get value from decrypting something years down the road.   

Things like signatures typically need to have some non repudiation property that lasts the useful lifetime of the document. That can be years or minutes depending on the document. 

In our case we are providing out of band integrity protection for the cert.  We could include the cert directly but it is allready being sent as part of TLS.  

In general the lifetime of the key pair used for access tokens will be less than the lifetime of the certificate, so it is hard to argue that we need stronger security than the cert itself.

We have a way to rotate keys/certs daily if desired with JWKS and it can support self signed certificates.  The security of this is still limited by the security of the TLS cert for the JWKS endpoint, but that is relatively easy to update if there is a need, and alternate certificate chains become available with security better than SHA256. 

However currently most if not all CAB forum roots are using SHA256 hashes with RSA2048 keys  (some like RSA still have roots using RSA 1028bit keys) 

I am normally the paranoid one in the crowd, but I would rather pick off some of the other issues that are more likely to go wrong first.  

We can point out extensibility for future use, but I am not buying us defining a new thumbprint when the one we have is as strong or stronger than the other parts of the trust chain.

I can see people choosing to use SHA512 having larger messages more processing as a way to avoid certificate rollover and that would be a bad tradeoff.

John B.

> On Apr 30, 2018, at 6:19 PM, Brian Campbell <> wrote:
> On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden < <>> wrote:
> > On 30 Apr 2018, at 15:07, John Bradley < <>> wrote:
> > My concern is that people will see a bigger number and decide it is better if we define it in the spec.  
> > We may be getting people to do additional work and increasing token size without a good reason by putting it in the spec directly.
> I’m not sure why this is a concern. As previously pointed out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn’t seem worth worrying about.
> Seems like maybe it's worth noting that with JWT, where size can be a legitimate constraint, those extra bytes end up being base64 encoded twice.  
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.