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

[Jonathan Hoyland]

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 makes the system completely brittle if that
certificate gets revoked, expires, or even just becomes unavailable because
of disk failure.
It would be great to see all the potential use cases broken down so the
best solutions can be considered.

Regards,

Jonathan



On Fri, 12 Mar 2021 at 11:00, Fries, Steffen 
wrote:

> 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
> ClientCertificateRequest that the server_name may be provided as extension
> but this may not be sufficient.
>
> Best regards
> Steffen
>
> > -Original Message-
> > From: TLS  On Behalf Of Fries, Steffen (T RDA CST)
> > Sent: Donnerstag, 11. März 2021 13: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 connection at
> any point
> > after the handshake is complete.
> > > I'm not sure what the behaviour is if the certificate itself is
> expired at the time
> > the EA was sent, but valid at the time the connection was established,
> but I'm
> > sure that could be nailed down.
> > > Would something like the client (and equivalently the server)
> requesting an EA
> > every 24 hours and hard failing if it didn't get one meet your needs?
> > It may help here. From an integration standpoint it is important that
> the same
> > certificate would be used with EA as used in the handshake to ensure the
> one
> > used to authenticate in the first place would be verified. That may mean
> that
> > one would have to store the initially used certificate or at least the
> fingerprint or
> > serial number and issuer to be able to request the right one in the
> authenticator
> > request.
> > This would be handled on application layer if I understood it right. As
> the goal
> > would be to have a trigger to verify the certificate against a (new)
> CRL, the
> > approach of having a timer or a trigger by the newly arrived CRL may be
> more
> > suitable. But I will have a closer look.
> >
> > Best regards
> > Steffen
> >
> > > Regards,
> >
> > > Jonathan
> >
> > On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni  ietf-d...@dukhovni.org>
> > wrote:
> > 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
> also use
> > > > DANE TLSA records instead of CRLs, just publish a
> > > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates
> the server's
> > > > public key, and give it a short-enough TTL that it can be replaced
> quickly.
> > > > Presto-magic, no need for OCSP, CRLs, ...
> > >
> > > While this may be a solution in general, it may not fit for power
> systems (like a
> > substation).
> > > The application of DNSSEC or DANE is not very common and may not be
> used.
> > Also due to
> > > Existing deployments, which do not feature these services (yet).
> >
> > I am not trying to suggest that DANE is currently a mainstream option
> > outside of SMTP (primarily in Northern and Central Europe for now, with
> > some signs of life in the USA, Canada and Brazil).  The above was more
> > of an aside for the record.  DANE may be a more realistic choice a few
> > years from now.  DNSSEC adoption is starting to grow faster, and if this
> > continues and accelerates, DANE may become more common, time will tell.
> >
> > Early adopters can of course choose to use it now, but it is far from
> > mainstream today.
> >
> > --
> > Viktor.
> >
> > ___
> > TLS mailing list
> > mailto:TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fries, Steffen]

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 ClientCertificateRequest that the server_name 
may be provided as extension but this may not be sufficient.

Best regards
Steffen

> -Original Message-
> From: TLS  On Behalf Of Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 11. März 2021 13: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 connection at any 
> > point
> after the handshake is complete.
> > I'm not sure what the behaviour is if the certificate itself is expired at 
> > the time
> the EA was sent, but valid at the time the connection was established, but I'm
> sure that could be nailed down.
> > Would something like the client (and equivalently the server) requesting an 
> > EA
> every 24 hours and hard failing if it didn't get one meet your needs?
> It may help here. From an integration standpoint it is important that the same
> certificate would be used with EA as used in the handshake to ensure the one
> used to authenticate in the first place would be verified. That may mean that
> one would have to store the initially used certificate or at least the 
> fingerprint or
> serial number and issuer to be able to request the right one in the 
> authenticator
> request.
> This would be handled on application layer if I understood it right. As the 
> goal
> would be to have a trigger to verify the certificate against a (new) CRL, the
> approach of having a timer or a trigger by the newly arrived CRL may be more
> suitable. But I will have a closer look.
> 
> Best regards
> Steffen
> 
> > Regards,
> 
> > Jonathan
> 
> On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni 
> wrote:
> 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 also use
> > > DANE TLSA records instead of CRLs, just publish a
> > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> > > server's
> > > public key, and give it a short-enough TTL that it can be replaced 
> > > quickly.
> > > Presto-magic, no need for OCSP, CRLs, ...
> >
> > While this may be a solution in general, it may not fit for power systems 
> > (like a
> substation).
> > The application of DNSSEC or DANE is not very common and may not be used.
> Also due to
> > Existing deployments, which do not feature these services (yet).
> 
> I am not trying to suggest that DANE is currently a mainstream option
> outside of SMTP (primarily in Northern and Central Europe for now, with
> some signs of life in the USA, Canada and Brazil).  The above was more
> of an aside for the record.  DANE may be a more realistic choice a few
> years from now.  DNSSEC adoption is starting to grow faster, and if this
> continues and accelerates, DANE may become more common, time will tell.
> 
> Early adopters can of course choose to use it now, but it is far from
> mainstream today.
> 
> --
>     Viktor.
> 
> ___
> TLS mailing list
> mailto:TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fries, Steffen]

> 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 connection at any 
> point after the handshake is complete. 
> I'm not sure what the behaviour is if the certificate itself is expired at 
> the time the EA was sent, but valid at the time the connection was 
> established, but I'm sure that could be nailed down.
> Would something like the client (and equivalently the server) requesting an 
> EA every 24 hours and hard failing if it didn't get one meet your needs?
It may help here. From an integration standpoint it is important that the same 
certificate would be used with EA as used in the handshake to ensure the one 
used to authenticate in the first place would be verified. That may mean that 
one would have to store the initially used certificate or at least the 
fingerprint or serial number and issuer to be able to request the right one in 
the authenticator request. 
This would be handled on application layer if I understood it right. As the 
goal would be to have a trigger to verify the certificate against a (new) CRL, 
the approach of having a timer or a trigger by the newly arrived CRL may be 
more suitable. But I will have a closer look.

