> Again, think carefully about the data you are recording. Also, TLS1.2 allows > renegotiation in an active connection to do things like change the cipher > algorithm, ask the client to send its certificate, and so on. Are you going > to record those? Client authentication seems like something important. And > which part are you recording". The client or server side or both? You said > "outgoing TLS record" but that's not clear to me. Renegotiation can be > initiated by either side FYI.
We would be recording the records send by the client to the servers, and those received by the client from the server. > Are you going to support session resumption, session tickets, pre-shared > keys? Are you going to ensure your client doesn't do any of those? Theoretically we would support archiving all SSL/TLS records, with one condition (copied from previous email): While any TLS records may be stored in the WARC, encrypted content in these records that needs to be available in decrypted form must be stored in a separate record in decrypted form. If the TLS record does not contain any other data of interest next to what is stored decrypted separately, the TLS record should not be stored, keeping only the decrypted record. The would prevent any need for storing sensitive keys, and is in line with storing the HTTP record in decrypted form as is already being done. This also means that in some cases it might make no sense to store the TLS record as it holds no interesting data next to the data that was stored in decrypted form. > I read RFC 7595 and looked at the IANA registry. I am fairly confident that > you will never get the "tls" scheme, so you might want to re-think things a > bit. Thank you for checking that, we will think about this. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
