On Wed, Jul 05, 2023 at 04:34:28PM +0200, Thom Wiggers wrote:
>
> 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,
> >
> > * 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.
The transcript would be computed with plain AuthKEM or TLS rules.
This is already required for handling the case where client thinks the
server supports PSK-KEM, but the server supports only TLS (e.g., due to
information time skew, or non-uniform cluster). This needs to fallback
to regular TLS.
> > 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.
Unfortunately, I don't think DNS is capable of handling the more
elaborate MTC negotiation.
With regard to certificate size, the main limit with newer DNS
transports (Do{T,Q,H,H3}) is the hard 64kB limit for a record set.
I think nowadays certificates are mostly 2.5-7kB or thereabouts.
However, future post-quantum certificates can be much larger.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
