Subject: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt

From: [email-masked]
Date: Thu, 18 Nov 2021 09:58:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : Service Names in TLS
        Authors         : Peter Saint-Andre
                          Jeff Hodges
                          Rich Salz
	Filename        : draft-ietf-uta-rfc6125bis-04.txt
	Pages           : 24
	Date            : 2021-11-18

Abstract:
   Many application technologies enable secure communication between two
   entities by means of Transport Layer Security (TLS) with Internet
   Public Key Infrastructure Using X.509 (PKIX) certificates.  This
   document specifies procedures for representing and verifying the
   identity of application services in such interactions.

   This document obsoletes RFC 6125.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc6125bis-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Mattsson <[email-masked]>
Date: Sat, 20 Nov 2021 11:57:59 +0000

Hi,

Two comments:

- 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.

- 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.

Cheers,
John

From: Uta <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Thursday, 18 November 2021 at 18:59
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt

Abstract:

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 20 Nov 2021 21:52:51 -0500

On Sat, Nov 20, 2021 at 6:58 AM John Mattsson <john.mattsson=
[email-masked]> 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?

> - 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?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Nov 2021 23:21:26 -0500

On Sat, Nov 20, 2021 at 11:57:59AM +0000, John Mattsson wrote:

> 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.

There is always a difference between the client and server in any
context where a server is not dedicated to just a single known in
advance client.

That difference is that the client knows in advance which peer it wants
to connect to, and checks that that's the case.  While the server learns
an identity of the client that connected to it, but since it did not
expect any particular client, there is rarely such a thing as finding
the "wrong" identity on the client end of the connection.  The client is
simply (module key or CA compromise) hoever its certificate says it is.

Thus server identities are for session integrity, confidentiality, ...
while client identities are for authorisation.  The asymmetry is
fundamental, and "mutual TLS" does not create a symmetric role for
the client.

-- 
    Viktor.

---

From: John Mattsson <[email-masked]>
Date: Sun, 21 Nov 2021 07:53:18 +0000

Ryan Sleevi <[email-masked]> wrote:
On Sat, Nov 20, 2021 at 6:58 AM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> 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.”

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Nov 2021 16:06:35 +0000

I find Viktor's description of the asymmetry between clients and servers to be spot-on.

John, could you craft a sample sentence you'd like to see?  Something like this as a new sentence at the end of the second paragraph of the "In Scope" section:

	In cases where both parties are part of the same administrative domain, it MAY be acceptable to have the server enforce the same naming requirements on the connecting client.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 21 Nov 2021 12:24:17 -0500

On Sun, Nov 21, 2021 at 04:06:35PM +0000, Salz, Rich wrote:
> John, could you craft a sample sentence you'd like to see?  Something
> like this as a new sentence at the end of the second paragraph of the
> "In Scope" section:
> 
> In cases where both parties are part of the same administrative
> domain, it MAY be acceptable to have the server enforce the same
> naming requirements on the connecting client. 
> 

If John's point was that an agent that acts sometimes as a client and
sometimes as a server may use the same certificate and key for both
roles, and so the server rules then apply, that's fine I think.

I don't recall any "cross-role" attacks that compromise a TLS server by
a separate attack on its activity as a TLS client.

-- 
    Viktor.

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 21 Nov 2021 16:05:44 -0500

On Sun, Nov 21, 2021 at 2:53 AM John Mattsson <[email-masked]>
wrote:

> 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:
>
>
>
> 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.
>

Ryan: Right now, the draft doesn't really speak at all to this being a
thing, other than saying you MUST NOT do it (although worded as a MUST of
the opposite). That is, the algorithm is defined as a reference identifier
being an explicit ("fully qualified") identifier, and the presented
identifiers being able to have wildcards.

What you're describing here is extracting, from the set of presented
identifiers, an acceptable reference identifier, and then re-attempting
validation. I think there's a lot of sharp corners there that are
non-obvious.

Using your example here, of a server set to accept any client presented
identifier in the form *.foo.example, a sharp edge here would be how to
handle when the presented identifier is also *.foo.example - is that an
acceptable match or not?

> 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.”
>

Sure, this is entirely reasonable text, but I don't think it addresses the
matching issue you've raised here with the server validating the DNS-ID of
the client.

The issue here is whether or not the server-validating-client has an
out-of-bands configuration comparable to what the client-validating-server
has, which is to say, something discrete not tied to/derived from the
certificate. Your example highlights that generally it's not a bounded set
of identifiers, but rather, some form of unbounded set derived from the
certificate, and that seems a somewhat separate algorithm, goal, and
process for validating. However, if the idea is the server has a discrete
set of unambiguous identities it'll accept, then sure, I agree, there's not
an inherent problem in using the same certificate for both (ignoring the
PKI management complexities, of course).

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 21 Nov 2021 18:15:39 -0500

> handle when the presented identifier is also *.foo.example - is that an

OpenSSL supports wildcards in the reference identifier, but to try to
reduce confusion these deliberately use a variant syntax, instead of
"*.foo.example" (presented wildcard) the referernce wildcaard syntax is
".foo.example".

In the case you highlight, yes "*.foo.example" matches ".foo.example",
because any specific host would and "*.foo.example" is a certificate
valid for any of them.

Which is not to say that I think that wildcard certs are a good idea.  I
strongly discourage their use.

-- 
    Viktor.