Hi Ilari, Thanks for your message, I will definitely use this when looking at DTLS.
Op wo 5 jul 2023 om 14:22 schreef Ilari Liusvaara <ilariliusva...@welho.com >: > On Wed, Jul 05, 2023 at 09:26:57AM +0200, Thom Wiggers wrote: > > Hi Ilari, > > > > Thanks for pointing this out. I will admit I am pretty unaware of the > > additional constraints that DTLS has, but I will try to look at this > issue > > in more detail. In the meantime, I would also appreciate it if people who > > are also concerned about AuthKEM+DTLS share their interest and concerns, > as > > that will help with their visibility and maybe give me a list of people > to > > ask questions to :) > > Actually, the changes might not be quite so nasty: > > - The DTLS epoch numbering needs to be changed: If AuthKEM is used, > then epoch 3 needs to be autheticated_handshake epoch instead of > application_0 epoch, which is pushed to epoch 4 and then that pushes > other application epoch one number forward. > > - Fortunately even if there are 5 active epochs during handshake, > the 2 bits in DTLS header are still enough, because one of those is > plaintext, and can be recognized from record types used. > > - There actually might be chance to make the early auth work. However, > there are subtle details: > > * The certificate being a message, it is subject to acknowledgements. > However, server hello must be logically before it. This is required > to meet the acknowledgment epoch rule. > * The server flight needs to be broken into two just before server > Finished, first part being unordered with certificate, and second > being the next flight. This is required to have the certificate > available for computing finished, and to meet the implicit > acknowledgment rule. > I'm very open to hacks, such as turning it into an ECH-style encrypted extension. Whatever makes this easier. I think the main open question, also for regular client-auth pre-shared-kem-key AuthKEM is how do we treat this message in the transcript if the server *can't* decrypt this message (and tries to fall back to e.g. plain AuthKEM or TLS). But this is something that is in the issue tracker and document already. > Of course, even if the theroetical changes are not so nasty, those can > still play absolute hell with implementations. And there could be some > other gotcha I have not considered. > I will not pretend that this is not a tough change on the practical side, especially in the PSK-KEM client-authenticated case. But for some use cases, this may be worth it. If this mode is deemed "too complicated" and we have no immediate strong proponents, we might postpone solving those client-auth issues for another time. We have plenty of discussion time ahead of us to determine that path :) > And then it occured to me earlier today that web browsers might not like > the abbreviated AuthKEM very much: They really do not like to use DNS > for server authentication, instead preferring to use certificates sent > in-band. Of course, adding certificate message would duplicate the key > information, which is a footcannon. > The keys-in-DNS idea is definitely more of an extension that I do not want to solve before settling on the main protocol. The main hard problem seems to be authenticating this key in DNS, and we definitely do not want to push all certificates there. (ChrisW told me that keys-in-DNS was also briefly discussed and shot down for semi-static/OPTLS for similar reasons). I am hoping we might have some synergies with the infra that supports ECH and perhaps the proposed much-compressed merkle tree certificates though. Any such deployments, which will need to periodically update the DNS records in the case of MTCs, might be a bit more advanced but seem by no means impossible. Cheers and thanks again, Thom PQShield > > > > -Ilari > > _______________________________________________ > 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
