On Sat, Jan 28, 2023 at 03:03:54PM +0200, Ilari Liusvaara wrote:
> On Sat, Jan 28, 2023 at 08:35:40AM +0000, John Mattsson wrote:
> > Thanks Ilari for that very fast and detailed answer. I a made a PR to
> > RFC8446bis to suggest adding “A node MAY use the same certificate as
> > both server and client certificate.”, I don’t know if there should be
> > more restrictions. The real practical problems seem to be cross-
> > protocol attacks on the application layer where TLS is used for
> > several application layer protocols.
>
> I had idea (but I never got to writing I-D) of PKIX certificate
> extension that constrained the certificate to specific set of
> explicit TLS Application Layer Protocols.
>
> E.g., constrain to {"http/1.1","h2","h3"} for HTTP certificate,
> or something like {"imap","submission"} (might need to register
> extra ALPNs) for user mailserver.
I don't think such an extension would gain much traction. To be useful,
the extension would need to be "critical", but since it would be thinly
supported, its use case would be in narrow walled-garden environments.
DANE addresses lack of specificity in certificate names by binding the
validity to a single layer 4 end-point:
$ dig +noall +ans +nosplit +multi +nottl -t tlsa
_25._tcp.dnssec-stats.ant.isi.edu
_25._tcp.dnssec-stats.ant.isi.edu. IN TLSA 3 1 1 (
B1E7FAAF6E482E2AFBC653C8E3B6BEF0E3352424AEBD24D2B480092951BC6097 )
And then, it often becomes possible to entirely dispense with the certificate:
$ posttls-finger -c -Lsummary,certmatch dnssec-stats.ant.isi.edu
posttls-finger: dnssec-stats.ant.isi.edu[128.9.29.254]:25:
raw public key fingerprint=...
posttls-finger: dnssec-stats.ant.isi.edu[128.9.29.254]:25:
Matched DANE raw public key:
3 1 1
B1E7FAAF6E482E2AFBC653C8E3B6BEF0E3352424AEBD24D2B480092951BC6097
posttls-finger: Verified TLS connection established to to
dnssec-stats.ant.isi.edu[128.9.29.254]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519
server-signature RSA-PSS (2048 bit raw public key)
server-digest SHA256
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
