<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 4/2/2021 6:33 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYoFL=HaawkqcnVeV03_KrFxKj7-HuOrmL4zeW0KQJE-A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Feb 4, 2021 at 11:17
AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true">dzacharo@harica.gr</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> Well, the idea was to do a Reverse lookup<br>
</div>
</blockquote>
<div><br>
</div>
<div>Right, that was the part not specified, but implied ;)
That's the language-to-be-improved :)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>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 :) </div>
</div>
</div>
</blockquote>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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? <br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>