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

Neil Madden <> Mon, 30 April 2018 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 741CC12D965 for <>; Mon, 30 Apr 2018 15:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 SNct3op_rVb2 for <>; Mon, 30 Apr 2018 15:23:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94AD8127342 for <>; Mon, 30 Apr 2018 15:23:59 -0700 (PDT)
Received: by with SMTP id q17-v6so3084393ywg.2 for <>; Mon, 30 Apr 2018 15:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YtVu/qYjHqPAXQuHfKDpM1JPg64MEgCML46s3i1ViLY=; b=QegQI6+p4FetNVORl76OI5Et3fwlXHzYO88TL+syr2TlFa82m6KLIqIASF8MS2M2JG QIuit9ZlLIyfprnU+pNZQj3gozGft7bkR4JR4d7DWXZs51AJiZEs116J3/Psx5IFWv/8 C6ZqmUJzQ8hQ7SQ5flAzsRI+aKVpEmE8DA2G0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YtVu/qYjHqPAXQuHfKDpM1JPg64MEgCML46s3i1ViLY=; b=Uf5otqPcOSMn3uxN1QUHIcVz/otAAglM0d4M9tlKQs9RCcfT+yhGx9OQqPEJv7iDP9 NwlGIDpZOM5SwFz1BI8PFjtpTfBbm3IrwK/C0uMRmP40ahb1dDRqT/yxbwkcVYxFX6YG e8pHzzu4x/Psr/kY2ebCAjwJZ6tHmK6UzW102SJ9f862CYUu6EUslJp1fc2uIcoimDbW 2D+1nbsEzXn7ZoUOsSTNJXqaPwJerk06eVFAnoiKn+IvYMfJ3tz8yIMW0WDfQuOG/825 c/H/uJJ74enntde3t1R5pgFf7Q7/jewWSEtA42VGv/8xrih8OVofzEXg4EZ/tgS1NtPD K2PQ==
X-Gm-Message-State: ALQs6tDsNI02TlGyN5QvrGJPyqP/I6r54+HShA91+e+Pf9CVn63HmzSD J/4PS2/WnrGgFBr1US0Lzm/RAG4mkIefWJo0oakk/g==
X-Google-Smtp-Source: AB8JxZoJUeinihD6la1+T5pgP7UU6ripulg34ARGu7QF9CTBiaMJEbMiC6hoGY+yF/12y8rbIL6HCVTNtM+QEBZKlVI=
X-Received: by 2002:a81:7c02:: with SMTP id x2-v6mr7391426ywc.81.1525127038601; Mon, 30 Apr 2018 15:23:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Neil Madden <>
Date: Mon, 30 Apr 2018 22:23:48 +0000
Message-ID: <>
To: John Bradley <>
Cc: Brian Campbell <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000005fa851056b184f61"
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:24:03 -0000

Responses inline again.

On Mon, 30 Apr 2018 at 19:44, John Bradley <> wrote:

> Inline.
> On Apr 30, 2018, at 12:57 PM, Neil Madden <>
> wrote:
> 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.
> Both C1 and C2 need to be valid certificates, so not just any collision
> will do.

That doesn’t help much. There’s still enough you can vary in a certificate
to generate collisions.

If the client produces C1 and C2 and has the private keys for them, I have
> a hard time seeing what advantage it could get by having colliding
> certificate hashes.

Me too. But if the security goal is proof of possession, then this attack
(assuming practical collisions) would break that goal.

> If the AS is trusting a CA, the attacker producing a certificate that
> matches the hash of another certificate so that it seems like the fake
> certificate was issued by the CA, is an attack that worked on MD5 given
> some predictability.  That is why we now have entropy requirements for
> certificate serial numbers, that reduce known prefix attacks.

The draft allows for self-signed certificates.

Second-preimage Resistance is being computationaly infusible to find a
> second preimage that has the same output as the first preimage.   The
> second preimage strength for SHA256 is 201-256bits and collision resistance
> strength is 128 bits.  See Appendix A of
> if
> you want to understand the relationship between message length and second
> Preimage resistance.
> RFC 4270 is old but still has some relevant info.
> Think of the confirmation method as the out of band integrity check for
> the certificate that is presented in the TLS session.

This is all largely irrelevant.

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.
> SHA512 uses double words and more rounds, true.  It also has more rounds
> broken by known attacks than SHA256
> So it is slightly more complex than doubling the output size doubles the
> strength.

SHA-512 also has more rounds (80) than SHA-256 (64), so still has more
rounds left to go...

> 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.
> Yes roughly half the speed in software but generally faster in hardware.
> I am not necessarily arguing for SHA3, rather I think this issue is larger
> than this spec and selecting alternate hashing algorithms for security
> should be separate from this spec.
> I am for agility, but I don’t want to accidentally have people doing
> something that is just theatre.
> Rotating certificates, and having the lifetime of a certificates validity
> is as useful as doubling the hash size.

Why not allow both?

> I don’t think the confirmation hash length is the weakest link.

Shouldn’t we allow all the parts to be as strong as possible?

> John B.
> 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.
> [snip]
> — Neil
> — Neil