I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-dane-use-cases-04
Reviewer: Alexey Melnikov
Review Date: 2011-07-08
IETF LC End Date: 2011-07-19
IESG Telechat date:
Summary: This draft is ready for publication as an Informational RFC
(with nits)
Major issues: none
Minor issues: none
Nits/editorial comments:
1. Introduction
The first reference to DNS needs a reference.
Clients thus rely on CAs to correctly assert bindings between public
keys and domain names, in the sense that the holder of the
corresponding private key should be the domain holder. Today, an
attacker can successfully authenticate as a given application service
domain if he can obtain a "mis-issued" ciertificate from one of the
typo: certificate
widely-used CAs -- a certificate containing the victim application
3.1. CA Constraints
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 Alice, Charlie needs to
claiming to *be* Alice
verify that Alice is actually requesting a certificate. Alice could
Injected or modified false DANE information of this type can be used
for denial of service, even if the attacker does not have a
certificate for the target domain. If an attacker can modify DNS
responses that a target host receives, however, there are already
much simpler ways of denying service, such as providing a false A or
AAAA record. In this case, DNSSEC is not helpful, since an attacker
could still case a denial of service by blocking all DNS responses
s/case/cause
for the target domain.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