Best regards
Steffen

> Regards,

> Jonathan

On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni  
wrote:
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 also use
> > DANE TLSA records instead of CRLs, just publish a
> > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> > server's
> > public key, and give it a short-enough TTL that it can be replaced quickly.
> > Presto-magic, no need for OCSP, CRLs, ...
>
> While this may be a solution in general, it may not fit for power systems 
> (like a substation). 
> The application of DNSSEC or DANE is not very common and may not be used. 
> Also due to 
> Existing deployments, which do not feature these services (yet). 

I am not trying to suggest that DANE is currently a mainstream option
outside of SMTP (primarily in Northern and Central Europe for now, with
some signs of life in the USA, Canada and Brazil).  The above was more
of an aside for the record.  DANE may be a more realistic choice a few
years from now.  DNSSEC adoption is starting to grow faster, and if this
continues and accelerates, DANE may become more common, time will tell.

Early adopters can of course choose to use it now, but it is far from
mainstream today.

-- 
    Viktor.

___
TLS mailing list
mailto:TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jonathan Hoyland]

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 is if the certificate itself is expired at
the time the EA was sent, but valid at the time the connection was
established, but I'm sure that could be nailed down.

Would something like the client (and equivalently the server) requesting an
EA every 24 hours and hard failing if it didn't get one meet your needs?

Regards,

Jonathan

On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni  wrote:

> 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 also
> use
> > > DANE TLSA records instead of CRLs, just publish a
> > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the
> server's
> > > public key, and give it a short-enough TTL that it can be replaced
> quickly.
> > > Presto-magic, no need for OCSP, CRLs, ...
> >
> > While this may be a solution in general, it may not fit for power
> systems (like a substation).
> > The application of DNSSEC or DANE is not very common and may not be
> used. Also due to
> > Existing deployments, which do not feature these services (yet).
>
> I am not trying to suggest that DANE is currently a mainstream option
> outside of SMTP (primarily in Northern and Central Europe for now, with
> some signs of life in the USA, Canada and Brazil).  The above was more
> of an aside for the record.  DANE may be a more realistic choice a few
> years from now.  DNSSEC adoption is starting to grow faster, and if this
> continues and accelerates, DANE may become more common, time will tell.
>
> Early adopters can of course choose to use it now, but it is far from
> mainstream today.
>
> --
> Viktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 also use
> > DANE TLSA records instead of CRLs, just publish a
> > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> > server's
> > public key, and give it a short-enough TTL that it can be replaced quickly.
> > Presto-magic, no need for OCSP, CRLs, ...
>
> While this may be a solution in general, it may not fit for power systems 
> (like a substation). 
> The application of DNSSEC or DANE is not very common and may not be used. 
> Also due to 
> Existing deployments, which do not feature these services (yet). 

I am not trying to suggest that DANE is currently a mainstream option
outside of SMTP (primarily in Northern and Central Europe for now, with
some signs of life in the USA, Canada and Brazil).  The above was more
of an aside for the record.  DANE may be a more realistic choice a few
years from now.  DNSSEC adoption is starting to grow faster, and if this
continues and accelerates, DANE may become more common, time will tell.

Early adopters can of course choose to use it now, but it is far from
mainstream today.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fries, Steffen]

> -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 SessionID
> > lifetime
> > - Regular session key update for the ongoing TLS Session
> > - Trigger to verify the certificates used by both sides on a regular
> >   base, ideally in relation to the update of locally available
> >   revocation information
> >
> > For the latter, the assumption was that some of the processes, when a
> > long term key is compromised, may not be perfectly synchronized,
> > meaning that the entity with a potentially compromised
> > certificate/private key (long term key) is not immediately taken from
> > the network.
> 
> So it sounds like the concern is that the key may have already been
> compromised at the time the session was established, but was not yet published
> on a CRL?  And so you want to keep checking the CRL periodically, in case the
> client is talking to an MiTM attacker, and it isn't too late to undo the 
> damage.
Yes, that would be one scenario. 

> 
> Now of course the client can just check its CRL any time it wants, without
> redoing the handshake.  It typically has (or can arrange to
> retain) the server's certificate chain from the initial handshake.
True, which requires either a timer to do the checks periodically (either using 
CRL or OCSP) or a trigger when a new CRL is locally available.
So I already gathered, that this may be the solution.

> So the only case that comes to mind where a new handshake is needed to
> refresh the certificate validity is with stapled OCSP, where the server is the
> source of the certificate freshness data.
Agree. This would be the case, in which the receiver may have no access to an 
OCSP responder.


> 
> 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 also use
> DANE TLSA records instead of CRLs, just publish a
> "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> server's
> public key, and give it a short-enough TTL that it can be replaced quickly.
> Presto-magic, no need for OCSP, CRLs, ...
While this may be a solution in general, it may not fit for power systems (like 
a substation). 
The application of DNSSEC or DANE is not very common and may not be used. Also 
due to 
Existing deployments, which do not feature these services (yet). 

Regards
Steffen
> 
> --
> Viktor.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 the ongoing TLS Session
> - Trigger to verify the certificates used by both sides on a regular
>   base, ideally in relation to the update of locally available
>   revocation information
> 
> For the latter, the assumption was that some of the processes, when a
> long term key is compromised, may not be perfectly synchronized,
> meaning that the entity with a potentially compromised
> certificate/private key (long term key) is not immediately taken from
> the network.

So it sounds like the concern is that the key may have already been
compromised at the time the session was established, but was not yet
published on a CRL?  And so you want to keep checking the CRL
periodically, in case the client is talking to an MiTM attacker,
and it isn't too late to undo the damage.

Now of course the client can just check its CRL any time it wants,
without redoing the handshake.  It typically has (or can arrange to
retain) the server's certificate chain from the initial handshake.

So the only case that comes to mind where a new handshake is needed to
refresh the certificate validity is with stapled OCSP, where the server
is the source of the certificate freshness data.

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 also use DANE TLSA records instead of CRLs, just publish a
"1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the
server's public key, and give it a short-enough TTL that it can be
replaced quickly.  Presto-magic, no need for OCSP, CRLs, ...

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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 software bits 
is like maintaining hardware blobs.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fries, Steffen]

Hi,

First of all thanks for all the discussion on that question, which is great 
input also to the discussion in IEC. 

> From: TLS  On Behalf Of Hannes Tschofenig
> I think it is useful to start with the problem description.
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 the ongoing TLS Session
- Trigger to verify the certificates used by both sides on a regular base, 
ideally in relation to the update of locally available revocation information

For the latter, the assumption was that some of the processes, when a long term 
key is compromised, may not be perfectly synchronized, meaning that  the entity 
with a potentially compromised certificate/private key (long term key) is not 
immediately taken from the network. If the certificate is put onto a CRL , the 
RP would realize this during the next complete handshake and tear down the 
connection. An alternative of this could indeed be to utilize an external 
trigger like whenever the CRL is refreshed (which should happen every 24 
hours), the certificates of ongoing connections are validated regarding their 
status. As this is independent of TLS, it would work also with TLS 1.3.

By comparing, what has been used in TLS 1.2 we simply stumbled about the fact 
that the trigger to perform the revocation check is no longer available for 
both sides, client and server. As said, the client could be authenticated using 
post authentication but not the server. This would mean to solve the problem of 
identifying a revoked certificate in an ongoing session could be done 
externally of TLS but the result would be fed back to TLS, if a connection 
needs to be closed due to a revoked certificate. 

Regards
Steffen



> 
> 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 used in the key hierarchy,
> * keys used for protecting the application traffic
> 
> Additionally, you could also consider the case that the trust anchor store 
> gets
> compromised.
> 
> In any case, you seem to be concerned about the leakage of long-term keys (at
> least that's what I get from the email thread).
> 
> If your long-term keys got compromised then you have a serious problem. Re-
> running even the full handshake will not indicate problem. It will just work 
> fine.
> 
> You will somehow have to find out that these long-term keys have been leaked,
> which will not be easy. Then, you need to isolate the endpoints using those
> compromised keys and reprovision new keys to them. You might want to
> terminate ongoing connections as well. Since you will often not know what
> exactly has been compromised (at least not quickly enough), you might need to
> take a range of steps to re-set it to a known good state (such as doing a
> firmware update, in case of an IoT device).
> 
> Many of these aspects are, however, outside the scope of TLS itself.
> 
> Could you elaborate on the threats you are trying to address?
> 
> Ciao
> Hannes
> 
> *: Often a device has more than one long-term key pair (used for different
> purposes). 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 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 protocol to support re-authenticating the server to the
> > >client as well.
> >
> > I think the current Post-Handshake authentication is not really
> > suitable for long-term connections. It assures that the other party is
> > still alive but it does not shut out any other third parties with
> > access to application_traffic_secret_N. Such parties may have gotten
> > the key with or without collaboration with one of the nodes.
> 
> We assume local security, so the only way the TLS keys could have leaked to
> third parties is if either a) the local security assumption fails, in which 
> case you
> have bigger problems, or b) the cryptographic security of TLS itself failed, 
> in
> which case you have bigger problems, or c) you're exceeding usage lim

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

[Olle E. Johansson]

> 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.
> 
> Many people expect this, but I don't think there's universal agreement
> that it's the right behavior.  The divide between authentication and
> authorization that (IIRC) Viktor called out is relevant here -- the
> initial key exchange and, to large extent, authentication, do not suddenly
> become invalid upon credential expiry, but any authorization derived from
> the credential might.  So it seems that whether the session should terminate
> at the certificate expiry time is rather dependent on what the session is
> being used for.

Maybe there’s a need for a BCP here. It is unclear to me how to apply these
discussions to SIP and we have a few points worth noting from this dicussion.

- Describe the dependencies in Benjamins statement above and how
  they apply to protocols
- Open a new session before deciding to close the old one
- Application timers to cert expiry

Seems like something for UTA to me.

/O
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> 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 well, and should outlast
the lifetime of the library...  Lord help civilization, if it
is still using C for critical software in ~100 years.

(Before that, some older certs used in the build had in fact expired).

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

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 that you don't have to worry about it.  14 January 2038
was one I've seen used, but that was at a point when 2038 was still 20+ years
away and the equipment might have been expected to be EOL'd by then.  Not sure
what's being used now that the time to Y2038 is a lot less than the lifetime
of the equipment.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 contrasting against something other
> than that...

Correct, I'm contrasting with N-year certs for N <= 30 (longer if
expected lifetime of device is larger, e.g. switches in the NYC subway
system, though their actual deployed lifetime has well exceeded anything
"planned").  In other words, with certs that will actually need to be
replaced now and then.

Peter's "never" scenario has its place, it's the cases that fall between
"never" and short-lived that I find suboptimal.  Do it well, or don't
do it at all.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

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, Mar 08, 2021 at 03:21:22AM +, Peter Gutmann wrote:
> 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 day: Will the cert renewal work, or will it fail for
> some reason?  Let's spin the cylinder and see if this is the day our grid goes
> down.
> 
> Even if you somehow create a 100% successful magical process for replacing
> certs that never ever fails, you're now introduced another possible failure
> situation, with certs changing constantly there's a chance that something that
> relies on them can't handle a new cert, for example because an issuing CA has
> renewed as well or something similar.
> 
> It's just building in more and more opportunities for failure from a mechanism
> that's supposed to be making your infrastructure more robust, not less.
> 
> Peter.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!GaaCbhUsGvSdgqi6crkwhODrap4fYzdX6pgIOq4zyhG9nX88r3GTRHuFOsw1ew$
>  

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

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 day: Will the cert renewal work, or will it fail for
some reason?  Let's spin the cylinder and see if this is the day our grid goes
down.

