Nico Williams writes:
>When expirations are short, you will not forget to renew. That's part of the
>point of short-lived certificates.
So instead of getting one chance a year for your control system to break
itself if the renewal fails, you get hundreds of them?
Peter.
Nico raised some really good points here.
I think it is useful to start with the problem description.
It seems that you are concerned that there is a possibility for leakage or
compromise of keying material during the lifetime of the session.
What could happen?
* Long-term keys*,
* Some keys
Graham, Deb,
* 'Expiry: for the server/client. I suspect this is mostly a 'don't
care', except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?). Is this worth addressing? I suspect not.'
I agree.
* I would imagine that the
Focusing on one sentence from below:
* I've found that the best method to prevent the device from connecting is
for the certificate to be revoked, the CRL refreshed and then a
re-authentication performed on all active connections.
Why would you trigger re-authentication of all
Hi
I have a fair amount of hands on experience with IPsec VPNs, and many
organisations look to use TLS in a similar manner.
To give you an example of where you might look to perform a regular
revocation check on long lived connections;
Solution with many remote devices (think remote access, so
So we can break this down into 2 categories:
expiry
revocation
for both clients and servers.
Expiry: for the server/client. I suspect this is mostly a 'don't care',
except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?). Is this worth
Hi
Ref
'Expiry: for the server/client. I suspect this is mostly a 'don't care',
except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?). Is this worth addressing? I suspect
not.'
I would imagine that the implementation would pull the session
On Sun, Mar 07, 2021 at 11:47:45PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I'm not sure what it is you're imagining. What actually happens in the
> cases I'm familiar with is . . . . .
>
> Well-put - the point being that the cases you're familiar with do not
> cover the entire
>> You may claim that my environment does not represent yours. Sure,
> > fine. Similarly, *yours does NOT represent mine*.
>
>I'm not telling you what to do.
By making a statement "this solution works" without any qualifiers, you
essentially are.
The truth is - it works well for
> On Mar 8, 2021, at 1:45 AM, Peter Gutmann wrote:
>
> Not that "never" since it would break a lot of things, but some time far
> enough in the future that you don't have to worry about it.
The cert generator I cobbled together for the OpenSSL test-suite
generates 100-year certs. These work
Viktor Dukhovni writes:
>But if the signal is not ignored, and proper automation is applied,
>reliability actually improves.
No, it drops. You're going from a situation where you've eliminated any
chances of outages due to expired certs to one where you get to play Russian
roulette every
Benjamin Kaduk writes:
>Just to confirm: the scenario you're using to contrast to the one described
>by Viktor (and Nico) is a scenarios in which the certificates expire at
>"never" (1231235959Z)?
Not that "never" since it would break a lot of things, but some time far
enough in the future
On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
> Nico Williams writes:
> > When expirations are short, you will not forget to renew. That's
> > part of the point of short-lived certificates.
>
> So instead of getting one chance a year for your control system to break
> itself if
> >> So instead of getting one chance a year for your control system to
break
> >> itself if the renewal fails, you get hundreds of them?
> >
> >Yes. Exactly. It's a human factors problem. And this solution
works.
>
> With all due respect, *absolutely
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Connection Identifiers for DTLS 1.2
Authors : Eric Rescorla
Hannes
Hi Peter,
Just to confirm: the scenario you're using to contrast to the one described
by Viktor (and Nico) is a scenarios in which the certificates expire at "never"
(1231235959Z)?
I think that at least some people are contrasting against something other
than that...
Thanks,
Ben
On Mon,
On 3/7/21, 17:36, "TLS on behalf of Nico Williams" wrote:
>
>On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
>> Nico Williams writes:
>> > When expirations are short, you will not forget to renew. That's
>> > part of the point of short-lived certificates.
>>
On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 3/7/21, 17:36, "TLS on behalf of Nico Williams" behalf of n...@cryptonector.com> wrote:
> >
> >On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
> >> Nico Williams writes:
> >> > When
On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > > So instead of getting one chance a year for your control system to break
> > > itself if the renewal fails, you get hundreds of them?
> >
> >Yes. Exactly. It's a human factors problem. And this solution
On Sun, Mar 07, 2021 at 07:31:24PM -0800, Benjamin Kaduk wrote:
> Just to confirm: the scenario you're using to contrast to the one described
> by Viktor (and Nico) is a scenarios in which the certificates expire at
> "never"
> (1231235959Z)?
>
> I think that at least some people are
Hi Hannes
You're right, I rushed the answer. You would only need to perform the CRL
check on all existing connections, not re-authenticate. This would then
kill the session for the recently revoked certificate.
So I've mainly worked on solutions involving mobile devices; laptops and
phones.
On Sun, Mar 07, 2021 at 12:15:24PM +, Graham Bartlett wrote:
>
> I would imagine that the implementation would pull the session down once
> the certificate expires, so the session only lasts for the lifetime of the
> certificate.
Many people expect this, but I don't think there's universal
22 matches
Mail list logo
