Re: [TLS] Proposals for draft-ietf-tls-subcerts-02

I support these changes.

Nick

On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J <cjpatton@ufl.edu>
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 <uri@ll.mit.edu>
> *Sent:* Tuesday, July 24, 2018 4:40 PM
> *To:* Ilari Liusvaara; Patton,Christopher J
> *Cc:* tls@ietf.org
> *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" <
> tls-bounces@ietf.org on behalf of ilariliusvaara@welho.com> 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
>     TLS@ietf.org
>     https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>