Subject: Re: [Uri-review] Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

From: Eric Johnson <[email-masked]>
Date: Thu, 17 Jan 2008 21:45:01 -0800

Hi Ted,

Thanks for your feedback. We're looking to address many of the points
you've raised. After the holidays, and consulting with the other people
working on this specification, we realized we had some follow up
questions. They follow:

Ted Hardie wrote:
> Hi Eric,
[snip]
> _Warning_: Vendors and applications SHOULD NOT include sensitive
>    information (such as authorization tokens) in an IRI.
>
> at a SHOULD strength level?
>   
Not clear what you're implying here. That it should read "MUST NOT"
instead? We were thinking that there could be scenarios where the IRI
was stored together with a user name and password, and in some
circumstances, it could possibly make sense to store all of the
information in a single string. So "MUST NOT" seemed overly strong.

[snip]
> This may also be important when considering Section 7.  You say:
>
> As JMS is an API rather than a protocol, it therefore specifies no
>    interoperable wire-level representation.  However, because the jms
>    IRI scheme is defined with reference to the API, this lack of wire-
>    level compatibility does not create an interoperability issue.
>
>    IRIs defined in this scheme are dependent upon the code and
>    configuration executing in the runtime environment, which may present
>    interoperability issues.  In particular, the available classes and
>    classloaders and the JNDI configuration could affect the
>    interpretation of a particular IRI.
>
> The mapping process in RFC 3987, Section 3.1 is intended to produce URIs,
> which do have an interoperable wire-level representation.  To avoid this
> interoperability problem, could you not require the mapping to be performed
> when the IRI changes context?
There are two levels of interoperability. At the level of encoding the
JMS IRI into a URI, we don't foresee any interoperability problems with
conformant implementations. However, there is also an interoperability
question with regards to the contents of the IRI, such as the
destination name and the JNDI information. From your wording, it isn't
quite clear to me whether you're referring to both of these problems or
just one.
>   There are URIs where the dereferencing
> is known to be affected by the local context (http://localhost/  ), but seeing
> a scheme where there are named parameters, a way of establishing a
> variant context, and still no expectation of interoperability because
> of runtime execution differences is worrying. 
>   
Talking it through, we're not quite sure how this is really any
different from HTTP, for example. Host resolution in HTTP is controlled
by proxy servers, routers, by the use of "hosts" files, and on Windows,
by that platforms' use of WINS resolution (at least, that's what I
recall it being). The net effect is that HTTP URL resolution can also be
dramatically affected by context. With this specification, In the case
of JNDI locations, there is, perhaps, slightly more cause for concern,
because it is all defined using APIs, rather than building upon known
standards (such as DNS and TCP/IP). However, given two different
implementations, using the same URL, properly configured, we don't
expect interoperability problems.

Do you think that we need to address this point differently?
> In section 8, you say:
>
>     Other optional
>    JMS configuration and message properties, indicated as IRI
>    parameters, like the "timeToLive", may reasonably be determined by
>    the sender of a message, without affecting the recipient.  Insofar as
>    a recipient may wish to dictate certain parameters, such as the
>    "jndiConnectionFactoryName", those parameters can be specified.
>
> I don't understand what you mean by the recipient dictating certain parameters.
> Do you mean that in a protocol exchange, the lack of these parameters will cause
> the recipient to reject the protocol message containing this uri/iri?
In the case of JMS, not having the correct information about the JNDI
ConnectionFactory name may keep the message from ever arriving at the
destination. So it isn't really a question of recipient rejecting the
message.

Maybe we should alter so that the last sentence finishes with "those
parameters can be specified, if they're not obtained from somewhere else."?
>   I assume
> it is then up to the API to indicate what the missing parameters are? 
>
> There are a couple of elements within the security considerations that concern
> me:
>
>    A malicious consumer of a service using a JMS IRI could send, as part
>    of a JMS message, an IRI with a parameter such as "timeToLive" with a
>    value specified in the IRI that differs from the corresponding JMS
>    message property ("JMSExpiration" header, in this example).  In the
>    case of such messages with such IRIs, recipients are strongly
>    cautioned to avoid applying processing logic based on particular IRI
>    parameters.  Discrepancies could be used to exploit differences in
>    behavior between the JMS transport layer and the processing logic on
>    top of that layer.  In the context of this specification, the
>    parameters of concern include:
>
>       deliveryMode
>       timeToLive
>       priority
>
>    Message senders are strongly urged to remove from the IRI extra
>    parameters like the above in environments where the data will be
>    redundant with information specified elsewhere in the JMS message.
>
> This sounds as if you are saying to recipients that they should ignore parameters
> when they appear to be redundant to similar data in the base messages.  The
> advice to senders to avoid silly states where these don't match sounds good, but
> I'm not sure how the recipient behavior works when dealing with variants.
> Are you assuming that this advice is only valid for shared parameters, and is not
> more general?
>   
It is more general. As stated above, some of these parameters end up as
message headers or message properties on the resulting JMS message. JMS
itself has "selector" capabilities that can use these headers and
properties. If the IRI is also carried in the message, we then run the
risk of the contents of the IRI differing from the contents of the data
fields in the message, and thus the message gets routed one way, but
processed another.

