[TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[arkiver]

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Eric Rescorla]

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  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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Salz, Rich]

The Media Type registration system is in flux and is about to become much more 
open.  Go to their WG page, 
https://datatracker.ietf.org/wg/mediaman/documents/, and look at the 
“Guidelines” and “Allowing Community Registrations” documents.

Like Eric, I don’t see why a URI is needed and look forward to your 
explanation.  If it is required, then I strongly suggest you use a URN under 
your own “warc” prefix.

In fact, I suggest the media types be “warc+tls” and, if really needed (sure 
some parts of the web are old), “warc+ssl” Then register those two suffices.  
At least, I think that’s a reasonable idea. It might be that warc-tls and 
warc-ssl is better.

Also, what is the point of archiving the actual bytes, as opposed to a 
human-readable abstraction of them? Do you expect to let others decrypt and 
verify your traffic? Are you going to expose the “master key” so that can be 
done? In a public archive?  Ouch!  Think carefully about the security issues 
you are creating by doing that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Deirdre Connolly]

Hi all,

Thanks to everyone who chimed in on this adoption call. It looks like there
is consensus to adopt this as a WG item and volunteers to help review.
Rich, can you please submit draft-ietf-tls-tls12-frozen-00 to datatracker,
and transfer the GitHub repo to the tlswg GitHub org?
Thank you!

Cheers,
Deirdre, for the holiday chairs ✨

On Thu, Dec 14, 2023 at 6:40 AM William Stratton Apsokardu <
williamsapsokardu...@outlook.com> wrote:

> Facebook Facebook
> FacebookFacebook
> Get Outlook for iOS 
> --
> *From:* TLS  on behalf of Nimrod Aviram <
> nimrod.avi...@gmail.com>
> *Sent:* Wednesday, December 13, 2023 9:49:55 AM
> *To:* Ilari Liusvaara 
> *Cc:* TLS@ietf.org 
> *Subject:* Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
>
> Hi Ilari, thanks for the clarification!
>
> I attempted to correct the text.
> Would you be willing to review the change? It's here:
>
> https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447
>
> thanks,
> Nimrod
>
>
> On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara 
> wrote:
>
> On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> >
> > Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> > change.  I’ll wait until/if this is adopted by the WG to merge it.
>
> Reading through the document, I noticed the following:
>
> "To securely deploy TLS 1.2, either renegotiation must be disabled
> entirely, or this extension must be present." (where this extension
> means renegotiation_info)
>
>
> Entirely disabling renegotiation is not sufficient to fix the
> renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
> MUST be required both ways.
>
> And then there is the other part to the triple handshake attack where
> using TLS exporters for authentication without extended_master_secret
> extension is insecure, even if renegotiation is not supported at all
> by either side and both sides implement renegotiation_info.
>
> And then there is more dangerously flawed stuff, e.g., session tickets
> (technically an extension).
>
>
>
>
> -Ilari
>
> ___
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls