Thanks Rick,
there need to be added, that for Usage 2 there also rises up the issue, on how secure the "own CA" is. CAs pay huge amounts to keep their infrastructure secure, like Hardware Key Modules, like Offline-Signing etc. So with Usage 2 the own CA can be everything, from an online CA, storing the private key in the public accessible webroot, enabling everyone who recognized it to issue certs for the domain by himself. Am 30.05.13 13:58 schrieb "Rick Andrews" unter <[email protected]>: >> On 30 maj 2013, at 10:09, Christian Heutger <[email protected]> wrote: >> >> > I support your point of view, however domain validation also has some >> > advantages with public certificates over DANE. The requirement for >> > renewing (create new private key), the instant revoke with CRL and >> > OCSP (against caching DNS) but finally also to aware against hackers >> > and spammers. So if you look at DANE, everyone can run a valid site >> > with https and e.g. spread malware through that as often https >> traffic >> > is not scanned and usually be trusted, like recent mentioned phishing >> > attacks. In addition with SMTP over TLS running mail servers, the >> > assumption would be, that it is a valid mail server. If everyone can >> > go with SMTP over TLS, giving more trust to valid SMTP connections >> will be undergone. >> >> The additional services you mention are optional and not part of >> WebTrust and/or ETSI certifications. There is no guarantee that such >> services are performed on services served under a classic PKI >> certificate. > >It seems that there are enough differences between PKI use in SMTP and >SSL/TLS that we should probably separate them for discussion. I'm most >familiar with SSL. The services you mention are not entirely optional. >SSL certs must be frequently renewed (the max validity period is being >reduced over the next few years thanks to CA/Browser Forum requirements). >IIS requires you to generate a new key pair when you renew. CRLs and OCSP >responses are updated when a certificate is revoked. > >> Regarding revocation we've seen too many examples where CRLs are not >> checked properly by the clients and/or OCSP responders are not >> responding (or responding so slow that users disable them). This might >> not be how the PKI infrastructure was designed, but it is the reality. > >Things have been improving here. Several CAs have moved to or are >considering moving to Content Distribution Networks (CDNs) for their CRLs >and/or OCSP responses, which provide very low latency and very high >availability. I hope browser vendors will reevaluate their behavior with >respect to revocation as the situation improves. Browsers that don't >check CRLs properly should address this problem in their implementations. > >I would say for SSL at least, a DV cert from a public CA is superior to >DANE without PKIX validation (DANE modes 2 and 3) because: >- The DV cert will conform to Baseline Requirements (minimum key size, >strong signing and hashing algorithm, acceptable validity period, proper >extensions) >- The DV cert would be very likely to have undergone automated checks for >weak keys, weak exponents, not on Debian weak key list, not on internal >phish lists, etc. >- The DV cert would contain AIA and/or CDP extensions, so if the CA >detects that the site is fraudulent, it can revoke the cert. >- The CA issuing the cert would have undergone a WebTrust or ETSI audit. >Audits aren't perfect, but I feel strongly that the threat of failing and >audit makes CAs pay more attention to detail. > >If I create my own self-signed SSL certificate, I can give it a 30-year >validity, use MD2 or MD5, include a Debian weak key, add no >basicConstraints extension or have CA=true. Such practices put my site >and my users at risk. > >> Anyone can do SMTP with TLS today and most (sane) mail servers do that. >> Without classic PKI. And the SMTP servers they talk to do no validation >> whatsoever. DANE can only make things better here. > >I'm not familiar with SMTP. I wonder if both ends of the connection do >proper chain validation and checks for the particular cert that is >expected? Has anyone attempted MITM attacks against mail servers to see >if they can be tricked? If they're not doing "classic PKI", it may be >trivial to spoof one end of an SMTP connection and cause all kinds of >trouble. > >-Rick > >-- >This message was scanned by ESVA and is believed to be clean.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
