On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario <hka...@redhat.com> wrote:
> On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > Thoughts? If the WG likes this design, I would suggest: > > > > - Most folks who want to use TLS 1.3 with external PSKs should probably > > design their protocols to provision universal PSKs instead, after it > > stabilizes. > > > > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the > > compatibility derivation in this draft, after it stabilizes. > > > > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API > > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off > by > > default if that API is used and, in a future release, use the > compatibility > > derivation after it stabilizes. > > that's not workable. > > the reason why implementations chose to use old API to provision TLS 1.3 > PSKs > was to make the upgrade process as smooth as possible, disabling TLS 1.3 > is > quite antithetical to that > Indeed. That is why the TLS 1.2 compatibility section exists. :-) So that implementations in that position can reuse TLS 1.2 PSK APIs in TLS 1.3 while honoring the security proof. But, unfortunately, there's a slight timing issue. There's no way some random draft published yesterday will be finalized before TLS 1.3. So implementations with TLS 1.2 PSK APIs would need to either violate the TLS 1.3 security proof or not ship TLS 1.3 until this draft finalizes. Neither seems great, so turning TLS 1.3 for PSK users in the initial TLS 1.3 implementation releases seems a reasonable stopgap approach, until the solution for this issue is finalized, at which point a latter release can enable TLS 1.3 across the board. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
