Can you explain why a URI type needs to be defined? If one needs to be defined, then:
- It should not have a generic name like "ssl" or "tls". That will confuse people and there's no sense in which you would use it to initiate a TLS connection. - You shouldn't define different URIs for SSL and TLS. SSLv3 and TLS < 1.3 are essentially the same protocol, and SSLv2 has been deprecated for many years. -Ekr On Wed, Dec 20, 2023 at 12:17 PM arkiver <arkiver= 40protonmail....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
