RE: FW: webdav feedback

> > 3. [nit] Is the reference for Dublin Core [Weibel et. al.], equivalent
> > to RFC 2413?  If so, we'd prefer that to just a URL.
>
> Note that RFC 2413 includes a URL to DC's site; would that be enough?

Referencing RFC 2413 will be fine for our purposes.  Since it was published
in September, 1998, and the -08 draft was submitted in April, we didn't have
an opportunity to cite the RFC intitially.  It's a non-normative reference,
anyway, and the RFC is informational.  This shouldn't have any impact on the
DAV properties binding draft you're working on, John.

> > 11. on the use of URLs as XML namespaces: there's a scalability and
> > reliability issue if any particular URIs used as namespace names are
> > distributed in products that are widely used, and they may not work if
> > used on private nets not connected to the Internet.
>
> We don't write anything that would suggest a client might dereference a
> namespace URL, do we?

I believe this is based on the XML Namespaces that is currently copied
by-value in the DAV spec., which has the "src" attribute.  This attribute
had been intended for use in retrieving a machine-readable description of
the namespace schema, and hence Keith's comment addresses this.  The problem
was if you have a million copies of some application released which all go
to this URL everytime they process XML.  The new namespace proposal doesn't
have an equivalent capability, and so this comment goes away, I believe.

>
> > 17. section 16.1:
> >
> > TLS doesn't inherently provide a secure connection, as TLS allows use
> > of insecure ciphersuites.  TLS is "secure" only if strong ciphersuites
> > are used (40 bit ciphersuites are certainly not secure enough for
> > passwords that might be reused in other contexts), and I believe you
> > need to have mutual authentication to thwart man-in-the-middle
> > attacks.  (I might be wrong about the latter - server-to-client
> > authentication might be sufficient to prevent man-in-the-middle
> > attacks)
>
> I'm pretty sure server-to-client is meant to be sufficient.  Existing SSL
> clients (well, Navigator, anyway :-) have to deal with this problem when
> running through a proxy.  Navigator connects to the proxy and
> issues a CONNECT
> request, which tells the proxy to open up a connection to the
> server and relay
> bits untouched.  If man-in-the-middle were a problem, the proxy
> would need to
> be trusted, in which case we wouldn't need a CONNECT; we could
> proxy https:
> just like http:.

I think the problem is exactly as Keith stated.  It is possible to have a
TLS connection with weak ciphers in use, and hence this security isn't very
strong, since someone could theoretically capture each packet, decrypt it,
and put together the message stream.

- Jim

Received on Monday, 12 October 1998 18:08:38 UTC