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 12:50 PM, =JeffH wrote:
> <snip/>
> 
>> stpete sez..
>>> 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
>                            ^^^^^^^^^^
> 
> I suggest we change this to "deriving".

After an IM chat with Jeff, I agree.

>>>   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)?
> 
> 
> BenC replies..
>>
> <snip/>
>> 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.
> 
> 
> So after the second para quoted above (from [S4.2.1]) how 'bout we add
> this..
> 
> 
> For example, given an input URI of
> "sip:alice:[e-mail];transport=tcp?subject=project%20x&priority=urgent",
> the client derives the service type "sip" from the scheme, and the
> domain name "example.net" from the authority component. 

Looks good. I love gnarly URIs. :)

> Also, given an
> input URI of "im:[e-mail]", the derived service type is "sip"
> (since the "im" scheme is defined as an abstract scheme in the SIP
> context by [SIP-IM] (RFC 3428)), and the domain name is again
> "example.net".

Well, the im: and pres: URIs can result in a derived service type of
"xmpp", too. It depends on what a service has deployed...

http://tools.ietf.org/html/rfc3860

http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml

Peter

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