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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf