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

Justin Richer <jricher@mit.edu> Fri, 20 April 2018 22:43 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226F612420B for <oauth@ietfa.amsl.com>; Fri, 20 Apr 2018 15:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hUdF1HBVYws for <oauth@ietfa.amsl.com>; Fri, 20 Apr 2018 15:43:42 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3381241F3 for <oauth@ietf.org>; Fri, 20 Apr 2018 15:43:41 -0700 (PDT)
X-AuditID: 12074422-bbdff700000047ff-bc-5ada6d196300
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 46.BD.18431.91D6ADA5; Fri, 20 Apr 2018 18:43:38 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w3KMhZXR002916; Fri, 20 Apr 2018 18:43:36 -0400
Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3KMhXVR022267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Apr 2018 18:43:35 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <1C26CD81-2DF2-4D9C-B5D6-F95761B426AE@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4C6570B4-4A11-4BFF-A60B-E151D4C6FD3D"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 20 Apr 2018 18:43:33 -0400
In-Reply-To: <CA+k3eCQQU-7CjY8Rm0wEzi2xUr+TL1yeCtLCtbbJJm9ujHX2DA@mail.gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "<oauth@ietf.org>" <oauth@ietf.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <CAGL6epK7X-jbO0c8GTxm2cAesYwU19R5_GsFY4tpUYxjW-MF_w@mail.gmail.com> <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <CA+k3eCRRUN0_+dVrRabjCrseV0C15wvKmY3jJQ4-eQqhZ2NUQQ@mail.gmail.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <CA+k3eCSTy7wqEOXxuoS4bCcQm=pfLTMMO+p4macVJ8p9wmfb7w@mail.gmail.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <CA+k3eCQQU-7CjY8Rm0wEzi2xUr+TL1yeCtLCtbbJJm9ujHX2DA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsUixCmqrSuVeyvK4MVSaYvV/28yWsyZ94vN 4uTbV2wOzB432hYweixZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGau2tLEUTJ/GVPG3aS97 A+PSd4xdjJwcEgImElcOPmDrYuTiEBJYzCTxc846dpCEkMBGRokDT0MhEteZJPrfHWMFSbAJ qEpMX9PCBGLzClhJfDrazgZiMwskScye18gOETeR2HGlDcwWFrCQOPXoB1g9C1DvjtNPwWxO gUCJr7sWMkP0Rko0r2oCu0hEQF/i9tM57BCLV7NIfH5+nx3iVCWJ/7uOME9g5J+FZN8sJPsg 4toSyxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzM Er3UlNJNjKCQZ3dR2sE48Z/XIUYBDkYlHt4bAreihFgTy4orcw8xSnIwKYnyBmcBhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwFgYC5XhTEiurUovyYVLSHCxK4ryL9++NEhJITyxJzU5NLUgt gsnKcHAoSfBW5QA1ChalpqdWpGXmlCCkmTg4QYbzAA2PA6nhLS5IzC3OTIfIn2K05zj0fkoP M8c5MHns8jQg+e/m/l5mIZa8/LxUKXFeV5A2AZC2jNI8uMmgdOa+zs7iFaM40KPCvDkgVTzA VAg3+xXQWiagtQYqN0DWliQipKQaGLNCm89WLZu7nmO+0Rtb7kWO0l9erT5dOL39V+7u9KJD rO2s61+f2mUyz8bxR5vCcp/J1gzxGjbnHL9p3FjH/GTRqsPHTxXpPu1z99l7S8t4sYS01u2V R/Iqtoa1bDAryvuTO2MXk6mI/1bJYLO1Br8SIlfyLp6yQ6d1s9+2Bdu05pY4Tf1Yp67EUpyR aKjFXFScCAC6IB2IQgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gbSJboJYQgfKYD7-gvHAGG5fXys>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2018 22:43:46 -0000

Additional confirmation methods can be easily defined outside of this draft. That said, I think those two in particular are pretty straightforward to add (well-known algorithms that are widely available) so it might make sense to just toss them in now? I think it’s fine either way.

 — Justin

