--On Sunday, July 18, 2010 14:55 +0200 Patrik Fältström
<paf@xxxxxxxxx> wrote:
> On 18 jul 2010, at 10.27, John C Klensin wrote:
>
>> Those problems are most evident with
>> aliases like CNAME and DNAME but, from the cross-tree pointer
>> perspective, MX, NAPTR, and your new proposal may be just
>> aliases on steroids.
>
> My suggestion in this draft (as explained in the Security
> Considerations Section of draft-faltstrom-uri) is to have the
> URI RR secured by DNSSEC, and then SSL cert match the hostname
> in the URI that you find in the RDATA.
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. 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.
>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.
(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.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf