Under TLS 1.3, why can a peer's warning-level alert not be treated as a recoverable condition mid-handshake?
answer
- severity lives in the description
- the level field stopped being an instruction
- exactly two alerts are not errors
- intent of the sender, not behaviour of the receiver
- TLS 1.2 genuinely differed here
basics
~20 sBecause TLS 1.3 makes severity implicit in the alert description. Every error alert must be treated as an error whatever level the sender claimed, and only the closure alerts close_notify(0) and user_canceled(90) are not error alerts.
solid answer
~40 sRFC 8446 moved severity out of the level field and into the description itself: error alerts must be sent at fatal level and must be treated as errors on receipt regardless of the level carried, and an unknown description must also be treated as an error. The only alerts that are not error alerts are the closure alerts, `close_notify(0)` and `user_canceled(90)`. So a peer that claims warning level on, say, `unrecognized_name(112)` still has the connection torn down by a conforming TLS 1.3 receiver - which is exactly why RFC 6066 calls a warning-level `unrecognized_name(112)` NOT RECOMMENDED. Read the level field as information about the sender's intent, never as permission to continue.
go deeper
The takeaway is short: in TLS 1.3 the alert's name decides whether the connection dies, not the level the sender claimed, and almost every alert kills it.
Explain that severity became implicit in the description, name the two closure alerts that are the exceptions, and say what a receiver does with a description it does not recognise.
Use it as a diagnostic fingerprint: one side logging a notice while the other logs a failed exchange usually means a peer of older vintage is still treating the level field as meaningful.
The angle is the cost of ambiguity in a protocol: this change removed a whole class of disagreement between implementations, and it is a clean example of failing closed being cheaper than negotiating severity.
## Severity moved into the description In TLS 1.3, RFC 8446 makes the severity of an alert implicit in **which** alert it is. Error alerts must be sent at fatal level, and a receiver must treat them as errors regardless of the level carried in the message; an alert description the receiver does not know must also be treated as an error. The practical consequence is blunt: the level field is no longer a decision input on the receiving side. That is a genuine change of model, not a tightening of one. It removes an entire class of ambiguity in which two implementations could disagree about whether an exchange was still alive. ## The two that are not error alerts The exceptions are the closure alerts: - `close_notify(0)`, the orderly end-of-data signal; - `user_canceled(90)`, sent when a peer is abandoning the exchange for a reason unrelated to a protocol failure. Everything else in the alert registry is an error alert and ends the connection. That is a two-item list, and it is worth memorising precisely because it is so short. ## Why RFC 6066 discourages a warning-level unrecognized_name(112) RFC 6066 says a server that does not recognise a requested `host_name` SHOULD either abort with a fatal-level `unrecognized_name(112)` or continue - and that sending a **warning-level** one is NOT RECOMMENDED, because a receiver's response to warning-level alerts is unpredictable. TLS 1.3 turns that unpredictability into a certainty in the unhelpful direction. A server that sends a warning-level `unrecognized_name(112)` hoping the exchange carries on gets the opposite: a conforming receiver treats it as an error and closes. The polite gesture is the thing that ends the connection. ## What changed from TLS 1.2 | | TLS 1.2 (RFC 5246) | TLS 1.3 (RFC 8446) | |---|---|---| | Level field on receipt | A decision input | Ignorable; severity follows the description | | Warning-level error alerts | Possible, receiver behaviour varied | Treated as errors anyway | | Not error alerts | Several warning-level conditions | Only `close_notify(0)` and `user_canceled(90)` | | Unknown description | Handling varied | Treated as an error | This is one of those places where erasing the version erases the claim. "Warning alerts are advisory" was a defensible sentence about TLS 1.2 and is a wrong one about TLS 1.3. ## How this shows up in a diagnosis 1. A component of an older vintage sends a warning-level alert and expects to continue. Against a TLS 1.3 peer, the exchange ends. 2. The observable symptom is an abort with no obvious error, because the sending side believes it reported something minor and logged it as such. 3. The two sides' accounts of the same event disagree: one recorded a notice, the other recorded a failure. That disagreement is the fingerprint. When you see it, stop asking which side is broken. Ask which version each side was speaking, and whether the description sent is in the two-item list of alerts that are not errors. ## The reading habit worth taking away The level field still carries information - it tells you what the **sender** thought it was doing. It has stopped carrying instruction: it does not tell the receiver what to do, and a candidate who says "it was only a warning, so the connection survived" has read a sender's intent as a receiver's behaviour. Those are different things, and TLS 1.3 separated them deliberately.
- What should a receiver do with an alert description it does not recognise?Treat it as an error. RFC 8446 requires unknown alert descriptions to be handled as error alerts, so a receiver never assumes an unfamiliar description is minor and continues. That choice matters for forward compatibility: a description added after an implementation was written fails closed rather than being silently ignored.
- If the level field is ignorable on receipt, is it useless?Not useless, but it is evidence rather than instruction. It tells you what the sending implementation believed it was reporting, which during a diagnosis is exactly the disagreement you are looking for: one side recording a notice while the other records a failure is the fingerprint of an implementation still using the older model.
saying these in an interview costs you the question
- Says a warning-level alert lets a TLS 1.3 handshake continue
- Believes the level field decides how a receiver reacts
- Cannot name the two alerts that are not error alerts
- Treats an unknown alert description as safe to ignore
- Describes TLS 1.2 behaviour as if it still applied