[NCAP-Discuss] Defining CI/CE

[Jeff Schmidt]

This reminded me about SSL/certificate issues. Has been discussed before, but here it is again so folks can think about it before we meet.

The primary driver behind ACA/Honeypot is that it offers a superior client notification experience. This is primarily predicated on the “client” being a traditional browser and the honeypot sending some super-helpful web content. (By the way, see the JAS 2012 report. This scenario is actually quite infrequent; the vast vast majority of traffic we saw while running honeypots of this type was machine-to-machine protocols not human web stuff. Alas. . . )

If we offer SSL, every modern browser will redirect 80 to 443 and display a scary SSL certificate warning. This is unavoidable (*) because we can’t know what FQDN the client is requesting and get proper certs. Depending on the browser, the helpful content page may not be available without significant hoop jumping that non-experts simply will not do. Especially the non-experts suffering from collisions issues. This will materially reduce the value of this notification.

If we don’t offer SSL, we won’t know what sorts of things are trying to connect over 443. We will be blind to that protocol and the notification experience will be no different than 2012 style CI (application layer doesn’t work, check logs).

It’s a tough spot.

(*) One potential solution is to convince the CA-Browser Forum to issue someone (presumably ICANN) short-lived wildcard TLD certificates for applied-for domains. That will allow the preferred notification mechanism to work. I don’t know if any CA will actually do that, but I expect someone will for enough money. The Let’s Encrypt people may be helpful, but I think a wildcard TLD cert violates CA-B policies so there is a larger conversation to be had. Some sort of “just in time” cert is not completely out of the realm of possibility, but it’s a stretch. . .

See the JAS 2012 report, and the email thread on this list on or about February 25, 2022.

Jeff




From: Jeff Schmidt <jschmidt at jasadvisors.com>
Date: Wednesday, August 2, 2023 at 4:00 PM
To: ncap-discuss at icann.org <ncap-discuss at icann.org>
Subject: FW: [NCAP-Discuss] Defining CI/CE
I think this is the latest

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org>
Date: Wednesday, November 9, 2022 at 11:39 AM
To: ncap-discuss at icann.org <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Defining CI/CE
Agreeing with Matt (L) - recall in Feb I sent the below/attached to this list attempting to pin down some pesky technical details on these techniques being promoted. My content is only intended to be a starting point - I would love to see the promoters of these techniques make additions/corrections so at least we're debating from a common frame of reference.

Jeff


> -----Original Message-----
> From: Jeff Schmidt <jschmidt at jasadvisors.com>
> Sent: Friday, February 25, 2022 6:28 PM
> To: ncap-discuss at icann.org
> Subject: Re: [NCAP-Discuss] Defining CI/CE
>
> Sorry, I was too imprecise in my SSL certificate language in the last one.
> Please replace with this one.
>
> Thx,
> Jeff
>
>
> On 2/25/22, 6:20 PM, "NCAP-Discuss on behalf of Jeff Schmidt via NCAP-
> Discuss" <ncap-discuss-bounces at icann.org on behalf of ncap-
> discuss at icann.org> wrote:
>
>     All:
>
>     I think a very important point has come out of this discussion - one of the
> reasons for the circular arguments is that we have never carefully defined CE
> and therefore we're operating under a number of assumptions which have
> vastly different implementation outcomes. Credit to Matt L and Danny for
> pointing this out.
>
>     Attached is my shot at a careful technical definition of the Controlled
> Interruption and Controlled Exfiltration options. We need to come to
> consensus on this before we can further discuss/recommend. The attached
> is the most conservative technical approach I can think of. This is just a
> strawman to start the conversation. I'm happy to be wrong on any/all of this.
> But no more glossing over the details - let's be super specific.
>
>     I would suggest the Chair(s) "force the issue" and call for consensus on this
> as quickly as discussion allows. Our lack of fundamental agreement here is
> blocking progress on this important item.
>
>     Thx,
>     Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230802/9612b6fa/attachment-0001.html>