Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 10:21:38 -0600

On 9/14/10 12:51 AM, Stefan Santesson wrote:
> Peter,
> 
> After the past discussions, the remaining things on my review list are:

Jeff and I would like to thank you for sticking with us as we slowly
work through the feedback we've received. Comments inline.

> General:
> consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI
> systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively
> include [PKIX] brackets to clarify that it references RFC 5280.

Jeff and I would prefer to define "PKIX" in the terminology section and
then use that definition as the basis for the terms "PKIX-based system"
and "PKIX certificate".

We propose to define "PKIX" as follows:

   PKIX is a short name for RFC 5280 [PKIX], which comprises a
   profile of the X.509v3 certificate specifications and X.509v2
   certificate revocation list (CRL) specifications for use in the
   Internet.

> General: 
> I would consider stating that server certificates according to this profile
> either MUST or SHOULD have the serverAuth EKU set since it is allways
> related to the use of TSL and server authentication. At least it MUST be set
> when allowing checks of the CN-ID (see 2.3 below).

Jeff and I are still discussing this topic and do not yet have editorial
agreement about how to proceed.

> 1.3.2 and section 3
> SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt
> Name (otherName form) RFC 4985.
> This error is repeated in section 3, bullet 4, on page 16.

Fixed.

> 1.1. 
> s/an application services/an application service

Fixed.

> 1.2
> I find the following text is hard to understand:
> ³(this document addresses only the DNS domain name of the application
> service itself, not the entire trust chain)²
> I¹m not sure what the DNS domain name has to do with checking the entire
> trust chain. Further, this document discuss more name forms than the DNS
> domain name.
> Perhaps this sentence was meant to say:
> "(this document only addresses name forms in the leaf server certificate,
> not any name forms in the chain of certificate used to validate the server
> certificate)"

That's better. Thanks for the text.

> 2.3
> It would be good if we could restrict the use of CN-ID for storing a domain
> name to the case when the serverAuth EKU is set. Requiring the EKU reduce
> the probability that the CN-ID appears to be a domain name by accident or is
> a domain name in the wrong context.
>  
> In many deployments, this also affects the name constraints processing to
> perform domain name constraints also on the CN attribute.
>  
> There should at least be a rule stating that any client that accepts the CN
> attribute to carry the domain name MUST also perform name constraints on
> this attribute using the domain name logic if name constraints is applied to
> the path. Failing this requirement poses a security threat if the claimed
> domain name in CN-ID violated the name constraints set for domain names.

See above; Jeff and I are still discussing this topic.

> 4.4.3 checking wildcard labels
> The restriction to match against only one subdomain seems to not be
> compatible with FRC 4592. RFC 4592 states:
>  
>    A wildcard domain name can have subdomains.  There is no need to
>    inspect the subdomains to see if there is another asterisk label in
>    any subdomain.

Speaking for myself, not for Jeff, I think the entire notion of a
subdomain is suspect and very poorly defined, which is why the XMPP WG
did away with it in rfc3920bis. For example, is foo.co.uk a subdomain of
co.uk? No. And I think we really don't want to pull in a normative
reference to the public suffix list in this specification!

> Further, I'm pretty sure that the rule of this draft is incompatible with
> many deployments of wildcard matching. I recall in Microsoft we allowed any
> number of subdomains when I was involved with the CAPI team.

It also seems to me that allowing recursive wildcards (e.g., allowing
*.*.example.com via *.example.com) is a major expansion beyond RFC 2818
or current verification methods.

Jeff would like to check the relevant specifications (all of the specs
in the "Prior Art" appendix) and the previous discussion threads on the
[email-masked] list before coming to a conclusion on this matter.

> 4.6.2 
> States:
>  
>    In this case, the
>    client MUSTverify that the presented certificate matches the cached
>    certificate and (if it is an interactive client) MUST notify the
>    user if the certificate has changed since the last time a secure
>    connection was successfully negotiated
>  
> How does the client know if the certificate has changed or whether it just
> obtained an unauthorized certificate?

If the client has lost its cache then it simply needs to proceed as
described under "Case #3: No Match Found, Uncached Certificate".

> I guess in some cases it would work but I feel sure there are exception
> cases where the client just has a configured certificate but no knowledge of
> what it obtained the last time it talked to the server.

Is your concern about caching the certificate or keeping track of what
the client received the actual "last time" it connected? The mention of
"last time" is meant to ensure continuity of checking, not to force the
client to keep track of particular connection attempts. Therefore in our
working copy we have changed that paragraph to read:

   If the client finds no presented identifier that matches any of the
   reference identifiers but a human user has permanently accepted the
   certificate during a previous connection attempt or via configured
   preferences, the certificate has already been cached.  In this case,
   the client MUST verify that the presented certificate matches the
   cached certificate; if the presented certificate does not match the
   cached certificate then the client MUST proceed as described under
   Case #3 below.

Thanks again for your feedback.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 09:44:13 -0700

>agreement about how to proceed.

This is not editorial, this is definitely technical. What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

> > a domain name in the wrong context.

That makes no sense from an operational standpoint. The inclusion of an EKU has nothing to do with the decision-making for the domain name location.

>> perform domain name constraints also on the CN attribute.

True, and irrelevant.

>> domain name in CN-ID violated the name constraints set for domain names.

Fully disagree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 11:58:49 -0600

On 9/22/10 10:44 AM, Paul Hoffman wrote:
>>> General: I would consider stating that server certificates
>>> according to this profile either MUST or SHOULD have the
>>> serverAuth EKU set since it is allways related to the use of TSL
>>> and server authentication. At least it MUST be set when allowing
>>> checks of the CN-ID (see 2.3 below).
>> 
>> Jeff and I are still discussing this topic and do not yet have
>> editorial agreement about how to proceed.
> 
> This is not editorial, this is definitely technical. 

