Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Hi Nick and EKR,
Please see below:

On 8/20/20, 4:40 PM, "Nick Lamb" <[e-mail]> wrote:

    On Thu, 20 Aug 2020 09:58:58 -0400
    Roelof DuToit <[e-mail]> wrote:
    
    > As co-author I am not a proponent of passive TLS inspection - not
    > least because of the ossification implications.  It cannot be labeled
    > as ineffective though (see further comments below), even if the
    > document strongly hints at not using passive TLS inspection in a
    > post-TLS-1.2 world.
    
    Mostly I endorse Ekr's comment that a document like this should
    actually spell out any convolutions and conditions necessary to the
    effective use of passive inspection. I would try to find time to
    examine a revised document that did this.
[NCW] The specific conditions are more deployment and vendor specific and proprietary so it'd be difficult to enumerate (and enumerate them all)...as well as which we believe is out of scope for the document.  I did add a paragraph to state that as well as we (the authors) are not proponents for these techniques but as it had been asked to how the deployments 'inspect' we thought it important to document the most common known practices.  Please look over the updates and see if that clarifies intent.
    
    But I do want to address one such in particular now:
    
    > 1. Policy-based control over the use of RSA key exchange.  It should
    > not be allowed.
    
    Qualys estimates that when TLS 1.3 was finalised RSA was required for
    about 5.7% of web sites (it had been larger previously). That's a
    pretty huge caveat.
    
    The same document we're discussing, draft-ietf-opsec-ns-impact-02
    actually several times relies upon RSA key exchange (in section 5.3) for
    methods it says will now be impacted by TLS 1.3 because that doesn't
    allow RSA key exchange.
    
    As written there's no problem, but it seems to me that if you add a
    condition saying to disallow RSA key exchange in section 5.1, this has
    the effect of implicitly rebuking this approach from section 5.3.
    
    That would be a little bit silly in a single document but it's even
    sillier when you recall that actually products in this space straddle
    both categories.
[NCW] Right, our intent was not to prescribe what should or should not be done, but rather educate as to what is being done in practice today.
    
    Nick.