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

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

[further elided]

On 12/7/10 10:44 PM, Ben Campbell wrote:
> 
> On Dec 7, 2010, at 11:02 PM, Peter Saint-Andre wrote:
> 
>> On 12/7/10 5:10 PM, Ben Campbell wrote:
>>> 
>>> On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote:
>>> 
>>> I note that (unless I missed it) the 5922 doesn't seem to allow
>>> for falling back to a dNSName. Is that a reasonable choice for a
>>> new protocol to make?
>> 
>> I think not. IMHO the fallback is a good idea.
> 
> But, from previous comments, such guidance does not belong in this
> draft, right?

I think that's right.

>>> Given the previous conversation about how SIP seems to be the
>>> only protocol with the equivalent scheme issue that actually uses
>>> URI-IDs, and that it doesn't seem to need to worry about which
>>> scheme its using at the moment, I no longer think this draft
>>> needs to worry about it. If it were to say anything at all along
>>> those lines, it would probably need to be along the lines of
>>> KISS. For example, I don't think you want designers trying to
>>> assert security properties by which scheme they include in a cert
>>> (i.e. "foo" vs "foos")
>> 
>> Well, I do think a using protocol does need to specify which URI
>> scheme names are acceptable for the application protocol. You
>> wouldn't want a client to think that fubar://example.com identifies
>> a SIP service. The tel: URI scheme is an interesting
>> counter-example in some ways.
> 
> Not to mention "im:" and "pres:" :-)
> 
> Am I correct in assuming you mean that in the context of what schemes
> they will put in a certificate, or match to a certificate, right? 

Correct. I think this text is clearer in Section 3.1:

   3.  If the service using the certificate deploys a technology in
       which a server is programatically associated with a URI for
       security purposes (e.g., this is true of [SIP] as specified by
       [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not
       describe usage of a URI-ID for HTTP services), then the
       certificate SHOULD include a URI-ID; the scheme SHALL be that of
       the protocol associated with the service type and the "authority"
       component SHALL be the fully-qualified DNS domain name of the
       service.  A specification that re-uses this one MUST specify
       which URI schemes are to be considered acceptable in URI-IDs
       contained in PKIX certificates used for the application protocol
       (e.g., "sip" but not "sips" or "tel" for SIP as described in
       [SIP-SIPS], or perhaps http and https for HTTP as might be
       described in a future specification).

> As
> opposed to what schemes are legal in the application protocol as a
> whole--since these are probably somewhat separate dimensions of
> extensibility. (If the second, then I'm in over my depth in
> meta-protocol design, and would certainly defer to an apps area
> expert if one were handy ;-)  )

Yeah, let's avoid that rat-hole. :)

>>>>> -- 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)?

Peter

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