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

From: "Patton,Christopher J" <[email-masked]>
Date: Tue, 24 Jul 2018 19:24:09 +0000

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.

Thanks,
Chris Patton

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Jul 2018 23:24:23 +0300

On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote:
> 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.
> 

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 24 Jul 2018 20:40:09 +0000

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-masked] on behalf of [email-masked]> wrote:

    

    

    
    -Ilari

    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: "Patton,Christopher J" <[email-masked]>
Date: Thu, 26 Jul 2018 18:01:15 +0000

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-masked]>
Sent: Tuesday, July 24, 2018 4:40 PM
To: Ilari Liusvaara; Patton,Christopher J
Cc: [email-masked]
Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02

    -Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 26 Jul 2018 16:03:25 -0700

I support these changes.

Nick

On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J <[email-masked]>
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.
>
>
>    - 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.
>
>
> ------------------------------
> *From:* Blumenthal, Uri - 0553 - MITLL <[email-masked]>
> *Sent:* Tuesday, July 24, 2018 4:40 PM
> *To:* Ilari Liusvaara; Patton,Christopher J
> *Cc:* [email-masked]
> *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-masked] on behalf of [email-masked]> wrote:
>
>     > I've taken the liberty of addressing the changes to the delegated
> credentials extension that were requested at IETF:
>     >