> You're saying that the server should know the sorry state of its
> DNS TLSA RRs as seen by the client. This is likely impractical.
> Servers just have key material and do TLS handshakes they are
> DNSSEC/DANE agnostic. They have no idea what mechanism if any the
> client is planning to use to authenticate the server's keys/certs.
I agree that the server software should not be trying to figure out
"TLSA RRs as seen by the client". The server may not have access to
the same DNS servers as the client. The best that we can ask is
that the system administrator of the server "keeps in mind" the
public configuration of the TLSA records that relate to the server.
I would be surprised to hear anyone in this group claiming that the
TLS server can be configured completely independently of the TLSA
records published in its domain. In particular, the keys used in the
TLSA records and in the TLS server have to be coordinated so that they
match. If they are not coordinated, DANE will never work with that
TLS server.
So, given that the people who configure the server must already know
whether their domain is publishing TLSA records that authenticate
their PKIX certificate, why is it such a stretch for the people who
configure the server to also know whether their domain is publishing
TLSA records that authenticate an RPK used by the server?
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
