Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt
Hi Ilari,
Thank you for the quick review. I've been integrating all of the
editorial feedback in the draft (separate mail to follow to the group).
Regarding your feedback:
On 06/09/2023 17:46, Ilari Liusvaara wrote:
Doing quick review:
Section 3.1.2:
- It is not clear what exactly is replaced if cert_data is known.
Obviously overriding the length field would be more compact, but it
also can be interpreted as replacing the value, wasting 3 bytes.
(Reminds me of RFC 8879, which is not clear about similar things.)
- CertificateEntry and Certificate length fields are just waste of
space, since both can be recovered in other ways when decoding.
- RFC 8879 does not allow ignoring unrecognized three-byte identifiers.
Instead, the connection MUST be terminated with bad_certificate alert.
This has consequence that any client that can ever add a custom trust
anchor via any means must have the complete certificate list (whereas
partial list would be enough if no custom trust anchors can ever be
added).
And I find the last comment about transcript validation failing very
scary.
I've improved the language in the draft to clarify exactly how this pass
works. A TLS1.3 Certificate Message carrying X509 is structured as follows:
struct {
opaque cert_data<1..2^24-1>;
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
When compressing during this first pass, we're going to be swapping the
opaque cert_data fields for short three byte identifiers and correcting
the lengths. The extension and certificate_request_context fields are
not going to be adjusted. Pass 2 is then going to compress the result
with ZStd with a provided dictionary.
When we're decompressing, after the ZStd pass, we're going to use the
length fields to parse the message and replace any recognized three byte
identifiers with the corresponding certificate, again leaving the
extensions and the certificate_request_context untouched.
I hope that clarifies why transmitting the lengths is necessary.
Regarding the decompression errors, I've updated the draft to say that
decompression must fail and the correct alert sent if the length fields
are incorrect as you suggested. I've filed an issue to discuss the case
of unrecognized identifiers specifically [1].
Regarding the general security considerations, I want to clarify the
situation. At the point we receive a Certificate (or a
CompressedCertificate) message in TLS1.3, we don't know who we're
talking to, the point of the message is to provide that information.
Obviously, a peer can send any payload it likes in a Certificate message
already, it's the job of the receiver to parse the Certificate message
and establish whether it trusts the presented certificate (chain).
Using Certificate Compression with any scheme (including this draft)
doesn't change the fundamentals. The result of decompressing the message
is handled exactly like a Certificate message. So with the exception of
memory safety bugs during decompression, there is no additional attack
surface. An attacker can already send arbitrary content in a Certificate
message and so implementations receiving a Certificate message already
have to be able to robustly validate it. Any attack which somehow
leveraged the decompression aspect is also possible by the attacker just
sending the output of the decompression directly as a Certificate
message. Nothing in this draft changes the situation from existing uses
of Certificate Compression.
Section 3.2.:
- Using alternate scheme could result drastically reduced implementation
complexity.
Furthermore, one can't even use standard zstd decoder with this due to
security reasons. One needs special one (but seems like reference zstd
library ships that as alternative API).
Can you clarify what you mean by this? The standard zstd decoder works fine.
Section 3.2.1.:
- I suspect that having CA-specific dictionaries would make it much
easier to be equitable and improve compression.
Then I don't think the dictionary construction method is good:
* Using just one certificate is very dubious.
* It is more optimal to consider byte substrings with no structure.
This is tracked in [2] and [3]. Depending on the experimental data we
get when evaluating [3], we might omit pass 2 entirely.
Section 3.2.1.1.:
- Caching monolithic compression from startup does not work because of
extension fields.
For caching to work, one would have to compress the certificate
entries independently and leave the extension fields in between
uncompressed.
The draft currently preserves the extension fields. Existing TLS
Certificate Compression APIs perform the caching at the level of the
entire message and so the cache is only used if t
[TLS] draft-ietf-tls-cert-abridge Update
Hi all, I wanted to give a quick update on the draft. On the implementation side, we have now landed support for TLS Certificate Compression in Firefox Nightly which was a prerequisite for experimenting with this scheme (thank you to Anna Weine). We're working on a rust crate implementing the current draft and expect to start experimenting with abridged certs in Firefox (with a server-side partner) ahead of IETF 120. On the editorial side, I've addressed the comments on presentation and clarification made since IETF 117 which are now in the editors copy - there's an overall diff here [1] and atomic changes here [2] . There are two small PRs I've opened addressing minor comments by Ben Schwarz on fingerprinting considerations [3] and Jared Crawford on the ordering of certificates [4]. Feedback is welcome via mail or on the PRs directly. Best, Dennis [1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt [2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/ [3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files [4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt
On Fri, Mar 01, 2024 at 12:48:54PM +, Dennis Jackson wrote: > > On 06/09/2023 17:46, Ilari Liusvaara wrote: > > Doing quick review: > > > > Section 3.1.2: > > > > - RFC 8879 does not allow ignoring unrecognized three-byte identifiers. > >Instead, the connection MUST be terminated with bad_certificate alert. > > > >This has consequence that any client that can ever add a custom trust > >anchor via any means must have the complete certificate list (whereas > >partial list would be enough if no custom trust anchors can ever be > >added). > > I hope that clarifies why transmitting the lengths is necessary. Regarding > the decompression errors, I've updated the draft to say that decompression > must fail and the correct alert sent if the length fields are incorrect as > you suggested. I've filed an issue to discuss the case of unrecognized > identifiers specifically [1]. The unrecognized identifier issue is a bit more subtle. Suppose that a client: - Has only partial list of certificates (enough to cover the built-in trust store). - Allows an admin to add a new trust anchor, or to override validation error. Then such client can get into situation where server sends chain that should be valid, but instead references a certificate the client does not have. Which is a hard error. > > Section 3.2.: > > > > - Using alternate scheme could result drastically reduced implementation > >complexity. > > > >Furthermore, one can't even use standard zstd decoder with this due to > >security reasons. One needs special one (but seems like reference zstd > >library ships that as alternative API). > > Can you clarify what you mean by this? The standard zstd decoder works fine. The standard zstd decoder can allocate very large amounts of memory. Thus, one has to use decoder that decodes in one shot to given buffer with a small bounded memory usage. Fortunately, standard zstd library does have such decoder. > > Section 3.2.1.: > > > > - I suspect that having CA-specific dictionaries would make it much > >easier to be equitable and improve compression. > > > >Then I don't think the dictionary construction method is good: > >* Using just one certificate is very dubious. > >* It is more optimal to consider byte substrings with no structure. > > This is tracked in [2] and [3]. Depending on the experimental data we get > when evaluating [3], we might omit pass 2 entirely. Regarding the dictionary construction, it is just that I think that using many certificates and choosing common unstructured substrings would lead to a better dictionary. It is not like this method uses certificate structure in any way. > > Section 3.2.1.1.: > > > > - Caching monolithic compression from startup does not work because of > >extension fields. > > > >For caching to work, one would have to compress the certificate > >entries independently and leave the extension fields in between > >uncompressed. > > The draft currently preserves the extension fields. Existing TLS Certificate > Compression APIs perform the caching at the level of the entire message and > so the cache is only used if the entire message, including extensions, is > bytewise identical. Can you think of an extension in a Certificate message > which changes frequently? Dealing with 1 variant is easy, dealing with up to N variants is much harder. And that N is exponential in number of supported extensions, and some extensions might do internal negotiation, making it grow even faster than 2^k. > > Section 5.1.: > > > > - I think the argument about adding roots taking time is flawed. Roots > >are usually not even included in the chain, but intermediates are, > >and can change much faster. > > > >I remember seeing one CA that judging from naming of the intermediate > >rotated it every 6 months. > > This draft definitely doesn't want to be a factor slowing rotation. I've > filed [4] to keep track of this. As discussed in Appendix B and in the IETF > 117 presentation, it might be that dynamic versioning is more suitable in > the long run. It seems to be very difficult for strategy like this to work well in very dynamic situations. Things like trust expressions seem to be much better designed for dealing with highly dynamic situations. And trust expressions can be leveraged for omitting intermediates (intermediates can be temporarily promoted into trust anchors). > > Section 5.4: > > > > - I think the current complexity as I understand the draft is just > >scary. > > > >I consider not being able to adjust extension fields in the fly to > >be a hard blocker (that is already a hard blocker for implementing > >RFC 8879 sending side). > > As discussed above, I think this is a misunderstanding of the draft and how > existing TLS Certificate Compression schemes work. I don't see any way around either forgoing caching or dealing with exponential complexity when c
Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt
Hi John, I confess that my first impression was "eww, extensions with side effects on other extensions, that sounds super finicky to implement correctly". But actually reading in further, it seems more that the guiding principle is instead "only have one way to do a thing", in this case to communicate the maximum record size an endpoint is prepared to receive. That said, it's still changing the semantics of an existing field, which incurs a requirement to survey the compatibility with existing implementations. I see that RFC 8449 does carve out a way for endpoints to send larger values if "explicitly allowed by such a future version or extension. A server MUST NOT enforce this restriction" so in theory we should be okay, but we still need to actually check. I also note that the semantics of record_size_limit per RFC 8449 are to apply to the plaintext length, so I think it actually is weird and overly complicated for your draft to propose that the negotiated length will now be of the ciphertext length. -Ben On Mon, Feb 26, 2024 at 08:59:20AM +, John Mattsson wrote: >Hi, > > > >We just submitted version -01 of “Large Record Sizes for TLS and DTLS”. >Michael Tüxen is a new co-author, the extension has been renamed to the >more mundane “large_record_size" and is now a flag extension. The flag >extension is now used together with "record_size_limit" to allow >negotiation of maximum record size, not just a fixed 2^16 – 1 bytes. > > > >The use for record sizes larger than 2^14 has been discussed in TSVWG for >use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be >beneficial in several of the discussed solutions to remove limitation or >to increase performance. > > > >We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in >Brisbane. > > > >Cheers, > >John Preuß Mattsson > > > >From: internet-dra...@ietf.org >Date: Monday, 26 February 2024 at 09:34 >To: John Mattsson , Michael Tüxen >, Hannes Tschofenig , >Hannes Tschofenig , John Mattsson >, Michael Tuexen >Subject: New Version Notification for >draft-mattsson-tls-super-jumbo-record-limit-01.txt > >A new version of Internet-Draft >draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully >submitted by John Preuß Mattsson and posted to the >IETF repository. > >Name: draft-mattsson-tls-super-jumbo-record-limit >Revision: 01 >Title:Large Record Sizes for TLS and DTLS >Date: 2024-02-26 >Group:Individual Submission >Pages:6 >URL: > > [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt >Status: > > [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ >HTML: > > [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html >HTMLized: > > [4]https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit >Diff: > > [5]https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01 > >Abstract: > > RFC 8449 defines a record size limit extension for TLS and DTLS > allowing endpoints to negotiate a record size limit smaller than the > protocol-defined maximum record size, which is around 2^14 bytes. > This document specifies a TLS flag extension to be used in > combination with the record size limit extension allowing endpoints > to use a record size limit larger than the protocol-defined maximum > record size, but not more than about 2^16 bytes. > >The IETF Secretariat > > Links: > 1. > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5PQtjvw8A$ > 2. > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5MOtgMACw$ > 3. > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5NSq7RMpA$ > 4. > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O0NTWNIQ$ > 5. > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5Phx4rvmg$ > ___ > TLS mailing list > TLS@ietf.org > https://urld
Re: [TLS] Trust Expressions Follow-up
I found the CDDL in the appendix intriguing:
https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#appendix-A
In SCITT, we've been kicking around a related concept...
It's had several names, all of which have led to confusion, so I will not
repeat them here, but I want to overlay how they have been related in SCITT:
trust-anchor = { ; cose sign1 of some key (JWK/PGP/COSE) or certificate
type: text,
* text => any,
}
trust-store-entry = { ; a receipt from a transparency service, proving a
trust anchor in included in a log (like CT/KT)
id: text,
labels: [+ uint],
max_lifetime: uint,
* text => any,
}
trust-store-version = { ; an aggregation of receipts, based on some query,
for example, all receipts for trust anchors signed by the same key.
timestamp: int,
entries: [+ trust-store-entry],
* text => any,
}
trust-store-manifest = { ; cose sign 1 of an aggregation of receipts,
related to some subject, for example, a software bill of materials, where
each receipt is for a specific software dependency
name: text,
max_age: uint,
trust_anchors: {+ text => trust-anchor},
versions: [+ trust-store-version],
* text => any,
}
One of the interesting topics we have discussed is producing stable
identifiers for these structures, building on URI templates and thumbprints.
In the examples I can see in the trust expressions draft, you have data by
value instead of data by reference.
Consider the following URI Template for expressing versions of a trust
store:
https://{service-provider}/{trust-store-manifest.name}/versions -> all
versions of a trust store by name
https://{service-provider}/{trust-store-manifest.name}/versions/1672531200
-> all receipts for certs in a trust store version (certs by reference) ->
list of signatures ( certs by value )
We had wondered if it would be valuable to assign a naming convention and
content addressed names to resources,
so that you could ask an arbitrary scitt transparency service for details
regarding any artifact that you might be holding as bytes for example:
https://{service-provider}/{trust-store-manifest.name}/trust_anchors/{thumbprint(A1)}
-> all versions of a trust store by name containing A1.
Obviously these names are not cross protocol friendly, we looked into URNs
for that (don't throw things at me, I know this is a sensitive subject in
the IETF).
The concept of SCITT Receipts seems close to the purpose of intermediate
ellison here:
https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-intermediate-elision
The idea was that if you had stable receipts from a transparency service
you trusted, you might not need to care about all the parts of a cert chain
that they validated before including the cert in their transparency log.
I'd be interested in prototyping a SCITT mapping for this, if I can wrap my
head around the use case a bit more.
OS
On Thu, Feb 29, 2024 at 6:31 PM David Benjamin
wrote:
> Oh, I should have added: I put together an informal "explainer"-style
> document to try to describe the high-level motivations and goals a bit
> better. The format is adapted more from the web platform end, which likes
> to have separate explainer and specification documents, but it seemed a
> good style for capturing, at a high level, what we're trying to accomplish.
> https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md
>
> It's largely a copy of the start of this email thread, but I figured it'd
> be useful to have a more canonical home for it. (We'll probably adapt some
> of that text back into the draft, after some more wordsmithing.)
>
>
> On Thu, Feb 29, 2024 at 7:18 PM David Benjamin
> wrote:
>
>> Circling back to this thread, we're now looking at prototyping the TLS
>> parts in BoringSSL, on both the client (Chrome) and the server side. Let us
>> know if you have any thoughts on the proposal!
>>
>> (Nothing that would prevent us from changing details, of course. But as
>> there are a lot of pieces here, we'd like to get some experience with
>> things.)
>>
>> On Thu, Jan 25, 2024 at 5:00 PM David Benjamin
>> wrote:
>>
>>> Hi all,
>>>
>>> Now that the holidays are over, I wanted to follow up on
>>> draft-davidben-tls-trust-expr and continue some of the discussions from
>>> Prague:
>>>
>>>
>>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html
>>>
>>>
>>> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00
>>>
>>> First, I wanted to briefly clarify the purpose of excluded_labels
>>> :
>>> it is primarily intended to address version skew: if the certificate is
>>> known to match (example, v10) and the client says (example, v11), the
>>> server doesn’t know whether v11 distrusted or retained the CA. We resolve
>>> that with a combination of e
Re: [TLS] draft-ietf-tls-cert-abridge Update
Hi Dennis, I created a git issue https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but I am pasting it here for the sake of the discussion: What does the client do if the server only does Pass 1 and compresses / omits the chain certs but does not compress the end-entity certs (Pass 2)? The client should be fine with that. It should be able to reconstruct the chain and used the uncompressed end-entity cert. It should not fail the handshake. I suggest the Implementation Complexity Section to say something like > Servers MAY chose to compress just the cert chain or the end-certificate > depending on their ability to perform Pass 1 or 2 respectively. Client MUST > be able to process a compressed chain or an end-entity certificate > independently. Thanks, Panos From: TLS On Behalf Of Dennis Jackson Sent: Friday, March 1, 2024 8:03 AM To: TLS List Subject: [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi all, I wanted to give a quick update on the draft. On the implementation side, we have now landed support for TLS Certificate Compression in Firefox Nightly which was a prerequisite for experimenting with this scheme (thank you to Anna Weine). We're working on a rust crate implementing the current draft and expect to start experimenting with abridged certs in Firefox (with a server-side partner) ahead of IETF 120. On the editorial side, I've addressed the comments on presentation and clarification made since IETF 117 which are now in the editors copy - there's an overall diff here [1] and atomic changes here [2] . There are two small PRs I've opened addressing minor comments by Ben Schwarz on fingerprinting considerations [3] and Jared Crawford on the ordering of certificates [4]. Feedback is welcome via mail or on the PRs directly. Best, Dennis [1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt [2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/ [3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files [4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt
Thanks Ben, >I confess that my first impression was "eww, extensions with side effects on >other extensions, that sounds super finicky to implement correctly". > >But actually reading in further, it seems more that the guiding principle is >instead "only have one way to do a thing", in this case to communicate >the maximum record size an endpoint is prepared to receive. >That said, it's still changing the semantics of an existing field, which >incurs a requirement to survey the compatibility with existing >implementations. I see that RFC 8449 does carve out a way for endpoints >to send larger values if "explicitly allowed by such a future version or >extension. A server MUST NOT enforce this restriction" so in theory we >should be okay, but we still need to actually check. That is indeed a good thing to check and discuss. The alternative is of course to define a new extension instead. >I also note that the semantics of record_size_limit per RFC 8449 are to >apply to the plaintext length, so I think it actually is weird and >overly complicated for your draft to propose that the negotiated length >will now be of the ciphertext length. Thanks for spotting this. That is just a mistake caused by the extension in the -00 version of the draft having the meaning “I am prepared records with ciphertexts of length 2^16 - 1”. If RFC 8449 is used, the semantics should not be changed. We will fix this in the next version. Cheers, John Preuß Mattsson From: Benjamin Kaduk Date: Friday, 1 March 2024 at 20:42 To: John Mattsson Cc: TLS@ietf.org Subject: Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt Hi John, I confess that my first impression was "eww, extensions with side effects on other extensions, that sounds super finicky to implement correctly". But actually reading in further, it seems more that the guiding principle is instead "only have one way to do a thing", in this case to communicate the maximum record size an endpoint is prepared to receive. That said, it's still changing the semantics of an existing field, which incurs a requirement to survey the compatibility with existing implementations. I see that RFC 8449 does carve out a way for endpoints to send larger values if "explicitly allowed by such a future version or extension. A server MUST NOT enforce this restriction" so in theory we should be okay, but we still need to actually check. I also note that the semantics of record_size_limit per RFC 8449 are to apply to the plaintext length, so I think it actually is weird and overly complicated for your draft to propose that the negotiated length will now be of the ciphertext length. -Ben On Mon, Feb 26, 2024 at 08:59:20AM +, John Mattsson wrote: >Hi, > > > >We just submitted version -01 of “Large Record Sizes for TLS and DTLS”. >Michael Tüxen is a new co-author, the extension has been renamed to the >more mundane “large_record_size" and is now a flag extension. The flag >extension is now used together with "record_size_limit" to allow >negotiation of maximum record size, not just a fixed 2^16 – 1 bytes. > > > >The use for record sizes larger than 2^14 has been discussed in TSVWG for >use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be >beneficial in several of the discussed solutions to remove limitation or >to increase performance. > > > >We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in >Brisbane. > > > >Cheers, > >John Preuß Mattsson > > > >From: internet-dra...@ietf.org >Date: Monday, 26 February 2024 at 09:34 >To: John Mattsson , Michael Tüxen >, Hannes Tschofenig , >Hannes Tschofenig , John Mattsson >, Michael Tuexen >Subject: New Version Notification for >draft-mattsson-tls-super-jumbo-record-limit-01.txt > >A new version of Internet-Draft >draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully >submitted by John Preuß Mattsson and posted to the >IETF repository. > >Name: draft-mattsson-tls-super-jumbo-record-limit >Revision: 01 >Title:Large Record Sizes for TLS and DTLS >Date: 2024-02-26 >Group:Individual Submission >Pages:6 >URL: > > [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt >Status: > > [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ >HTML: > > [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html >HTMLized: > > [4]https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit >Diff: > > [5]https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01 > >Abstract: > > RFC 8449 defines a record size limit extension for TLS and DTLS > allowing endpoints to negotiate a record size limit smaller than the > protoco
