[cabf_validation] Minutes of the Validation Subcommittee - 11 Feb 2021

[Ben Wilson]

*Minutes of the Validation Subcommittee - 11 Feb 2021*

*Antitrust Statement* read by Tim.

*Attendees*: Ben Wilson, Wayne Thayer, Tim Hollebeek, Corey Bonnell, Ryan
Sleevi, Shelley Brewer, Daniela Hood, Dean Coclin, Dimitris Zacharopoulos,
Amanda Mendieta, Bruce Morton, Clint Wilson, Michelle Coon, Rebecca Kelley,
Johnny Reading, Julie Olson, Niko Carpenter, Enrico Entschew, Aneta
Wojtczak, Paul VanBrouwershaven

*Agenda* read/reviewed.

·         There was a discussion about IP Address validation between Ryan
and Dimitris on the list.

·         There was also a discussion of the certificate profile formatting
that occurred with the Infrastructure Committee.

·         We can continue discussion of the ADN/Wildcard issue

·         Next F2F Agenda

*IP Address Validation Discussion*

Dimitris: My team conducted a review of the requirements and noted that
domain contact method allowed the start of authority (SOA) contact to be
used for domain validation. We wondered why the SOA doesn't apply to IP
validation records.  Why couldn’t we allow that, and an email could be sent
using the SOA record for validating an IP address by sending an email to
the DNS SOA email address? If I understand the opposition, email addresses
in the SOA record are not directly linked to certificates and they could be
delegated for other reasons, but that argument would apply the same for
domain validation as well.

Ryan: Our DNS validation methods basically work from the root. We start
with the TLD/gTLD, but then you start encountering TLD policies, like the
public suffix list, and we get to the registerable domain name. So, our DNS
validation methods flow from a top-down hierarchy where the authority is
the ICANN/IANA root.

For example, we would do a WHOIS lookup for sleevi.com, not ryan.sleevi.com,
even though ryan.sleevi.com can have a WHOIS record with a zone split. We
have anchored our validation methods at the registerable domain, for
example, with the method in BR section 3.2.2.4.2. SOA records in DNS are
for DNS. IP Addresses have a different hierarchy. You start with IANA, then
you go to the regional Internet registries, you go to the local Internet
registries, and look at the IP address blocks and that information feeds
back into the RIRs in their data sources.

With BR section 3.2.2.5 (IP Address validation), we also work from the top
down. The source of truth for ownership is we start first with the IANA
functions, which are abstract.  Then we go to the RIRs and expect that
whatever block is owned by the RIR can be delegated and assigned further.
They may have assigned it to an LIR, or they may have assigned it directly
to an entity. IP Addresses do not use WHOIS or SOA. They use different net
block records for expressing information about ownership.

Using WHOIS for a domain makes sense because we consider WHOIS to be the
protocol of record. Using WHOIS on an IP address doesn't make sense because
IP addresses have a different resource expression. SOAs are not placed on
IP addresses, they are used with the in-addr.arpa "zone" for reverse zone
lookups.  That zone is not the source of truth IP address delegation. In
most cases, the reverse zone look-up information is not kept in sync with
the IP address delegation information. The source of trust is the RIR.
Reverse-zone lookup is useful, but is using a separate system subordinate
to the RIR registration system, and so the two are not kept in sync. So,
looking up an SOA on a reverse-zone lookup is not looking at the source of
truth the same way as doing a WHOIS with the domain registrar for DNS.

Second, the reverse zone data is not maintained in the same way. It is a
secondary information system. Even when you have IP address transfers, that
information does not necessarily propagate into the reverse zone. Unless
you update the zone delegation to the new holder of the IP address, it is
very common that Entity A still has the SOA record in charge while Entity B
was assigned the IP address because they did a transfer, and these are
separate management systems.

Dimitris: This is the first time I've heard that reverse lookup is not
authoritative. At least in Greece they are pretty well maintained—the IP
address blocks that are under their control. I can see why it might not be
in sync when you are transferring from one ISP to another ISP. But I'm also
curious about the WHOIS question because all of the IP address blocks from
the RIRs are available for queries, and they reply with contact
information. I think the same challenges that we have with domain names and
WHOIS also exist with IP address validation. What about the SOA record?  Isn't
that linked in WHOIS? For example, when we had a discussion on the Baseline
Requirements about the RDAP protocol. Instead of making that change to all
of the validation methods, we agreed to make a change in the definition of
a "domain contact."  This is where the DNS SOR record is included.

Paul: I agree with Ryan that to SOA and the ARPA zone is a secondary source.
When you get IP addresses delegated, that doesn't have to be through
registration. There are ISPs that just delegate you a block of addresses
without updating the WHOIS information.  Even so, you can request a partial
or full delegation in the ARPA zone for a block of addresses, and that
block might be re-delegated, but the delegation for reverse lookup might
not be updated. It is just a record in the WHOIS database of IP addresses,
and from there that zone is built for reverse delegation relationship.

D: If you get an assigned IP address block, then your registrar will allow
you to add NS records for that reverse ARPA zone.

R: Not necessarily. The way that net block subdivisions are carved out.
Let's pretend that 10.0.0.8 was delegable and delegated to Entity Foo. And
let's also assume that Entity Bar was delegated 10.1.0.0/16. Entity Bar
cannot get the SOA records without getting Entity Foo to update that. There
are situations where Entity Foo can get added as a net-block carve-out.
What is being highlighted here is that the SOA and DNS records, because
they require more multi-party coordination, it is functionally
less-maintained and there is less recourse.  Often ISPs don't want the
management headache.

D: Having experience with reverse lookups, .arpa, etc. over the years, I am
OK with dropping the issue.

R: It’s messy. I agree that we need a more reliable technical control for
determining this. RDAP was a great example with respect to DNS. We want to
move to more authoritative records. We'll see from  BGPsec and RPKI that we
get closer to a source of truth, but today in practice and from a risk
perspective we need these secondary sources to stay more in sync with the
canonical source.

D: What about Method 8, where we have similar challenges?  Let's revisit
Method 8.

Tim: Our experience is that when we start talking about IP address
validation, the room gets quiet pretty fast.

D: We have a whole section, and we will be facing these issues.  We need to
address them.  We'll be facing the same types of challenges in terms of
risk and security.

Tim: I agree. We experienced this when working on the IP address validation
methods.  People try to make analogies to the DNS methods, but they work
differently.

*Infrastructure Committee's Work on Tables and Certificate Profiles*

Ryan:  I have a branch set up for this with both a CSV-to-table workflow
and a bullet-list-to-table workflow. There are two workflows because we
have an issue.  Posted in chat -
https://github.com/cabforum/build-guidelines-action/issues/17.  How do we
get good, rich detail in tables?  They use "block level sections", if we
want those—bullet points in a table cell.

There are cross references and links to sections, which is good.  Hyperlinks
help.

[Group reviewed tables using WebEx]

R: Do we want all tables to be the width of the page or should they
automatically adjust?

Ben: I like the automated width adjustments.

R: Extensions are broken out into separate sections. This helps with
complex extensions, like the certificate policies extension.

Dimitris: We discussed on the last call that maybe section 7 could be seen
as separate files in landscape mode?

R: Yes. That is lower on the priority, but it is still on the to-do list.  It
might work when piecing together a PDF, but not great in Word or HTML. I
played with a little bit, and I was able to get a lot of the content fit in
place with a one-point smaller font. I do still have that list of things we
discussed.

Tim: Is the source code CSV?

R: No – these are regular mark-down tables. I wasn't using any block
content in the tables, so I just used standard mark-down tables. We could
keep them as separate files in CSV.

Tim: In long-term, it would be great if we had machine-readable files that
could be translated into markdown and things like this so that the same
profile could drive linters.

Paul: In that case, we might want to consider JAML files with comments and
structures.

