[TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS
Hi, During the COSE virtual interim meeting yesterday, there was agreement that the COSE working group should work on CBOR compression of RFC 7925 profiled X.509 certificates. The work will be based on draft-raza-ace-cbor-certificates and draft-mattsson-cose-cbor-cert-compress and the two drafts will be merged. Doing this work in a security group focused on CBOR makes a lot of sense. https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00 https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 The COSE draft charter has already been updated to reflect this. https://github.com/cose-wg/Charter/blob/master/Charter.md As the algorithm is focused on compressing RFC 7925 profiled certificates, It seems like a very good match for cTLS. To keep the number of internet-drafts down, I plan to also include the TLS IANA registrations in the merged draft submitted to the COSE WG and let draft-mattsson-tls-cbor-cert-compress-00 expire. Any comments from the TLS WG are very welcome, but otherwise these is not so much to discuss, this is just another certificate compression algorithm. Any TLS related discussions would likely be regarding the certificate profile in RFC 7925 and if any clarifications or updates are needed. This is likely best discussed in UTA which may take up work on a TLS/DTLS 1.3 update of RFC 7925. https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01 Cheers, John -Original Message- From: John Mattsson Date: Thursday, 12 March 2020 at 08:58 To: "TLS@ietf.org" Cc: "u...@ietf.org" Subject: FW: New Version Notification for draft-mattsson-tls-cbor-cert-compress-00.txt Hi, We have submitted a new draft to TLS https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 The draft register a new compression algorithms for use with TLS Certificate Compression in TLS 1.3 and DTLS 1.3 (draft-ietf-tls-certificate-compression). The draft uses https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 to compress RFC 7925 profiles certificates by encoding them from DER to CBOR. The aim is to be compatible with all RFC 7925 profiled certificates. With the included example DER encoded RFC 7925 certificate to certificate is compressed from 314 to 136 bytes, a compression rate of 57%. The general purpose compression algorithms defined in draft-ietf-tls-certificate-compression do not seem able to compress profiled RFC 7925 X.509 certificates much at all. zlib compressed the example cert 9%, but for other certificates we tested, zlib did in many cases not provide any compression at all. We have submitted a similar draft to the COSE WG registering a new algorithms for the TLS 1.3 certificate compression extension. https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 Cheers, John -Original Message- From: "internet-dra...@ietf.org" Date: Monday, 9 March 2020 at 21:19 To: John Mattsson , John Mattsson , Joel Höglund , Joel Hoglund , Göran Selander , Martin Furuhed , Göran Selander , Shahid Raza Subject: New Version Notification for draft-mattsson-tls-cbor-cert-compress-00.txt A new version of I-D, draft-mattsson-tls-cbor-cert-compress-00.txt has been successfully submitted by John Preuss Mattsson and posted to the IETF repository. Name: draft-mattsson-tls-cbor-cert-compress Revision: 00 Title: CBOR Certificate Algorithm for TLS Certificate Compression Document date: 2020-03-09 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-mattsson-tls-cbor-cert-compress-00.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-cbor-cert-compress/ Htmlized: https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-cbor-cert-compress Abstract: Certificate chains often take up the majority of the bytes transmitted in TLS handshakes. Large handshakes can cause problems, particularly in constrained IoT environments. RFC 7925 defines a TLS certificate profile for constrained IoT. General purpose compression algorithms can in many cases not compress RFC 7925 profiled certificates at all. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document specifies the CBOR certificate compression algorithm for use with TLS Certificate Compression in TLS 1.3 and DTLS 1.3.
[TLS] On the two types of ACKs in DTLS 1.3
Hi all, I am aware that we're late into the standardization of DTLS 1.3, and likely too late for any intrusive change, but I'd still like to share another comment on the proposed ACKing scheme and its implication on complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the aspect discussed earlier regarding handshake-level vs. record-level ACKs (https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMSzxZg30RM/) As it stands, there are two quite different kinds of ACKs sharing the same wire-format: 1. ACKs as 'retransmission requests' Consider the following two excerpts from the draft: A: "When an implementation receives a partial flight, it SHOULD generate an ACK that covers the messages from that flight which it has received so far." B: "Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments." This means that ACKs should be sent only on signs of disruption, and that receivers of partial ACKs are supposed to immediately retransmit. In particular, this precludes recurring use of ACKs where an ACK is generated for each message as it comes in and is processed: Indeed, implementations behaving this way would trigger multiple retransmissions on the peer, provided the peer obeys (B), even if there's not a single packet-loss or reordering occurring. In this sense, the above ACKs are 'negative' and should not be seen at all during a disruption-free handshake. Note, also, that handshakes will continue to progress if this kind of ACKs is entirely ignored, which amounts to falling back to how DTLS 1.2 handles retransmissions, purely on the basis of timeouts and implicit acknowledgement. 2. ACKs as 'acknowledgement of completion' In contrast to the previous kind of ACK, those ACKs are 'positive' in that they indicate completion of a handshake, and they are mandatory in that a handshake will not complete unless they are used. In particular, an implementation MUST support those kinds of ACKs. At the moment, both kinds of ACKs are handled in the same way on the wire, and in order to even distinguish them an implementation has to maintain accurate knowledge of the sequence numbers of records it has sent. In particular, even if implementations decide to not make use of type-1 ACKs -- that is, retransmission requests -- it doesn't buy them anything in terms of code-size and simplicity, because they still have to implement type-2 ACKs, and detecting those requires implementing record sequence number bookkeeping. I believe that this will harden migration of DTLS 1.2 stacks to DTLS 1.3, because it makes the minimal difference between a compliant DTLS 1.3 implementation and a pair of "DTLS 1.2 + TLS 1.3 logic" quite large. In contrast, if retransmission requests and completion-ACKs were treated differently, and in particular easily distinguishable on the wire, then migration from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal compliant DTLS 1.3 would only require implementing 'completion-ACKs', which, since they convey only a single bit of information, can in principle have a much simpler wire-format than what we have for ACKs today. I would be interested in comments from implementors, esp. for stacks targeting embedded / constrained environments. Cheers, Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS
Hi John, Thanks for the heads-up. Discussing this aspect in draft-tschofenig-uta-tls13-profile-01 makes sense. I was wondering whether you have been working on an implementation of draft-mattsson-cose-cbor-cert-compress-00 / draft-raza-ace-cbor-certificates-04. Ciao Hannes -Original Message- From: TLS On Behalf Of John Mattsson Sent: Friday, April 3, 2020 9:03 AM To: TLS@ietf.org; u...@ietf.org Subject: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Hi, During the COSE virtual interim meeting yesterday, there was agreement that the COSE working group should work on CBOR compression of RFC 7925 profiled X.509 certificates. The work will be based on draft-raza-ace-cbor-certificates and draft-mattsson-cose-cbor-cert-compress and the two drafts will be merged. Doing this work in a security group focused on CBOR makes a lot of sense. https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00 https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 The COSE draft charter has already been updated to reflect this. https://github.com/cose-wg/Charter/blob/master/Charter.md As the algorithm is focused on compressing RFC 7925 profiled certificates, It seems like a very good match for cTLS. To keep the number of internet-drafts down, I plan to also include the TLS IANA registrations in the merged draft submitted to the COSE WG and let draft-mattsson-tls-cbor-cert-compress-00 expire. Any comments from the TLS WG are very welcome, but otherwise these is not so much to discuss, this is just another certificate compression algorithm. Any TLS related discussions would likely be regarding the certificate profile in RFC 7925 and if any clarifications or updates are needed. This is likely best discussed in UTA which may take up work on a TLS/DTLS 1.3 update of RFC 7925. https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01 Cheers, John -Original Message- From: John Mattsson Date: Thursday, 12 March 2020 at 08:58 To: "TLS@ietf.org" Cc: "u...@ietf.org" Subject: FW: New Version Notification for draft-mattsson-tls-cbor-cert-compress-00.txt Hi, We have submitted a new draft to TLS https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 The draft register a new compression algorithms for use with TLS Certificate Compression in TLS 1.3 and DTLS 1.3 (draft-ietf-tls-certificate-compression). The draft uses https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 to compress RFC 7925 profiles certificates by encoding them from DER to CBOR. The aim is to be compatible with all RFC 7925 profiled certificates. With the included example DER encoded RFC 7925 certificate to certificate is compressed from 314 to 136 bytes, a compression rate of 57%. The general purpose compression algorithms defined in draft-ietf-tls-certificate-compression do not seem able to compress profiled RFC 7925 X.509 certificates much at all. zlib compressed the example cert 9%, but for other certificates we tested, zlib did in many cases not provide any compression at all. We have submitted a similar draft to the COSE WG registering a new algorithms for the TLS 1.3 certificate compression extension. https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 Cheers, John -Original Message- From: "internet-dra...@ietf.org" Date: Monday, 9 March 2020 at 21:19 To: John Mattsson , John Mattsson , Joel Höglund , Joel Hoglund , Göran Selander , Martin Furuhed , Göran Selander , Shahid Raza Subject: New Version Notification for draft-mattsson-tls-cbor-cert-compress-00.txt A new version of I-D, draft-mattsson-tls-cbor-cert-compress-00.txt has been successfully submitted by John Preuss Mattsson and posted to the IETF repository. Name:draft-mattsson-tls-cbor-cert-compress Revision:00 Title:CBOR Certificate Algorithm for TLS Certificate Compression Document date:2020-03-09 Group:Individual Submission Pages:6 URL: https://www.ietf.org/internet-drafts/draft-mattsson-tls-cbor-cert-compress-00.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-cbor-cert-compress/ Htmlized: https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-cbor-cert-compress Abstract: Certificate chains often take up the majority of the bytes transmitted in TLS handshakes. Large handshakes can cause problems, particularly in constrained IoT environments. RFC 7925 defines a TLS certificate profile for constrained IoT. General purpose compression algorithms can in many cases not compress RFC 7925 profiled certificates at all. By using the fact that the certificates are
[TLS] Efficiency of ACKing scheme
Hi again,
The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I wonder if the current spec matches the authors' intentions.
Example:
Consider a flight broken down as sequence of records 1, 2, .., N.
Assume record 2 gets dropped, while all other records go through
without reordering, corruption or loss; hence, the record sequence
observed on the receiver is 1, 3, 4, ..., N.
Then, according to the spec, the following SHOULD happen:
On the receiver-side, we have the following from Section 7.1:
```
When an implementation receives a partial flight, it SHOULD generate
an ACK that covers the messages from that flight which it has
received so far. Implementations have some discretion about when to
generate ACKs, but it is RECOMMENDED that they do so under two
circumstances:
* When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message.
```
So, when the receiver receives records 1 and 3, it notices that 2 is missing
and immediately sends an ACK for { 1, 3 }.
On the sender-side, we have the following from Section 7.2:
```
7.2. Receiving ACKs
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions. Upon receipt
of an ACK for only some messages from a flight, an implementation
SHOULD retransmit the remaining messages or fragments.
```
So, when the receiver receives the ACK for { 1, 3 }, it resends records
2, 4, 5, .., N.
That's obviously not optimal, and probably not what was intended, but what
unambiguously appears to be the recommended behavior according to the spec.
How should this be resolved?
I see two similar and comparably unintrusive options:
1) Send ACKs only after period of inactivity
Instead of sending ACKs straight away when something hints at
something going wrong (such as an out-of-order receipt), as
currently stated in Section 7.1, only send ACKs after a period
of time where no further messages has been received.
That is, replace the current version
```
When an implementation receives a partial flight, it SHOULD generate
an ACK that covers the messages from that flight which it has
received so far. Implementations have some discretion about when to
generate ACKs, but it is RECOMMENDED that they do so under two
circumstances:
* When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message. Implementations
MUST NOT send ACKs for handshake messages which they discard as
out-of-order, because otherwise those messages will not be
retransmitted.
* When they have received part of a flight and do not immediately
receive the rest of the flight (which may be in the same UDP
datagram). A reasonable approach here is to set a timer for 1/4
the current retransmit timer value when the first record in the
flight is received and then send an ACK when that timer expires.
In addition, implementations MUST send ACKs upon receiving all of any
flight which they do not respond to with their own messages.
```
by something along the following lines:
```
As long as implementation has received some but not all of the next incoming
flight, it SHOULD send an ACK message after an implementation-defined period
a time during which no further messages are received. A reasonable approach
here is to reset a timer to 1/4 the current retransmission timer with every
record received in the current flight, and send an ACK when that timer
expires.
```
In the above example, this would mean that as long as records 3,4,..,N arrive
in close succession, it will only once send an ACK for {1,3,4,...,N} in the
end,
triggering retransmission of record 2 only, which is optimal.
The drawback of this is that the receiver of a flight does not inform a peer
about a gap in a flight as soon as it notices it. For this to work, the
content
of an ACK would need to be what's missing instead of what's present, which
appears to be a too intrusive change to be considered at this stage. The
benefit of this approach is that it leads to very good retransmission
bandwidth.
2. Essentially same as option 1., but 'mirrored': Allow the receiver of a flight
to send ACKs recurringly (though preferably still bunched, i.e. using some
timer
for the bunching), and replace the part of Section 7.2:
```
7.2. Receiving ACKs
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions. Upon receipt
of an ACK for only some messages from a flight, an
Re: [TLS] Efficiency of ACKing scheme
An additional note: All solutions which retain the paragraph
Upon receipt
of an ACK for only some messages from a flight, an implementation
SHOULD retransmit the remaining messages or fragments.
and hence trigger retransmission immediately upon receiving a partial ACK,
suffer from the following problem:
On Low-MTU networks, and looking ahead at the use of Post-Quantum Cryptography,
it might happen that a single ACK is too small to hold the entire list of record
sequence numbers of the flight being ACKed.
Doing the math in an example: If the maximum plaintext size is, say, 512 Bytes,
then a single ACK can not ACK more than 64 Records, each of which contains at
most 512 Bytes of handshake data. Hence, we've got a theoretical max of ~32Kb
flight length we can ACK in a single ACK message.
While this seems a lot, some PQC schemes go beyond that. For example, the
SPHINCS
signature scheme has 41Kb signature size.
To avoid this problem, it appears beneficial to go for option 2., that is, don't
retransmit immediately upon receiving an ACK, but accumulate some ACKs first.
This
allows to split ACKing a very large flight into multiple ACKs.
From: TLS on behalf of Hanno Becker
Sent: Friday, April 3, 2020 5:35 PM
To: tls@ietf.org
Subject: [TLS] Efficiency of ACKing scheme
Hi again,
The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I wonder if the current spec matches the authors' intentions.
Example:
Consider a flight broken down as sequence of records 1, 2, .., N.
Assume record 2 gets dropped, while all other records go through
without reordering, corruption or loss; hence, the record sequence
observed on the receiver is 1, 3, 4, ..., N.
Then, according to the spec, the following SHOULD happen:
On the receiver-side, we have the following from Section 7.1:
```
When an implementation receives a partial flight, it SHOULD generate
an ACK that covers the messages from that flight which it has
received so far. Implementations have some discretion about when to
generate ACKs, but it is RECOMMENDED that they do so under two
circumstances:
* When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message.
```
So, when the receiver receives records 1 and 3, it notices that 2 is missing
and immediately sends an ACK for { 1, 3 }.
On the sender-side, we have the following from Section 7.2:
```
7.2. Receiving ACKs
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions. Upon receipt
of an ACK for only some messages from a flight, an implementation
SHOULD retransmit the remaining messages or fragments.
```
So, when the receiver receives the ACK for { 1, 3 }, it resends records
2, 4, 5, .., N.
That's obviously not optimal, and probably not what was intended, but what
unambiguously appears to be the recommended behavior according to the spec.
How should this be resolved?
I see two similar and comparably unintrusive options:
1) Send ACKs only after period of inactivity
Instead of sending ACKs straight away when something hints at
something going wrong (such as an out-of-order receipt), as
currently stated in Section 7.1, only send ACKs after a period
of time where no further messages has been received.
That is, replace the current version
```
When an implementation receives a partial flight, it SHOULD generate
an ACK that covers the messages from that flight which it has
received so far. Implementations have some discretion about when to
generate ACKs, but it is RECOMMENDED that they do so under two
circumstances:
* When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message. Implementations
MUST NOT send ACKs for handshake messages which they discard as
out-of-order, because otherwise those messages will not be
retransmitted.
* When they have received part of a flight and do not immediately
receive the rest of the flight (which may be in the same UDP
datagram). A reasonable approach here is to set a timer for 1/4
the current retransmit timer value when the first record in the
flight is received and then send an ACK when that timer expires.
In addition, implementations MUST send ACKs upon receiving all of any
flight which they do not respond to with their own messages.
```
by something along the following lines:
```
As long as implementation has received some but not all of the next incoming
flight, it SHOULD send an ACK message after an implementation-defined period
a time during which no further messages are received. A reason
Re: [TLS] Virtual TLS Interim Meeting
On Tue, Mar 24, 2020 at 7:54 PM Joseph Salowey wrote: > The chairs think it would be good to schedule a virtual TLS interim > focused on ECHO and also have a readout from the PSK design team. We have > some dates that the IESG has recommended for us. The proposal is: > > 1900 - 2100 UTC April 27 > > Please use the following form to let us know if you can attend: > >https://forms.gle/Wkk7dsx9q1ipmi2B9 > > [Joe] Of the 26 responses only 1 indicated that the time did not work so we are moving forward with requesting this meeting time. More details will follow once the meeting is scheduled. > Thanks, > > Chris, Joe, and Sean > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] tls - New Interim Meeting Request
A new interim meeting request has just been submitted by Joseph Salowey. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-tls-01 - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Meeting Type: Virtual Meeting Session 1: Date: 2020-04-27 Start Time: 12:00 America/Los_Angeles Duration: 02:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Transport Layer Security (tls) WG Virtual Meeting: 2020-04-27
The Transport Layer Security (tls) Working Group will hold a virtual interim meeting on 2020-04-27 from 12:00 to 14:00 America/Los_Angeles (19:00 to 21:00 UTC). Agenda: 1. Administrivia and agenda bashing 2. ECHO 3. PSK design team readout Information about remote participation: Remote participation information will be obtained at the time of approval ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Virtual TLS Interim Meeting
Hi Joe, Pre-agenda bashing question for chairs and authors of the ESNI/ECHO draft... I'd like to try again to suggest simplifications for ECHOConfig (e.g. no extensions, just one public key per RR VALUE etc.) and perhaps also some more rules constraining inner/outer CH variances. How would you prefer those be raised? As issues in GH or threads on the list and would you rather I try group 'em as much as possible or make each issue as fine-grained as possible? Optimistically, this meeting might be the one where we mostly tie this stuff down, so I hope it's ok that some of these issues have been raised before in one form or another. The move from ESNI->ECHO and to HTTPSSVC and the goal to get to WGLC I think justifies re-checking if we really need the current level of (what I claim is too much:-) complexity in ECHO. Ta, S. On 03/04/2020 18:15, Joseph Salowey wrote: > On Tue, Mar 24, 2020 at 7:54 PM Joseph Salowey wrote: > >> The chairs think it would be good to schedule a virtual TLS interim >> focused on ECHO and also have a readout from the PSK design team. We have >> some dates that the IESG has recommended for us. The proposal is: >> >> 1900 - 2100 UTC April 27 >> >> Please use the following form to let us know if you can attend: >> >>https://forms.gle/Wkk7dsx9q1ipmi2B9 >> >> > [Joe] Of the 26 responses only 1 indicated that the time did not work so we > are moving forward with requesting this meeting time. More details will > follow once the meeting is scheduled. > > >> Thanks, >> >> Chris, Joe, and Sean >> > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