Sorry, by "editorial agreement" I meant consensus between the document
editors about how we think it's best to address the issue that Stefan
raised. Jeff and I have discussed many of the issues that have been
raised, but haven't yet had a chance to discuss this one.

> What possible
> advantage is there to making certificates that do not have this flag
> set be excluded from the practices you are defining? That is, if a
> TLS client gets a certificate from a TLS server that the TLS server
> says is its authentication certificate, why should the client care
> whether or not that flag is set? That flag is an assertion from the
> CA, not from the server who is authenticating.
> 
>>> 2.3 It would be good if we could restrict the use of CN-ID for
>>> storing a domain name to the case when the serverAuth EKU is set.
>>> Requiring the EKU reduce the probability that the CN-ID appears
>>> to be a domain name by accident or is a domain name in the wrong
>>> context.
> 
> That makes no sense from an operational standpoint. The inclusion of
> an EKU has nothing to do with the decision-making for the domain name
> location.
> 
>>> In many deployments, this also affects the name constraints
>>> processing to perform domain name constraints also on the CN
>>> attribute.
> 
> True, and irrelevant.
> 
>>> There should at least be a rule stating that any client that
>>> accepts the CN attribute to carry the domain name MUST also
>>> perform name constraints on this attribute using the domain name
>>> logic if name constraints is applied to the path. Failing this
>>> requirement poses a security threat if the claimed domain name in
>>> CN-ID violated the name constraints set for domain names.
> 
> Fully disagree.

Thanks for your input. Our little editors team will take your comments
under advisement during our discussion of this open issue. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Sep 2010 19:36:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Wednesday, September 22, 2010 9:44 AM
> To: Peter Saint-Andre; Stefan Santesson
> Cc: IETF cert-based identity; [email-masked]; [email-masked]
> Subject: [TLS] Why require EKU for certid?
> 
> >> I would consider stating that server certificates according to this
> >> profile either MUST or SHOULD have the serverAuth EKU set since it is
> >> allways related to the use of TSL and server authentication. At least
> >> it MUST be set when allowing checks of the CN-ID (see 2.3 below).
> >
> This is not editorial, this is definitely technical. What possible
advantage is
> there to making certificates that do not have this flag set be excluded
from the
> practices you are defining? That is, if a TLS client gets a certificate
from a TLS
> server that the TLS server says is its authentication certificate, why
should the
> client care whether or not that flag is set? That flag is an assertion
from the CA,
> not from the server who is authenticating.
> 
> > > 2.3
> > > It would be good if we could restrict the use of CN-ID for storing a
> > > domain name to the case when the serverAuth EKU is set. Requiring
> > > the EKU reduce the probability that the CN-ID appears to be a domain
> > > name by accident or is a domain name in the wrong context.
> 
> That makes no sense from an operational standpoint. The inclusion of an
EKU
> has nothing to do with the decision-making for the domain name location.
> 
> > > processing to
> >> attribute to carry the domain name MUST also perform name constraints
> >> on this attribute using the domain name logic if name constraints is
> >> applied to the path. Failing this requirement poses a security threat
> >> if the claimed domain name in CN-ID violated the name constraints set
for
> domain names.

I also agree that this is not something that I would ever like to see as a
required element.  Applying name constraint logic in places that it should
not be performed is something that is very hard on any certificate
evaluation logic.

I think it would be much more an issue of "asking" CAs not to issue
certificates that have this characteristic.

Jim

> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Sep 2010 18:13:44 +0200 (MEST)

>>> domain name in CN-ID violated the name constraints set for domain names.

I do agree with Paul that something is very wrong about this paragraph.

What it seems to request is that dNSName SAN name constraints ought
to be performed on CN-ID if server endpoint identification is
performed with CN-ID.

Since there is a requirement to use (issue) DNS-IDs in server certs,
and a requirement to ignore CN-ID when DNS-ID is present, such a
name constraints processing scheme looks awkward to me.

Name Constraints (and its processing) is something that is specified
in PKIX Internet Certificate and CRL profile (rfc-5280 and its
predecessor rfc-3280) plus some ISO-specs (btw. are these publicly
available anywhere), and that is normally implemented entirely within
the certificate path validation of the PKI software.

The BCP for server endpoint identification with TLS is something,
that according to the last sentence of section 1 of all TLS specs
is a matter of the application on top of TLS.

A CA with name constraints for DNSName SANs (required critical according
to rfc5280, mind you) in its own CA certificate that issues TLS server
certificates without dNSName SANs yields "fubar" on my scorecard.

The support of CN-IDs is "legacy" and retained for backwards
compatibility with the installed base.

Those that need the backwards compatibility will _not_ disable
the matching fallback if DNSName SANs are present, and they're
even more unlikely to adopt such a weird name constraints
processing of a fallback they shouldn't be doing in the 
first place and keep doing only to not interfere with
installed base.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Sep 2010 10:43:50 -0700

On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote:

>> [..snip..]

> What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

Does this point need discussion?  Without checking, I suspect that 5280 says you obey the EKU, period.  OTOH I think Paul raises a valid point.

OTOH (again) one could argue that the EKU provides a way to prevent a stolen cert/key issued to the machine for a different function from being repurposed to support a fake server.  (I'm not convinced this is significant, but it's something.)

Absent discussion and consensus, I vote for whatever 5280 says, which I suppose is what the current silence on the topic equates to.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]