Re: [TLS] TLS1.3 + PSK with multiple identities

[Olivier Levillain]

Hi list,

I have been working in the labs at ANSSI (the French Network and
Information System Agency) for several years and I just defended my PhD
thesis on the TLS ecosystem (documents are available at
http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/).

>> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
>>> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
 More compact and makes the option where server sends some bad option
 more clear.
>> Note that if we really want to be more compact, we might also observe
>> that there is a redundant length field in the extension as sent by the
>> client:
>>case client_hello:
>>PskIdentity identities<6..2^16-1>;
>>
>> Each extension has at least four bytes on the wire — the extension_type
>> itself, and the length field of the extension_data in a uint16.
>>
>> If I am interpreting the spec correctly, then the data for the
>> PreSharedKeyIdentity extension in the ClientHello then follows that
>> with another uint16, which is *always* a value two lower than the one
>> which immediately precedes it.
>>
>> e.g.
>>
>>   0x00 0x29  // ExtensionType extension_type == 41
>>   0x00 0x14  // opaque extension_data<0..2^16-1>
>> // This length field is entirely redundant:
>> 0x00 0x12  // PskIdentity identities<6..2^16-1>
>>  // First identity:
>>   0x00 0x00  // PskKeyExchangeMode, PskAuthenticationMode
>>   0x00 0x04  // opaque identity<0..2^16-1>
>> 0x44 0x61 0x76 0x65 // "Dave"
>>  // Second identity:
>>   0x00 0x00  // PskKeyExchangeMode, PskAuthenticationMode
>>   0x00 0x06  // opaque identity<0..2^16-1)>
>> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë"
>>
>> Do we care that the '0x00 0x12' bytes on my third line above are
>> entirely redundant on the wire? Or have I interpreted it wrong?
>>
> Not enough to fix it, this is just the way TLS rolls.

Sorry if I am a little late to the party, but I noticed that even if
this is generally true, I believe it has not always been enforced in TLS
extensions.

In 2006, the IETF standardised the session tickets extension, allowing
for session resumption without server-side state (RFC 4507).
However, no TLS stack implements the specification correctly: even
if the specification described the _content_ of the extension as
a variable-length object (that is an opaque object prefixed by its
length), every implementation ignores this second (useless) length
field.  The RFC 5077, published in 2008, fixes the gap
between the specification and the implementations.

RFC 4507 :

The SessionTicket extension has been assigned
the number 35.  The format of the SessionTicket
extension is given at the end of this section.

  struct {
opaque ticket<0..2^16-1>;
  } SessionTicket;

00 23  Ticket Extension type 35
01 02  Length of extension contents
01 00  Length of ticket
FF FF .. ..Actual ticket

RFC 5077

The SessionTicket extension has been assigned
the number 35.  The extension_data field of
SessionTicket extension contains the ticket.

00 23  Ticket Extension type 35
01 00  Length of extension contents (ticket)
FF FF .. ..Actual ticket


Best regards,
olivier

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

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Mon, Oct 3, 2016 at 2:21 PM, BITS Security  wrote:

> If PCI has mandated upgrading TLS because of vulnerabilities, they are
> likely to do it again and in fact have provided strong hints to the market
> where they should be beyond the minimum requirement itself.


This is simply not true. In 2015 the PCI council was pushing for updating
to TLS 1.1+ in short order, but backed off out of "industry concerns"
similar to the ones you are voicing here, and have delayed the mandatory
rollout of TLS 1.1 until 2018.

That's at least two years away.

After that, they will deprecate TLS 1.1. That will probably take at least a
year. So in 2019 (again, pure speculation as to the earliest time this will
possibly happen), TLS 1.2 will be mandatory.

After that, they may deprecate TLS 1.2 if it is demonstrated to be
insecure. There is no reason to suspect at this point that that will even
happen. TLS 1.2 is generally recognized as secure, and the "LTS" profile
should fix whatever low-priority security concerns remain.


> I don't see that the timing really matters because it isn't based on the
> age of the standard, it is based on the standard becoming outdated.


That is absolutely not true. The PCI's motivation for TLS version upgrades
has been real-world security vulnerabilities, and again, it took them 15
years to deprecate TLS 1.0.

There is absolutely no evidence that the PCI council plans on making TLS
1.3 mandatory any time soon, and if we follow a version-a-year cadence
(which they're NOT presently working on, based on the one deprecation data
point we have it's ~3 years per version) it will be 2020 at the earliest
before it happens.

You are asking the IETF to make a serious compromise regarding the security
of the Internet based on *pure speculation*. A minimum degree of due
diligence here would be to first ask the PCI council what their plans for
mandating TLS 1.3 actually are, and if they *actually* give you a date that
scares you, that might be a reason to voice concern so late in the process.

I think what you're proposing is actively harmful to Internet security and
you should be working with the PCI Council, not the IETF, to address your
concerns.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd]

>
> If you look at the industry reports like the Verizon PCI Breach and
Compliance Reports, private keys simply aren't being stolen.  Maybe there
is an outlier or two but there certainly isn't a documented trend I can
find.  If you have contravening information to provide I am all ears.

Surely you remember the day when all SWIFT provided devices had to be
replaced thanks to some fun in the random number generators. Then there is
POISON NUT.

The Shadow brokers leak included tools to extract VPN keys from Cisco
routers. TJ Maxx involved breaking WEP.

>
> - Andrew
>
>
>
> From: Tony Arcieri [mailto:basc...@gmail.com]
> Sent: Tuesday, September 27, 2016 4:17 PM
> To: BITS Security 
> Cc: Peter Bowen ; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
bitssecur...@fsroundtable.org> wrote:
> The PCI DSS is already requiring TLS 1.2 for financial institutions that
participate in the Payment Card Industry.  .BANK (exclusive top level
banking domain) is also planning to require TLS 1.2.   We're anticipating
that a regulatory body like these will require TLS 1.3 at some point in the
future.  Financial institutions then have to comply if they want to
continue to do business with the companies represented by the regulatory
body (like large credit card companies in the case of PCI).
>
> Hello again,
>
> I work firsthand enforcing these requirements at a payments company.
Again, I do not speak on behalf of my employer.
>
> It wasn't until last year that PCI decided to deprecate TLS 1.0, at the
time a 16 year old standard. I think your sense of emergency is highly
over-exaggerated.
>
> I find it highly unlikely that any group such as the PCI Council will
begin mandating TLS 1.3 any time soon. I would go as far as to call your
concerns "imaginary".
>
> If you are worried about such an eventuality, the IETF is the wrong place
to complain. It is far, far too late in the TLS 1.3 process to be voicing
these concerns. Where were you 2+ years ago when it was the appropriate
time in the TLS development cycle to voice such concerns? I think the view
of more "forward thinking" payments companies is TLS 1.3 has taken too long
already, and they would like to start deploying it in its current form and
would prefer unnecessary holdups/distractions which have already occurred
throughout the process.
>
> That said, there is still plenty of time to ensure that groups like the
PCI Council do not put in place requirements which would affect the
centralized traffic-decrypting MitM-capability on your payments stack.
Perhaps you should be voicing your concerns there? If you are worried about
a TLS 1.3 mandate preventing your MitM capability, the onus is on you to
convince the relevant payments standards bodies that mandating TLS 1.3 is a
bad idea for the payments industry. I think those organizations are better
poised to judge whether such an approach reflects on necessary requirements
versus pervasive antipatterns among complacent companies unprepared for the
future and ripe for a data breach.
>
> In the meantime, you have disclosed a veritable treasure map to a
traffic-decrypting single point of failure which ostensibly exists at all
of the companies you represent which attackers could leverage to recover
all payment credentials. That sounds like a huge security threat.
>
> Would you mind disclosing which companies you represent, so I can ensure
for the safety of my own money that I do not use them?
>
> --
> Tony Arcieri
> ___
> 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] Industry Concerns about TLS 1.3

[Jeffrey Walton]

> PCI requirement providing Intrusion Detection at the entrance to Cardholder 
> Data Environments as well as at critical points inside the Cardholder Data 
> Environment.  Intrusion Detection requires decryption of TLS.  For some 
> large, complex organizations this can be a large number of physical 
> inspection points, more than can be accommodated by MITM.  I understand this 
> may not be a problem for your current environment but others do not have that 
> luxury.
>

This may be less than an ideal requirement.

Malware wants to do three things (with some hand waiving): (1) spread,
(2) collect data, and (3) egress data. I think Step (1) and intrusion
detection is a worthy cause, but not at the cost of breaking the
secure channel.

Perhaps it would be better to focus on (2) and (3). (2) can be tricky
based on how deeply the malware is burrowed in. (3) is much easier
since the malware needs to open a socket.

Policies for (3) are really just whitelist/blacklist approaches. I'm
guessing egress points are wide open at the moment, and the PCI
requirement is fostering blacklists and causing the organization to be
reactive. If the egress points are closed at the organizational
boundary, then the organization is proactive and using a whitelist
approach.

Would it be possible to have the PCI folks re-examine their position
since it seems to be boxing BITS members into something untenable?

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> I work firsthand enforcing these requirements at a payments company. Again, I 
> do not speak on behalf of my employer.   
> It wasn't until last year that PCI decided to deprecate TLS 1.0, at the time 
> a 16 year old standard. I think your sense of emergency is highly 
> over-exaggerated.   
> I find it highly unlikely that any group such as the PCI Council will begin 
> mandating TLS 1.3 any time soon. I would go as far as to call your concerns 
> "imaginary".  

If PCI has mandated upgrading TLS because of vulnerabilities, they are likely 
to do it again and in fact have provided strong hints to the market where they 
should be beyond the minimum requirement itself.  I don't see that the timing 
really matters because it isn't based on the age of the standard, it is based 
on the standard becoming outdated.  We're trying to get ahead of foreseeable 
problem some will have. 

Further, PCI does not require TLS encryption at all in a private data center, 
at least not technically.  However, in practice they strongly recommend 
segmenting the Cardholder Data Environment, which I suspect most financials 
have done, and many have used TLS as part of their strategy for segmentation 
(encrypted PCI traffic flowing through devices does not bring these devices 
into scope for audit).  So according to current practice, auditors are going to 
require certain levels of TLS in order for our segmenting strategies to work.

> If you are worried about such an eventuality, the IETF is the wrong place to 
> complain. It is far, far too late in the TLS 1.3 process to be voicing these 
> concerns. Where were you 2+ years ago when it was the appropriate time in the 
> TLS development cycle to voice such concerns? I think the view of more 
> "forward thinking" payments companies is TLS 1.3 has taken too long already, 
> and they would like to start deploying it in its current form and would 
> prefer unnecessary holdups/distractions which have already occurred 
> throughout the process.

PCI requirement providing Intrusion Detection at the entrance to Cardholder 
Data Environments as well as at critical points inside the Cardholder Data 
Environment.  Intrusion Detection requires decryption of TLS.  For some large, 
complex organizations this can be a large number of physical inspection points, 
more than can be accommodated by MITM.  I understand this may not be a problem 
for your current environment but others do not have that luxury.

> That said, there is still plenty of time to ensure that groups like the PCI 
> Council do not put in place requirements which would affect the centralized 
> traffic-decrypting MitM-capability on your payments stack. Perhaps you should 
> be voicing your concerns there? If you are worried about a TLS 1.3 mandate 
> preventing your MitM capability, the onus is on you to convince the relevant 
> payments standards bodies that mandating TLS 1.3 is a bad idea for the 
> payments industry. I think those organizations are better poised to judge 
> whether such an approach reflects on necessary requirements versus pervasive 
> antipatterns among complacent companies unprepared for the future and ripe 
> for a data breach.

We can implore PCI all we want, but if events overtake us, such as the 
introduction of new security risks, we have to be prepared for eventualities 
like TLS 1.3 being the mandate and must be prepared perform IDS/IPS routines at 
scale such an environment.

> In the meantime, you have disclosed a veritable treasure map to a 
> traffic-decrypting single point of failure which ostensibly exists at all of 
> the companies you represent which attackers could leverage to recover all 
> payment credentials. That sounds like a huge security threat.
> Would you mind disclosing which companies you represent, so I can ensure for 
> the safety of my own money that I do not use them?

I don't know how this listserv operates in practice but it is this type of 
sophistry that hard boils my eggs to put it politely.  Perhaps this is just the 
regular cost of participation but that would be unfortunate.  

If you look at the industry reports like the Verizon PCI Breach and Compliance 
Reports, private keys simply aren't being stolen.  Maybe there is an outlier or 
two but there certainly isn't a documented trend I can find.  If you have 
contravening information to provide I am all ears. 

- Andrew 



From: Tony Arcieri [mailto:basc...@gmail.com] 
Sent: Tuesday, September 27, 2016 4:17 PM
To: BITS Security 
Cc: Peter Bowen ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security  
wrote:
The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require 

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> > The various suggestions for creating fixed/static Diffie Hellman keys raise 
> > interesting possibilities.  We would like to understand these ideas better 
> > at a technical level and are initiating research into this potential 
> > solution.  We need to understand the potential ramifications and other 
> > implementation details.  This solution would have to be implemented in 
> > servers, firewalls, load balancers, Internet proxies, and mainframes.  If 
> > vendors broadly refuse to support then it is not much a solution but at 
> > this point looks like it is worth exploring.  

> Bear in mind that, if you do that, anyone who gets a copy of that secret will 
> be able to retrospectively decrypt all of your organization's TLS traffic.  
> However, that's presumably true of any solution that satisfies the 
> requirement that you describe: there will always be _some_ secret that the 
> organization possesses that, if obtained by an adversary, would let the 
> adversary retrospectively decrypt traffic.

We can put private keys in an HSM and implement other processes to protect 
them.  This is what some are doing with RSA today.  If you look at the Verizon 
breach report and other similar resources, breaches from stolen network packets 
and/or stolen private keys is not a discernible trend (though I will cede past 
results don't predict future performance). 

> This configuration might be a bit dangerous because it means that "servers, 
> firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so 
someone inside or outside the organization who can steal that information can 
then read all of the traffic, even traffic that was originated by devices they 
don't know about or have a relationship to.
> So organizational unit X can read the traffic of organizational unit Y, even 
> if X wasn't meant to be in a supervisory or audit relationship over Y, 
> because the ability to emit decryptable traffic of this kind also implies the 
> ability to decrypt others' sessions.

We've heard this a different way, for example not every layer of the data 
center would have the same key or that key is always available. I have to admit 
to some ignorance here which is why we want to explore this potential option.  
Even if it works (which it might not as you say) there still is the question of 
if vendors would being willing to support.  

> It also provides a way that other parties outside of the organization can, 
> even through passive eavesdropping, recognize the organization's traffic as 
> associated with that organization -- kind of like a global cookie inside the 
> TLS handshake.  People could use that to target surveillance or advertising 
> even if they didn't know or recognize the organization's IP address ranges.

Something else important to check on that could undermine this solution.  
Appreciate it.  

- Andrew 




-Original Message-
From: Seth David Schoen [mailto:sch...@eff.org] 
Sent: Tuesday, September 27, 2016 2:30 PM
To: BITS Security 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

BITS Security writes:

> The various suggestions for creating fixed/static Diffie Hellman keys raise 
> interesting possibilities.  We would like to understand these ideas better at 
> a technical level and are initiating research into this potential solution.  
> We need to understand the potential ramifications and other implementation 
> details.  This solution would have to be implemented in servers, firewalls, 
> load balancers, Internet proxies, and mainframes.  If vendors broadly refuse 
> to support then it is not much a solution but at this point looks like it is 
> worth exploring.  

Bear in mind that, if you do that, anyone who gets a copy of that secret will 
be able to retrospectively decrypt all of your organization's TLS traffic.  
However, that's presumably true of any solution that satisfies the requirement 
that you describe: there will always be _some_ secret that the organization 
possesses that, if obtained by an adversary, would let the adversary 
retrospectively decrypt traffic.

This configuration might be a bit dangerous because it means that "servers, 
firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so 
someone inside or outside the organization who can steal that information can 
then read all of the traffic, even traffic that was originated by devices they 
don't know about or have a relationship to.
So organizational unit X can read the traffic of organizational unit Y, even if 
X wasn't meant to be in a supervisory or audit relationship over Y, because the 
ability to emit decryptable traffic of this kind also implies the ability to 
decrypt others' sessions.

It also provides a way that other parties outside of the organization can, even 
through passive 

[TLS] [Editorial Errata Reported] RFC6066 (4817)

[RFC Errata System]

The following errata report has been submitted for RFC6066,
"Transport Layer Security (TLS) Extensions: Extension Definitions".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6066=4817

--
Type: Editorial
Reported by: ResponderIDs type is not defined anywhere. 

Section: 8

Original Text
-
In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
responders that the client trusts. 

Corrected Text
--
In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP
responders that the client trusts.

or clearer 

In OCSPStatusRequest, the "responder_id_list" provides a list of
"ResponderID", OCSP responders that the client trusts.

Notes
-
ResponderIDs is not defined anywhere within the document.

Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed this.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6066 (draft-ietf-tls-rfc4366-bis-12)
--
Title   : Transport Layer Security (TLS) Extensions: Extension 
Definitions
Publication Date: January 2011
Author(s)   : D. Eastlake 3rd
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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