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

[Ilari Liusvaara <[e-mail]>]

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