> On Apr 19, 2018, at 12:23 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> Okay, so I retract the idea of metadata indicating the hash alg/cnf method (based on John pointing out that it doesn't really make sense). 
> 
> That still leaves the question of whether or not to define additional confirmation methods in this document (and if so, what they would be though x5t#S384 and x5t#S512 seem the most likely). 
> 
> There's some reasonable rational for both adding one or two new hash alg confirmation methods in the doc now vs. sticking with just SHA256 for now. I'll note again that the doc doesn't preclude using or later defining other confirmation methods.
> 
> I'm kind of on the fence about it, to be honest. But that doesn't really matter because the draft should reflect rough WG consensus. So I'm looking to get a rough gauge of rough consensus. At this point there's one comment out of WGLC asking for additional confirmation method(s). I don't think that makes for consensus. But I'd ask others from the WG to chime in, if appropriate, to help me better gauge consensus. 
> 
> On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> I’m not particularly wedded to SHA-512, just that it should be possible to use something else. At the moment, the draft seems pretty wedded to SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on many 64-bit machines) and provides a very wide security margin against any future crypto advances (quantum or otherwise). I’d also be happy with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely available. 
> 
> I don’t think short-lived access tokens is a help if the likelihood is that certs will be reused for many access tokens. 
> 
> Public Web PKI certs tend to only use SHA-256 as it has broad support, and I gather there were some compatibility issues with SHA-512 certs in TLS. There are a handful of SHA-384 certs - e.g., the Comodo CA certs for https://home.cern/ <https://home.cern/> are signed with SHA-384 (although with RSA-2048, which NSA estimates at only ~112-bit security). SHA-512 is used on some internal networks where there is more control over components being used, which is also where people are mostly likely to care about security beyond 128-bit level (eg government internal networks). 
> 
> By the way, I just mentioned quantum attacks as an example of something that might weaken the hash in future. Obviously, quantum attacks completely destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it provides a considerable margin to hedge against future quantum *or classical* advances while allowing the paranoid to pick a stronger security level now.. We have customers that ask for 256-bit AES already.
> 
> (I also misremembered the quantum attack - “Serious Cryptography” by Aumasson tells me the best known quantum attack against collision resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) space so is impractical. I don’t know if that is the last word though).  
> 
> As for SHA-1, doesn’t that prove the point? SHA-1 is pretty broken now with practical collisions having been demonstrated. The kind of attacks on CA certs demonstrated for MD5 [1] are probably not too far off for SHA-1 now. As far as I am aware, we’re nowhere near those kinds of attacks on SHA-256, but I’d prefer that there was a backup plan in place already rather than waiting to see (and waiting for everyone to have hard-coded SHA-256 everywhere).
> 
> Now I have to get back to my daughter’s birthday party… :-)
> 
> [1] http://www.win.tue.nl/hashclash/rogue-ca/ <http://www.win.tue.nl/hashclash/rogue-ca/>
> 
> Neil
> 
> 
> On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
> The WG discusses RS meta-data as part of one of Dick’s proposals.   I am unclear on who is going to work on it in what draft.
> 
> If the client is doing mtls to both the Token endpoint and RS the information in the confirmation method is not relevant to the client as long as the AS and RS are in agreement like with most tokens.
> 
> The hash on the certificate and length of the signing key are equally or more vulnerable to any sort of attack.
> At least with AT the tokens are not long lived.
> 
> Doing anything better than SHA256 only makes sense if the cert is signed by something stronger like SHA512 with a 2048bit RSA key.   That seems sort of unlikely in the near term.  
> 
> I prefer to wait to see what general fix is proposed before we jump the gun with a bandade for a small part of the overall problem.
> 
> People are typically using SHA1 fingerprints.  We added SHA256 for JWT and got push back on that as overkill. 
> I don’t think this is the correct place to be deciding this.   
> 
> We could say that if new thumbprints are defined the AS and RS can decide to use them as necessary.
> That is sort of the situation we have now.
> 
> The correct solution may be a thousand rounds of PBKDF2 or something like that to make finding collisions more difficult rather than longer hashes.
> 
> John B.
> 
> > On Apr 12, 2018, at 5:20 PM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
> > 
> > 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 <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> 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.
> 
> 
> 
> 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._______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>