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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 19 Aug 2020 18:45:44 +0000

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

---

From: Roelof DuToit <[email-masked]>
Date: Thu, 20 Aug 2020 09:58:58 -0400

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.

> On Aug 19, 2020, at 6:43 PM, Nick Lamb <[email-masked]> wrote:
> 
> The passive eavesdropper can indeed see the handshake in TLS 1.2, but
> since they were not a participant they don't actually know what it
> means even though it wasn't encrypted.
> 
> For example, suppose an RSA certificate is sent and the handshake seems
> to agree RSA key exchange and Client sends an EncryptedPreMasterSecret.
> The passive eavesdropper has no idea if that's actually encrypted to the
> RSA public key from the certificate, it's just an opaque blob.
> 
> 
> Thus it's easily possible for an eavesdropper to witness a handshake in
> which the eavesdropper believes what happened is:
> 
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret to the local hospital
> both agreed this all worked fine and continue encrypted
> 
> The eavesdropper's "Don't eavesdrop on people's medical stuff" policy
> kicks in and it allows the connection unmolested. Unfortunately what
> really happened is:
> 
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret for the GRU data exfiltration
> server ignoring the bogus certificate
> $5Bn of stolen commercial documents are uploaded to the server

Advanced passive TLS inspection devices use a combination of techniques to defend against those attacks for TLS 1.2 (and below):
1. Policy-based control over the use of RSA key exchange.  It should not be allowed.
2. Checking the signature in the ServerKeyExchange message when (EC)DHE key exchange is used.
3. Not trusting the destination IP address.  The hostname from the SNI is resolved and compared.

None of those techniques are perfect given an advanced adversary that controls the client + DNS in the enterprise + the flow of traffic on the server side of the TLS inspection device.
(Side note: If I’m an attacker that has control over DNS then I would not bother with TLS-based attacks for data exfiltration).
In other words, nation state attacks might succeed but it does not mean that passive TLS inspection devices are not effective against other attacks.

—Roelof

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Aug 2020 12:13:45 -0700

On Thu, Aug 20, 2020 at 7:01 AM Roelof DuToit <[email-masked]> 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.
>
> Advanced passive TLS inspection devices use a combination of techniques to
> defend against those attacks for TLS 1.2 (and below):
> None of those techniques are perfect given an advanced adversary that
> controls the client + DNS in the enterprise + the flow of traffic on the
> server side of the TLS inspection device.
> (Side note: If I’m an attacker that has control over DNS then I would not
> bother with TLS-based attacks for data exfiltration).
> In other words, nation state attacks might succeed but it does not mean
> that passive TLS inspection devices are not effective against other attacks.
>

It seems to me that the conditions under which this kind of inspection
works and does not work are quite subtle. If you want to proceed with this
document, it would probably be good to document them,

-Ekr

---

From: Nick Lamb <[email-masked]>
Date: Mon, 17 Aug 2020 16:39:38 +0100

Nick.

---

From: Nick Lamb <[email-masked]>
Date: Wed, 19 Aug 2020 23:43:14 +0100

On Wed, 19 Aug 2020 18:45:44 +0000
Nancy Cam-Winget (ncamwing)" <[email-masked]> wrote:  
>     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.

It's not a problem for the document to describe today's practices but
it's a mistake to label them "effective" if we know they are not.

>     since this practice didn't work, it will remain exactly as
> effective (not at all) as before.

Describing something as "effective" when it is not effective isn't a
matter of today's practice but of a misunderstanding of what's
possible at all.

>     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.

Nick.

---

From: Nick Lamb <[email-masked]>
Date: Fri, 21 Aug 2020 00:39:48 +0100

On Thu, 20 Aug 2020 09:58:58 -0400
Roelof DuToit <[email-masked]> 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.

> 1. Policy-based control over the use of RSA key exchange.  It should

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.

Nick.