R: That would require a lot of development.  There are two tools – one is a
Lua filter. Pandoc supports either the Lua plugins, or it supports the
abstract syntax from A to JSON and allows you to mutate. The Python tool
reads JSON in and spits JSON out, which is what Pandoc uses to produce
tables.  That will require development and engineering work, if folks want
to spend resources committed to develop this.

T: I’d like this work to be compatible in the future.

R: I want to make it as accessible to the greatest number of people.

P: That’s why I’ve recommended JAML because that is like markdown.  It is
easy to edit from a Github browser, whereas CSV you would need to download
it into a spreadsheet editor, but I get your point, it does require
development resources.

Corey:  Looking at the markdown, is the alignment of the columns, is that
mandatory or did you do that to improve the visual presentation of the
markdown?

R: I was just adding whitespace to make the markdown as readable as the
table. The only thing mandatory are the dashes which control how much space
is dedicated to each column.

T: I appreciate the effort to make it easier for non-technical people to
prepare ballots.

R: I’m calling out that the “references” columns are missing from the
tables.  How do we want to express that information? We could create more
tables, or we could hyperlink references.  There are also explanations that
we could give or quote from resources like RFC 5280, extensions, naming,
ordering, etc. We could ask, "when you look at this, what are the other
bits of information that you want?"

Corey: I definitely think we need to have the references in there. For
someone reviewing the content, they will not want to track down the
references. Some of these are hard to find, e.g. street address isn't in
RFC 5280, but in X.520. Let’s leave these fleshed out since we will have
done the work.

R: We could do the links, which I prefer, or I explored other options, like
putting references underneath.  We could adjust by section, whether there
are references, etc.

T: I like the link idea because it preserves the horizontal space in the
table.

Ben: Maybe we put a tag or link off to the side for references instead of
hyperlinking the text in the first column.

*ADN-wildcard discussion*

Corey: RS had presented the deprecation ballot for ADN in method 18 and 19.
I responded asking about the intent and asked whether it was due to
something recent or to address a long-standing issue.  It was mentioned in
Herndon, and with the ACME working group, and in the mail archive. Ryan
clarified that it was a continuation of work on the validation methods. I
think it would be valuable if there were some transition time for
subscribers so that not only can the security goals be met but also so that
it is a smooth transition process.

Ryan: “Why now?” We’ve seen a number of CAs have started to offer this as a
competitive reason without regard to the security issues. We know that
there are security issues. We have seen CAs begin to use them as a way of
onboarding large numbers of customers without regard to the security
issues. We have seen an uptick in public communications on these methods.
How Google has thought about the goals of domain and IP validation. We have
seen excellent recommendations from Doug and Corey on improving the
validation experience for subscribers, which I am on board with--things
that make TLS easier and more automated. But then there are the risks. What
are you authorizing – a CA, all certificates, unlimited, a key, from a
particular entity, etc.? That is captured on the list.

*Next F2F Meeting Agenda*

Tim: Next week, please spend some time to figure out the topics that we
want to discuss during the virutal F2F.  That will help me prepare the
agenda for our next meeting in two weeks. We have limited time during the
F2F, so let’s make an effective use of the time. My plan is to use the
first 15 minutes to discuss what our group has accomplished since the last
meeting. Then, we’ll discuss key topics going forward, many of which will
be obvious, but please let me know of any topics you want discussed in the
wider group. We'll also want to discuss the relative priorities of these
tasks because we have come to the point where the validation subcommittee
has a lot of work on its plate and needs to decide them -- e.g. completing
the certificate profiles work, improving validation requirements, etc.

Ryan:  We can look at our resources such as the validation summit document,
the Trello board, GitHub, and then we can make sure to put everything else
on the list, too, like .18 and .19, and IP address validation, etc. Does it
make sense to collate those and put them on the mailing list and use the
next call to make sure everything has transferred.

Tim will point to the issues in an email to the list early next week.

Meeting adjourned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210214/1ad25662/attachment-0001.html>