client_early_traffic_secret and alert

[kazu-yamamoto]

Sec 7.3. says:

Alerts are sent with the then current sending key (or as plaintext if no such key has been established.)

In my experience, there is one exception. When a client tries to send early data but the negotiation fails for some reasons, the client should clear the client_early_traffic_secret and send an alert in plaintext.

[ekr]

This seems right to me. @davidben @martinthomson?

[davidben]

I suspect neither option works reliably, because you don't know what state the server is in. Let's say the server sent an illegal ServerHello after reading your ClientHello. If the server had accepted early data, it's expecting client_early_traffic_secret and won't accept plaintext. If the server had rejected early data, it can't read client_early_traffic_secret and is expecting plaintext (but willing to skip over early data).

Normally, we'd know which of these it is, but we're presuming a situation where, for whatever reason, the server is failing to respond. Leaving the key alone (what we do) is a bit safer as there's less risk of accidentally sending plaintext application data. But really I think this situation doesn't matter. There are two kinds of error situations in TLS:

1. The peer is a perfectly valid TLS implementation, you just don't have some parameter in common
2. The peer sent something illegal under protocol rules

Delivering an alert is important in case 1 because that will happen on configuration error. I don't think the alert is very important in case 2 because, in principle, it should never happen. When it does, it's nice to have debugging information, but I wouldn't contort the protocol or implementation to achieve it. I believe all the relevant alert conditions on receiving ServerHello and EncryptedExtensions are case 2. (After EncryptedExtensions, you've learned whether the server accepted early data and it's no longer ambiguous.)

[davidben]

If the server had accepted early data, it's expecting client_early_traffic_secret and won't accept plaintext. If the server had rejected early data, it can't read client_early_traffic_secret and is expecting plaintext (but willing to skip over early data).

Well... the client can send an alert under client_early_traffic_secret, immediately followed by a plaintext one, and that will work in both cases. I don't think that's worth it, given it's all case 2. 😄

[ekr]

OK, I'm persuaded by @davidben to do the minimal thing, which is to not change it. This matches the plan for 8446-bis to make only minimal required changes. Please object by 2/29 if you disagree.

[martinthomson]

I'm similarly persuaded. Though even in case 1 you generally have servers that are not behaving.