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

From: =JeffH <[email-masked]>
Date: Wed, 08 Dec 2010 11:50:55 -0800

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

 >>   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:[email-masked];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:[email-masked]", 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".

?

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 13:16:04 -0700

>>>   component of a URI or extracting the service type from the scheme of

After an IM chat with Jeff, I agree.

> 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:[email-masked]", 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 13:23:23 -0700

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

We can tweak it to:

   As an example, given an input URI of "sip:alice:pswd@
   example.net;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:[email-masked]", the derived service type might
   be "sip", depending on how the example.net service is deployed (since
   the "im" scheme [CPIM] is defined as an abstract scheme in the SIP
   context by [SIP-IM]), and the domain name would again be
   "example.net".

/psa

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Dec 2010 15:34:06 -0600

> >>   component of a URI or extracting the service type from the scheme of

WFM

> For example, given an input URI of "sip:alice:[email-masked];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:[email-masked]", 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:[email-masked]" would probably get the idea across.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Dec 2010 15:39:21 -0600

On Dec 8, 2010, at 2:16 PM, Peter Saint-Andre wrote:

[...]

> Looks good. I love gnarly URIs. :)

See my comment to Jeff. A simpler URI would be good enough, as long as its got _something_ beyond just the scheme and authority parts. And we should be careful with transport=tcp lest someone ask why we are connecting via TLS. How about just "sips:[email-masked]"? (the "sips" scheme both shows that we intend to use TLS, and illustrates how a user input scheme of "sips" might result in a reference id scheme of "sip".)

> "xmpp", too. It depends on what a service has deployed...

If my SIP client derives an XMPP service, it will violate the principle of least surprise :-) But on reflection, I think the "im" example may delve to far into the esoteric even for me. 

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 14:47:10 -0700

> See my comment to Jeff. A simpler URI would be good enough, as long
> as its got _something_ beyond just the scheme and authority parts.
> And we should be careful with transport=tcp lest someone ask why we
> are connecting via TLS. How about just "sips:[email-masked]"? (the
> "sips" scheme both shows that we intend to use TLS, and illustrates
> how a user input scheme of "sips" might result in a reference id
> scheme of "sip".)

WFM.

>>> Also, given an input URI of "im:[email-masked]", 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...
>> 
> 
> If my SIP client derives an XMPP service, it will violate the
> principle of least surprise :-) But on reflection, I think the "im"
> example may delve to far into the esoteric even for me.

Me, too. And I've already noted that the "im" and "pres" haven't been
deployed widely, if at all. Striking that sentence seems sensible.

Peter

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