Even if you somehow create a 100% successful magical process for replacing
certs that never ever fails, you're now introduced another possible failure
situation, with certs changing constantly there's a chance that something that
relies on them can't handle a new cert, for example because an issuing CA has
renewed as well or something similar.

It's just building in more and more opportunities for failure from a mechanism
that's supposed to be making your infrastructure more robust, not less.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>> 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* environments, including yours. I've 
some where it would work too.
Unfortunately, I *also* have plenty where it cannot work.

>. . . . .  It's reasonable to suspect that even someone I
>know and I know is smart may not have all the relevant details.

My point is - we *both* may not have all the relevant details about each 
other's environments. Which is why I absolutely disagreed with your "this 
solution works" statement. 

>Besides, your
>
>>>> With all due respect, *absolutely not*.
>
>followed by no explanation, seems like much more likely to be intended
>to cause offense than "I'm not sure what it is you're imagining"
>followed by an explanation.  I took it at face value however, and
>followed up.  What a crime.

;-) OK, touche.

 


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 works.
> 
> With all due respect, *absolutely not*.

Well, it works when fragile manual processes (likely to be entirely
forgotten until things break) that are almost good enough to get by
on every year or two, become plainly unreasonable when exercised every
month or every week.  In other words, short-lived certs force:

- Active monitoring

- Automation of preëmptive renewals (with sufficient time
  to retry more than once on failure).

The tools to make this possible need to be available before we ask
people to invent this for themselves, but the effect on operational
discipline is real.

If either monitoring or automation are skipped, then sure, you have
a recipe for failure.  But if the signal is not ignored, and proper
automation is applied, reliability actually improves.

I see this effect in the stability of DANE deployments at domains that
are using Let's Encrypt with "mailinabox.email" which automates the
lifecycle including TLSA record updates, ..., v.s. DYI MTAs with certs
are only renewed every year or two (often wildcard shared by all MTAs
for the domain).

The mailinabox systems do a far better job of keeping their certs valid.
Despite the fact that they make up 1/3 of the deployed MXs, they make up
a much smaller fraction of the domains I ping when the DANE survey finds
poorly managed cert chains that fail authentication.

Does this mean that a nuclear reactor's cooling system should shut down
when a cert expires?  Probably not, ... but if one is going to manage
certificates that do expire, my bet is that the short-lived ones are
better managed, and will exhibit fewer total hours of downtime, despite
the more frequent expirations.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 spectrum of use cases. Specifically, they do not
> match *my* operating environment.
> 
> 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.

> And let's dispose with the "you're imagining" crap, shall we? I think
> we've known each other long enough to be more polite. Otherwise, suit
> yourself.

No offense was meant.  It's reasonable to suspect that even someone I
know and I know is smart may not have all the relevant details.

Besides, your

>>> With all due respect, *absolutely not*.

followed by no explanation, seems like much more likely to be intended
to cause offense than "I'm not sure what it is you're imagining"
followed by an explanation.  I took it at face value however, and
followed up.  What a crime.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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

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 spectrum of use cases. Specifically, they do not match *my* operating 
environment.

You may claim that my environment does not represent yours. Sure, fine. 
Similarly, *yours does NOT represent mine*.

And let's dispose with the "you're imagining" crap, shall we? I think we've 
known each other long enough to be more polite. Otherwise, suit yourself.


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 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?
> >
> >Yes.  Exactly.  It's a human factors problem.  And this solution works.
> 
> With all due respect, *absolutely not*.

I'm not sure what it is you're imagining.  What actually happens in the
cases I'm familiar with is that there is one very long-lived root of
trust (e.g., an endorsement key in a TPM) credential that is used to get
all the short-lived credentials, and this is fully automated.  In some
cases the short-lived credentials are obtained by apps using the host's
credentials, and then only when the application is running but still,
periodically.

The benefits of this arrangement are: a) no need for revocation of
short-lived credentials, b) no need to worry about credential
expiration (because the process is automated).

I've also seen environments with very long-lived credentials where
someone has to remember to renew them.  I've seen lots of failures in
those, but none in the case described above.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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.
>> 
>> 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*.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 the renewal fails, you get hundreds of them?

Yes.  Exactly.  It's a human factors problem.  And this solution works.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Graham Bartlett]

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. Normally if the device is lost/stolen it's gone and assumed
compromised. You wont be issuing it a new certificate for that device.

cheers

On Sun, Mar 7, 2021 at 3:50 PM Hannes Tschofenig 
wrote:

> 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 connections? You could
> terminate the connection of the device with the compromised certificate.
>
>
>
> In your IPSec VPN scenario, how do you get a new certificate to the
> compromised device?
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS  *On Behalf Of * Graham Bartlett
> *Sent:* Sunday, 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 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 phones,
> laptops, IoT devices etc)
>
> A remote device is compromised, on the gateway there could be 1000s of
> devices connected.
>
> I've found that most vendor solutions aren't geared up for an admin to
> easily determine the compromised device and prevent this reconnecting. Most
> organisations have a disconnect between the SOC, PKI team and the team that
> manages the remote access gateway, getting a process that'll involve all 3
> teams usually doesn't work.
>
>
>
> 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.
>
>
>
> I'm not as familiar with TLS as I am IPsec, but hope that this explains
> a scenario where I feel re-authentication would be very valuable.
>
>
>
> cheers
>
>
>
> On Sun, Mar 7, 2021 at 9:58 AM 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 the renewal fails, you get hundreds of them?
>
> Peter.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

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 agreement
that it's the right behavior.  The divide between authentication and
authorization that (IIRC) Viktor called out is relevant here -- the
initial key exchange and, to large extent, authentication, do not suddenly
become invalid upon credential expiry, but any authorization derived from
the credential might.  So it seems that whether the session should terminate
at the certificate expiry time is rather dependent on what the session is
being used for.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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 implementation would pull the session down once 
the certificate expires, so the session only lasts for the lifetime of the 
certificate.

