--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström
<paf@xxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf