Subject: [TLS] network-based security solution use cases

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sat, 4 Nov 2017 01:49:54 +0000

All,

@IETF99, awareness was raised to some of the security WGs (thanks Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and asked what the implications would be for the security solutions today.  https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an initial draft to describe some of the impacts relating to current network security solutions.  The goal of the draft is NOT to propose any solution as a few have been proposed, but rather to raise awareness to how current network-based security solutions work today and their impact on them based on the current TLS 1.3 specification.

Regards, Nancy, Flemming and Eric

---

From: Florian Weimer <[email-masked]>
Date: Sun, 05 Nov 2017 16:31:52 +0100

* Nancy Cam-Winget:

> @IETF99, awareness was raised to some of the security WGs (thanks
> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in
> TLS 1.2 and asked what the implications would be for the security
> solutions today.
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an
> initial draft to describe some of the impacts relating to current
> network security solutions.  The goal of the draft is NOT to propose
> any solution as a few have been proposed, but rather to raise
> awareness to how current network-based security solutions work today
> and their impact on them based on the current TLS 1.3 specification.

I'm not sure if this approach is useful, I'm afraid.  The draft is
basically a collection of man-in-the-middle attacks many people would
consider benign.  It's unclear where the line is drawn: traffic
optimization/compression and ad suppression/replacement aren't
mentioned, for example, and I would expect both to be rather low on
the scale of offensiveness.

What the draft is essentially arguing is that many user cannot afford
end-to-end encryption for various reasons, some legal, some technical,
some political.  But it seems to me that this is currently not a
viewpoint shared by the IETF.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Nov 2017 09:43:52 -0800

I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized.  Those techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
   methods with RSA and DH key exchanges.  When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Second, this property is really only available with RSA. Although
it is possible for an attacker to synchronize DH keys by generating
bogus DH parameters, the technique described by Bhargavan et al
results in an insecure MS (i.e., the server's public DH share).
[See Section V-B of https://www.mitls.org/downloads/tlsauth.pdf]
Any middlebox doing this, therefore, has completely broken TLS
for the endpoints on both sides of it. Your document suggests
that people do use this technique: I sincerely hope not.

In short, this property of TLS 1.3 is really a property of the use
of (EC)DHE [0], the use of which is important for security even in TLS 1.2
(hence the rapid increase in the use of ECDHE and the corresponding
decline in static RSA). Even if TLS 1.3 were never deployed, the
continued use of static RSA is going to be come increasingly
nonviable.

Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.

- PSK and resumption
You write:

   In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
   which can be negotiated as part of an initial handshake and then used
   in a subsequent handshake to perform resumption using the PSK.  TLS
   1.3 states that the client SHOULD include a "key_share" extension to
   enable the server to decline resumption and fall back to a full
   handshake, however it is not an absolute requirement.

   Example scenarios that are impacted by this are middleboxes that were
   not part of the initial handshake, and hence do not know the PSK.  If
   the client does not include the "key_share" extension, the middlebox
   cannot force a fallback to the full handshake.  If the middlebox
   policy requires it to inspect the session, it will have to fail the
   connection instead.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
    the server can forget it at any time
    (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage).
Thus,
    a client which does not allow a full handshake will often
    find itself unable to connect.

(b) The relevant question is not whether the client offers a key share
    extension but whether it advertises any DH groups. If the client sends
    a group but not a key share, the server can send HelloRetryRequest
    to force the client to send a key share.

For these reasons, as far as I know, every client (and at least every
browser client) should allow a full handshake even when trying to resume.

- Server Certificate Concealment
You note that in TLS 1.2 the middlebox can examine both the SNI and the
server's certificate in order to decide whether to MITM the connection,
but that in TLS 1.3, the middlebox cannot guarantee that the SNI in
uses is correct:

   In TLS 1.2, the ClientHello, ServerHello and Certificate messages are
   all sent in clear-text, however in TLS 1.3, the Certificate message
   is encrypted thereby hiding the server identity from any
   intermediary.  Note that even _if_ the SNI is provided (in cleartext)
   by the client, there is no guarantee that the actual server
   responding is the one indicated in the SNI from the client.

In this case, it's important to distinguish between conformant and
nonconformant clients. In the former case -- as when the user is
not attempting to evade inspection -- the SNI will reflect the
identity that the client expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting to evade
inspection, the certificate might not match. However, in this
scenario, the client and server are colluding and so there are
a variety of ways to avoid inspection, even when doing TLS 1.2.

For example:

1. The client and server can share a prearranged public key and then
negotiate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
under the server's prearranged key and continues with TLS as usual.
This cannot be detected by the middlebox without decrypting the EPMS.

2. If an (EC)DHE cipher suite must be negotiated, then the attack
described above does not work directly because the server's signature
over the ServerKeyExchange can be validated, and of course the
attacker server does not have the legitimate server's key. However,
the server can forward the ClientHello to the legitimate server,
capture the Certificate and ServerKeyExchange and the proxy those to
the client. This looks legitimate to the inspection device and then
the client can simply send the Encrypted PMS in the first chunk of
data that is apparently encrypted under the server's key.

For these reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.

-Ekr

[0] Note: the use of static DH is very rare.

On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> All,
>
>
>
> @IETF99, awareness was raised to some of the security WGs (thanks Kathleen
> ☺) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and
> asked what the implications would be for the security solutions today.
> initial draft to describe some of the impacts relating to current network
> security solutions.  The goal of the draft is NOT to propose any solution
> as a few have been proposed, but rather to raise awareness to how current
> network-based security solutions work today and their impact on them based
> on the current TLS 1.3 specification.
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 6 Nov 2017 21:48:38 -0500

> the scale of offensiveness.
We didn't draw any particular line, but the use case scenarios that we 
tried to highlight are those related to overall security and regulatory 
requirements (including public sector) where a network-based solution 
currently exists, and (we believe) is not easily replaced. A number of 
these are routinely encountered in present-day enterprise, cloud and 
public sector, and we believe they will continue to be relevant. On top 
of that, we have a rapidly expanding base of IoT endpoints with limited 
capabilities, which presents a whole new and highly vulnerable attack 
surface.

> viewpoint shared by the IETF.
That is our read of the current situation as well, however the concern 
is that by focusing solely on privacy and e2e security, there are 
additional important considerations that are being ignored. Our intent 
with the draft is to illustrate some of those and see if we can get to 
some consensus around the need to address those (and/or possibly others).

Thanks

-- Flemming

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Nov 2017 09:13:19 +0000

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
> requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).

Thanks,
S.

[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 Nov 2017 10:56:35 -0500

Thank you for the feedback Ekr - please see below for responses

> attacks on TLS 1.2 as fielded. It is for this reason that the TLS
Thanks for the bringing that one up - we will make sure to include that 
in the next version.

Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's 
an integral part of the protocol that cannot be disabled. The TLS 1.2 
extension does not share that property.

> that people do use this technique: I sincerely hope not.
I'm not aware of actual implementations doing this with DH.

> continued use of static RSA is going to be come increasingly
Fair point.

> all traffic in the connection.
We have several different use case scenarios in there, and I agree with 
the observation that they cannot all be satisfied at the same time. For 
example, we cannot scan for malware in an encrypted stream to a 
financial institution that we are not allowed to decrypt. That doesn't 
mean either use case is invalid. Customers do both in real-life (just 
not at the same time).

> (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage 
> <https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage>). 
> Thus,
If that is indeed the case, then I would suggest changing the spec 
language to a MUST here instead so we can guarantee it.

> a false sense of security, as this check is easily bypassed.
I agree we should distinguish between between conformant and non-comformant.

For the conformant case, I do not know to what extent we can rely on the 
client always sending the SNI, but even if it is always sent, there are 
still use case scenarios around certificate audit, etc. that cannot be 
satisified in TLS 1.3 without becoming an active MITM. With the recently 
adopted proposal around SNI encryption, there are more use cases that 
cannot be satisfied without becoming an active MITM.

For the non-conformant case, you bring up some good points. We can 
reduce the set of bypass scenarios there, but we cannot eliminate them.

Thanks again for the feedback - we will update accordingly in the next 
version of the draft.

-- Flemming

> On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     All,
>
>     Kathleen ☺) that TLS 1.3 will obscure visibility currently
>     afforded in TLS 1.2 and asked what the implications would be for
>     the security solutions today.
>     https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00
>     <https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00>is
>     an initial draft to describe some of the impacts relating to
>     current network security solutions.  The goal of the draft is NOT
>     to propose any solution as a few have been proposed, but rather to
>     raise awareness to how current network-based security solutions
>     work today and their impact on them based on the current TLS 1.3
>     specification.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 09:23:17 -0800

On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen <[email-masked]>
wrote:

> Thanks for the bringing that one up - we will make sure to include that in
> the next version.
>
> Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an
> integral part of the protocol that cannot be disabled. The TLS 1.2

It seems like an odd complaint that we are making protection against
Unknown Key Shares an integral part of the protocol

> example, we cannot scan for malware in an encrypted stream to a financial
> institution that we are not allowed to decrypt. That doesn't mean either
> use case is invalid. Customers do both in real-life (just not at the same
> time).
>

I'm finding it a bit puzzling what you claim customers do. Specifically,
you seem to be saying that customers examine the beginning of the
connection and then stop. What are they scanning for and what makes them
stop?

>     (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> html#NSTMessage). Thus,

I don't believe this is necessary. There are certainly reasons why you
would want to do PSK w/o (EC)DHE (e.g., you are really PSK only).

> satisified in TLS 1.3 without becoming an active MITM.
>

You can do certificate audit by making an independent connection and
eliciting the certificate.

> With the recently adopted proposal around SNI encryption, there are more
> use cases that cannot be satisfied without becoming an active MITM.
>

Yes, I agree with that.

For the non-conformant case, you bring up some good points. We can reduce
> the set of bypass scenarios there, but we cannot eliminate them.
>

I'm not persuaded that you can meaningfully reduce them. What technical
approach do you believe would do so?

-Ekr

>> TLS 1.2 and asked what the implications would be for the security solutions
>> today.  https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is
>> an initial draft to describe some of the impacts relating to current
>> network security solutions.  The goal of the draft is NOT to propose any
>> solution as a few have been proposed, but rather to raise awareness to how
>> current network-based security solutions work today and their impact on
>> them based on the current TLS 1.3 specification.
>>
>>
>>
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 Nov 2017 18:11:49 -0500

On 11/7/17 12:23 PM, Eric Rescorla wrote:
>
>
> On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thanks for the bringing that one up - we will make sure to include
>     that in the next version.
>
>     Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3,
>     it's an integral part of the protocol that cannot be disabled. The
>     TLS 1.2 extension does not share that property.
>
>

I understand your point. What I am saying is that there are some side 
effects of doing so that impacts use case scenarios that exist today. If 
you cannot drop out, then you have two choices:
1) Always be a MITM, which you may not want to (e.g. consider sessions 
with financial institutions)
2) Never be a MITM, which means you cannot do any of the network-based 
security use cases we have highlighted

What you really want is the ability to do it more selectively.

>     We have several different use case scenarios in there, and I agree
>     with the observation that they cannot all be satisfied at the same
>     time. For example, we cannot scan for malware in an encrypted
>     stream to a financial institution that we are not allowed to
>     decrypt. That doesn't mean either use case is invalid. Customers
>     do both in real-life (just not at the same time).
>
>
> I'm finding it a bit puzzling what you claim customers do. 
> Specifically, you seem to be saying that customers examine the 
> beginning of the connection and then stop. What are they scanning for 
> and what makes them stop?
>
It's the handshake process, which typically governs the associated 
policy for the session (e.g. decrypt-and-inspect or do-not-decrypt). You 
will try to determine whether the session should undergo inspection at 
the time the ClientHello passes through the box, however sometimes, you 
end up making a final (and different) decision when the ServerHello is 
received. The decision is guided by policies configured for the 
middlebox which may determine it based on various criteria (e.g. 
category of the destination such as "Financial Services", geography, etc.)

> would want to do PSK w/o (EC)DHE (e.g., you are really PSK only).
Agree with the example, but is that really a resumption scenario ?

>     For the conformant case, I do not know to what extent we can rely
>     on the client always sending the SNI, but even if it is always
>     sent, there are still use case scenarios around certificate audit,
>     etc. that cannot be satisified in TLS 1.3 without becoming an
>     active MITM.
>
>
Not always. The certificate audit may be for an external server you 
connected to (outbound scenario). Even for inbound scenarios, you would 
have to ensure you actually find the local servers and check their 
certificates, which would imply a need for continuous scanning of all of 
your infrastructure. I guess it's technically doable (similar to 
vulnerability scanners), but it's difficult on an IPv6 enabled network 
due to the size of the address space.

>     With the recently adopted proposal around SNI encryption, there
>     are more use cases that cannot be satisfied without becoming an
>     active MITM.
>
>
> Yes, I agree with that.
>
>
> I'm not persuaded that you can meaningfully reduce them. What 
> technical approach do you believe would do so?
>
Let me rephrase that: A determined attacker will be able to bypass the 
above mechanism, however what we see in practice today is that malware 
is increasingly using TLS to hide command and control traffic (not to 
mention that it often gets downloaded over a TLS protected session to 
begin with). I am not aware of specific examples of malware that try to 
bypass inspection using techniques as described above (nor have I 
looked), but it's certainly possible. There are other discrepancies that 
will show up though when you start looking at the actual destination 
reached and possibly do other analysis over the (encrypted) session.

Thanks

-- Flemming

> -Ekr
>
>
>
>     Thanks again for the feedback - we will update accordingly in the
>     next version of the draft.
>
>     -- Flemming
>
>
>>
>>     -Ekr
>>
>>
>>         @IETF99, awareness was raised to some of the security WGs
>>         (thanks Kathleen ☺) that TLS 1.3 will obscure visibility
>>         currently afforded in TLS 1.2 and asked what the implications
>>         would be for the security solutions today.
>>         current network security solutions.  The goal of the draft is
>>         NOT to propose any solution as a few have been proposed, but
>>         rather to raise awareness to how current network-based
>>         security solutions work today and their impact on them based

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 Nov 2017 18:27:56 -0500

Thanks for taking an initial look at the document Stephen - please see 
below for responses so far

> exact document on which that claim is based?
For NERC, you can look under  "(CIP) Critital Infrastructure 
Protection". CIP-005-5 for example covers the electronic security 
perimeter, which has a couple of relevant requirements and associated text:

http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States 

To be clear though, the document does not specifically call out breaking 
TLS, but it does clearly call out the need to detect malicious inbound 
and outbound communications by leveraging an "Electronic Access Point" 
(e.g. IDS/IPS) to enforce the Electronic Security Perimeter.
> send that (it's been asked for a bunch of times without any answer

I will need to look more closely for such a quote - if anybody else 
knows of one, please chime in as well.

Thanks

-- Flemming

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 7 Nov 2017 23:53:56 +0000

Hi Stephen,
Adding to Flemming’s comment,  finding “exact quotes” will be difficult as their intent is really not to break things but rather want to ensure that inspection and oversight is available to affect guards/protections within an (enterprise/data center) infrastructure.   That said, PCI and other regulations will have a lot of documents that one has to go through….one that kind-of calls explicitly to the use of packet inspection, firewalling and such is in:

https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

It is an assessment questionnaire for vendors to evaluate their compliance, the requirements speak to securing the network and systems including firewalls, DMZs and the ability to do packet inspection.

Thanks, Nancy 

On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)" <[email-masked]> wrote:

    

    
    Thanks
    
    -- Flemming

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Nov 2017 00:01:30 +0000

Hiya,

> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States

Thanks for that.

So I didn't see any mention of TLS in that document at all.

> TLS, but it does clearly call out the need to detect malicious inbound

For inbound (on page 9) I see it mentions IDSes and application
layer firewalls as examples yes. Given that the latter would not
require any messing with TLS at all, this seems to be a very
clear example of a regulation not requiring breaking TLS. That'd
mean there is no regulatory requirement at all wouldn't it?

But again, if there are real regulatory requirements there that
really do call for MitM attacks on TLS I'd be glad to look at them
if you want to quote them.

> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.

Personally, I have to say I find the outbound stuff nonsense.
I know people make money selling product and services for that.

> knows of one, please chime in as well.

It's been asked for a number of times without any substantive
response. I would assume that one of the authors of this would
be able to point at the text that caused you to add in a mention
of PCI-DSS. If not, that seems odd.

I actually looked through the PCI spec myself and found that it
is fairly explicitly asking for good crypto and not bad crypto.
(E.g. as mentioned, saying to minimise the number of copies of
keys that are anywhere.)

Maybe the ADs ought liaise to some of those organisations and
ask them if they do or do not recognise the claims related to
breaking TLS being attributed to them?

Or even better, maybe just not making those claims would be
easier all around and more accurate.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Nov 2017 00:08:52 +0000

Hiya,

On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> will be difficult 

I'm sorry but when making a claim that such and such a regulation
*requires* breaking TLS then you really do need to be that precise.

> as their intent is really not to break things but
> rather want to ensure that inspection and oversight is available to
> affect guards/protections within an (enterprise/data center)
> infrastructure.   That said, PCI and other regulations will have a
> lot of documents that one has to go through….one that kind-of calls
> explicitly to the use of packet inspection, firewalling and such is
> in:
> 

The first mention of TLS there talks about protecting administrator
passwords via TLS. That totally argues against deployment of any kind
of MitM infrastructure.

> 
> It is an assessment questionnaire for vendors to evaluate their
> compliance, the requirements speak to securing the network and
> systems including firewalls, DMZs and the ability to do packet
> inspection.

Please point me at the specific text. Given you added PCI-DSS to
your document I would assume you did the work already. If not,
that's a bit odd.

S.

> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
>>> We didn't draw any particular line, but the use case scenarios
>>> that we tried to highlight are those related to overall security
>>> and regulatory requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route
>> to ietf-100) and I followed the reference to [1] but that only lead
>> to a forest of documents in which I didn't find any reference to
>> breaking TLS so far at least. Can you provide an explicit pointer
>> to the exact document on which that claim is based?
> To be clear though, the document does not specifically call out
> breaking TLS, but it does clearly call out the need to detect
> malicious inbound and outbound communications by leveraging an
> "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic
> Security Perimeter.
>> I'd also claim that your reference to PCI-DSS is misleading, as
>> that same spec also explicitly calls for there to be good key
>> management specifically including minimising the number of copies
>> of keys, so at most, one might be able to claim that PCI-DSS is ok
>> with people who break TLS in a nod-and-a-wink manner. But if you do
>> have a real quote from PCI-DSS that calls for breaking TLS then
>> please do also send that (it's been asked for a bunch of times
>> without any answer being provided so far).
> 
>> Thanks, S.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 8 Nov 2017 00:23:03 +0000

