On Sun, Oct 07, 2012 at 09:04:46AM +0200, Nikos Mavrogiannopoulos wrote: > On 10/06/2012 03:03 PM, Ilari Liusvaara wrote: > >> 2. Too many certificate usage fields to indicate the _same_ thing. > > > Nope, no two certificate usages are the same. > >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same as > >> 3. The difference is that if my certificate is signed by a CA I use 1, > >> but if the CA signature expires but I don't renew I have to notify the > >> DNS administrator to change it to 3. That's quite interesting. What is > >> that for? > > Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX path > > validation, whereas usage 3 does _not_ require path validation. > > Well, my point is that they transfer exactly the same data. 0 transfers > an end-entity certificate and so does 2. They differ, as you say, on > what the receiving party does on that data. Why bother? How would a > server operator ever know what the receiving party will do on the data?
How does any server operator deploy a TLS-protected site if they don't know what trust anchors their users have available? Today, without DANE, if you deploy a TLS service and don't pay attention to that, you're going to get complaints from (some subset of) your users about certificate errors (or they aren't being checked at all, which isn't exactly secure). All CA certificates are not equal. > Let's say I'm on an company that has it's main web site signed with a CA > certificate that is installed on all employees computers. Do I use 0 or > 2? All employees perform PKIX path validation so it should be 0. Now you > connect to this site, but you don't trust this CA. So it should have > been 2, or both? If you expect only your employees to connect, then 0. If it's facing the public and you want them to be able to use it, then 2. This is no different than the decisions you had to make when chosing a CA in the first place. This is the same as asking "but what CA should I use for my web site?" When I go to get a certificate from a CA, they all talk about being trusted by X% of web browsers, and/or name the browser platforms they are trusted by. If your users have the CA in their trust anchor sets (however that is, whether by local customization or because the clients have done it for you), then use 0/1. Otherwise, you'll need to use 2/3 or it won't work in some percent of cases. > PKIX path validation is a process that runs on the client and the server > has no indication whether it will actually occur, or that it will share > a common trusted party at all. DANE would help in the cases the peers do > not share a common trusted party by providing an indication of the > identity of peer. However, the DANE protocol goes to extremes only. > Either the server shares nothing with no-one (self-signed), or shares a > CA with everyone. Reality is somewhere between those extremes. You can always deploy like so: example.com. IN TLSA 0 0 1 ..... example.com. IN TLSA 2 0 0 ..... If the cert is in their trust store, the first record will work (so will the second, but will either never get used or get used 50% of the time, depending on the implementation). If it's not in their trust store, only the second will work, but it will work. I'm not sure how we could have done better--CA certificates are either trusted or not, there is no in between. Do you have a proposal, other than to cut options which would (apparently) make us even more extreme? > What the writer of the RFC may have meant, is whether you do a > verification against the commercial CA set in a browser. However, this > set varies from browser to browser and scenarios like the one above will > occur. DANE is complicated by the fact that PKIX is complicated. > > You can use 2/3 even if your certificate is signed by public CA. > > You just likely won't get any indications of security above DV level. > > 0/1 are only really useful if you have a OV or EV certificate. > > OV or EV are pretty much marketing terms, they shouldn't have been > considered in a protocol. Who said they were? You aren't reading very carefully--he said "likely won't" -- this is all up to the people defining OV/EV, which isn't the IETF. > >> The same if I have a self-signed certificate that one can verify using > >> DANE. If I decide to buy a signature from a CA to increase security, I > >> actually create confusion for the users of DANE. Users of DANE would see > >> the certificate usage 3 in my public key, and what should they think? > > If the usage 3 entry matches, ignore your CA certificate and proceed with > > the connection. > > Doing that I would reduce the security of the connection. By ignoring > the CA certificate I put the trust on the DNS administrator only. My > goal as an implementor of DANE is to disperse the trust to various > parties and warn the user of any discrepancy. With the mix or 0,2 and > 1,3 I see many cases of false alarms and eventually users disabling the > DANE verification. Read (or reread) Section 8. If you think that 0/1 isn't putting trust in the DNS admins I suggest you look into what it takes to get a certificate from a CA. > Those are not things that typically occur in a _new_ protocol like DANE. > You see these in a 10 year protocol with a gazillion of options added > through the years. DANE has already too many in its first incarnation. You aren't the only one looking to deploy this. DANE is more complex than I'd like because PKIX and the reality of its deployment is more complex than I'd like. DANE may be new, but PKIX is not. -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
