Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

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

On 12/8/10 11:34 AM, Ben Campbell wrote:
> 
> On Dec 8, 2010, at 9:45 AM, Peter Saint-Andre wrote:
> 

>>>>>>> -- 4.2.2:
>>>>>>> 
>>>>>>> Can we have a URI-ID example?
>>>>>> 
>>>>>> How's this?
>>>>>> 
>>>>>> A voice-over-IP (VoIP) user agent that is connecting via
>>>>>> SIP to the voice service at "voice.example.edu" might have
>>>>>> only one reference identifier: a URI-ID of
>>>>>> "sip:voice.example.edu" (see [SIP-CERTS]).
>>>>> 
>>>>> Would it make sense to say something to indicate this is
>>>>> true, even though the connection may have been opened based
>>>>> on a URI of "sip:[e-mail]"? (I'm trying to
>>>>> figure out the best way to word that without trying to invoke
>>>>> SIP request-URI vs route set complexities, but my brain is
>>>>> tired. I will think further about it.)
>>>> 
>>>> What do you mean by "the connection was opened based on a URI
>>>> of sip:[e-mail]"? Yes, the client might know that
>>>> it is configured for an account with that URI, but in order to 
>>>> communicate with the application service it will need to
>>>> resolve the DNS domain name (and application type) to an IP
>>>> address. So that's the reference identifier. The presented
>>>> identifier in the certificate will also be of the form
>>>> sip:domain, not sip:user@domain.
>>> 
>>> Sure, and I guess what I am talking about is how one derives a 
>>> reference identifier of sip:voice.example.edu from an address of 
>>> record (AoR) of sip:[e-mail]. For example, I click
>>> on the AoR on a web page, or I type it from Mr. User's business
>>> card. I guess my point is it would be useful for the example to
>>> show that, given the URI of a _resource_, you derive (extract?) a
>>> URI of a _service_ to be the reference entry. You've mentioned
>>> that in text, but it would be useful for the example to show it
>>> as well.
>> 
>> Isn't that a matter for the application protocol?
>> 
>> I want to authenticate with my IMAP server as
>> [e-mail], so my client needs to figure out which DNS
>> domain name(s) it will attempt to resolve in order to communicate
>> with the right IMAP server (perhaps the client checks its
>> configuration or simply chops off the "user@" from the front). The
>> result of that process is the source domain that's used as input to
>> the verification procedures described in this I-D. It seems to me
>> that the same goes for XMPP, SIP, etc.
>> 
>> In Section 1.2 define source domain as:
>> 
>> source domain:  The fully-qualified DNS domain name that a client 
>> expects an application service to present in the certificate (e.g.,
>> "www.example.com"), typically input by a human user, configured
>> into a client, or provided by reference such as in a hyperlink.
>> The combination of a source domain and, optionally, a service type
>> enables a client to construct one or more reference identifiers.
>> 
>> In Section 2.1 we say:
>> 
>> From the perspective of the application client or user, some names 
>> are direct because they are provided directly by a human user
>> (e.g., via runtime input, prior configuration, or explicit
>> acceptance of a client connection attempt) whereas other names are
>> indirect because they are automatically resolved by the client
>> based on user input (e.g., a target name resolved from a source
>> name using DNS SRV records).  This dimension matters most for
>> certificate consumption, specifically verification as discussed in
>> this document.
>> 
>> In Section 4.2.1 we say:
>> 
>> The inputs used by the client to construct its list of reference 
>> identifiers might be a URI that a user has typed into an interface 
>> (e.g., an HTTPS URL for a web site), configured account
>> information (e.g., the domain name of a particular host or URI used
>> for retrieving information or connecting to a network, which might
>> be different from the server portion of the user's account name),
>> a hyperlink in a web page that triggers a browser to retrieve a
>> media object or script, or some other combination of information
>> that can yield a source domain and a service type.
>> 
>> The client might need to extract the source domain and service
>> type from the input(s) it has received.  The extracted data MUST
>> include only information that can be securely parsed out of the
>> inputs (e.g., extracting the fully-qualified DNS domain name from
>> the "authority" component of a URI or extracting the service type
>> from the scheme of a URI) or information for which the extraction
>> is performed in a manner that is not subject to subversion by
>> network attackers (e.g., pulling the data from a delegated domain
>> that is explicitly established via client or system configuration,
>> resolving the data via [DNSSEC], or obtaining the data from a
>> third-party domain mapping service in which a human user has
>> explicitly placed trust and with which the client communicates over
>> a connection that provides both mutual authentication and integrity
>> checking).  These considerations apply only to extraction of the
>> source domain from the inputs; naturally, if the inputs themselves
>> are invalid or corrupt (e.g., a user has clicked a link provided by
>> a malicious entity in a phishing attack), then the client might end
>> up communicating with an unexpected application service.
>> 
>> Do you feel we need to say more about how an application client 
>> determines the source domain? Is there something special about SIP
>> AORs that this document does not cover (but should be covering)?
> 
> As you mention, 4.2.1 says "The inputs used by the client to
> construct its list of reference identifiers might be a URI that a
> user has typed into an interface..." and "The client might need to
> extract the source domain and service type from the input(s) it has
> received."
> 
> In the case of SIP (and of HTTP if we pretended it used URI-IDs, that
> input as typed in by a user is likely to contain stuff that has to be
> stripped out of the reference identifier. For example, in SIP, this
> input is very likely to be the AoR of the person you want to call.

This is what I don't understand.

Let's say you are sip:[e-mail] and I am sip:[e-mail].
Why does my client need to resolve nostrum.com in order to communicate
with you? It seems to me that my client needs to resolve stpeter.im and
then connect to that as my "home" server on the SIP network. My server
then does the work of routing signalling traffic from stpeter.im to your
server at nostrum.com, but my client doesn't communicate directly with
nostrum.com because I'm not registered there.

(I freely grant that my understanding might be based on email and XMPP,
whereas SIP might have a different architecture.)

> i.e. a URI identifying a user. I am suggesting a soup to nuts example
> of how a real world input such as that gets converted to a resulting
> URI reference identity.

Yes, examples always help.

> I don't think this is peculiar to SIP, other than due to the fact
> that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would
> have similar issues of getting from the URI as entered by a user to a
> source identifier in URI  form.

In the case of HTTP, my client (browser) is going to pull out the
"authority" component of the URI:

http://www.example.com/foobar.html => www.example.com

But I think we already say that in Section 4.2.1:

   The client might need to extract the source domain and service type
   from the input(s) it has received.  The extracted data MUST include
   only information that can be securely parsed out of the inputs (e.g.,
   extracting the fully-qualified DNS domain name from the "authority"
   component of a URI or extracting the service type from the scheme of
   a URI) or information for which the extraction is performed in a
   manner that is not subject to subversion by network attackers (e.g.,
   pulling the data from a delegated domain that is explicitly
   established via client or system configuration, resolving the data
   via [DNSSEC], or obtaining the data from a third-party domain mapping
   service in which a human user has explicitly placed trust and with
   which the client communicates over a connection that provides both
   mutual authentication and integrity checking).  These considerations
   apply only to extraction of the source domain from the inputs;
   naturally, if the inputs themselves are invalid or corrupt (e.g., a
   user has clicked a link provided by a malicious entity in a phishing
   attack), then the client might end up communicating with an
   unexpected application service.

See also Section 4.3:

   o  For a reference identifier of type URI-ID, the DNS domain name
      portion is the "reg-name" part of the "authority" component and
      the application type portion is the scheme name matching the
      [ABNF] "scheme" rule from [URI] (not including the ':' separator).
      As previously mentioned, this document specifies that a URI-ID
      always contains an "authority" component whose "host" subcomponent
      contains a "reg-name".  (Matching only the "reg-name" rule from
      [URI] limits verification to DNS domain names, thereby
      differentiating a URI-ID from a uniformResourceIdentifier entry
      that contains an IP address or a mere host name, or that does not
      contain an "authority" component at all.).  Furthermore, note that
      extraction of the "reg-name" might necessitate normalization of
      the URI (as explained in [URI].  As an example, a URI-ID of "sip:
      voice.example.edu" would be split into a DNS domain name portion
      of "voice.example.edu" and an application type of "sip" (mapping
      to an application protocol of SIP as explained in [SIP-CERTS]).

However, perhaps we need to say more in Section 4.2.1, including some
examples?

Peter

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