--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström
<paf(_at_)cisco(_dot_)com> wrote:
...
No luser is going to understand the difference between the two
elements of the validation mechanism. Far more likely, the
"weakest link" principle will apply and the expectation of
security from DNSSEC will drop to that of the quality of the
typical self-signed or "prove that you own the domain name by
receiving mail" TLS/SSL cert. Again, at a minimum, I think
your Security Considerations section should analyze and warn
about the fragility in practice of the approach you suggest.
What I think might be needed is that IETF comes up with a
proper architecture for the following:
"An application do have the need to contact a service. The
service is identified by a unique identifier that is
registered by IANA (that identifies a service) and a domain
name. On top of that, there might be a sub-identifier in the
form of a unique identifier for a user (i.e. local part in an
email address etc). What are the steps the application should
go through before it actually opens some connections over IP,
and what should it do then to secure the whole thing."
We have a number of alternatives:
1. Use MX
2. Use SRV and well known algorithm for the service, using
prefixes of the owner
3. Use A and AAAA and well known algorithm
4. We have DDDS, using NAPTR with service selection in RDATA
if DNS is used as the base database (of various flavours,
UNAPTR etc)
5. We have the daboo-srv-caldav that uses SRV plus
http redirect from a .well-known path that is used in the HTTP
transaction
6. We have TXT records with well known syntax in the RDATA
7. I propose using a SRV-like prefix naming that
give back full URIs, and the rest of the resolution have to do
with URI resolution
Part of the question I'd asking is whether, given the rate of
growth, we will have 20 of those options a few years from now.
If we do, what will that do to implementer confusion,
interoperability, and security? The assumption that new RR
types are fairly cheap does not imply that adding more and more
nearly-equivalent (or at least functionally-overlapping) ones is
desirable. So, yes, I think it may be time to do some serious
architectural work here that comes up with specific guidelines,
both about new RRs in this general area and about what should be
used when. If we can't give crisp answers to the latter
question, it may be time to start deprecating options, not just
adding more of them.
Let me state that I do not think we should delay the
draft-daboo-srv-caldav IF a work like this is started. If we
get some work like this, I suggest letting
draft-daboo-srv-caldav pass, given people do not think the
solution with an http redirect is too weird.
Agreed. I would not have stepped into this discussion at all
had the possibility of substituting a still-unapproved new RR
type not come up. I think the discussion has been very useful,
but don't believe that we should hold the present draft up as a
result.
I do not like the mechanism proposed in
draft-daboo-srv-caldav. Definitely not. But that is a
different thing than requiring rough consensus on a generic
way of finding an endpoint of a connection for a service.
Agree with that too, including not liking the mechanism.
Luckily, Maastricht is a week from now and we can talk about
it.
In our collective copious spare time.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf