> On Feb 21, 2018, at 2:21 PM, Paul Wouters <p...@nohats.ca> wrote:
>
>> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is still valid
>> (say the smaller of some refresh time or 50% of TTL has expired).
>> That way, for a client that keeps communicating regularly may be
>> (partially) protected against downgrades. Perhaps it is too late
>> to make such a change at this stage in the document's life-cycle.
>
> Is it customary for TLS clients that do PKIX validation to check the
> certificate expiry for long lived TLS connections?
The text you're responding to is NOT about long-lived TLS connections,
rather it addresses the case where the client makes repeated connections
frequently enough to benefit from caching previously obtained TLSA
records for verifying future connections. In that case it makes sense
to "refresh" the TLSA records (include the extension in a new request)
even before the previously cached data has expired.
> I assumed most TLS clients verification is done at the start of the
> connection only and the connection is then deemed verified until it
> closes - irrespective of the signature lifetimes of the certificate?
Correct, but not applicable to the topic at hand.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
