Ryan Sleevi <ryan-i...@sleevi.com> wrote:
On Sat, Nov 20, 2021 at 6:58 AM John Mattsson
<john.mattsson=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>>
wrote:
- In some applications using mutually authenticated TLS, e.g., between nodes in
5G core networks or in mesh networks there is basically no difference between
the client and the server. It would be very good if the document states that
for such use cases the recommendations apply also for the client certificate.
How do these examples construct their set of reference identifiers? And are
they using the same identifiers, or, as is common in these cases, bespoke
identifiers unique / scoped to a particular community? For example, the classic
"extract the name from the certificate" used in such mutual/mesh networks is
something the spec explicitly disclaims in Section 6.1.1, so it's difficult to
see how to unify such an approach safely?
John: I agree with Section 6.1.1 that the client need a limited set of
reference identifiers. Reading 6.1. again, i think that the term "set" that you
use might be better than list. Is the intention to forbid sets of reference
identifiers such as:
*.eaptlsserver.ssid-ipv6only.ietf112.ietf.org
That seems too strict for general TLS (i.e., not only HTTPS), and too much of
an implementation detail. Using a wildcard reference identifies seems like a
better security solution than using a wildcard presentation identifier in some
cases.
John: Thinking a bit more, what I wanted to say was that there are use cases
that are symmetrical in the way that any of the two nodes can start TLS. Such
use cases can use the same certificate for both the TLS client and TLS server
role. While TLS has a strict client and server roles, that division might not
be done before one of the nodes sends a client hello. Unless there are any
problems I don't see, I think it would be good if the document stated.
"In some use cases the same certificate is used for both client and server
roles. A server certificate following this specification MAY be used also as a
client certificate.”
- I think it would be good if the document made the use of IPaddress for Naming
of Application Services NOT RECOMMENDED. They should probably only be used to
reach DNS resolvers.
There's been past discussion within ACME on this point. There's no reason to
believe that IP Addresses are any less useful or less secure than DNS names
from a client validation point: they both have central registries (RIRs/LIRs or
the IANA/ICANN TLDs, respectively), and are generally recognized legally as a
form of tangible property, albeit with potential time-bounded use. The concerns
around IP address certificates primarily comes down to the validation
practices, and whether or not there are sufficient, and reliable, metadata
channels to convey the authorization of a certificate being issued (e.g. ACME's
DNS record format making an explicit protocol agreement for authorizing
certificates), but from a client/UTA perspective, that seems unrelated. For
that matter, for the better part of the HTTPS/TLS specifications lifetime, DNS
validation as practiced by most non-internally-operated CAs was just as
ill-defined, and that didn't seem to result in a NOT RECOMMENDED for DNS names.
I realize I'm making assumptions about your objections in the absence of
details, and so that's largely based on past IETF conversations about the
merits of IP vs DNS names. However, if the above wasn't your concern, could you
elaborate more on the NOT RECOMMENDED, and how that applies to concerns
regarding client validation behaviours versus CA issuance practices?
John: I agree with what you say. There is no reason to believe that IP
Addresses are less secure. My NOT RECOMMENDED came from that issuance and
validation of IP addresses in certificates seems much less mature than DNS
names, it is problematic to get working. I have also seen services go down when
the IP address change (but reliance on a local DNS might be equally bad (or
worse) for reliability). I would generally like to keep down the number of
options. Identities in X.509 is a mess. But if there are use cases we should
fix the problem instead. I don’t think any normative recommendations on IP
addresses are needed.
I think I am mostly questioning the "Identifiers such as IP address are not
discussed.". Surely UTA can give the reader some more guidance than that. I
think just writing some few sentences about the pros and cons of IP addresses
vs. DNS names would be helpful for the reader.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
