Thanks all for the feedback! In light of your observations, we've revised the changes proposed for draft-02: https://github.com/tlswg/tls-subcerts/pull/13.
The changes for draft-02 are as follows: * Drop support for TLS 1.2. * Add the protocol version and credential signature algorithm to the Credential structure. * Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate. Any additional feedback is welcome. Thanks, Christopher Patton ________________________________ From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Sent: Tuesday, July 24, 2018 4:40 PM To: Ilari Liusvaara; Patton,Christopher J Cc: [email protected] Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 I object to re-interpreting/overloading the Critical flag. It has one and only one meaning: "If the parser does not understand the given attribute, it must abort parsing if this attribute is marked as Critical (or ignore this attribute and continue parsing if the Critical flag is not set)". On 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" <[email protected] on behalf of [email protected]> wrote: 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
