* Olafur Gudmundsson <ogud@ogud.com>:
> Thank you Victor 
> 
> On May 12, 2014, at 3:27 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> 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