Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions
Hi Devon I support adoption On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov wrote: > I support adoption. > > Cheers, > > Andrei > > -Original Message- > From: TLS On Behalf Of Watson Ladd > Sent: Friday, April 26, 2024 7:13 PM > To: Devon O'Brien > Cc: tls@ietf.org; Bob Beck > Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions > > On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien 40google@dmarc.ietf.org> wrote: > > > > After sharing our first draft of TLS Trust Expressions and several > discussions across a couple IETFs, we’d like to proceed with a call for > working group adoption of this draft. We are currently prototyping trust > expressions in BoringSSL & Chromium and will share more details when > implementation is complete. > > > > > > As we mentioned in our message to the mailing list from January, our > primary goal is to produce a mechanism for supporting multiple subscriber > certificates and efficiently negotiating which to serve on a given TLS > connection, even if that ends up requiring significant changes to the draft > in its current state. > > > > > > To that end, we’re interested in learning whether wg members support > adoption of this deployment model and the currently-described certificate > negotiation mechanism or if they oppose adoption (and why!). > > We absolutely need to solve the problem and the draft is a good starting > point. > > > > > > > Thanks! > > > > David, Devon, and Bob > > > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www/. > > ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7CAndrei.Popov%40micr > > osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7 > > cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C% > > 7C=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D=0 > > > > -- > Astra mortemque praestare gradatim > > ___ > 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
Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3
On Sat, Apr 27, 2024, 8:03 AM David Benjamin wrote: > What should the next steps be here? Is this a bunch of errata, or > something else? > Errata at a minimum but this might be big enough for a small RFC describing the fix. > > On Wed, Apr 17, 2024 at 10:08 AM David Benjamin > wrote: > >> > Sender implementations should already be able to retransmit messages >> with older epochs due to the "duplicated" post-auth state machine >> >> The nice thing about option 7 is that the older epochs retransmit problem >> becomes moot in updated senders, I think. If the sender doesn't activate >> epoch N+1 until KeyUpdate *and prior messages* are ACKed and if KeyUpdate >> is required to be the last handshake message in epoch N, then the previous >> epoch is guaranteed to be empty by the time you activate it. >> >> On Wed, Apr 17, 2024, 09:27 Marco Oliverio wrote: >> >>> Hi David, >>> >>> Thanks for pointing this out. I also favor solution 7 as it's the >>> simpler approach and it doesn't require too much effort to add in current >>> implementations. >>> Sender implementations should already be able to retransmit messages >>> with older epochs due to the "duplicated" post-auth state machine. >>> >>> Marco >>> >>> On Tue, Apr 16, 2024 at 3:48 PM David Benjamin >>> wrote: >>> Thanks, Hannes! Since it was buried in there (my understanding of the issue evolved as I described it), I currently favor option 7. I.e. the sender-only fix to the KeyUpdate criteria. At first I thought we should also change the receiver to mitigate unfixed senders, but this situation should be pretty rare (most senders will send NewSessionTicket well before they KeyUpdate), DTLS 1.3 isn't very widely deployed yet, and ultimately, it's on the sender implementation to make sure all states they can get into are coherent. If the sender crashed, that's unambiguously on the sender to fix. If the sender still correctly retransmits the missing messages, the connection will perform suboptimally for a blip but still recover. David On Tue, Apr 16, 2024, 05:19 Tschofenig, Hannes < hannes.tschofe...@siemens.com> wrote: > Hi David, > > > > this is great feedback. Give me a few days to respond to this issue > with my suggestion for moving forward. > > > > Ciao > > Hannes > > > > *From:* TLS *On Behalf Of *David Benjamin > *Sent:* Saturday, April 13, 2024 7:59 PM > *To:* > *Cc:* Nick Harper > *Subject:* Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS > 1.3 > > > > Another issues with DTLS 1.3's state machine duplication scheme: > > > > Section 8 says implementation must not send new KeyUpdate until the > KeyUpdate is ACKed, but it says nothing about other post-handshake > messages. Suppose KeyUpdate(5) in flight and the implementation decides to > send NewSessionTicket. (E.g. the application called some > "send NewSessionTicket" API.) The new epoch doesn't exist yet, so naively > one would start sending NewSessionTicket(6) in the current epoch. Now the > peer ACKs KeyUpdate(5), so we transition to the new epoch. But > retransmissions must retain their original epoch: > > > > > Implementations MUST send retransmissions of lost messages using the > same epoch and keying material as the original transmission. > > https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1-3 > > > > This means we must keep sending the NST at the old epoch. But the peer > may have no idea there's a message at that epoch due to packet loss! > Section 8 does ask the peer to keep the old epoch around for a spell, but > eventually the peer will discard the old epoch. If NST(6) didn't get > through before then, the entire post-handshake stream is now wedged! > > > > I think this means we need to amend Section 8 to forbid sending *any* > post-handshake message after KeyUpdate. That is, rather than saying you > cannot send a new KeyUpdate, a KeyUpdate terminates the post-handshake > stream at that epoch and all new post-handshake messages, be they > KeyUpdate > or anything else, must be enqueued for the new epoch. This is a little > unfortunate because a TLS library which transparently KeyUpdates will then > inadvertently introduce hiccups where post-handshake messages triggered by > the application, like post-handshake auth, are blocked. > > > > That then suggests some more options for fixing the original problem. > > > > *7. Fix the sender's KeyUpdate criteria* > > > > We tell the sender to wait for all previous messages to be ACKed too. > Fix the first paragraph of section 8 to say: > > > > > As with other handshake messages with no built-in
Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3
What should the next steps be here? Is this a bunch of errata, or something else? On Wed, Apr 17, 2024 at 10:08 AM David Benjamin wrote: > > Sender implementations should already be able to retransmit messages > with older epochs due to the "duplicated" post-auth state machine > > The nice thing about option 7 is that the older epochs retransmit problem > becomes moot in updated senders, I think. If the sender doesn't activate > epoch N+1 until KeyUpdate *and prior messages* are ACKed and if KeyUpdate > is required to be the last handshake message in epoch N, then the previous > epoch is guaranteed to be empty by the time you activate it. > > On Wed, Apr 17, 2024, 09:27 Marco Oliverio wrote: > >> Hi David, >> >> Thanks for pointing this out. I also favor solution 7 as it's the simpler >> approach and it doesn't require too much effort to add in current >> implementations. >> Sender implementations should already be able to retransmit messages with >> older epochs due to the "duplicated" post-auth state machine. >> >> Marco >> >> On Tue, Apr 16, 2024 at 3:48 PM David Benjamin >> wrote: >> >>> Thanks, Hannes! >>> >>> Since it was buried in there (my understanding of the issue evolved as I >>> described it), I currently favor option 7. I.e. the sender-only fix to the >>> KeyUpdate criteria. >>> >>> At first I thought we should also change the receiver to mitigate >>> unfixed senders, but this situation should be pretty rare (most senders >>> will send NewSessionTicket well before they KeyUpdate), DTLS 1.3 isn't very >>> widely deployed yet, and ultimately, it's on the sender implementation to >>> make sure all states they can get into are coherent. >>> >>> If the sender crashed, that's unambiguously on the sender to fix. If the >>> sender still correctly retransmits the missing messages, the connection >>> will perform suboptimally for a blip but still recover. >>> >>> David >>> >>> >>> On Tue, Apr 16, 2024, 05:19 Tschofenig, Hannes < >>> hannes.tschofe...@siemens.com> wrote: >>> Hi David, this is great feedback. Give me a few days to respond to this issue with my suggestion for moving forward. Ciao Hannes *From:* TLS *On Behalf Of *David Benjamin *Sent:* Saturday, April 13, 2024 7:59 PM *To:* *Cc:* Nick Harper *Subject:* Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3 Another issues with DTLS 1.3's state machine duplication scheme: Section 8 says implementation must not send new KeyUpdate until the KeyUpdate is ACKed, but it says nothing about other post-handshake messages. Suppose KeyUpdate(5) in flight and the implementation decides to send NewSessionTicket. (E.g. the application called some "send NewSessionTicket" API.) The new epoch doesn't exist yet, so naively one would start sending NewSessionTicket(6) in the current epoch. Now the peer ACKs KeyUpdate(5), so we transition to the new epoch. But retransmissions must retain their original epoch: > Implementations MUST send retransmissions of lost messages using the same epoch and keying material as the original transmission. https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1-3 This means we must keep sending the NST at the old epoch. But the peer may have no idea there's a message at that epoch due to packet loss! Section 8 does ask the peer to keep the old epoch around for a spell, but eventually the peer will discard the old epoch. If NST(6) didn't get through before then, the entire post-handshake stream is now wedged! I think this means we need to amend Section 8 to forbid sending *any* post-handshake message after KeyUpdate. That is, rather than saying you cannot send a new KeyUpdate, a KeyUpdate terminates the post-handshake stream at that epoch and all new post-handshake messages, be they KeyUpdate or anything else, must be enqueued for the new epoch. This is a little unfortunate because a TLS library which transparently KeyUpdates will then inadvertently introduce hiccups where post-handshake messages triggered by the application, like post-handshake auth, are blocked. That then suggests some more options for fixing the original problem. *7. Fix the sender's KeyUpdate criteria* We tell the sender to wait for all previous messages to be ACKed too. Fix the first paragraph of section 8 to say: > As with other handshake messages with no built-in response, KeyUpdates MUST be acknowledged. Acknowledgements are used to both control retransmission and transition to the next epoch. Implementations MUST NOT send records with the new keys until the KeyUpdate *and all preceding messages* have been acknowledged. This
