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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tls