jdev - 2020-11-13

  1. defanor

    If a user sets server host name and port manually, and the address (A/AAAA) record chosen to connect to it passes DNSSEC validation, is it okay to perform DANE TLSA verification against that manually provided host name?

  2. flow

    defanor, you don't perform TLSA verification against the provided host name, you perform it against the provided xmpp service name

  3. flow

    e.g. user configures his jid to be "user@example.org" and host name to be "enterprise.example.org", then you would perform TLSA verification against "example.org"

  4. defanor

    But with SRV records it would be "enterprise.example.org", according to <https://tools.ietf.org/html/draft-ietf-dane-srv-14#section-3.3>, so it seemed to me that with a manually provided host name it would be similar, since it more or less replaces SRV.

  5. flow

    this only talks about the TLSA DNS query (/lookup)

  6. flow

    i.e., it says that you want to lookup the TLSA record on the SRV target

  7. defanor

    Indeed. I thought I've read in one of the related RFCs that it allows to use certificates for different domains on different servers, but probably misunderstood something; re-reading the RFCs. And GnuTLS's dane_verify_session_crt seems to only assume a single domain name, not one for the certificate and one for TLSA. Still, what are the required conditions to use DANE with a manually provided host?

  8. flow

    defanor, dunno, but I could imagine that you do the TLSA lookup on the user provided DNS name

  9. defanor

    https://tools.ietf.org/html/rfc7673#section-6 -- if I'm reading it right, with DANE-EE there's no constraints on certificate's identifier, and with DANE-EE it could be either service/source or target server/derived domain. Or am I misinterpreting it?

  10. defanor

    "and with non-DANE-EE", rather.

  11. Zash

    https://tools.ietf.org/html/rfc7712 ✎

  12. Zash

    https://tools.ietf.org/html/rfc7712#section-5.1 even ✏

  13. flow

    defanor, yes, that appears right. but the problem is the "and/or" part in RFC7673 ยง 6. as most APIs only take one identifier as input (sure you could invoke the verify() method multiple times)

  14. flow

    personally, if in doubt, I would always use the XMPP service name and not the DNS name of the discovered/expliclity configured host for verification

  15. Zash

    Yeah, you start with the identifier you got from the user. Only use something if it can be securely derived from that.

  16. flow

    Zash, but in this case I get two identifiers from the user: the user's JID domainpart and the DNS name of the server hosting the XMPP service

  17. Zash

    Hmm, rgiht ✎

  18. Zash

    Hmm, right. ✏