Subject: Re: [Bimi] Problematic cert activities

From: Wei Chuang <[email-masked]>
Date: Mon, 1 Apr 2019 09:09:41 -0700

I realized that I removed the bimi list for this thread (as my kids were
hopping around me as I was writing the reply).   I'll forward your reply
too.

-Wei

*From: *Wei Chuang <[email-masked]>
*Date: *Sun, Mar 31, 2019 at 4:18 PM
*To: *Dave Crocker

Dave,
> Thank you for the Youtube link!  The preliminary attack disclosure by
> Woodcock@PCH is a really nice find! as it shows another recent instance
> of a functioning attack on DNS registry system and on using proof of
> control of a domain to show ownership.  I'll admit it involves a number
> technologies/protocols I'm not really familiar with.  If I understand this
> correctly, the attack initially starts with the EPP protocol run by DNS
> registries to obtain control of the domain, and from their get Let's
> Encrypt and apparently Comodo certificates, so they can harvest IMAP
> credentials.  From the Youtube presentation, one claim is that proper
> validation of DNSSEC could have prevented this attack (which I don't
> actually follow, and if anyone could shed further light on this, I would
> greatly appreciate it)
>
> With regards to VMC, in theory there's a face-to-face validation step to
> could mitigate this though that is only done on the initial request.  I'll
> have to check if subsequent certificate requests are vulnerable or if other
> measures protect against this type of attack.
>
> -wei
>
> PS Sorry for the delay in getting back to this as I was in transit.
>
> *From: *Dave Crocker <[email-masked]>
> *Date: *Fri, Mar 29, 2019 at 9:03 AM
> *To: [email-masked]
>
> This includes some details about bad actors getting 'valid' certificates
>> to which they were not authorized:
>>
>>       Briefing on Dec 18 - Jan 19 DNS/IMAP Prepositioning Attacks - Bill
>> Woodcock
>>
>>
>>
>> https://www.youtube.com/watch?v=oNF6TE75mzg&t=4s&fbclid=IwAR0-oyzrIeMrN6ufedjeNy4QugKmKOak6AF0fd0Qn7IvlFMZcbITdZzXf84
>>
>>
>>
>> d/
>> --
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>>
>> --
>> bimi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bimi
>>
>

---

From: Wei Chuang <[email-masked]>
Date: Mon, 1 Apr 2019 09:10:13 -0700

---------- Forwarded message ---------
*From: *Dave Crocker <[email-masked]>
*Date: *Sun, Mar 31, 2019 at 4:33 PM
*Subject: *Re: [Bimi] Problematic cert activities
*To: *Wei Chuang <[email-masked]>

On 3/31/2019 4:18 PM, Wei Chuang wrote:
> could mitigate this though that is only done on the initial request.
> I'll have to check if subsequent certificate requests are vulnerable or
> if other measures protect against this type of attack.

In an unrelated, and relatively random conversation today, I had a bit
of insight that is no doubt obvious to serious security folk but hadn't
occurred to me:  We have the concept of 2FA, with two independent
channels that provide validation of the requestor. But we ought to add
the idea of two-factor confirmation.  So rather than just sending an
email to confirm that the owner of the cited email address agrees with
whatever the transaction is, do a second, separation confirmation -- eg,
via the phone number.

The set of attack behaviors described by Bill are such that I doubt this
would have made a difference -- there were more basic holes being
exploited -- but I suspect there is value to be had with it.

The broader point is that we seem not to take a holistic approach to
protection of infrastructure services...

> PS Sorry for the delay in getting back to this as I was in transit.

Delay?  There was a delay? ...

d/

---

From: Wei Chuang <[email-masked]>
Date: Mon, 1 Apr 2019 09:23:40 -0700

*To: *Wei Chuang

> whatever the transaction is, do a second, separation confirmation -- eg,

FWIW Bill mentions registrar lock which provides a call back process 2FA
mechanism though unfortunately at extra cost.

Some CA issued certificates have a similar call back/secondary verification
mechanism.  The current CABF Web EV guidelines 11.10 calls for the CA to
verify that the certifcate request was authorized.  That verification may
use phone, fax, or postal but also may involve email which in this scenario
is problematic.  As currently specced, VMC is an extension of web EV, and
is supposed to use this secondary verification process.

-Wei