On 20/07/17 21:21, Carl Mehner wrote:
> On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
> wrote:
> I think using TLS 1.2 and waiting will only work up to a point. When
> the regulators do require TLS 1.3 (and that may be years and years
> away), enterprises still need som
I would like to point out that a lot of this discussion seems to hinge
on the following argument:
On 17/07/17 13:04, Roland Dobbins wrote:
> On 16 Jul 2017, at 11:14, Salz, Rich wrote:
>
>> I really want to hear an answer to that question from folks who say
>> they need TLS 1.3 but without it.
>
On 17/07/17 17:32, Roland Dobbins wrote:
> Sure - detecting attempted additional compromise and lateral movement
> utilizing exploits within TLS-encrypted traffic.
This is about decrypting traffic inside your network.
> Another is detecting (and subsequent blocking of) the download of
> malware
Nits:
RFC 4279 reference is missing.
"TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or
"TLS 1.3 and higher versions"
On 04/05/17 18:41, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following
e increase in security weighted with the difficulty of
> obtaining
> such short-lived certificates from a CA probably does not justify the
> extra
> complexity of adding subcerts.
>
>
> @Simon Friedberger Do you feel that short lived CA certificates are
> actually deplo
I agree, that's why I only see a security gain if the theft of the
certificate remains undetected.
On 05/04/17 14:35, Salz, Rich wrote:
>>Server operators
>>often want to create short-lived certificates for servers in low-
>>trust zones such as CDNs or remote data centers.
> But as cu
It seems the intention behind short lived certificates is pretty clear:
Server operators
often want to create short-lived certificates for servers in low-
trust zones such as CDNs or remote data centers.
But even if this is true it needs to be analyzed why server operators want
to do th
