[TLS] April Vitrual TLS Interim Scheduled
The April TLS interim virtual meeting is scheduled for 2020-04-27 19:00 - 21:00 UTC More details will follow shortly. Agenda is available here: https://datatracker.ietf.org/meeting/interim-2020-tls-01/session/tls Cheers, Sean, Joe and Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New Version Notification for draft-rashok-tls-ticket-request-msg-01.txt
Hi All, Updated draft with performance improvement on Client's App data processing when TLSv1.3 server ignores session ticket msg after handshake. Requesting all to provide your opinion on this draft. +--+-+-+ | Num of Ticket | Average time taken by | Average time taken by | | send by Serv |SSL_read |SSL_read | | after handshake | (AES_GCM_256) |(Chacha20Poly1305) | +--+-+-+ |0 | 62 usecs| 56 usecs | |1 |102 usecs| 86 usecs | |2 |132 usecs| 128 usecs | |4 |195 usecs| 185 usecs | |6 |250 usecs| 241 usecs | +--+ +--+-+-+ | Num of Ticket |Average number of|Average number of| | send by Serv | connections per second | connections per second | | after handshake | (AES_GCM_256) |(Chacha20Poly1305) | +--+-+-+ |0 | 1260 | 1356 | |1 | 1134 | 1229 | |2 | 1092 | 1141 | |4 | 1001 | 1060 | |6 |929 | 1002 | +--+ A new version of I-D, draft-rashok-tls-ticket-request-msg-01.txt has been successfully submitted by Raja Ashok and posted to the IETF repository. Name: draft-rashok-tls-ticket-request-msg Revision: 01 Title: TLS Ticket Request Message Document date: 2020-04-14 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-01.txt Status: https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ Htmlized: https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg Diff: https://www.ietf.org/rfcdiff?url2=draft-rashok-tls-ticket-request-msg-01 Abstract: TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve new session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Epochs for ACKs
Hi all, On ACK protection, DTLS 1.3 Draft 37 says in Section 7: ACK records MUST be sent with an epoch that is equal to or higher than the record which is being acknowledged. Implementations SHOULD simply use the current key. Since the update of incoming and outgoing keying material is independent, I don't know how this can be enforced: After a sequence of key updates, the incoming epoch might be 42 while the outgoing epoch is 17. What problems arise if one replaces the paragraph by the following: ACK records MUST be sent with the current key, irrespective of the epoch that is used to protect the record that is being acknowledged. It appears that the paragraph is particularly relevant for the case of ACKing a ServerHello, which as far as I understand shall happen with epoch 1. Since 'current key' doesn't appear unambiguously defined at the point of the client processing the ServerHello, it might be worth spelling out this case explicitly. Best, 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] Efficiency of ACKing scheme
Hi,
Apologies for the late reply.
First, let me say that foremost I wanted to highlight the potential
efficiency problem with the current solution. The mentioned alternative
isn't yet fully thought through, so it may well have drawbacks itself
that render it no better than the current version. However, in any
case I'd hope we can in the end find a solution which doesn't suffer from
the current inefficiency, as this seems prohibitive for IoT deployments.
Replying to Ekr's initial comment first:
> ISTM that the easiest way to deal with this is to have the sender
> treat the current ACK state as the union of the states it has received
> and permit receivers to only ACK each packet once (while encouraging them
> to fill the ACK packet). Then you would retransmit if your new ACK state
> was partial rather than if the ACK was partial.
I agree, something along those lines should work and I was attempting that
with the proposed text, though spelling out the details doesn't seem entirely
straightforward. For example, we don't want to retransmit immediately if we
receive an ACK such that the new cumulative ACK state is partial, because
otherwise we'd retransmit many times while building up the ACK state. The
proposed text therefore recommends to retransmit after a sufficiently
long period during which no further ACK is received.
Receivers, in turn, may send ACKs one-by-one, though it is encouraged
to fill them, as you said.
So if I understand your comment above correctly, it appears
to be in line with the intention of the proposed new text.
Note that the proposal leaves it open whether receivers send
ACKs recurringly, even if everything is transmitted perfectly,
or only when they notice a disruption. The only recommendation
I think the text should make is that once an implementation decides
to start ACKing, it shouldn't leave a too large time-gap between
two consecutive ACKs: This is for the recommended heuristic of
"retransmission on ACK-less period" on the sender to work.
Best,
Hanno
From: Thomas Fossati
Sent: Thursday, April 9, 2020 4:12 PM
To: Eric Rescorla
Cc: Hanno Becker ; Rob Sayre ;
tls@ietf.org ; Thomas Fossati
Subject: Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 15:34, "Eric Rescorla" wrote:
> > > But this requires being able to send an empty ACK that means "I
> > > got nothing". In which case, I don't see how it's really different
> > > from the current text except that it gives the sender less
> > > guidance.
> >
> > Not sure there's an "empty ACK" in Hanno's proposal. This is how I
> > interpret it in the context of your example: in the second flight,
> > if rec#0 (containing SH) is lost and rec#1 gets through, the
> > receiver sends ACK {1}. From that the sender can infer the gap and
> > retransmit rec#0.
> >
> > You can't send ACK{1} because you can't decrypt it because it is
> > out of order with respect to the DH key. This is the point of the
> > empty ACK.
True, so you send ACK{} (as per last para of Section 7.1) and similarly
the receiver can deduce a gap -- indeed a very precise one -- and
re-send record containing the SH.
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