Agree. I guess this case rarely happens because short-lived certificates are 
not so short lived after all.



  *   Revocation:  The RP* can check this whenever it desires.  If one has 
designed a long lived connection, then the RP needs to handle it.  Does TLS, 
the protocol need to handle it?  Don't know.

I don’t see a need for TLS to do something.


  *   Short lived certificates:  I think these are a good idea.  And if one 
does this, rekey/renewal early and often is the way to prevent breakage.  
IMHO

I would imagine that the change of certificate will trigger a new handshake. If 
only the client-side certificate changes on a regular basis then I could 
imagine the Post handshake authentication to be quite useful.

Ciao
Hannes

On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley 
mailto:debcool...@gmail.com>> wrote:
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 addressing?  I suspect not.

Revocation:  The RP* can check this whenever it desires.  If one has designed a 
long lived connection, then the RP needs to handle it.  Does TLS, the protocol 
need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does 
this, rekey/renewal early and often is the way to prevent breakage.  IMHO




On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett 
mailto:graham.i...@gmail.com>> wrote:
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 phones, laptops, IoT 
devices etc)
A remote device is compromised, on the gateway there could be 1000s of devices 
connected.
I've found that most vendor solutions aren't geared up for an admin to easily 
determine the compromised device and prevent this reconnecting. Most 
organisations have a disconnect between the SOC, PKI team and the team that 
manages the remote access gateway, getting a process that'll involve all 3 
teams usually doesn't work.

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.

I'm not as familiar with TLS as I am IPsec, but hope that this explains a 
scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nico Williams mailto:n...@cryptonector.com>> 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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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 connections? You could terminate 
the connection of the device with the compromised certificate.

In your IPSec VPN scenario, how do you get a new certificate to the compromised 
device?

Ciao
Hannes

From: TLS  On Behalf Of Graham Bartlett
Sent: Sunday, 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 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 phones, laptops, IoT 
devices etc)
A remote device is compromised, on the gateway there could be 1000s of devices 
connected.
I've found that most vendor solutions aren't geared up for an admin to easily 
determine the compromised device and prevent this reconnecting. Most 
organisations have a disconnect between the SOC, PKI team and the team that 
manages the remote access gateway, getting a process that'll involve all 3 
teams usually doesn't work.

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.

I'm not as familiar with TLS as I am IPsec, but hope that this explains a 
scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nico Williams mailto:n...@cryptonector.com>> 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.


___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Graham Bartlett]

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 down once
the certificate expires, so the session only lasts for the lifetime of the
certificate.

I know that some IPsec implementation does this.

cheers



On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley  wrote:

> 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 addressing?  I suspect
> not.
>
> Revocation:  The RP* can check this whenever it desires.  If one has
> designed a long lived connection, then the RP needs to handle it.  Does
> TLS, the protocol need to handle it?  Don't know.
>
> Short lived certificates:  I think these are a good idea.  And if one does
> this, rekey/renewal early and often is the way to prevent breakage.
> IMHO
>
>
>
>
> On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett 
> wrote:
>
>> 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 phones,
>> laptops, IoT devices etc)
>> A remote device is compromised, on the gateway there could be 1000s of
>> devices connected.
>> I've found that most vendor solutions aren't geared up for an admin to
>> easily determine the compromised device and prevent this reconnecting. Most
>> organisations have a disconnect between the SOC, PKI team and the team that
>> manages the remote access gateway, getting a process that'll involve all 3
>> teams usually doesn't work.
>>
>> 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.
>>
>> I'm not as familiar with TLS as I am IPsec, but hope that this explains
>> a scenario where I feel re-authentication would be very valuable.
>>
>> cheers
>>
>> On Sun, Mar 7, 2021 at 9:58 AM 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 the renewal fails, you get hundreds of them?
>>>
>>> Peter.
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deb Cooley]

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 addressing?  I suspect
not.

Revocation:  The RP* can check this whenever it desires.  If one has
designed a long lived connection, then the RP needs to handle it.  Does
TLS, the protocol need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does
this, rekey/renewal early and often is the way to prevent breakage.
IMHO




On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett 
wrote:

> 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 phones,
> laptops, IoT devices etc)
> A remote device is compromised, on the gateway there could be 1000s of
> devices connected.
> I've found that most vendor solutions aren't geared up for an admin to
> easily determine the compromised device and prevent this reconnecting. Most
> organisations have a disconnect between the SOC, PKI team and the team that
> manages the remote access gateway, getting a process that'll involve all 3
> teams usually doesn't work.
>
> 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.
>
> I'm not as familiar with TLS as I am IPsec, but hope that this explains
> a scenario where I feel re-authentication would be very valuable.
>
> cheers
>
> On Sun, Mar 7, 2021 at 9:58 AM 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 the renewal fails, you get hundreds of them?
>>
>> Peter.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Graham Bartlett]

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 phones, laptops,
IoT devices etc)
A remote device is compromised, on the gateway there could be 1000s of
devices connected.
I've found that most vendor solutions aren't geared up for an admin to
easily determine the compromised device and prevent this reconnecting. Most
organisations have a disconnect between the SOC, PKI team and the team that
manages the remote access gateway, getting a process that'll involve all 3
teams usually doesn't work.

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.

I'm not as familiar with TLS as I am IPsec, but hope that this explains
a scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM 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 the renewal fails, you get hundreds of them?
>
> Peter.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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 used in the key hierarchy,
* keys used for protecting the application traffic

Additionally, you could also consider the case that the trust anchor store gets 
compromised.

