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

[Ben Campbell <[e-mail]>]

On Dec 8, 2010, at 1: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".
> 
> 

WFM

> >>   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. 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".

That's pretty much what I had in mind, although the URI is more complex that you are likely to see as user input.  just "sip:[e-mail]" would probably get the idea across.

> 
> 
> ?
> 
> =JeffH
> 
> 
>