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).
> It may also be reasonable to encourage applications to choose either
> PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate
> to the problem at hand. Mixing the two yields the union of the
> interoperability problems and the intersection of the security
> features.
>
Are you proposing a BCP ?
we can add that to the milestones, after the current Operational/Errata
document is done.
Olafur
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
