* Olafur Gudmundsson <[email protected]>: > Thank you Victor > > On May 12, 2014, at 3:27 PM, Viktor Dukhovni <[email protected]> wrote: > > > On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote: > > > >> Objective: > >> > >> ... > >> DANE functionality to their work. In addition the working group > >> will monitor and provide guidance to operators and tool developers. > >> will monitor and provide guidance to operators and tool developers. > > > > The above is a duplicate line. > > Fixed in version 03 to be posted soon > > > > >> The DANE working group has developed a framework for securely > >> retrieving keying information from the DNS [RFC6698]. This > >> framework allows secure storing and looking up public key > >> information in the DNS. This provides a binding between a domain > >> name providing a particular service and the key that can be used > >> to establish encrypted connection to that service. > > > > [ The below thoughts are likely too specific to rise to visibility > > in the charter, so are more likely fodder for 6698 revisions. ] > > > > The RFC6698-specified lookup key of _<port>._<proto>.<fqdn> is not > > universally applicable. It works OK for well known services such > > as SMTP on ports 25/587 or HTTPS on 443, but is not always well > > suited to environments in which service ports are dynamically > > registered. Also, sometimes the verifier wants to authenticate a > > TLS client acting on behalf of some domain in an appropriate > > capacity. > > > This also works well for services looked up via SRV records. > As the SRV contains the port number. > For a protocol that has some kind of other selector of port, still at the end > of the day > the "Server" side has a "known-port" to the client, if the service moves from > one port to another port OR > provides service on multiple ports then it is possible that the protocol > definition for the DANE variant of that protocol can say > lookup of Authentication records is <Proto>FP at hostname. > > > Applications will in some use-cases need to agree on a lookup key > > that is not tied to a numeric port. It could be a service name or > > a client role. While a generic DANE TLS RFC (e.g. 6698) cannot > > anticipate or standardize such alternative lookup keys, a future > > update to 6698 should I think mention the need for such bindings, > > and encourage applications employing DANE TLSA to define appropriate > > alternative lookup keys. This could be of immediate benefit in > > XMPP to authenticate the origin of inbound traffic. > > > > Interesting are you you are saying we want to examine/specify client side > DANE > records (right now DANE is all about server side records).
I suggested that once to Viktor in an offlist mail, because I think a Receiver might also want to know, which Sender it talks to. Thesis: If I were a company to whom suppliers deliver work via email, I'd like to ensure its really them and not someome else, who sends me the production plan for some vital component. BTW: We run a mail gateway for suppliers who must deliver their work via TLS to their customers. The only way to enforce that is setting a policy on the sending side. I'd find a policy on the receiving side that incorporates DANE (if you can do it I require you to use it) attractive. Also for e.g. banks that need to exchange data between themselves. If encryption is vital there should be a mutual encryption policy. Each side should be able to enforce a policy that requires the other party to use encryption or transport will be rejected. +1 from my side if that helps to examine the usefulness of client side DANE. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
