Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

I don't believe so, but that would seem like a configuration issue. I guess if you really wanted you could define an extension that goes in the Certificate Request message (which the AR is based on), assuming there isn't one already, that requests a specific serial number. Although that of course

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Hi Jonathan, Maybe a further question to the draft you referenced (exported authenticators). Is there a way to request a distinct certificate in the AuthenticatorRequest? Can I ask for the certificates used in the initial handshake from both sides? I saw in the extension that in the ClientCerti

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

> From: Jonathan Hoyland > Sent: Donnerstag, 11. März 2021 00:31 > One option that I haven't seen mentioned in the thread is > https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14. Thank you for the pointer to the draft. > EAs let you send a certificate from either side of the

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

One option that I haven't seen mentioned in the thread is Exported Authenticators . EAs let you send a certificate from either side of the connection at any point after the handshake is complete. I'm not sure what the behaviour

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote: > > My take is such measures are much too complicated. Just keep the connection > > lifetime short, and make a new one from time to time. Also keep certificate > > lifetimes short. Where DNSSEC is an option on both ends, you can al

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

> -Original Message- > From: TLS On Behalf Of Viktor Dukhovni, Sent: Montag, > 8. März 2021 19:05 > > The problem that was addressed so far with the session renegotiation in TLS > 1.2 was motivated by different points. > > > > - Recommendation in RFC 5246 regarding the use of the SessionI

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Mon, Mar 08, 2021 at 08:51:31AM +, Fries, Steffen wrote: > The problem that was addressed so far with the session renegotiation in TLS > 1.2 was motivated by different points. > > - Recommendation in RFC 5246 regarding the use of the SessionID lifetime > - Regular session key update for

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Peter can certainly speak for himself :) but I don't think it's never. I think it's also the kind of thing where someone does things manually, and then goes out into the field for a service operation. So not just never, but also situations where automation isn't appropriate and installing softw

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Behalf Of Nico Williams > Sent: Friday, March 5, 2021 8:35 PM > To: John Mattsson > Cc: tls@ietf.org > Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in > long > lasting connections > > On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote:

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

> On 7 Mar 2021, at 17:25, Benjamin Kaduk > wrote: > > 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.

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

> 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 wel

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 t

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 contras

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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, Ma

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 single

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

>> 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 *some*

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 wo

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

> >> 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 not*.

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 exp

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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. >> >

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

March 7, 2021 12:16 PM > *To:* Peter Gutmann > *Cc:* John Mattsson ; TLS > List > *Subject:* Re: [TLS] Question to TLS 1.3 and certificate revocation > checks in long lasting connections > > > > Hi > > > > I have a fair amount of hands on experience with IPsec

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 ag

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 implem

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

John Mattsson ; TLS List Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections 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 lo

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 address

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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 p

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

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. _

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

poses). Without further complicating things, the impact depend a bit on which keys have been leaked. -Original Message- From: TLS On Behalf Of Nico Williams Sent: Friday, March 5, 2021 8:35 PM To: John Mattsson Cc: tls@ietf.org Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation c

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Sat, Mar 06, 2021 at 01:21:14AM -0500, Viktor Dukhovni wrote: > I suspect that in at least some cases the motivation to revalidate the > server certificate is only requested because it could be done in > principle, and ticks some checkbox about using CRLs, because they > exist, rather than from

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Sat, Mar 06, 2021 at 06:55:52AM +, Peter Gutmann wrote: > Nico Williams writes: > > >I've seen 5 day server certificates in use. > > For IEC-62351 work you're far more likely to see certificates issued with an > expiry date of never, because the last thing you want is your power grid to

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Nico Williams writes: >I've seen 5 day server certificates in use. For IEC-62351 work you're far more likely to see certificates issued with an expiry date of never, because the last thing you want is your power grid to be taken offline due to a cert someone forgot to renew. In terms of CRL u

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Sat, Mar 06, 2021 at 12:11:25AM -0600, Nico Williams wrote: > On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote: > > This leaves us with the case where Bob's certificate is no longer valid but > > Bob has a new certificate [0]. In this case, just re-validating does not > > help. Doe

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote: > This leaves us with the case where Bob's certificate is no longer valid but > Bob has a new certificate [0]. In this case, just re-validating does not > help. Does that happen so often that we need protocol machinery other than > just

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 01:13:57PM -0500, Viktor Dukhovni wrote: > This harks back to another recent thread where it was noted that one > needs to make a distinction between authentication and authorisation. > > The integrity of a TLS 1.3 session (which always performs ephemeral key > agreement th

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 5, 2021 at 11:38 AM Watson Ladd wrote: > On Fri, Mar 5, 2021, 10:43 AM John Mattsson > wrote: > > > > >While renegotiation will never be re-added, there is post-handshake > > >authentication (RFC 8446, section 4.6.2), and while that is currently > > >about authenticating the _client_

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 5, 2021, 10:43 AM John Mattsson wrote: > > >While renegotiation will never be re-added, there is post-handshake > >authentication (RFC 8446, section 4.6.2), and while that is currently > >about authenticating the _client_ to the server, it should be trivial to > >extend the protocol to

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote: > >While renegotiation will never be re-added, there is post-handshake > >authentication (RFC 8446, section 4.6.2), and while that is currently > >about authenticating the _client_ to the server, it should be trivial to > >extend the pr

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

-Original Message- From: Nico Williams Date: Friday, 5 March 2021 at 18:35 To: John Mattsson Cc: "Fries, Steffen" , "TLS@ietf.org" Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections On Fri, Mar 05, 2021 at 05:01:

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 02:01:52PM +, Fries, Steffen wrote: > I've got a question regarding application of TLS 1.3 to protect long > lasting connections. Specifically on the trigger to perform a > revocation check for the utilized certificates in the handshake. > > The background is that fo

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 05:01:04PM +, John Mattsson wrote: > On Friday, 5 March 2021 at 15:02, Fries, Steffen wrote: > > I've got a question regarding application of TLS 1.3 to protect long > > lasting connections. Specifically on the trigger to perform a > > revocation check for the utilized

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

The TLS WG has not addressed long-lived connections. Probably because most of the people who developed the spec are in the Web space. That's not intended as a criticism, just pointing out where there seems to be this blind spot. AFAIK, nothing stops either side from periodically going off on its

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

y, 5 March 2021 at 15:02 To: "TLS@ietf.org" Subject: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections Hello all I've got a question regarding application of TLS 1.3 to protect long lasting connections. Specifically on the trigger to perform a

[TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Hello all I've got a question regarding application of TLS 1.3 to protect long lasting connections. Specifically on the trigger to perform a revocation check for the utilized certificates in the handshake. The background is that for the securing TCP based communication in power system automa