<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 8:19 AM, <a href="mailto:philliph@comodo.com">philliph@comodo.com</a> <span dir="ltr"><<a href="mailto:philliph@comodo.com" target="_blank">philliph@comodo.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Unfortunately, the flaw in your argument starts here, and unfortunately invalidates the rest of it.<br>
<br>
</span>I really don’t think you help your case with that type of talk.<br></blockquote><div><br></div><div>Similarly, I'm not sure how abstract talk about the mathematical mesh really helps identify or resolve the problems we've identified.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have read the threads and I find that each time someone tries to pin you down on an argument you skate away and claim that you were actually arguing something different.<br></blockquote><div><br></div><div>No - I'm highlighting that your approach to trying to present it as "There's only these two reasons" is flawed, and so any conclusion that tries to look at only a subset of the arguments is understandably going to have the possibility of reaching a different conclusion, but is also flawed, because it's ignoring a large number of other arguments.</div><div><br></div><div>If it helps by analogy to help you understand this point, it's a bit like discussing a math problem in the form of "(2x + 3y + 4z + 7a)/13b = 400". The goal is to "Solve for X", but as you can see, there's a complex set of variables here. My arguments to date have been of the form that "We know (from outside data) that y is 13, z is 23, a is 15, and b is unknown, but we want it less to be 40" - and thus advancing the argument that x is bounded by the goal of keeping b < 40.</div><div><br></div><div>Your argument here seems to be that "We can ignore y, z, a, and b if we treat the problem as simply 2x = 400, thereby x = 200, thereby whatever value you propose X is, is wrong". That is, you're ignoring the other variables' value entirely, and trying to simply ignore them being present in the equation.</div><div><br></div><div>I can understand why you believe your solution is right - and indeed, if it were that simple, it might very well be. But unfortunately, your understanding of the problem is wrong, and thus the solution you advance is for a different problem.</div><div><br></div><div>This is not being cagey - this is reiterating to you that we cannot ignore y, z, a or b.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Arguing that the point has been answered elsewhere seems to be the only mode of argument you wish to engage in.<br></blockquote><div><br></div><div>Well, when you insist on ignoring the fact that the point has been repeatedly addressed, what else is there? By trying to understand where the previous remarks have left you confused or unsatisfied, we can perhaps reach a common understanding. However, by simply presenting strawman arguments - which are not the ones being advanced - so that you can demolish them, we aren't able to actually move forward.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which is cryptographic algorithm agility that you were trying to avoid engaging on.<br></blockquote><div><br></div><div>Is that what you believe my response was? If so, how can I better communicate to you that my point was not that cryptographic algorithm agility was not important, but that it was not one of only two factors to argue for this case. Indeed, by examining the many _other_ cases where agility benefits us, independent of algorithm agility, you might hopefully realize that the problem is not _just_ algorithm agility, nor is it _primarily_ algorithm agility, but the systemic issues involved in any meaningful transition of any insecure practice - whether it be algorithm, domain validation, information vetting - or to the systematic introduction of any improvements - such as CAA, CT, EKUs, or normalized OIDs.</div><div><br></div><div>I would think you, of all people, would be sensitive and appreciative to this argument, given your previous lament about the IETF rejecting your multi-signature solution. Consider how the ecosystem might look if it had been accepted, but the practice was such that certificates were valid for 10 years or more (as they were at the time you introduced the proposal). In this model, relying parties and browsers would not be able to _require_ multi-signature until the non-multi-signature certificates had expired. Or, alternatively, when the ecosystem needed to phase out SHA-1, it would still be forced to break all SHA-1 signed, non-multi-signature certificates - which, again, depending on timelines, could be a significant amount.</div><div><br></div><div>My point is that your solution, if it can be called that, only works because it's solving a different problem, by only constraining itself to one small part of the problem, and ignoring the systemic and symptomatic issues of the overall whole. I am not trying to tell you your answer is wrong for the problem you're setting out to solve, I'm telling you that you're solving a different problem, and due to it being only a subset of the overall issue, the wrong problem.</div></div></div></div>