[cabfpub] AIA chasing

[J.C. Jones]

Ryan,

As mentioned in the bug discussion, it's not to be taken that 5.88% is
gospel, rather that it's 1) a very noisy indication of the effect fetching
would have on total errors, and 2) a call for interested community members
to help us do more with the data.

More sophisticated analysis is absolutely welcome; we have both the
certificate dataset and the hostname dataset which we can operate on. If
someone were interested in writing a tool that, given a host, would
determine whether AIA fetching would avoid a connection error, I'd be happy
to run it and provide the results to the community.

(Note to implementers, we'd need to probably provide Moz's trusted roots as
a configuration item, too)

Cheers,

J.C.
Crypto Engineering






On Mon, Apr 3, 2017 at 9:08 AM, Ryan Sleevi via Public <public at cabforum.org>
wrote:

> That is most unfortunate.
>
> It doesn't look like the code in https://gist.github.com/mozkeeler/
> 29754494dcdb3b169483595283f29923 fully accounts for the value of AIA with
> respect to finding alternative paths on such connections. That is, it seems
> like it undercounts for situations such as:
>
> Leaf -> Intermediate 1 -> Intermediate 2 -> Old CA
>         -> Intermediate 1 -> Intermediate 2' -> New CA
>         -> Intermediate 1' -> New CA
>
>
> The analysis Mozilla performed only appeared to examine the end-entity
> certificate, as noted in https://bugzilla.mozilla.
> org/show_bug.cgi?id=399324#c80 . However, Chrome's experience with AIA is
> that it is most useful for covering the root key rollover and intermediate
> rollover scenarios. I can think of a number of CA members who have
> exercised this code path, but such data was excluded from your analysis.
>
> I appreciate you looking into this matter, though, and for ensuring the
> data and tools were publicly available in order to perform such an analysis.
>
> An alternative methodology to examine would be to examine the supplied
> chains from the subset of servers (or user error reports) for which you're
> interested in, and determine whether there exists a path to a known Mozilla
> trust anchor. For example, you could use the CCADB disclosures, crt.sh
> dataset (which handedly already groups by ca_id), or directly from
> Certificate Transparency log servers. For such situations where the server
> did not supply a path that immediately resolved, but one or more paths was
> known to Mozilla, you could examine whether or not the AIA identity
> provided by the common elements in that path (even if the only common
> element was the leaf) would have provided one or more intermediates known
> to be valid.
>
> I do hope you reconsider, because it does appear that the testing
> methodology was flawed.
>
> On Mon, Apr 3, 2017 at 10:51 AM, Gervase Markham via Public <
> public at cabforum.org> wrote:
>
>> Participants may be interested in some recent research we did on AIA
>> chasing:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c80
>>
>> The upshot is that Firefox has no plans to implement this feature.
>>
>> Gerv
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170403/9b5dd3c4/attachment-0003.html>