Ilari Liusvaara wrote: >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client handshake keys after ServerHello. > >> This is a pain for us, we don't have the code that Ilari talks about, >> so some of our tests end up hitting decode errors on the server, but >> it's been manageable thus far. > > The code I was talking about was handling the special case that the > server might receive either encrypted or unencrypted alert in response > to its flight. And the difference it makes is just what error is > declared as abort reason.
Up to TLSv1.2 there was no confusion about whether a TLS record was encrypted or not: everything before "ChangeCipherSpec" is cleartext, everything thereafter is encrypted. Easy and straightforward solution would be to add the (meta-)information whether the Contents of a TLSv1.3 record are encrypted or not into the outer ContentType field, i.e. define an additional "encrypted Alert" content type and ensure that Alerts ContentTypes are always visible in the traditional TLS record header (rather than the bogus/futile attempt to hide this information). Having to do heuristics on something that can be easily deterministically tagged as one or the other, seems a little odd. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
