Re: [TLS] Industry Concerns about TLS 1.3

> On Sep 26, 2016, at 7:21 PM, Eric Rescorla wrote: > > There are other ways to accomplish this. For example, the server might > use session ticket keys that are stored centrally encrypted under a > suitable escrow key. If clients always enable session tickets, then > every

Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 4:09 PM, Viktor Dukhovni wrote: > > There are other ways to accomplish this. For example, the server might > use session ticket keys that are stored centrally encrypted under a > suitable escrow key. If clients always enable session tickets, then

Re: [TLS] Industry Concerns about TLS 1.3

> On Sep 26, 2016, at 3:23 PM, BITS Security > wrote: > > That said, at least one of the sites you mentioned was known to have an APT > inside their perimeter (Operation Aurora) for about a month and part of the > tactics within that attack which was publicly

Re: [TLS] Industry Concerns about TLS 1.3

BITS Security writes: > Outbound TLS connections require MITM for decryption. Inbound or > internal TLS connections can be decrypted with an RSA private key > under TLS 1.2. It would be unwise to build a security or regulatory structure on the principle that MITM

Re: [TLS] Industry Concerns about TLS 1.3

? Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. ? So in my opinion, it makes sense to keep using TLS 1.2 internally. Won't the TLS WG stop addressing newly found protocol-level security issues in TLS 1.2 at some point in the future? I

Re: [TLS] Industry Concerns about TLS 1.3

Andrew, Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. Also, unlike SSL 3.0 – TLS 1.1, TLS 1.2 is not currently known to be weak or insecure, if properly implemented and not using insecure cipher suites. So in my opinion, it makes sense

Re: [TLS] Industry Concerns about TLS 1.3

Hi Brian--Thanks for the practitioner comment. Something perhaps worth mentioning here is that there often isn't just one support team inside an enterprise. There are application support teams for each application, network support people, security engineering support people, server support

Re: [TLS] Industry Concerns about TLS 1.3

Peter- Outbound TLS connections require MITM for decryption. Inbound or internal TLS connections can be decrypted with an RSA private key under TLS 1.2. The PCI DSS is already requiring TLS 1.2 for financial institutions that participate in the Payment Card Industry. .BANK (exclusive top

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

> Pushed to the extreme, the result is a sort of protocol drift, in which buggy > variants get first tolerated, and then accepted as de-facto standards. Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 4.0?), e.g. the relaxed rules around the signature_algorithms

Re: [TLS] Industry Concerns about TLS 1.3

Pawel Jakub Dawidek wrote: > > Because of that, every corporate network needs visibility inside TLS > traffic not only incoming, but also outgoing, so they can not only > debug, but also look for data leaks, malware, etc. There may be a some countries with poor civil liberty protections where

Re: [TLS] Industry Concerns about TLS 1.3

Hi All There is a smart way to recover DH secret by a third party It is DH tripartite base on EC paring https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00 Rgs Pascal 2016-09-25 23:20 GMT+02:00 Ackermann, Michael : > I understand your concern over what the

Re: [TLS] Industry Concerns about TLS 1.3

Thijs van Dijk wrote: > > Regular clients, no. > But this would be a useful addition to debugging / scanning suites (e.g. > Qualys), or browser extensions for the security conscious (e.g. CertPatrol). With FREAK and LOGJAM attacks, there is a significant difference in effort between servers