Re: [lamps] Recharter Discussion

[Ryan Sleevi <[e-mail]>]

On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell <
> [e-mail]> wrote:
>
>>
>> Hi Phill,
>>
>> On 29/06/17 17:54, Phillip Hallam-Baker wrote:
>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <
>> [e-mail]
>> >> wrote:
>> >
>> >>
>> >>
>> >> On 29/06/17 16:21, Russ Housley wrote:
>> >>> Do others have an opinion?
>> >>
>> >> The function sounds useful but perhaps better provided
>> >> via an API to a CT log (not sure). The reason I'd wonder
>> >> about that is that it's hard to see what code would
>> >> read this new value and not want more information than
>> >> that. A CT log API could provide more so might be more
>> >> useful (e.g. if an RP could ask "show me your history of
>> >> meta-data related to certs for example.com").
>> >>
>> >> Probably not that relevant, but similar information would
>> >> also exist in passive DNS DBs I guess.
>> >>
>> >
>> > ​There is always a cut off between the standardized parts and the rest.
>> >
>> > When I first proposed this, it was for human consumption. What I am
>> > thinking about now is rather more of a hook for likely proprietary AI
>> > systems reading it.​
>>
>> Right, that's why a CT API seems maybe more useful and (I think,
>> but I may be wrong), might be easier to get deployed.
>>
>> >
>> > ​Security is risk mitigation, not risk elimination. Right now we can
>> > eliminate what? 95% of phishing sites with free DV certs by simply
>> > rejecting any certs less than 5 days old. ​
>
>
Who is we?

Is this a statement of what you believe browsers should do, versus will?
Have you heard of or can provide evidence for any expression of support,
from any browser, for this philosophy?


>> >
>> >
>> > ​What we do next with the ​data is going to be important. But not
>> something
>> > we are going to be able to really work on at all, let alone standardize
>> > until after we have data.
>> >
>> > All I want to do right now is to instrument so we can start collecting
>> data.
>> >
>>
>> I'm not opposed to defining such a cert extension (which I
>> assume would be the end result) if there's likely to be
>> deployment. But I still think that given that CT logs will
>> have this info already, (and more, and covering >1 issuer)
>> a new CT API may be better than putting it in certs.
>>
>
> ​I don't really want to push everything into CT. This is not information
> that is going to be immediately available, you would have to do a lot of
> log crunching to validate.
>
> Given that some browsers won't do CRLs or OCSP, I can't see them using CT
> for pro-active checking before they accept the connection. Where I see the
> value of First Issued is to allow browsers to winnow out certs that are
> most likely OK and concentrate checking on those that might be a bit dodgy.
>

Are you aware of any browsers interested in this? This feels very much like
LogoType - which was intended for browsers (among others) and rightfully
not widely implemented.


> At any rate, putting an extension into the cert is pretty simple while
> changing the CT API to support short lived certs is likely to be a
> performance. I think that this is an easy win to get much of the return and
> takes the pressure off the CT end of things.
>

CT already has to deal with this. It does seem you're conflating two
unrelated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful if you could explain what you believe the
browser security model to be, and how this supports what browsers are doing
or have expressed support for.

I do not see any value to this as an extension - and I can see undesirable
(and unreliable) data being added by CAs - so I'm curious to understand why
using CT is insufficient, especially for the proposed browser-run machine
learning reputation determination.