In any case, you seem to be concerned about the leakage of long-term keys (at 
least that's what I get from the email thread).

If your long-term keys got compromised then you have a serious problem. 
Re-running even the full handshake will not indicate problem. It will just work 
fine.

You will somehow have to find out that these long-term keys have been leaked, 
which will not be easy. Then, you need to isolate the endpoints using those 
compromised keys and reprovision new keys to them. You might want to terminate 
ongoing connections as well. Since you will often not know what exactly has 
been compromised (at least not quickly enough), you might need to take a range 
of steps to re-set it to a known good state (such as doing a firmware update, 
in case of an IoT device).

Many of these aspects are, however, outside the scope of TLS itself.

Could you elaborate on the threats you are trying to address?

Ciao
Hannes

*: Often a device has more than one long-term key pair (used for different 
purposes). 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 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 protocol to support re-authenticating the server to the
> >client as well.
>
> I think the current Post-Handshake authentication is not really
> suitable for long-term connections. It assures that the other party is
> still alive but it does not shut out any other third parties with
> access to application_traffic_secret_N. Such parties may have gotten
> the key with or without collaboration with one of the nodes.

We assume local security, so the only way the TLS keys could have leaked to 
third parties is if either a) the local security assumption fails, in which 
case you have bigger problems, or b) the cryptographic security of TLS itself 
failed, in which case you have bigger problems, or c) you're exceeding usage 
limits on a symmetric cipher.

Changing session keys wouldn't help you in cases (a) or (b).

I think the only interesting case is (c).  If you're using a 128-bit block 
cipher, you're not in case (c) as you'd have to transfer something like 2PB 
before you exceed AES key usage limits.

At some point you have to be prepared to reconnect.  Application protocols that 
work like BGP (destroy the world on RST) simply need to be fixed to not do that.

> Agree that the negotiation part of renegotiation should not come back.
> Below is a sketch of what I think would be needed Post-Handshake for

That's essentially renego-lite.  Note that there's protocol timing trickiness 
in getting this right.  SSHv2, which does have proper re-keying, has experience 
with that.

> DTLS/SCTP with DTLS 1.3:

What's special about DTLS vs. TLS?  Why should one get this but not the other?

Nico
--

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 a clear threat this addresses.

I agree.  There's no need.

> However, it is possible that there actually exist use-cases where this
> makes some sense, and that case, If connection lifetimes would otherwise
> last unacceptably long, make a new connection, and close the old (in
> some appropriate order).

Yeah, but then, in 2021 BGP still depends on long-lived connections...

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 be
> taken offline due to a cert someone forgot to renew.

When expirations are short, you will not forget to renew.  That's part
of the point of short-lived certificates.

Set lifetime long enough that you have enough time to renew in most
outage scenarios (i.e., pick N days such that you expect no outage will
take longer than that to resolve, and be conservative for things like
power grids), but short enough that you simply must automate renewal.

> In terms of CRL updates the situation is similar, the spec may say you need to
> check once every X time interval but in practice you forget to perform the
> check in case it takes your grid offline.  Or set a flag saying "cert revoked"
> and continue anyway, I've seen both.  [...]

Sure.

>   [...].  The 24-hour thing sounds like someone's
> checkbox requirement rather than anything practically useful, or usable.

Short-lived certs are a "checkbox requirement" where the theory is that
if it's short enough (doesn't have to be 1 day) then you will be forced
to automate renewal, so you'll never fail to renew.

It's about improving ops, not so much about security.

That it also helps with revocation -so you don't have to bother with it-
is also an ops (and dev) benefit.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

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 updates the situation is similar, the spec may say you need to
check once every X time interval but in practice you forget to perform the
check in case it takes your grid offline.  Or set a flag saying "cert revoked"
and continue anyway, I've seen both.  The 24-hour thing sounds like someone's
checkbox requirement rather than anything practically useful, or usable.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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. Does that happen so often that we need protocol machinery other than
> > just tearing down the connection and starting over?
> 
> Probably not.  I've seen 5 day server certificates in use.  And while
> it's possible to keep connections open that long or longer, as Viktor
> points out, if you do keep a connection open and active longer than that
> and the server is still there (i.e., some node has its address and the
> connection's traffic keys), then that's probably good enough evidence
> that the server is still valid and still would have a fresh cert if you
> were to reconnect to it.

In general, I think breaking an established connection just to
reauthenticate the server only needlessly risks occasionally finding an
expired certificate that someone forgot to renew.  Server certificates
good at time of connection establishment should, barring extraordinary
circumstances be good for the life of the connection.

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 a clear threat this addresses.

However, it is possible that there actually exist use-cases where this
makes some sense, and that case, If connection lifetimes would otherwise
last unacceptably long, make a new connection, and close the old (in
some appropriate order).

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 tearing down the connection and starting over?

Probably not.  I've seen 5 day server certificates in use.  And while
it's possible to keep connections open that long or longer, as Viktor
points out, if you do keep a connection open and active longer than that
and the server is still there (i.e., some node has its address and the
connection's traffic keys), then that's probably good enough evidence
that the server is still valid and still would have a fresh cert if you
were to reconnect to it.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 that offers forward-secrecy) is not compromised if later the
> signing keys of one of the parties is compromised.  So there is no need
> to check CRLs or renegotiate to just to maintain a secure connection.
> 
> On the server side, if the client's identity is used as a key into an
> authorisation table, one just needs to periodically (or even at each
> logical request) to revalidate the client's authorisation, there is
> generally no need to "re-authenticate" the client.

Yes, authorization is probably getting conflated here.  Suppose the
authorization is local and slow to be updated.  E.g., when an employee
separates from their employer, local authorization may not get updated
with much celerity, so if the subject's certificate expires sooner than
local authz could get updated, then re-authenticating the subject would
help.  (This assumes credentials do expire with celerity, but that is
good practice.)

That might seem weird, but consider a stateful file server, something
like NFSv4, say, and suppose that a client connects, authenticates,
successfully opens some file to which they were authorized and... maybe
now they can use that open file reference forever, much as one expects
in POSIX.  Except NFSv4 will require reauthentication though, so the
client cannot in fact use that open file reference forever.  But the
NFSv4 server (I think) will not re-evaluate ACLs for existing open file
handles as the ACLs change (per POSIX).  Re-authenticating the client
does serve something of an authorization purpose in the file server
example.  (Of course, a file server doesn't need to hew to POSIX on
this, and could re-evaluate ACLs for open file references, and/or it
could have a revocation feature like BSD's revoke(2) that lets users
forcibly close open file references.)

> If there is a concern that a server may somehow mid-session cease to be
> [...]

+1

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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_ to the server, it should be trivial to
> > >extend the protocol to support re-authenticating the server to the
> > >client as well.
> >
> > I think the current Post-Handshake authentication is not really suitable
> for long-term connections. It assures that the other party is still alive
> but it does not shut out any other third parties with access to
> application_traffic_secret_N. Such parties may have gotten the key with or
> without collaboration with one of the nodes.
>
> The application traffic secret N+1 and the security of the
> authentication is unaffected by compromise of key N AFAIK. I'm not
> sure what property you want here that is stronger.
>

It seems to me that there are potentially two distinct properties here:

1. Post-Compromise Security in the case where the traffic keys were leaked
2. Re-authentication of the server.

Id like to understand the second use case better.

Assume that Alice connects to Bob and Bob authenticates with certificate X
which is valid at the time. As long as Bob's certificate remains valid, I'm
not sure that any new TLS behavior is required. I.e., Alice is free to
re-validate the certificate (i.e., check for revocation) but it's not clear
to me that as long as it is valid, it is necessary for Bob to re-prove
possession of the key. The primary threat that the defends against is an
un-detected temporary misuse of Bob's key at a prior time, which seems
distinct from future compromise. So, it seems like you can just re-validate
the key and then abort the connection if that fails, as Rich Salz suggests.

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 tearing down the connection and starting over?

-Ekr

[0] Potentially, with a different key, though just assuming that because
the key is the same you can transplant the new identity on seems dangerous,
as we usually want to sign over the identities.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

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 support re-authenticating the server to the
> >client as well.
>
> I think the current Post-Handshake authentication is not really suitable for 
> long-term connections. It assures that the other party is still alive but it 
> does not shut out any other third parties with access to 
> application_traffic_secret_N. Such parties may have gotten the key with or 
> without collaboration with one of the nodes.

The application traffic secret N+1 and the security of the
authentication is unaffected by compromise of key N AFAIK. I'm not
sure what property you want here that is stronger.
Sincerely,
Watson Ladd

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 protocol to support re-authenticating the server to the
> >client as well.
> 
> I think the current Post-Handshake authentication is not really
> suitable for long-term connections. It assures that the other party is
> still alive but it does not shut out any other third parties with
> access to application_traffic_secret_N. Such parties may have gotten
> the key with or without collaboration with one of the nodes.

We assume local security, so the only way the TLS keys could have leaked
to third parties is if either a) the local security assumption fails, in
which case you have bigger problems, or b) the cryptographic security of
TLS itself failed, in which case you have bigger problems, or c) you're
exceeding usage limits on a symmetric cipher.

Changing session keys wouldn't help you in cases (a) or (b).

I think the only interesting case is (c).  If you're using a 128-bit
block cipher, you're not in case (c) as you'd have to transfer something
like 2PB before you exceed AES key usage limits.

At some point you have to be prepared to reconnect.  Application
protocols that work like BGP (destroy the world on RST) simply need
to be fixed to not do that.

> Agree that the negotiation part of renegotiation should not come back.
> Below is a sketch of what I think would be needed Post-Handshake for

That's essentially renego-lite.  Note that there's protocol timing
trickiness in getting this right.  SSHv2, which does have proper
re-keying, has experience with that.

> DTLS/SCTP with DTLS 1.3:

What's special about DTLS vs. TLS?  Why should one get this but not the
other?

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

>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 support re-authenticating the server to the
>client as well.

I think the current Post-Handshake authentication is not really suitable for 
long-term connections. It assures that the other party is still alive but it 
does not shut out any other third parties with access to 
application_traffic_secret_N. Such parties may have gotten the key with or 
without collaboration with one of the nodes.

Agree that the negotiation part of renegotiation should not come back. Below is 
a sketch of what I think would be needed Post-Handshake for DTLS/SCTP with DTLS 
1.3:

   {KeyShareEntry} >
  {KeyShareEntry}
  {CertificateVerify}  
   <   {Finished}  
   {CertificateVerify}
   {Finished}  >


   Derive-Secret( ... ) = exporter_secret_N

Cheers,
John

-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: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 certificates in the handshake. 

You can perform OCSP or CRL checks on the RPs at any time.  You don't
need a protocol trigger for it.  You can use a timer.

The issue is that the EE certificate (or intermediates in the chain
perhaps) could expire or be replaced before the connection ends, and
then you might want the EE to present a new certificate and, if for a
new key, then also a proof of possession.  One could use session
renegotiation back when it existed, but it does not now.

> > Hence the question if there is a feature in TLS 1.3, which would
> > provide the functionality to invoke a mutual certificate based
> > authentication.

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 support re-authenticating the server to the
client as well.

Authenticating the client to the server and vice-versa would be
independent, at least when using certificates, though not so much when
using PSK.  Each relying party would send a CertificateRequest message
on a timer based on local configuration of certificate freshness policy
and/or the peer's certificate's expiration time, or whatever you like.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 for the securing TCP based communication in
> power system automation we defined the application of TLS in IEC
> 62351-3. The document specifies how to use TLS v1.2 in this
> environment. As some of the connections are rather long lasting
> connections, the document defines the usage of TLS session
> renegotiation at least every 24 hours to update the session key
> material on one hand and to enforce the certificate verification from
> both sides (TLS is always used with mutual authentication) including
> the revocation check. The 24 hours were motivated by an expected CRL
> update once a day. 

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 that offers forward-secrecy) is not compromised if later the
signing keys of one of the parties is compromised.  So there is no need
to check CRLs or renegotiate to just to maintain a secure connection.

