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

Brian Campbell <> Thu, 12 April 2018 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12CE412DA0D for <>; Thu, 12 Apr 2018 13:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xSk4h7YVyCVk for <>; Thu, 12 Apr 2018 13:21:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03B9812D87F for <>; Thu, 12 Apr 2018 13:21:07 -0700 (PDT)
Received: by with SMTP id 142-v6so482510itl.5 for <>; Thu, 12 Apr 2018 13:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOWtBwxrzP1bGkoMFFNrES7c7Qn+Yg+c16CefUaumQA=; b=Cx+kFoJlI0iogpWcHm4tjpeoI+RlqF0Mm9zFPyCBXsjQMGwOsTw5+FIXjsRuLG4vxi hXtyVjZC7j2CiMUp86x67Uy+CQ/q2W6OdFQgbmjoO7758qRUV8W4IUbs8uTPo38LXM19 RS++CDNvy6ihnbXQbrmxN75F+k2umq0ryOFL8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nOWtBwxrzP1bGkoMFFNrES7c7Qn+Yg+c16CefUaumQA=; b=Byxe3jcXJepJiF2aC9SwVHUtxjb+NlyK/4uTNQqVvYm12N21e0uGaikuWiDi+SM515 uLBDv9T6QlNb0Ve0Ak0FYhBVvyByPKU59Xt8XfZ/Jv00TgZDr9gWvJpf0LM6jvb6P8fw CMSnDxOtVz8cRBDCFSdJc0csyE/zZOgiWFc57TlIBslFnI5cHAvJNCpdArl68UbBv5xo Ygo0VqfIBBv0SkoQUCj9Hblu9vl/2129dNGITEi8zI8IHnzjOk5xChm5O5rdOZ+vw4kP kk4lyTht9pjRhM6e5tG3IPZlnLaT+T1dDxwBYmDsrJ+CRi4M3B6A+5h0iaGeDH9hc5za 8meA==
X-Gm-Message-State: ALQs6tDwiYZfB6DvA0JhU1FHrk6EfO1rGW9eypMVQhN2Tiq4G2yY7occ 7NuNWfUAbOFKDqvDDhRCJqVX61ej6FmQj+/JwEo7UYZKjq+MIaENkHB0ipfGiW0oBuE49lEInAq BEZFdFET9tF8xlw==
X-Google-Smtp-Source: AIpwx49uAP8I4HJBo1HdRKgHKtztMCRAMDhj31tQ4nPz238rFOsJjfVInHcddJBylR8bbXcAqCc8oaKbMB8BNTEMTk8=
X-Received: by 2002:a24:5491:: with SMTP id t139-v6mr2430345ita.89.1523564466188; Thu, 12 Apr 2018 13:21:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 Apr 2018 13:20:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <>
From: Brian Campbell <>
Date: Thu, 12 Apr 2018 14:20:35 -0600
Message-ID: <>
To: John Bradley <>
Cc: Neil Madden <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000ccf2260569ac7e91"
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 20:21:14 -0000

That's true about it being opaque to the client. I was thinking of client
metadata (config or registration) as a way for the AS to decide if to bind
the AT to a cert. And moving from a boolean to a conf method as an
extension of that. It would be more meaningful in RS discovery, if there
was such a thing.

I don’t know that SHA512 would be the best choice either but it is
something that is stronger and could be included now. If there's consensus
to do more than SHA256 in this doc.

On Thu, Apr 12, 2018 at 1:52 PM, John Bradley <> wrote:

> Inline
> Snip
>> 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.
> Regards
> John B.

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