Subject: Re: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt

From: Ondrej Mikle <[email-masked]>
Date: Fri, 01 Jul 2011 15:01:12 +0200

On 06/29/11 19:55, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS-based Authentication of Named
Entities Working Group of the IETF.
[...]
> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt

1) One suggestion for clarity:

  Page 6, paragraph 2 - rest of Section 3.1 reads:

   "In principle, DANE information expressing CA constraints can be
   presented with or without DNSSEC protection.  Presenting DANE
   information without DNSSEC protection does not introduce any new
   vulnerabilities, but neither does it add much assurance.  Deletion of
   records removes the protection provided by this constraint, but the
   client is still protected by CA practices (as now).  Injected or
   modified false records are not useful unless the attacker can also
   obtain a certificate for the target domain.  Thus, In the worst case,
   tampering with these constraints increases the risk of false
   authentication to the level that is now standard."

Since the case of CA constraints without DNSSEC/IPSec was much discussed (e.g.
https://www.ietf.org/mail-archive/web/dane/current/msg02682.html), this section
might use explicit note mentioning the "downgrade to type 1 (EE cert) attack" is
not possible in this scenario and is covered/implied by Section 3.3, where
DNSSEC is required.

2) Minor fixes (typos, missing words - changes enclosed in asterisks):

Section 3.1, paragraph 3:

- missing verb "be":

   Alice may wish to provide similar information to an external CA
   operator Charlie.  Prior to issuing a certificate for
   alice.example.com to someone claiming to *be* Alice, Charlie needs to

- extend "RPs" to "relying parties" (the acronym appears only once):

   Alice could
   indicate her preferred CA using DANE to CAs as well as *to relying parties*.

- Page 6, paragraph 2 - de-capitalize "In" in the last sentence

   Thus, *in* the worst case,
   tampering with these constraints increases the risk of false
   authentication to the level that is now standard.

Regards,
  Ondrej Mikle