On the server side, if the client's identity is used as a key into an
authorisation table, one just needs to periodically (or even at each
logical request) to revalidate the client's authorisation, there is
generally no need to "re-authenticate" the client.

If the client is presenting bearer-tokens for entitlement, the client
may periodically need to obtain fresh tokens.

If there is a concern that a server may somehow mid-session cease to be
a legitimate application endpoint for clients that are still connected
to it, and an expectation that timely CRLs and periodic revalidation
of the server certificate would help to avoid that, then perhaps
something should be done.

This feels to me like rather a very distant risk.  When a server is
taken out of rotation, the operator should typically terminate all
client connections at that time.  How often would one expect to
lose operational control of a running server, such that the only
way to protect active clients is via certificate revocation, with
clients finding out soon enough for this to be useful?

If loss of operational control of servers is a real concern, then I
guess clients should avoid long-lived sessions, and open new connections
frequently, limiting connection reuse and TLS session resumption to just
minutes (just to amortise the cost of the initial handshake over a short
sequence of back-to-back requests).

Once there's a new TLS session every ~5 minutes, there's no need for
CRLs, renegotiation, ... but a quick sequence of requests is still
handled efficiently.

So, in summary, avoid CRLs, OCSP, ... they're obsolete crutches.  Use
short-lived certificates (possibly just days or hours), reconnect often
if that's appropriate.  Demand fresh authorisation tokens from clients
if authorisation is encoded in the tokens, rather than checked out
of band by the server on a request-by-request basis.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

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 certificates in the handshake. 

You can perform OCSP or CRL checks on the RPs at any time.  You don't
need a protocol trigger for it.  You can use a timer.

The issue is that the EE certificate (or intermediates in the chain
perhaps) could expire or be replaced before the connection ends, and
then you might want the EE to present a new certificate and, if for a
new key, then also a proof of possession.  One could use session
renegotiation back when it existed, but it does not now.

> > Hence the question if there is a feature in TLS 1.3, which would
> > provide the functionality to invoke a mutual certificate based
> > authentication.

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 support re-authenticating the server to the
client as well.

Authenticating the client to the server and vice-versa would be
independent, at least when using certificates, though not so much when
using PSK.  Each relying party would send a CertificateRequest message
on a timer based on local configuration of certificate freshness policy
and/or the peer's certificate's expiration time, or whatever you like.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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 own to 
verify the peer identity and then sending an alert to shut things down.  That 
might not scale well, and some kind of extension that allows both sides to send 
updated status information might be useful and I would support that. (Peter 
Gutman, you still around? :)
 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

Hi,

I asked a very similar question a couple of weeks ago. Good to know that other 
people have similar problems.
https://mailarchive.ietf.org/arch/msg/tls/bo-_9gbNqNAlyzs2Opv16hLwt2k/

Cheers,
John


-Original Message-
From: TLS  on behalf of "Fries, Steffen" 

Date: Friday, 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 revocation check for the 
utilized certificates in the handshake. 

The background is that for the securing TCP based communication in power system 
automation we defined the application of TLS in IEC 62351-3. The document 
specifies how to use TLS v1.2 in this environment. As some of the connections 
are rather long lasting connections, the document defines the usage of TLS 
session renegotiation at least every 24 hours to update the session key 
material on one hand and to enforce the certificate verification from both 
sides (TLS is always used with mutual authentication) including the revocation 
check. The 24 hours were motivated by an expected CRL update once a day. 

As TLS 1.3 is available the consequent next step is the consideration also for 
power system automation. In TLS 1.3 session renegotiation is not available 
anymore. The session key update can easily be addressed by the post-handshake 
messages. For performing a certificate based authentication during the session 
I understood one could use the post-handshake authentication approach. But this 
seems to be available only for a client side authentication. Is there any 
option in TLS to also enforce a server side authentication during an ongoing 
session?  Again, the reason for a certificate based authentication is to have a 
trigger for the revocation check of the certificates used in the initial 
handshake. If post-handshake certificate based authentication is not supported 
in TLS 1.3, it would require to have a separate mechanism/process that checks 
the revocation state of the certificates utilized in the initial handshake. 

Hence the question if there is a feature in TLS 1.3, which would provide the 
functionality to invoke a mutual certificate based authentication.

Best regards
Steffen

--
Steffen Fries
Siemens AG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fries, Steffen]

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 
automation we defined the application of TLS in IEC 62351-3. The document 
specifies how to use TLS v1.2 in this environment. As some of the connections 
are rather long lasting connections, the document defines the usage of TLS 
session renegotiation at least every 24 hours to update the session key 
material on one hand and to enforce the certificate verification from both 
sides (TLS is always used with mutual authentication) including the revocation 
check. The 24 hours were motivated by an expected CRL update once a day. 

As TLS 1.3 is available the consequent next step is the consideration also for 
power system automation. In TLS 1.3 session renegotiation is not available 
anymore. The session key update can easily be addressed by the post-handshake 
messages. For performing a certificate based authentication during the session 
I understood one could use the post-handshake authentication approach. But this 
seems to be available only for a client side authentication. Is there any 
option in TLS to also enforce a server side authentication during an ongoing 
session?  Again, the reason for a certificate based authentication is to have a 
trigger for the revocation check of the certificates used in the initial 
handshake. If post-handshake certificate based authentication is not supported 
in TLS 1.3, it would require to have a separate mechanism/process that checks 
the revocation state of the certificates utilized in the initial handshake. 

Hence the question if there is a feature in TLS 1.3, which would provide the 
functionality to invoke a mutual certificate based authentication.

Best regards
Steffen

--
Steffen Fries
Siemens AG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls