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

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

Hi Nick,
Thanks for reviewing the doc, please see further responses/comments below:

On 8/17/20, 8:40 AM, "TLS on behalf of Nick Lamb" <[e-mail] on behalf of [e-mail]> wrote:

    I am not very familiar with IETF working group practices, however it
    strikes me as surely unusual to have a document enter Last Call
    (supposedly believed by its owners to be ready for publication) and yet
    immediately then be revised showing it was in fact not ready at all.
[NCW] It was an unfortunate oversight on my part as I somehow did not catch
Tom's feedback when I updated the draft until he pointed it out and I had to
go to the opsec mailarchive to retrieve his initial comments.   
I don't believe, we the authors made any notion that we were ready for publication;
I believe the last call process is to ensure there is more review before publication.
    
    However this seems to be what happened to draft-ietf-opsec-ns-impact.
    The below comments concern draft-ietf-opsec-ns-impact-02, the newer
    document.
    
    Section 4.1 Perfect Forward Secrecy ends:
    
    > TLS session data.ss
    
    I think this is a typographical error and the trailing "ss" should be
    removed from the document. If not it should be explained.
    [NCW] Thanks for catching it, a formatting remnant which will be removed.
    
    
    Section 4.2 Encrypted Server Certificate describes a practice which is
    inherently unsound. Passive inspection of the Certificate message from
    TLS 1.2 or earlier isn't a reliable source of information because a
    passive eavesdropper isn't able to discern whether the X.509 document
    presented corresponds to this server or not. The Client can confirm
    this using the TLS protocol but an eavesdropper can't. So the change in
    TLS 1.3 does not impact the practical security policy available, only an
    appearance is altered.
[NCW] The document describes what is in practice today with TLS 1.2 and 1.1
whether we believe it is unsound or otherwise, it is what is done today.
    
    Passive systems described throughout Section 5.1 fall to this same
    error, using the phrase "reduced effectiveness" which the document
    defines as not being "as effective on TLS 1.3 traffic" but in fact
    since this practice didn't work, it will remain exactly as effective
    (not at all) as before.
[NCW] Again, the document is describing what is in practice today.
    
    A related consequence passes into Section 5.2. Since the Certificate
    message is only reliable for a Client, it has in fact always been
    necessary to fully proxy the TLS session in order to rely on this data,
    so this is not in fact an impact from TLS 1.3 but (if it wasn't done
    previously for all versions) a vulnerability in such products.
[NCW] With TLS 1.2 the observer can see the handshake thru completion
with the Finished message before affecting a policy decision.
    
    
    As it stands then, this document is misleading.
    
    Nick.
    
    _______________________________________________
    TLS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tls