[cabfpub] AIA chasing

[Ryan Sleevi]

Considering that SSLLabs offers such a tool, has Mozilla considered
reaching out to them to exercise a scan of the subset of hosts you're
interested in, and sharing that data?

On Mon, Apr 3, 2017 at 1:08 PM, J.C. Jones <jc at mozilla.com> wrote:

> 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/moz
>> keeler/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.or
>> g/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/e4c51772/attachment-0003.html>