es
that could cause an IP-address mismatch, many of which the client
wouldn't see.
>
> Cheers,
> S.
>
>
>>
>>
>> Subodh
>>
>> ____ From: Stephen Farrell
>> Sent: Wednesday, April 5, 2017 12:30:31
>> PM To: Subodh I
ents not using a proxy is non-negligible, which I assume is
the case. Was that considered?
Cheers,
S.
>
>
> Subodh
>
> From: Stephen Farrell
> Sent: Wednesday, April 5, 2017 12:30:31
> PM To: Subodh Iyengar; Simon Friedberger; tls@ietf.or
On 05/04/17 18:07, Subodh Iyengar wrote:
>
> The threat model here is that since if a less-trusted host having a
> key is compromised for a certain period of time without detection, and
> an attacker can steal private keys during that period. In many
> situations we are fine with giving the TLS ter
solution.
Subodh
From: Stephen Farrell
Sent: Wednesday, April 5, 2017 12:30:31 PM
To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; Kaduk, Ben
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts
I've no strong opinion f
I've no strong opinion for or against this. One question below
though.
On 05/04/17 17:07, Subodh Iyengar wrote:
> The threat model here is that since if a less-trusted host having a
> key is compromised for a certain period of time without detection,
> and an attacker can steal private keys durin
On 04/05/2017 11:07 AM, Subodh Iyengar wrote:
>
> > There is also an alternate world in which the TLS terminators should
> not have certificates/keys on them but it is okay to give them
> delegated credentials. Here, one benefit is clear: performance. But
> the attacker capabilities against which
being able to deploy short lived credentials to
not only less trusted locations, but also to more trusted locations as well
which is another use case that I want to use this for.
Subodh
From: TLS on behalf of Simon Friedberger
Sent: Wednesday, April 5, 2017 5:3
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
>Server operators
>often want to create short-lived certificates for servers in low-
>trust zones such as CDNs or remote data centers.
But as currently specified, that low-trust short-lived certificate, if
captured, can be used to spoof the operator anywhere else in the world. Yes,
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
On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
> Thanks for your question Brian.
>
> The motivation behind delegated credentials is to create a more
> reasonable deployment model for short lived credentials.
My apologies for being blunt, but that text reads like a solution in
search of a problem.
his clears things up.
Subodh
From: TLS on behalf of Brian Sniffen
Sent: Thursday, March 30, 2017 2:54:29 PM
To: tls@ietf.org
Subject: [TLS] security considerations for draft-rescorla-tls-subcerts
I'm trying to understand the adversary model in which Delegate
I'm trying to understand the adversary model in which Delegated
Credentials are helpful. It seems like if you weren't going to sign off
on a cloud service provider getting a certificate before, you *probably*
shouldn't let them have a delegated credential now---but if you were
going to do so, *and
13 matches
Mail list logo
