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

[Peter Saint-Andre <[e-mail]>]

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
[e-mail] 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/