Hi TLS Working Group, This is a question about media types and URIs that are not defined for TLS and SSL in their RFCs. I would like to define and start using these, if the proposed definition looks reasonable. First a short introduction on what we would use this for, and then the proposed definitions.
The [WARC (Web ARChive) format](https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/) is widely used in web archiving. Traditionally only HTTP requests and responses would be stored in a WARC file, with the idea that storing both the original requests and responses provides enough information on why and how certain data was returned by a web server. Nowadays we see examples of web servers that employ TLS fingerprinting to serve different HTTP responses. In that case storing just the HTTP request is not enough to explain a response. [Wget-AT](https://github.com/ArchiveTeam/wget-lua) is a modified version of Wget used to archive hundreds of millions of web resources every day. With the release of [Wget-AT 20231213.01](https://github.com/ArchiveTeam/wget-lua/releases/tag/v1.21.3-at.20231213.01) recording of minimal information about the used TLS session was implemented - simply the used cipher suite and the used SSL/TLS protocol. Recording of the cipher suite is also being discussed at https://github.com/iipc/warc-specifications/issues/86. A next step in recording SSL/TLS session information would be storing certificates and SSL/TLS records. To record the incoming and outgoing SSL/TLS records, one could use records similar to how HTTP requests and responses are stored. However, a URI and Media Type need to be defined. These are not defined in [RFC 8446](https://datatracker.ietf.org/doc/html/rfc8446). I would like to propose the following. For TLS records as defined in [RFC 8446 section B.1.](https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.1) we would use the following media type > Media Type name: application > Media subtype name: tls > Required parameters: version > version: The human readable protocol version of the TLS > record. Which at the moment may have the values > "1.0", "1.1", "1.2", or "1.3". > Optional parameters: contenttype > contenttype: The content type of the record, which in the > case of TLS 1.3 may be one of "change_cipher_spec", > "alert", "handshake", "application_data", or "heartbeat". The "contenttype" is an optional parameter so a SSL/TLS record can be easily identified as being part of a handshake or not, without having the parse the (different versions of) SSL/TLS records. An alternative parameter name like "content_type" could also be used, but "contenttype" was chosen since [RFC 2616 section 19.1.](https://datatracker.ietf.org/doc/html/rfc2616#section-19.1) uses "msgtype", and not "msg_type". The URI for TLS records would be > "tls://" host ":" port This is inspired by [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). Similarly for SSL records we would use as Media Type > Media Type name: application > Media subtype name: ssl > Required parameters: version > version: The human readable protocol version of the SSL > record. Which has one of the values "2.0" or "3.0". > Optional parameters: contenttype > contenttype: The content type of the record as defined in > [RFC 6101 section > 5.2.1.](https://datatracker.ietf.org/doc/html/rfc6101#section-5.2.1) > and which is one of "change_cipher_spec", > "alert", "handshake", or "application_data", for > SSL 3.0. > For SSL 2.0, the "contenttype" would have as value > one of "handshake", "security_escape", or > "application_data", derived from the text at > [The SSL Protocol section > 4.1.1.](https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00.txt#section-4.1.1). The SSL URI would be (similar to the TLS URI) > "ssl://" host ":" port This is currently not in an RFC, but we would like to start using it for writing WARC files. Does the use of these two Media Types and URIs make sense, or are there obvious problems with them? If the reactions to this idea/proposal are positive, I plan on moving forward with supporting this in Wget-AT for writing WARC files. Best regards, arkiver _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
