Re: Review of draft-saintandre-tls-server-id-check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I realise that this thread has moved on to a question of what RFC4985 means (and
I agree with the conclusions) but I thought that this post was about to raise a
quite different point, that may still need clarifying.

see inline

Tom Petch

----- Original Message -----
From: "Bernard Aboba" <bernard_aboba@xxxxxxxxxxx>
To: <ietf@xxxxxxxx>; <stefan@xxxxxxxxxxx>
Sent: Wednesday, August 25, 2010 2:38 AM

I reviewed draft-saintandre-tls-server-id-check.

In a number of instances, this document is vague on the verification of an
SRV-ID, and in one instance, it appears to contradict RFC 4985, even though it
does not update that document.

Section 2.1 states:

   o  An SRV-ID can be either direct (provided by a user) or more
      typically indirect (resolved by a client) and is restricted (can
      be used for only a single application).

This is consistent with RFC 4985 Section 2.1 which states:

   The SRVName, if present, MUST contain a service name and a domain
   name in the following form:

      _Service.Name

Yet, Section 5.1 states:

When the connecting application is an interactive client, the source
   domain name and service type MUST be provided by a human user (e.g.
   when specifying the server portion of the user's account name on the
   server or when explicitly configuring the client to connect to a
   particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
   the user inputs in an automated fashion (e.g., a host name or domain
   name discovered through DNS resolution of the source domain).  This
   rule is important because only a match between the user inputs (in
   the form of a reference identifier) and a presented identifier
   enables the client to be sure that the certificate can legitimately
   be used to secure the connection.

   However, an interactive client MAY provide a configuration setting
   that enables a human user to explicitly specify a particular host
   name or domain name (called a "target domain") to be checked for
   connection purposes.

[BA]  As I understand RFC 4985, the SRV-ID provided in the target certificate is
to be
matched against components (service name and domain name) of the SRV RR obtained
via lookup within the source domain. As a result, I don't believe that RFC 4985
is
consistent with this advice (e.g. the reference identifier is not matched
against the
SRV-ID).

[TP] what I thought was about to be raised here was a contradiction that RFC4985
is all about information gotten from a DNS retrieval whereas the wording of s5.1
in this I-D

"the source
   domain name and service type  ...  MUST NOT be derived from
   the user inputs in an automated fashion (e.g., ... discovered through DNS
resolution ... "

would appear to exclude DNS resolution.  If DNS resolution is off limits, then
RFC4985 would appear not to apply.

Does s5.1 of the I-D mean what it appears to say?

Tom Petch


Section 4.1 is not as clear as it could be on this point, given that it talks
about both
matching of the source domain and the target domain:

   4.  When checking a reference identifier against a presented
       identifier, the client (a) MUST match the source domain (or, in
       some cases, target domain) of the identifiers and (b) MAY also
       match the service type of the identifiers.

      Implementation Note: Naturally, in addition to checking
      identifiers, a client might complete further checks to ensure that
      the server is authorized to provide the requested service.
      However, such checking is not a matter of verifying the
      application service identity presented in a certificate, and
      therefore methods for doing so (e.g., consulting local policy
      information) are out of scope for this document.



--------------------------------------------------------------------------------


>

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]