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

Neil Madden <> Mon, 30 April 2018 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD6E31241F5 for <>; Mon, 30 Apr 2018 08:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Pv--qWky8T14 for <>; Mon, 30 Apr 2018 08:57:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8163812DB6C for <>; Mon, 30 Apr 2018 08:57:49 -0700 (PDT)
Received: by with SMTP id t11so14044546wmt.0 for <>; Mon, 30 Apr 2018 08:57:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUaFTREPTvCFficYbzpQlnFNgpZou9w828VUHrcl2DY=; b=G4X792VZLTAOx/6/Z1UcSAglGQF2HjjTYive0AoSy/iF7I/UobU1eoBZwovGgUHoqY vlFUmvC1kNdsmM08XdVHb9Hn69wnT4YTI+FP976/Pfi2tbFko7bt5Kx2bDKxOQCEUx8v 5UsXJGzU0BX43l8afUguomcGfBWL3QR/g9NMI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUaFTREPTvCFficYbzpQlnFNgpZou9w828VUHrcl2DY=; b=KzVeDCrrJQ6x5XWpbGfTNgB2/3tE7qE5d0GtqJNX/3nFIltyMIru9npXShTyoaWSum J+IkxREYqt6OfAAGo8+gcpLxWp4GJhoyLJ69KN5bPeqyKKmpR+lReb2Qrh1ANqEDRCoi a9YFv8xGhq0vjI3Mhr3vx7Py1F6P0qGjT9NLndN1IwqARG8KJM5NovDhn/NCQOOg8/T+ VmqYjv93lhXW/3dzOScCe1Hs5q1fLpFBi4uvGO+PjyIBxEIIrzS0WzD4UkPUWch9uOZr AwkTf/8A1aRHlrj6dvSQuIQiB2JyeaDoB1+T5E+Bd1awDMgFAY1jCpjLg9wFQfD8Vf5A cClQ==
X-Gm-Message-State: ALQs6tCz0EAwv1KhL2HghOaV09ZAPVV4kq9IqqRiuQKIAz7ZOwY8QKTL CQ3DZ7xG37k4vcOJEbSoJlvjaw==
X-Google-Smtp-Source: AB8JxZqfJR8hCOEplv/x+H6zLO+RWWQwsbPG0n1oci5015IWRsL60LnX3LIlmcRt4ocgjRodeHX8Jw==
X-Received: by with SMTP id v80mr7723974wmd.91.1525103867934; Mon, 30 Apr 2018 08:57:47 -0700 (PDT)
Received: from guest2s-mbp.home ( []) by with ESMTPSA id 135sm8420592wmx.21.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 08:57:46 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Neil Madden <>
In-Reply-To: <>
Date: Mon, 30 Apr 2018 16:57:45 +0100
Cc: Brian Campbell <>, oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <> <> <> <> <> <>
To: John Bradley <>
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 15:57:53 -0000

Hi John,

> On 30 Apr 2018, at 15:07, John Bradley <> wrote:
> I lean towards letting new certificate thumbprints be defined someplace else.
> With SHA256, it is really second preimage resistance that we care about for a certificate thumbprint, rather than simple collision resistance.  

That’s not true if you consider a malicious client. If I can find any pair of certificates c1 and c2 such that SHA256(c1) == SHA256(c2) then I can present c1 to the AS when I request an access token and later present c2 to the protected resource when I use it. I don’t know if there is an actual practical attack based on this, but a successful attack would violate the security goal implied by the draft: that that requests made to the protected resource "MUST be made […] using the same certificate that was used for mutual TLS at the token endpoint.”

NB: this is obviously easier if the client gets to choose its own client_id, as it can find the colliding certificates and then sign up with whatever subject ended up in c1.

> MD5 failed quite badly with chosen prefix collision attacks against certificates (Thanks to some X.509 extensions).
> SHA1 has also been shown to be vulnerable to a PDF chosen prefix attack (
> The reason NIST pushed for development of SHA3 was concern that a preimage attack might eventually be found agains the SHA2 family of hash algorithms. 
> While SHA512 may have double the number of bytes it may not help much against a SHA2 preimage attack,. (Some papers  suggest that the double word size of SHA512 it may be more vulnerable than SHA256 to some attacks)

This is really something where the input of a cryptographer would be welcome. As far as I am aware, the collision resistance of SHA-256 is still considered at around the 128-bit level, while it is considered at around the 256-bit level for SHA-512. Absent a total break of SHA2, it is likely that SHA-512 will remain at a higher security level than SHA-256 even if both are weakened by cryptanalytic advances. They are based on the same algorithm, with different parameters and word/block sizes.

> It is currently believed that SHA256 has 256 bits of second preimage strength.   That could always turn out to be wrong as SHA2 has some similarities to SHA1, and yes post quantum that is reduced to 128bits. 
> To have a safe future option we would probably want to go with SHA3-512.   However I don’t see that getting much traction in the near term.  

SHA3 is also slower than SHA2 in software.

> Practical things people should do run more along the lines of:
> 1: Put at least 64 bits of entropy into the certificate serial number if using self signed or a local CA.  Commercial CA need to do that now.
> 2: Rotate certificates on a regular basis,  using a registered JWKS URI
> 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.


— Neil