On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote: > Hi all, > > > I've taken the liberty of addressing the changes to the delegated credentials > extension that were requested at IETF: > > https://github.com/tlswg/tls-subcerts/pull/13 > > > The changes that would be adopted in draft-02 are as follows: > > * Drop support for TLS 1.2. > * Allow the critical bit of the X.509 extension to be set. > * Add the protocol version and credential signature algorithm > to the Credential structure. > * Make the KeyUsage of the delegation certificate stricter. > * Specify undefined behavior in a few cases. > > It was suggested that we add optional "must-use-DC" semantics to the > certificate. The solution we came up with was to add a "strict" flag > to the extension that is set if (and only if) the extension is marked > critical. The idea is that if the "strict" flag is set and the server > doesn't offer a DC, then client must abort the handshake, In my opinion, > the complexity this adds to the protocol outweighs the potential benefits. > > Comments on the PR are welcome.
This has the signifcant critical flag issue. It should at minimum be explicitly called out, as I do not know any precendent for this kind of behavior (check that some extension is critical yes, but not changing meaning of extension depending on critical flag). I watched the presentation and the resulting Q&A again. Short summary of relevant stuff: - The motivation in the slides is to reduce exposure of private keys to memory disclosure vulernabilities, without reducing performance. - The orignal proposal was to add a TLS Feature extension value. No discussion. - The drawback of "strict mode" would be causing issues with servers that can not effectively switch between certificates. - There is question about fallback. Paraphrased answer: LURK. TLS Feature extensions have some really unwnated properties here. They are never critical on client side, and they have OR-inheritance. You definitely do not want OR-inheritance here. Well, after this, the best usecase I can come up with strict flag is still dealing with LURK endpoints that can not do proof-of-possession or format checking[1]. [1] TLS 1.2 and 1.3 servers should only ask for signatures and only over the following kinds of data: - <64 bytes> 03 00 17 41 04 <64 bytes> - <64 bytes> 03 00 18 61 04 <96 bytes> - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521) - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool) - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool) - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool) - <64 bytes> 03 00 1D 20 <32 bytes> - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448) - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes> None of these covers delegated credential signatures, which would cause any attempt to ask for DC signature to fail if the format is checked.. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
