Re: [certid] DNSSEC-based name canonicalization

[Peter Saint-Andre <[e-mail]>]

Interesting topic, but I see nothing in this branch of the discussion
that necessitates changes to the I-D. Do correct me if I'm wrong. :)

On 9/16/10 11:21 PM, Martin Rex wrote:
> Matt McCutchen wrote:
>>
>> On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: 
>>> Cleanup of my prior message:
>>>
>>>  
>>> Matt McCutchen wrote:
>>>>
>>>> On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
>>>>> Clearly unsafe operations:
>>>>>
>>>>>   - building a reference identifier from the result of a
>>>>>     DNS CNAME lookup
>>>>>
>>>>> (the use of DNSSEC does not make this safe)
>>>>
>>>> Why not?  I'm not saying it's good practice, but I don't see an actual
>>>> vulnerability.
>>>
>>> You need two characteristics:
>>>  
>>>   (1) _trustworty_ information source for a name transformation
>>>   (2) _protected_access_ to the information source
>>>
>>> DNSSEC meets (2) but not (1)
>>
>> Why not (1)?  It should go without saying that by DNSSEC I meant "DNSSEC
>> with a set of trustworthy trust anchors that will get us to the desired
>> signed zone".  From there, the DNS admin has full authority to say what
>> certificates a client trying to connect to a host in her zone should
>> accept.
> 
> DNS needs to be available, fast, efficient and low-low-low cost.
> 
> The cost of creating and maintaining DNS records with any trustworthyness
> that is measurably distinct from zero, with the necessary expertise to
> set up and devotion to practise scrutiny for every change to the data
> is probably going to far exceed the funding of most, if not all DNS admins.
> 
> Are there already workable procedures and APIs for software to
> distinguish "normal" DNSSEC lookup results from "trustworthy" DNSSEC
> lookup results with some level of portability?  How and how often
> would admins/consumers have to update and reconfirm every "trustworthy"
> DNSSEC key they keep?
> 
>>
>> We could have a record, CERTNAME or something, that specifies the
>> hostname for which the certificate should be valid (via keyassure or
>> PKIX + server-id-check).  I realize now that it would be dangerous to
>> reinterpret CNAME for this purpose, just as it is dangerous to
>> reinterpret CERT as making an assurance, but that is a separate issue.
>> I still wouldn't advise doing it unless we come up with a compelling use
>> case.
> 
> DNS domains is a resource that is managed pretty arbitrary on a
> first-come first-served basis.  It has some loose "a domain is leased
> to at most one entity at any single time" provision, that's it.
> DNS is vital for the internet, so it needs to remain fast,
> efficient and free, and all of that combined makes it hardly
> usable to bootstrap an infrastructure of trust, with any meaningful
> level of trust.
> 
> The fraction of resources that web browsers accesses through HTTPS,
> where the first HTTPS link is served through a page received via
> HTTP in a completely untrusted fashion is mindboggling.
> Example "ebay".  What do you think: how many users that login
> through the ebay sign-in page via HTTPS every day, have supplied
> the URL of the signin page in a trusted&secure fashion, and
> how many open http://www.ebay.<country> and click a link
> on that page?
> 
> How about online banking?  An internet commerce that cares strongly
> about security should serve only one single "301 Moved Permanently"
> page with an HTTPS url on port 80, making it difficult to bookmark
> anything else than a HTTPS urls to this site.
> 
> "Secure" electronic commerce on the internet is often
> like a handful of iron rings that are quickly attached to
> each other with tiny rubber bands from the kitchen drawer
> in order to give the impression of a chain.  Occasionally,
> some of these "chains" rip apart by their own weight alone.