Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
On Sun, Nov 21, 2021 at 04:05:44PM -0500, Ryan Sleevi wrote: > 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? 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
On Sun, Nov 21, 2021 at 2:53 AM John Mattsson
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:
>
>
>
> *.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.
>
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).
>
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
On Sun, Nov 21, 2021 at 04:06:35PM +, Salz, Rich wrote: > 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. > 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
Ryan Sleevi wrote: On Sat, Nov 20, 2021 at 6:58 AM John Mattsson 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
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
On Sat, Nov 20, 2021 at 11:57:59AM +, John Mattsson 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. 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
On Sat, Nov 20, 2021 at 6:58 AM John Mattsson 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? ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt
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 on behalf of internet-dra...@ietf.org Date: Thursday, 18 November 2021 at 18:59 To: i-d-annou...@ietf.org Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt 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/ ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