To fix this text, I'm thinking we should explicitly mention the JMS
selector ability, rather than vague hand-waving about the "JMS transport
layer".
> In describing the semantic attacks, you say:
>
> A possible semantic attack on the "jndi" variant could be
>    accomplished by replacing characters of a JNDI destination name in
>    one language with equivalent looking characters from another
>    language, known as an "IDN homograph attack" (IDN) [REF-Homograph].
>    This kind of attack can work on a jms IRI for the JNDI destination
>    name, and only when the JMS environment enables automated
>    registration of JMS destinations.  Such an environment should prevent
>    the use of homograph equivalents, so that clients do not accidentally
>    send their requests to unintended destinations.
>
>
> why is this just an issue for the jndi destination name and not for other
> parameters, like the replytoName or jndiUrl?  Preventing
> the use of homograph equivalents is also a fairly difficult and onerous
> task when the full UCS is permitted; this is one of the reasons that
> the use of mapping to URIs tends to be encouraged in IETF protocol
> slots.  They are less human friendly, but the ladder of comparison for
> them is fairly well known and the limitations remove many homographs.
> Is that an option for comparison here?
>
> You say:
>
>  This specification does not allow for IP addresses, so no issues
>    around IP addresses, rare or otherwise, are raised by this
>    specification.
>
> Could IP addresses not appear in a parameter?  How does the parameter production
> prevent this, if so?
>   
I believe rewriting this as "This specification does not define or
anticipate any use for IP addresses as part of the IRI..." might address
your concern. You're right, we don't explicitly exclude the use of IP
addresses as parameters, but if someone does abuse this specification in
that way, it ought to be their problem to deal with.

Thanks again for your feedback.

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Jan 2008 16:34:28 -0800

>information in a single string. So "MUST NOT" seemed overly strong.

MUST NOT means never.  SHOULD NOT means don't do this unless
you understand why you're breaking the rule.  There is nothing in
the document to indicate when it would be okay to break the
rule and I don't know of any general context where it would be
understood to be okay for this.  So, I think you need to give an
example context where this makes sense.  The one you've given
doesn't seem particularly compelling to me (since the IRI could
obviously leave the context it is currently stored in), but the
general idea is that I think more guidance would help.

>quite clear to me whether you're referring to both of these problems or

I was, first of all, pointing out that you don't lack an interoperable
wire-level representation; you can use the mapping process in
3987, Section 3.1 to produce URIs (which are, happily, also IRIs).
You don't have to specify this; you get it for free. 

The second question is whether you need that and what it is doing
for you.  The answer to that may be that you don't need that, but that's
not how this reads to me now.  At the moment, it also reads as if you
are saying that variation among classloaders and JNDI could mean
that the same IRI would be interpreted in different ways in different
environments.   That raises the question, for me at least, of whether
having a common representation helps get past that.  I suspect
that the issue is semantic, rather than syntactic, but I don't think
the document is clear on this point.

>expect interoperability problems.

Well, the odd thing here is that you have mechanisms (named parameters,
a way of establishing variant context) that seems like they out to make
it easier to establish the contextual difference, but you seem actually
worse off than HTTP.  If you read 2616's statements about idempotent
methods, you get a sense that HTTP has some contexts where there are
clear expectations of repeatability and the ability to do things like
trade etags across clients and proxies.  Post, of course, is a black box.

It's not the job of the uri/iri scheme to change how things work,
obviously, but it is useful when the documentation is clear about
the extent to which a particular class of URIs/IRIs can be expected
to have context-dependent or context-independent usefulness.
At this point, the level of context dependence seems high enough
that I wonder why you want to use URIs/IRIs at all; how can
you pass these identifiers around with an expectation that you
know what they mean?

>selector ability, rather than vague hand-waving about the "JMS transport

Okay.

>Thanks again for your feedback.

Thanks for the reply, and my apologies for the delay in getting back to you.
				regards,
					Ted Hardie