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

2021-11-21 Thread Viktor Dukhovni
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

2021-11-21 Thread Ryan Sleevi
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

2021-11-21 Thread Viktor Dukhovni
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

2021-11-21 Thread Salz, Rich
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

2021-11-20 Thread John Mattsson
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

2021-11-20 Thread Viktor Dukhovni
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

2021-11-20 Thread Ryan Sleevi
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

2021-11-20 Thread John Mattsson
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