On Wed, May 29, 2013 at 07:24:25PM -0700, Rick Andrews wrote:
> > -----Original Message-----
> > We should not debate the merits and demerits of various PKI models
> > here. The OP's question was about browser behaviour, and my comment
> > on the existing public CA PKI was mostly irrelevant personal opinion,
> > intended to justify the expectation that browsers will not only
> > support certificate usage 0/1 to the exclusion of 2/3.
>
> Viktor,
>
> Is there another list that's right for discussing the merits and
> demerits of the different DANE options? I work for a CA, so of
> course I believe that the current PKI is *not* irreparably broken,
> nor do I agree that modes 2 and 3 are "substantially more robust".
> Because I believe your voice is respected in this forum, I wanted
> to speak up to make it clear that this opinion is not shared by
> all.
You have little to worry about. There's plenty of disagreement
all around, and I am a relative newcomer here, whatever respect I
may have earned here is limited in scope. I expect my drafts will
prove a tough sell on various points.
I think we can all agree that my answer to the OP's question about
browser support for 2/3 is not controversial.
--
Viktor.
P.S. [ Explanation of personal views, not intended to change anyone's mind. ]
My concerns with respect certificate usages 0, 1 (and even 2) are
rather pragmatic. Security systems that generate too many false
positives (false alarms of something wrong) and require users to
"click OK" to get past the annoying FPs ultimately fail to protect
users, even when the false negative rate is lower than with competing
systems.
My view is that a system with fewer FPs is better even if it has
more FNs, provided these are in balance. Pulling numbers out of
thin air (not to be taken as carefully considered values), I'd
prefer a system with 0.01% FPs and 0.01% FNs over one with 5% FPs
and 0.00002% FNs. The point being that with a 5% FP rate, the user
won't believe the verdict even when the system detects a real
problem.
In implementing DANE support for Postfix, I've found that usage 3
is by far the easiest to implement correctly for both the verifying
client and the verified server. All the other use cases exhibit
subtleties that make FPs (verification failures with no actual MITM
in sight) more likely. With public CAs this includes incomplete
list of CAs on the client side, problems with CRLs, ... And I
don't buy the FN story for public CAs since there are so many of
them one needs to trust to avoid FPs.
With email reliable/timely delivery generally outweighs security
considerations, MTAs are store and forward, there is no user to
click OK, so high FP rates are simply unacceptable. The KISS
principle leads me to conclude that with SMTP usage "3" wins over
all the others.
There are other reasons I dislike the public CA PKI, but I don't
bring particularly relevant expertise to those topics beyond what
others have said many times in the past.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
