I support these changes. Nick
On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J <[email protected]> wrote: > 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 >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
