On May 12, 2014, at 4:46 PM, Patrick Ben Koetter <[email protected]> wrote:
> * 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 > Patrick, This is real good input thank you for posting this. I'm willing to add text to the charter to address this, at the end of paragraph #3: "In addition the WG may develop a framework to look up "client" side DANE records for authorization/authentication purposes." (will finalize after more feedback and talking to Warren) Olafur _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
