[Servercert-wg] Update definition of IP Address Contact in the BRs

[Dimitris Zacharopoulos (HARICA)]

On 4/2/2021 6:33 μ.μ., Ryan Sleevi wrote:
>
>
> On Thu, Feb 4, 2021 at 11:17 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     Well, the idea was to do a Reverse lookup
>
>
> Right, that was the part not specified, but implied ;) That's the 
> language-to-be-improved :)
>
>>     It's also not clear to me the motivation of why. I'm hoping you
>>     can elaborate if there are more concrete arguments in favor other
>>     than "for consistency". For example, an explanation of use cases
>>     that are otherwise unmet without this change, particularly since
>>     it'll require careful language to ensure it does what I believe
>>     you're trying to do, but which is not yet specified to do so :)
>
>     I consider this a secure method of contacting the entity that
>     controls/owns the IP address space, just as the SOA can be used
>     for forward Domain Name lookups as part of 3.2.2.4.2.
>
>
> Unfortunately, I think this introduces unintentional surprises into 
> the chain, so I'm not sure it's unconditionally good. That is, the SOA 
> is used for one set of semantics, and this would enable it for a 
> different, and it's not clear that when the SOA record was 
> established, that delegation (of TLS authority) was intentional.
>
> The requirement to use the RIRs/LIRs unambiguously establishes a chain 
> of authority to the "owner" of the IP address (i.e. without 
> delegation). Introducing the added SOA semantics, particularly if a 
> delegation event had occurred, might delegate authority otherwise 
> unintended. Using "a new record" could resolve the ambiguity (by 
> having a strong, explicit signal of delegation of TLS authority), but 
> that's a non-trivial amount of work :) That's why "consistency" alone 
> wasn't a very compelling thing, and I was trying to figure out if the 
> delegation beyond the RIR/LIR level was intentional.

I thought about this a bit differently, not for the "delegation" as you 
frame it but contacting the chain of authority to the "owner" of the IP 
address. The "owner" of the IP address would be easily contacted if the 
"owner" was to request a Certificate using validation per 3.2.2.5.2. 
While I understand the call to "TLS Certificate issuance" delegation 
scope, as has been baked into the CAA DNS records, this change I 
proposed has the same security properties as the forward name lookups 
for a Domain Name which is currently allowed and no security risks have 
been documented or concerns raised. The same delegation scope issue 
applies for existing WHOIS/RDAP queries for Technical or Administrative 
Registrant contact email addresses/phone numbers that is widely used for 
3.2.2.4.2 and 3.2.2.4.15.

I see no different security risks compared to the existing requirement 
that applies to 3.2.2.4.2. Do others share the same interpretation?


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210204/ad539ff6/attachment.html>