Re: [TLS] Industry Concerns about TLS 1.3

[Ronald del Rosario]

+1 to Tony

I am also in charge of enforcing TLS Standards in our CDE.  I also do not speak 
on behalf of my employer, but:

PCI extended the migration from SSLv3 and TLS 1.0 to a secure version (TLS 1.1 
or higher) until June 
2018.

Thanks,
Ron

From: TLS  on behalf of Tony Arcieri 
Date: Tuesday, September 27, 2016 at 1:17 PM
To: BITS Security 
Cc: Jeffrey Walton 
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 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



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Request for information: Lightweight Mutual Authentication for Constrained Devices?

[Ronald del Rosario]

Greetings TLS Group,

Looking for standards/drafts/documentation or similar research discussing a 
mutual authentication framework for contained devices (Devices with limited 
processing power, battery, runs on wireless Network)

Thanks in advance,
Ron




CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Ronald del Rosario]

 ECDSA can be smaller, faster, and more secure all at once; and if you don't 
 like ECDSA or want an alternative, there's RSA.

Isn't that a step backward reverting to RSA?

Ron F. Del Rosario



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.

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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Ronald del Rosario]

Or what we do in WebRTC, which uses a certificate that has no good
information in it?”

+1. Anxiously waiting for response on this, as I am currently helping 
non-profit groups build a private and secure P2P Messaging System using WebRTC, 
which of course utilizes encrypted P2P connection between two browsers (A 
centralized signaling server must be at the middle as a broker for the sessions)

The DTLS handshake performed between two WebRTC clients re-lies on self-signed 
certificates. As a result, the certificates themselves cannot be used to 
authenticate the peer, as there is no explicit chain of trust to verify.

Ron


From: TLS tls-boun...@ietf.orgmailto:tls-boun...@ietf.org on behalf of 
Martin Thomson martin.thom...@gmail.commailto:martin.thom...@gmail.com
Date: Friday, August 28, 2015 at 11:44 AM
To: Eric Rescorla e...@rtfm.commailto:e...@rtfm.com
Cc: tls@ietf.orgmailto:tls@ietf.org tls@ietf.orgmailto:tls@ietf.org
Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys?

Or what we do in WebRTC, which uses a certificate that has no good
information in it?



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls