On 28/09/16 01:17, Seth David Schoen wrote:
> People with audit authority can then know all of the secrets,
How well does that whole audit thing work in the financial services
industry? (Sorry, couldn't resist:-)
S.
smime.p7s
Description: S/MIME Cryptographic Signature
Seth David Schoen writes:
> 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
+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
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
On Tue, Sep 27, 2016 at 11:34 AM, BITS Security <
bitssecur...@fsroundtable.org> wrote:
> Ilari - I understand yours (and others) view on this but there is no
technical reason why this couldn't be part of the standard. A potential
solution, like many cipher suite *choices* in past versions of TLS,
On Mon, Sep 26, 2016 at 4:55 PM, Martin Rex wrote:
> And no, there can not be any valid regulations to require such
> monitoring, because _every_ to the secrecy provisions and criminalization
> requires an explicit law from the parlamentarian legislator.
GDPR Article 88 leaves
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
Ilari - I understand yours (and others) view on this but there is no technical
reason why this couldn't be part of the standard. A potential solution, like
many cipher suite *choices* in past versions of TLS, would be optional and up
to both clients and servers to configure what they are
> On 27 Sep 2016, at 11:33 AM, Judson Wilson wrote:
>
>
>
> Yes, I know that changed. It was an example of something that works with
> TLS 1.2 even when PFS is used. With TLS 1.3 server or client implementations
> can find other ways to retain long-term records of
On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote:
> Hi Eric--Thank you for the prompt.
>
> Our requirements are for the same capabilities we have today with TLS
> 1.2, namely to be able to take a trace anywhere in our enterprise and
> decrypt it out of band (assuming that we own
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
Hi Eric--Thank you for the prompt.
Our requirements are for the same capabilities we have today with TLS 1.2,
namely to be able to take a trace anywhere in our enterprise and decrypt it out
of band (assuming that we own the TLS server). This includes traces taken from
physical taps, traces
Andrei Popov writes:
>Won’t the TLS WG stop addressing newly found protocol-level security issues
>in TLS 1.2 at some point in the future?
They already have, which is the point of TLS-LTS. Since that fixes all known
issues (and that also includes long-standing
>
> Yes, I know that changed. It was an example of something that works with
> TLS 1.2 even when PFS is used. With TLS 1.3 server or client
> implementations
> can find other ways to retain long-term records of session keys. The
> capability
> to do that is not a requisite or desirable protocol
14 matches
Mail list logo