Hi Stephen,
Please see below:

On 11/7/17, 4:08 PM, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    I'm sorry but when making a claim that such and such a regulation
    *requires* breaking TLS then you really do need to be that precise.
[NCW] In TLS 1.2, not sure why you state *requires* as there is the visibility afforded to 
at least allow for the identity disclosure to enable white or blacklist for example.  

    The first mention of TLS there talks about protecting administrator
    passwords via TLS. That totally argues against deployment of any kind
    of MitM infrastructure.
[NCW] Agreed, they also state in ensuring that the newest TLS version where 
possible is used.  BUT, they also expect monitoring and troubleshooting.

    Please point me at the specific text. Given you added PCI-DSS to
    your document I would assume you did the work already. If not,
    that's a bit odd.
[NCW] From the link above, you can look at requirements in 1.3,
also Requirement 10 details the need to monitor and provide audit trails
for network resources and cardholder data.
    
    S.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 7 Nov 2017 16:27:31 -0800

> for network resources and cardholder data.

None of the questions in requirement 10 require middlebox interception.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Nov 2017 00:40:37 +0000

Hiya,

> at least allow for the identity disclosure to enable white or blacklist for example.  

Quoting from your draft wrt PCI-DSS:

" Requirement #2 (and Appendix A2 as it concerns TLS)
   describes the need to be able to detect protocol and protocol usage
   correctness."

That one is nice - you seem to be arguing for protocol non-conformance
(or for weakening conformant implementations) in order to help ensure
"protocol usage correctness." That kind of makes my head spin.

Another quote wrt NERC:

" In fact, regulatory standards such as NERC CIP
   [NERCCIP] place strong requirements about network perimeter security
   and its ability to have visibility to provide security information to
   the security management and control systems. "

Where exactly did you see those "strong requirements" that presumably
*require* breaking TLS?

I don't see them.

When I or others ask to be shown them we don't get shown them.

To me that means those are not *required*.

> possible is used.  BUT, they also expect monitoring and troubleshooting.

Sure. Not all monitoring *requires* breaking TLS. Same for
troubleshooting.

Of course people who sell kit for that or have been doing
that for a while might want to see what they do as being
mandatory/required/regulated-for but I'm not seeing it.

> for network resources and cardholder data

You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7
that call for MitMing TLS. That seems to be about addressing
and DMZs and firewall and router configs.

Requirement 10 seems to be dealing with audit of accesses to
cardholder data, not with TLS at all. I read pages 50-55 for
that.

Honestly, what you're saying is there does not seem to be
there.

S.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 8 Nov 2017 12:06:46 -0500

> So I didn't see any mention of TLS in that document at all.
Correct - the document is not a technical protocol specification but 
rather provides a set of requirements that have to be satisfied.
> mean there is no regulatory requirement at all wouldn't it?
An application layer firewall (aka NGFW these days) does indeed require 
you to be involved with TLS. How would you perform application-level 
inspection without ? Example functions include scanning for malware 
downloads, URL/application filtering, attack signatures (getting a bit 
more into the IDS space).

> if you want to quote them.

Again, the document is not a technical protocol specification, but it 
clearly describes the notion of an electronic security perimeter with a 
need for electronic access point and provides IDS/IPS as example 
instantiations of such a function. Let me quote a bit more from said 
document:
<quote>
/The standard adds a requirement to detect malicious communications for 
Control Centers. This//
//is in response to FERC Order No. 706, Paragraphs 496-503, where ESPs 
are required to have two//
//distinct security measures such that the BES Cyber Systems do not lose 
all perimeter protection//
//if one measure fails or is misconfigured. The Order makes clear that 
this is not simply//
//redundancy of firewalls, thus the SDT has decided to add the security 
measure of malicious//
//traffic inspection as a requirement for these ESPs. Technologies 
meeting this requirement//
//include Intrusion Detection or Intrusion Prevention Systems (IDS/IPS) 
or other forms of deep//
//packet inspection. These technologies go beyond 
source/destination/port rule sets and thus//
//provide another distinct security measure at the ESP./
</quote>

I don't know how you can reasonably argue that you satisfy the 
requirement here if you don't inspect encrypted traffic.

> I know people make money selling product and services for that.
It's not nonsense - it's deployed for a reason and it actually blocks a 
lot of attacks, in no small part by disabling command and control 
traffic. WannaCry and HeartBleed are just two of the more prominent 
examples of this, and there are many more where they came from (some 
encrypted, some not). You may want to take a look at 
http://blog.talosintelligence.com/2017/05/wannacry.html and 
http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html 
for starters. Feel free to browse around for many more.

> (E.g. as mentioned, saying to minimise the number of copies of
Let's take the PCI-DSS part on the parallel part of this thread.

> breaking TLS being attributed to them?
I think that's a really good suggestion.

Thanks

-- Flemming

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 10 Nov 2017 19:39:23 +0000

Hi all,

I think Flemming has expressed our points well.  But I think we are losing sight of the purpose of the draft: this is what industry is doing today in response to requirements; whether imposed by customers or regulations.  I would not expect these to explicitly state how a solution, architecture and protocol is to be implemented, they do impose requirements to an expected outcome.  As such, solutions have embraced the use of TLS pervasively and balanced the requirements of customers/regulations to provide firewall, inspection for monitoring and troubleshooting by the use cases as documented in the draft.

We are NOT against the use of PFS and improved security; we continue to look forward to evolving solutions that use TLS (1.3)…but in some cases there are implications that we thought merited awareness and further discussion.

Warm regards, Nancy

On 11/7/17, 4:40 PM, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    

    Another quote wrt NERC:

    
    I don't see them.

    

    

    
    
    S.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Nov 2017 17:11:26 -0800

On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

>
> Hi all,
>
> I think Flemming has expressed our points well.  But I think we are losing
> sight of the purpose of the draft: this is what industry is doing today in
> response to requirements; whether imposed by customers or regulations.  I
> would not expect these to explicitly state how a solution, architecture and
> protocol is to be implemented, they do impose requirements to an expected
> outcome.  As such, solutions have embraced the use of TLS pervasively and
> balanced the requirements of customers/regulations to provide firewall,
> inspection for monitoring and troubleshooting by the use cases as
> documented in the draft.
>
> We are NOT against the use of PFS and improved security; we continue to
> look forward to evolving solutions that use TLS (1.3)…but in some cases
> there are implications that we thought merited awareness and further
> discussion.
>

Nancy,

I don't dispute that some organizations ("industry" seems like a pretty
overbroad term as many organizations do not do these things) engage in some
of the practices that you list. However, as I noted in my review, I think
there are real concerns about whether these practices in fact securely
achieve their stated goals (even ignoring the impact that accommodating
them would have on TLS 1.3).

-Ekr

>     >     > perimeter, which has a couple of relevant requirements and
> associated
>     >     > text:
>     >     >
>     >     > http://www.nerc.com/_layouts/PrintStandard.aspx?
> standardnumber=CIP-005-5&title=Cyber%20Security%20-%
> 20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States
>     >     >
>     >     >
>     >     >