skip to content

How would you choose and stage a minimum TLS version floor across a metering fleet you cannot upgrade all at once?

level: principalimportance: should knowfreq 40%

answer

  1. measure before you enforce
  2. the population is set by check-in cadence
  3. report-only first, then per segment
  4. refusal is a fatal alert, then silence
  5. exception scoped and dated, never global

basics

~20 s

Measure before enforcing: record the version every peer actually negotiates over a full check-in cycle, take TLS 1.2 as the deprecation baseline and prefer 1.3, run the floor in report-only first, then raise it population by population with a separately scoped, time-boxed exception.

solid answer

~50 s

A floor is a decision about which peers you are prepared to refuse, so the input is evidence, not a configuration file. Collect the version actually negotiated per peer identity over a full check-in cycle - a device that reports monthly appears in no weekly sample. Use the published deprecation as the baseline: RFC 8996 deprecates TLS 1.0, TLS 1.1 and DTLS 1.0, which makes TLS 1.2 the target floor with TLS 1.3 preferred where both ends can reach it. Then stage it: run the floor in report-only so refusals are counted but not applied, raise it for one population at a time, and give whatever is left a separately scoped endpoint with its own lower floor, its own list of permitted peers and an end date - never a global relaxation. Refusal is abrupt: the peer gets a fatal `protocol_version(70)` alert and a closed connection, and cannot report the loss over the channel it just lost.

code

pseudocode · 11 lines
pseudocode
on ClientHello from peer:
    offered = supported_versions list, or legacy_version if absent
    best = highest version in offered that this concentrator enables

    if best is none or best is below floor:
        if enforcing for this peer's population:
            send fatal alert protocol_version(70)
            abort
        record would_refuse, peer_id, best, timestamp

    continue the handshake with best

go deeper

for a junior

Recall that refusing an old version is an all-or-nothing outcome for the peer: it either negotiates something at or above the floor, or it gets no connection at all.

for a middle

Explain the mechanics of a refusal - no common version means a fatal protocol_version(70) alert and a closed connection - and that the deprecation baseline puts the target floor at TLS 1.2.

for a senior

Show the staging you would actually run: negotiated-version telemetry per peer across a full check-in cycle, a report-only phase that names the devices, then enforcement per population with the missing-check-in alarm as the signal.

for a principal

Own the trade: how much of the estate you are prepared to cut off and on what date, how the exception is bounded so it cannot become permanent, and who holds the replacement budget for what the floor strands.

## The decision you are actually making A version floor is not a security setting you turn on; it is a statement about which peers you will stop talking to. In a concentrator serving meters installed over fifteen years, the population on the other side is fixed hardware on long replacement cycles, and a refusal is silent from its side. Everything below follows from that asymmetry. ## Step 1 - measure what is negotiated, not what is configured The inventory that matters is the version each peer *actually ends up on*, recorded per peer identity at the end of each handshake. - A configuration audit tells you what each end could do in principle; the negotiated version tells you what it does. - The observation window is set by check-in cadence, not by traffic volume. A device that reports monthly, or only on a threshold crossing, is invisible in a week's data - and a floor validated against a week refuses a segment nobody counted. - Record first-seen and last-seen per peer, so a population that has already gone quiet is not mistaken for one that would be refused. - Count peers, not connections. A handful of chatty devices will otherwise dominate any percentage you compute. ## Step 2 - pick the floor The baseline is published, not invented: RFC 8996 deprecates TLS 1.0, TLS 1.1 and DTLS 1.0. That makes TLS 1.2 the floor to aim at, with TLS 1.3 preferred wherever both ends can reach it. Two refinements are worth stating explicitly: - A floor is a *version*. It does not settle which cipher suites or which groups are acceptable - those are configured separately, and on this material the TLS 1.2 and TLS 1.3 suite lists are configured independently of each other. - A floor above the deprecation line is a different decision again, and it is a trade against the population, not a further step of the same argument. ## Step 3 - make refusal observable before it is real | Phase | What is enforced | What you learn | |---|---|---| | Observe | nothing | who negotiates what, per peer, over a full cycle | | Report-only | nothing | which peers *would* be refused, by name, with counts | | Enforce per population | the floor, for one segment | whether the projection was right, at bounded blast radius | | Enforce estate-wide | the floor | the exception list is now the whole remaining problem | The report-only phase is the one teams skip, and it is the only one that converts a percentage into a list of device identities somebody can be made responsible for. ## Step 4 - raise it in populations, and bound the exception 1. Enforce for one segment - a district, a firmware generation, a concentrator - and watch the missing-check-in signal, not the error log, because a refused device has no channel to complain over. 2. Repeat per population, keeping each step small enough that a wrong projection is recoverable within one reporting cycle. 3. Put the remainder on a **separately scoped** endpoint with its own lower floor and its own list of permitted peer identities. A global relaxation applies to every peer, including the ones already upgraded, and it silently un-does the work. 4. Give that exception an end date at the moment it is created, and make its peer list shrink as a tracked number. ## What a refused peer experiences There is no partial mode. A peer whose offer contains nothing at or above the floor gets a fatal `protocol_version(70)` alert and a closed connection; there is no reduced-function session, no fallback, and no application channel over which the device can report what happened. Detection therefore has to sit on the accepting side, as an alarm on peers that stopped checking in on schedule - which is also why the report-only phase is worth more than any amount of device-side instrumentation. ## What this does not solve - A device that cannot be upgraded is a replacement decision, not a configuration decision. Staging buys the time to make it; it does not remove it. - The floor governs only what this deployment accepts. A concentrator that also *initiates* connections has a second, independent floor as a client, and the two are easy to leave inconsistent. - Raising the floor does not change what any certificate proves or which peers are trusted; those remain exactly as they were.

  • What does a device see when the floor refuses it, and who notices?
    It sees a fatal `protocol_version(70)` alert and a closed connection, with no negotiated channel to report the loss over. Nobody on the device side notices. Detection belongs to the accepting end - an alarm on peers whose check-in is overdue - which is why the report-only phase produces the list that matters.
  • Why is a week of handshake telemetry not enough for a metering fleet?
    Because the population is defined by check-in cadence rather than traffic. A device reporting monthly, or only on a threshold crossing, appears in no weekly sample, so a floor validated against a week refuses a segment that was never measured. The window has to cover a full reporting cycle, and seasonal devices a full season.
  • Where should the exception for the stragglers live?
    On a separately scoped listener with its own lower floor, its own list of permitted peer identities and an expiry date set when it is created. A global relaxation applies to every peer including the upgraded ones, so it quietly returns the estate to where it started while looking like progress.

It is a weight limit posted on a bridge that lorries already cross daily. Raising the number is a decision about which vehicles you will turn away, so you count the traffic before you change the sign, not after.

saying these in an interview costs you the question

  • Sets the floor from a policy document without measuring what peers negotiate
  • Assumes a refused device will report the failure itself
  • Treats a week of telemetry as the whole population
  • Relaxes the floor globally to accommodate a handful of peers
  • Thinks a version floor by itself settles which suites and groups are allowed
  • Expects a refused peer to connect with reduced function instead of not at all