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

[Eric Rescorla]

On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> 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





> Warm regards, Nancy
>
>
> On 11/7/17, 4:40 PM, "Stephen Farrell"  wrote:
>
>
> Hiya,
>
> On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> > Hi Stephen,
> > Please see below:
> >
> > On 11/7/17, 4:08 PM, "Stephen Farrell" 
> wrote:
> >
> >
> > 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.
> > [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.
>
> 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*.
>
> >
> > > 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
> >
> > 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.
>
> 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.
>
> >
> > >
> > > 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,
> > 

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

[Nancy Cam-Winget (ncamwing)]

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"  wrote:


Hiya,

On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Please see below:
> 
> On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:
> 
> 
> 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.
> [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.  

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

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

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.

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

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

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

[Flemming Andreasen]

On 11/7/17 7:01 PM, Stephen Farrell wrote:

Hiya,

On 07/11/17 23:27, Flemming Andreasen wrote:

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

On 11/7/17 4:13 AM, Stephen Farrell wrote:

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:

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?

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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States


Thanks for that.

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.

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

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




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.


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:


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


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



and outbound communications by leveraging an "Electronic Access Point"
(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.
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.



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

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

It's been asked for a number of times without 

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

[Stephen Farrell]

Hiya,

On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Please see below:
> 
> On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:
> 
> 
> 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.
> [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.  

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

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

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.

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

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.


> 
> S.
> 
> 
> > 
> > Thanks, Nancy
> > 
> > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> >  wrote:
> > 
> > Thanks for taking an initial look at the document Stephen - please
> > see below for responses so far
> > 
> > On 11/7/17 4:13 AM, Stephen Farrell wrote:
> >> Hiya,
> >> 
> >> On 07/11/17 02:48, Flemming Andreasen wrote:
> >>> 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?
> > 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:
> > 
> > 
> 

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

[Watson Ladd]

On Tue, Nov 7, 2017 at 4:23 PM, Nancy Cam-Winget (ncamwing)
 wrote:
> Hi Stephen,
> Please see below:
>
> On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:
>
>
> 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.
> [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.
>
> > 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
>
> 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.
>
> >
> > 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.
> [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.

None of the questions in requirement 10 require middlebox interception.
>
> S.
>
>
> >
> > Thanks, Nancy
> >
> > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> >  wrote:
> >
> > Thanks for taking an initial look at the document Stephen - please
> > see below for responses so far
> >
> > On 11/7/17 4:13 AM, Stephen Farrell wrote:
> >> Hiya,
> >>
> >> On 07/11/17 02:48, Flemming Andreasen wrote:
> >>> 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?
> > 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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=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.
> >> 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).
> >
> > I will need to look more closely for such a quote - if anybody else
> > knows of one, please chime in as well.
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> >> Thanks, S.
> >>
> >>
> >> [1]
> >> 
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
> >
> >>
> >
> >
> >
> >
>
>
>
> ___
> TLS mailing 

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

[Nancy Cam-Winget (ncamwing)]

Hi Stephen,
Please see below:

On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:


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

> 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

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.

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


> 
> Thanks, Nancy
> 
> On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
>  wrote:
> 
> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>> 
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> 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?
> 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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=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.
>> 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).
> 
> I will need to look more closely for such a quote - if anybody else 
> knows of one, please chime in as well.
> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks, S.
>> 
>> 
>> [1] 
>> 
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>
>> 
> 
> 
> 
> 



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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:
> 
> https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

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, Nancy
> 
> On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
>  wrote:
> 
> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>> 
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> 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?
> 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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=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.
>> 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).
> 
> I will need to look more closely for such a quote - if anybody else 
> knows of one, please chime in as well.
> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks, S.
>> 
>> 
>> [1] 
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>
>> 
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 07/11/17 23:27, Flemming Andreasen wrote:
> Thanks for taking an initial look at the document Stephen - please see
> below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> 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?
> 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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 

Thanks for that.

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

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

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.

> and outbound communications by leveraging an "Electronic Access Point"
> (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.

>> 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).
> 
> I will need to look more closely for such a quote - if anybody else
> 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.

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



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nancy Cam-Winget (ncamwing)]

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)"  wrote:

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

On 11/7/17 4:13 AM, Stephen Farrell wrote:
> Hiya,
>
> On 07/11/17 02:48, Flemming Andreasen wrote:
>> 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?
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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=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.
> 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).

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

Thanks

-- Flemming


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



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Flemming Andreasen]

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


On 11/7/17 4:13 AM, Stephen Farrell wrote:

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:

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?
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=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=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.

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


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


Thanks

-- Flemming



Thanks,
S.


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



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Flemming Andreasen]

On 11/7/17 12:23 PM, Eric Rescorla wrote:



On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen > wrote:


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


On 11/6/17 12:43 PM, Eric Rescorla wrote:

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.


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.


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


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.



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.


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



- 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 

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

[Eric Rescorla]

On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen 
wrote:

> Thank you for the feedback Ekr - please see below for responses
>
>
> On 11/6/17 12:43 PM, Eric Rescorla wrote:
>
> 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.
>
> 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.
>

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



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



> - 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.
>
> If that is indeed the case, then I 

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

[Flemming Andreasen]

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

On 11/6/17 12:43 PM, Eric Rescorla wrote:

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.

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.



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.


I'm not aware of actual implementations doing this with DH.



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.


Fair point.



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.

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




- 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 

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

[Stephen Farrell]

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
>>
> 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?

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



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Flemming Andreasen]

On 11/5/17 10:31 AM, Florian Weimer wrote:

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



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



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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 

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

[Florian Weimer]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] network-based security solution use cases

[Nancy Cam-Winget (ncamwing)]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls