[TLS] Re: ECH status
Hiya, Good to see things moving along, thanks. On 9/17/24 06:05, Joseph Salowey wrote: There has been some discussion of ECH proxy on the list, but something similar has already been discussed as pointed out in the thread and there does not appear to be consensus to make this sort of change in this version. That's the correct call. As I read the discussion on the list, it seemed to involve basically breaking ECH, so let's just not do that. The idea also seemed to involve a bit of a maybe unintended side-swipe at DNSSEC, and we shouldn't make that worse either;-) The server code for handling split-mode backend accept confirms is also pretty trivial and not a reason to change anything. Cheers, S. PS: If anyone would like to play with any kind of ECH split-mode tests/trials, do ping me off-list, esp. if you'd be willing to play the client-facing part of such a game. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS Interim (was Re: interim-2024-tls-01 interim approved)
Hi! Another reminder that we have a virtual interim scheduled for 2024-10-01 @ 9am Pacific time. We are still working out the details but the topic is Trust Expressions / Trust Anchor Transition. Cheers, spt > On Sep 10, 2024, at 13:33, Sean Turner wrote: > > Hi! We have scheduled a virtual interim to discuss Trust Expressions / Trust > Anchors Transition. We are in the process of defining some ground rules for > the meeting as well as setting some expected outcomes, but we wanted to get > the interim on the calendar. > > Cheers, > spt > >> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool >> wrote: >> >> >> An interim meeting for tls has been approved or does not require additional >> approval. >> A message has been sent to the secretariat requesting the interim be >> announced. >> >> >> - >> Working Group Name: Transport Layer Security >> Area Name: Security Area >> Session Requester: Sean Turner >> >> Meeting Type: Virtual Meeting >> >> Session 1: >> >> Date: 2024-10-01 >> Start Time: 12:00 America/New_York >> Duration: 03:00 >> Remote Participation Information: >> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >> Agenda Note: >> >> - >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS 1.3 ACKs near the version transition
Ah, I just noticed this text at the end of Section 7.1: > Note that in some cases it may be necessary to send an ACK which does not contain any record numbers. For instance, a client might receive an EncryptedExtensions message prior to receiving a ServerHello. Because it cannot decrypt the EncryptedExtensions, it cannot safely acknowledge it (as it might be damaged). If the client does not send an ACK, the server will eventually retransmit its first flight, but this might take far longer than the actual round trip time between client and server. Having the client send an empty ACK shortcuts this process. https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8 I guess then the intent is indeed that if you receive some random encrypted DTLS 1.3 header, even though you don't know it's DTLS 1.3 yet, you interpret as activating the ACKing mechanism? But that seems to prompt more questions than it answers. For instance, what happens if you do that, but then finally receive the ServerHello and it turns out this was just some junk packet and we're really negotiation DTLS 1.2? Do you check that the ACK mechanism has been activated and return an error? Do you just pause the ACK mechanism and hope you're in an OK state? This seems quite prune to send the implementation into unexpected and untested states. On Thu, Sep 12, 2024 at 4:31 PM David Benjamin wrote: > Hi all, > > I noticed another issue with the DTLS 1.3 ACK design. :-) > > So, DTLS 1.3 uses ACKs. DTLS 1.2 does not use ACKs. But you only learn > what version you're speaking partway through the lifetime of the > connection, so there are some interesting corner cases to answer. As an > illustrative example, I believe the diagram in section 6 is [probably] > incorrect: > https://www.rfc-editor.org/rfc/rfc9147.html#section-6 > > If the client loses the first packet, it never sees the ServerHello and > thus learns it's speaking DTLS 1.3. While it does see the second packet, > that packet only contains ciphertext that it cannot decrypt. Unless it > decides to say "this looks like a 1.3 record header, therefore I will turn > on the 1.3 state machine", which isn't supported by the RFC (maybe TLS 1.4 > will use the same record header but redo ACKs once again), it shouldn't > activate the 1.3 state machine yet. I expect what will *actually* happen > is that the client will wait for the retransmission timeout a la DTLS 1.2. > > More generally, I believe these are the situations to worry about: > > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all) implementation > receives an ACK record for whatever reason, what happens? This decision we > don't get to change. Rather, it is a design constraint. Both OpenSSL and > BoringSSL treat unexpected record types as a fatal error. I haven't checked > other implementations. So I think we must take as a constraint that you > cannot send an ACK unless you know the peer is 1.3-capable. > > 2. Do plaintext ACKs exist? Or is the plaintext epoch permanently at the > old state machine? Honestly, I wish the answer here was "no". That would > have avoided so many problems, because then epochs never change state > machines. Unfortunately, the RFC does not support this interpretation. > Section 4.1 talks about how to demux a plaintext ACK, and section 6, though > wrong, clearly depicts a plaintext ACK. So instead we get to worry about > the transition within an epoch. Keep in mind that transitions happen at > different times on both sides. Keep in mind that there is a portion of the > plaintext epoch that lasts after version negotiation in HelloRetryRequest > handshakes. > > 3. If a 1.3-capable server receives half of a ClientHello, does it send an > ACK? I believe (1) means the answer must be "no". If you haven't read the > ClientHello, you haven't selected the version, so you don't know if the > client is 1.3-capable or not. If the client is not 1.3-capable, sending an > ACK may be incompatible. > > 4. Is it possible for a 1.3-capable client to receive an ACK *before* it > receives a ServerHello? If so, how does the client respond? I believe the > answer to this question, if plaintext ACKs exist, is unavoidably "yes". > Suppose the server receives a 1.3 ClientHello and then negotiates DTLS 1.3. > That is a complete flight, so Section 7.1 discourages ACKing explicitly > (you can ACK implicitly), but it *does not forbid* an explicit ACK. An > explicit ACK may be sent if the server cannot generate its responding > flight immediately. That means a server could well send ACK followed by > ServerHello. Now suppose ServerHello is lost but the ACK gets through. Now > the client must decide what it's doing. Rejecting the ACK would result in > connection failure, so we must either drop the ACK on the floor, or process > it. While processing it would be more efficient (you don't need to > retransmit the whole ClientHello), it means the plaintext epoch must > support this hybrid state where 1.3 ACKs are processed but never sent! Or >
[TLS] Re: DTLS 1.3 ACKs near the version transition
> On Sep 17, 2024, at 5:28 PM, David Benjamin > wrote: > > Ah, I just noticed this text at the end of Section 7.1: > > > Note that in some cases it may be necessary to send an ACK which does not > > contain any record numbers. For instance, a client might receive an > > EncryptedExtensions message prior to receiving a ServerHello. Because it > > cannot decrypt the EncryptedExtensions, it cannot safely acknowledge it (as > > it might be damaged). If the client does not send an ACK, the server will > > eventually retransmit its first flight, but this might take far longer than > > the actual round trip time between client and server. Having the client > > send an empty ACK shortcuts this process. > > https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8 > > I guess then the intent is indeed that if you receive some random encrypted > DTLS 1.3 header, even though you don't know it's DTLS 1.3 yet, you interpret > as activating the ACKing mechanism? But that seems to prompt more questions > than it answers. For instance, what happens if you do that, but then finally > receive the ServerHello and it turns out this was just some junk packet and > we're really negotiation DTLS 1.2? Do you check that the ACK mechanism has > been activated and return an error? Do you just pause the ACK mechanism and > hope you're in an OK state? This seems quite prune to send the implementation > into unexpected and untested states. > > Yeah, I think this has missed a nasty corner case here for implementations that support both. I think I also lean towards option A) (from below) here. Anyone else who has gotten at least their hands mildly dirty in a DTLS implementation that supports both 1.2 and 1.3 care to chime in as well? > On Thu, Sep 12, 2024 at 4:31 PM David Benjamin wrote: > Hi all, > > I noticed another issue with the DTLS 1.3 ACK design. :-) > > So, DTLS 1.3 uses ACKs. DTLS 1.2 does not use ACKs. But you only learn what > version you're speaking partway through the lifetime of the connection, so > there are some interesting corner cases to answer. As an illustrative > example, I believe the diagram in section 6 is [probably] incorrect: > https://www.rfc-editor.org/rfc/rfc9147.html#section-6 > > If the client loses the first packet, it never sees the ServerHello and thus > learns it's speaking DTLS 1.3. While it does see the second packet, that > packet only contains ciphertext that it cannot decrypt. Unless it decides to > say "this looks like a 1.3 record header, therefore I will turn on the 1.3 > state machine", which isn't supported by the RFC (maybe TLS 1.4 will use the > same record header but redo ACKs once again), it shouldn't activate the 1.3 > state machine yet. I expect what will actually happen is that the client will > wait for the retransmission timeout a la DTLS 1.2. > > More generally, I believe these are the situations to worry about: > > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all) implementation > receives an ACK record for whatever reason, what happens? This decision we > don't get to change. Rather, it is a design constraint. Both OpenSSL and > BoringSSL treat unexpected record types as a fatal error. I haven't checked > other implementations. So I think we must take as a constraint that you > cannot send an ACK unless you know the peer is 1.3-capable. > > 2. Do plaintext ACKs exist? Or is the plaintext epoch permanently at the old > state machine? Honestly, I wish the answer here was "no". That would have > avoided so many problems, because then epochs never change state machines. > Unfortunately, the RFC does not support this interpretation. Section 4.1 > talks about how to demux a plaintext ACK, and section 6, though wrong, > clearly depicts a plaintext ACK. So instead we get to worry about the > transition within an epoch. Keep in mind that transitions happen at different > times on both sides. Keep in mind that there is a portion of the plaintext > epoch that lasts after version negotiation in HelloRetryRequest handshakes. > > 3. If a 1.3-capable server receives half of a ClientHello, does it send an > ACK? I believe (1) means the answer must be "no". If you haven't read the > ClientHello, you haven't selected the version, so you don't know if the > client is 1.3-capable or not. If the client is not 1.3-capable, sending an > ACK may be incompatible. > > 4. Is it possible for a 1.3-capable client to receive an ACK before it > receives a ServerHello? If so, how does the client respond? I believe the > answer to this question, if plaintext ACKs exist, is unavoidably "yes". > Suppose the server receives a 1.3 ClientHello and then negotiates DTLS 1.3. > That is a complete flight, so Section 7.1 discourages ACKing explicitly (you > can ACK implicitly), but it does not forbid an explicit ACK. An explicit ACK > may be sent if the server cannot generate its responding flight immediately. > That means a server coul
