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

John Bradley <> Thu, 12 April 2018 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88EEA12D87F for <>; Thu, 12 Apr 2018 12:52:21 -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 2AkDdWe3ViGn for <>; Thu, 12 Apr 2018 12:52:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11CAA129515 for <>; Thu, 12 Apr 2018 12:52:18 -0700 (PDT)
Received: by with SMTP id p126-v6so2616584ybg.8 for <>; Thu, 12 Apr 2018 12:52:18 -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=aRQF4dYHF/7n89NXJ7+6iMmKLlTku77kZU2wErXjBjk=; b=yVuXdZJeMJfDJPhhmIDorOp9ShLEncVq4X2E2hjNiR9kSeja3W8RgZ2PWzHmB6uiBA +f3l2AZCLR5MsSn7ZBkxx+vNke8c4g3JKlA0jEnMOpIlaQdr4MMHfz8XXyV4/cclq+j+ vE8DH0rtkA7+f5S7w4MpQhHG4lRFjsLis8S1igq1Ms3ny2IE8zBdgLECg3XZLnJcNDHb ev5GQwvv/PoP0bcKLGrugvyfbKSfHJnvVam9s/iA5YLgU03bRp1D7GpV+Y2nVxooPs9p 02Mq9NLKtuSCmgQkSY5iPV+eHByo4hUt8kD43gyuMR5pxohXFsIx7SycvPp5JqyOHQ3w CcPA==
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=aRQF4dYHF/7n89NXJ7+6iMmKLlTku77kZU2wErXjBjk=; b=Sja1/832XA+JaiNVqh2iio1SO4ODsohJx04maqNZk6sKL+ZFUnnVZrrey8XVK9XQzS tO0yKoQnfbRSQK3Sxi7iKIVZ+vVztYe2Cvm/jokvkQ5FALpqyQSIhKELZb/MW/kIYtRR jL0EWWq4O8pJ3kyqwD2wSbS6+Z2oujTB579Hwt2STQojNZNkewEXtYftDcbhvDE+6RR8 xk/jzPGSUSx7Es8XqHB5egnucF2d93qBYGpeJmhUHBH1ldf579WrR90x4jOQRHRVxhdq TtmoFafFHaTygF32TiyUnrnoPzLUONOJY8E9tzpjd6MxnzzSpmnMiB4uUVzJiiwkzIx3 Dzdw==
X-Gm-Message-State: ALQs6tA/NXAxlAvzFH5uD9U2eUp/m0wZoLB5JQMLbH6vOE4u2vKLA2mZ XHBLENUxvBUCuVLHiaaY/Mq0hA==
X-Google-Smtp-Source: AIpwx49eYeWb3vBvke1VAuTs/2ryeRiJDB4ZYF8WEqmUsqHfl2RD6T9UZDbEOkjxDCC5O/zzzjj1uw==
X-Received: by 2002:a25:e645:: with SMTP id d66-v6mr1589283ybh.370.1523562737807; Thu, 12 Apr 2018 12:52:17 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id i15sm694366qta.4.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 12:52:16 -0700 (PDT)
From: John Bradley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A659EE5D-AF1C-409B-BD63-10A2D747E52B"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 12 Apr 2018 16:52:12 -0300
In-Reply-To: <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary>
Cc: Brian Campbell <>, oauth <>
To: Neil Madden <>
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: Thu, 12 Apr 2018 19:52:21 -0000



> 12. The use of only SHA-256 fingerprints means that the security strength of the sender-constrained access tokens is limited by the collision resistance of SHA-256 - roughly “128-bit security" - without a new specification for a new thumbprint algorithm. An implication of this is that is is fairly pointless for the protected resource TLS stack to ever negotiate cipher suites/keys with a higher level of security. In more crystal ball territory, if a practical quantum computer becomes a possibility within the lifetime of this spec, then the expected collision resistance of SHA-256 would drop quadratically, allowing an attacker to find a colliding certificate in ~2^64 effort. If we are going to pick just one thumbprint hash algorithm, I would prefer we pick SHA-512.
> The idea behind haveing just one thumbprint hash algorithm was to keep things simple. And SHA-256 seems good enough for the reasonably foreseeable future (and space aware). Also a new little spec to register a different hash algorithm, should the need arise, didn't seem particularity onerous. 
> That was the thinking anyway. Maybe it is too short sighted though?
> I do think SHA-256 should stay regardless. 
> But the draft could also define SHA-512 (and maybe others). What do you and WG folks think about that?
> *** Yes please. 
> It would probably then be useful for the metadata in §3.3 and §3.4 to change from just boolean values to something to convey what hash alg/cnf method the client expects and the list of what the server supports. That's maybe something that should be done anyway. That'd be a breaking change to the metadata. But there's already another potential breaking change identified earlier in this message. So maybe it's worth doing...
> How do folks feel about making this kind of change? 
The confirmation method is opaque to the client.  I don’t think adding hash algs to discovery will really help.
The AS selection needs to be based on what the RS can support.

If anyplace it should be in RS discovery. 

As a practical matter you art going to find a client certificate with more than a SHA256 hash anytime in the near future. 
So for a short lived access token 128bits of collision resistance is quite good.   We are going to have issues with certificates long before this becomes a problem.

SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RSA keys, but again that is over the long term.  
We are using short lived access tokens.  People should rotate the certificate more often than once a year if this is a real issue.

I am not against new hash for the fingerprint, but I also don’t know that SHA512 would be the best choice if we are concerned about quantum crypto resistance.   That is a issue beyond mtls and should be addressed by CFRG etc.

John B.