On 18 jul 2010, at 22.04, John C Klensin wrote: > Patrik, I'll try to study your URI draft more carefully before > getting to Maastricht, but, based on looking through it a few > times, it seems to me that: > > (1) If the RR contains a domain name outside the zone of its > ownername, one essentially loses all hope of using DNSSEC > mechanisms for validation. DNSSEC is validating that the URI itself is what did come from the authoritative source. So you know the URI is not "fake". That is what you get, regardless of whether the domain name in the URI is in the same or some other domain. Nothing more than that. > If the URI itself it resolves to an > alias, the problem may be no worse, but is harder to think > about. I know that you know this already, but it seems to me > that the Security Considerations section should address it. >> Fair. > 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. > (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 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. 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. Patrik
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf