Hi Patrik,
--On July 19, 2010 4:42:51 AM +0200 Patrik Fältström <paf@xxxxxxxxx>
wrote:
From my point of view, adding additional RR types with those
properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME)
does increase the security risks -- not by adding risks that
were not there before, but by making it harder to keep track of
and analyze the various risk vectors, especially when these
various RR types can have data that points to others of them.
YMMD.
Ok. I think the current resolution mechanism in the daboo-srv-caldav
draft also have a very "interesting" security mechanism as that is
relying on a correct SRV plus a redirect in HTTP that can redirect to
anything...and in this second step you rely on both the SRV and the HTTP
redirect actually refer you to the correct resource.
This can be tied down of course if the HTTP redirect and the SRV are
bound to:
- The SRV not do a referral outside the domain in question
- The http redirect is on the same server the SRV referred to
But that also removes some "interesting" flexibility that one might want
to do. Like hosting virtual domains at some hosting company.
So the security in draft-daboo-srv-caldav is mostly addressed by reference
to draft-saintandre-tls-server-id-check. In particular that draft describes
use of the X509 SRVName attribute as a means for a client to determine that
the SRV lookup results they got are valid (in addition to doing normal
hostname checks on the actual host). I would suggest that your draft
reference draft-saintandre-tls-server-id-check too, and perhaps suggest the
same use of SRVName verification but in this case applied to the URI RR.
(2) It seems to me that "we" may be creating very high
expectations in the community for the security and integrity of
information in DNSSEC-signed zones that can be validated with a
root trust anchor (look at almost any of the recent
announcements for examples). While I understand the "DNSSEC for
the URI RR; TLS/SSL cert for the URI's hostname" model mentioned
above and described in the I-D, the reality is that many,
perhaps most, of the TLS/SSL certs in the world are nearly
useless or, to put it more politely, offer a very low level of
assurance relative to what people have been encouraged to
believe about root-anchored DNSSEC.
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
Bear in mind that the web folks are also looking at a solution in their
domain - in particular proposals such as webfinger are a way to map an
identifier (in this case based on a new acct: URI scheme) to various
services.
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.
So Alexey did ask the authors of .well-known about this use and we have a
little side-thread going on that. I am certainly willingly to be persuaded
that draft-daboo-srv-caldav is stretching the use too far, in which case I
would suggest a "TXT path='/xyz'" solution.
So one question I have with URI is whether additional "metadata" is likely
to be needed? In which case TXT is likely to be used at provide that. If
that is the case, then I don't see why URI is needed, vs SRV/TXT (with a
path= in the TXT).
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.
Luckily, Maastricht is a week from now and we can talk about it.
I'm up for that.
--
Cyrus Daboo
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf