headers
Julian Reschke | 2 Mar 2007 17:05
Picon
Picon

Re: IETF Last Call review: changes suggested

Julian Reschke schrieb:
>>       If the client wishes to avoid accidentally creating either 
>> lock-null or empty locked
>>         resources, an "If-Match: *" header can be included with LOCK 
>> requests to prevent the server from
>>         creating a new resource.
> 
> This will work in theory, but I'm pretty sure it doesn't in practice 
> because of server bugs (I'll try to write a test case next week). We 
> shouldn't recommend this as guidance unless we're pretty sure it works 
> in practice.
> ...

I finally found the time to write a test case (attached), and as 
expected, the results were mixed. The test passed on MS IIS (yikes!) and 
Xythos, but fails on SAP KM (we're fixing that right now) and Apache 
mod_dav (<https://issues.apache.org/bugzilla/show_bug.cgi?id=38034>).

Thus, adding this kind of recommendation may be more harmful than 
helpful, as long as it doesn't work with Apache moddav (volunteers?).

Best regards, Julian
Attachment (lock-null-if.js): application/x-javascript, 3357 bytes
Permalink | Reply | 0 comments |
headers
Julian Reschke | 3 Mar 2007 12:54
Picon
Picon

Status of RFC2518bis?


Hi,

I just noticed that apparently a new draft (18) of RFC2518bis has been 
published several weeks ago, but

- I didn't see any announcement on the Internet Draft announcement 
mailing list (see 
<http://www1.ietf.org/mail-archive/web/i-d-announce/current/index.html>, 
or check 
<http://www.google.de/search?q=draft-ietf-webdav-rfc2518bis+I-D+ACTION+site%3Aietf.org>),

- there was no announcement over here, and

- the working copy at 
<http://ietf.osafoundation.org/webdav/rfc2518bis/draft-ietf-webdav-rfc2518bis.xml> 
hasn't been updated since December 01.

Cullen, Lisa, could you please clarify what's going on here...?

Best regards, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Mar 2007 14:46
Picon
Picon

Proposed resolution for Issue 237 (new attack scenario based on XmlHttpRequest object)


Proposed Changes (see also 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237> and 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz237>:

Proposed changes:

+++
NEW (add to 20.8)

    One specific attack scenario deserves special mention here: with the
    arrival of the "XMLHttpRequest" API (see [WD-XMLHttpRequest]), user
    agents have acquired the capability to submit arbitrary HTTP requests
    against the server the content was obtained from.  With the well-
    known semantics of HTTP verbs such as PUT and DELETE, the following
    attack becomes possible:

    1.  Alice prepares an HTML page with embedded Javascript code that
        will submit a DELETE request against the URI
        http://www.example.com/users/bob/ (a resource she has not write
        access to).

    2.  Alice stores this HTML page at
        http://www.example.com/users/alice/readme.html, a resource she
        has write access to.

    3.  Alice emails Bob a link to
        http://www.example.com/users/alice/readme.html, for which he has
        read access once authenticated.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bjoern Hoehrmann | 4 Mar 2007 20:22
Picon

Re: Proposed resolution for Issue 237 (new attack scenario based on XmlHttpRequest object)


* Julian Reschke wrote:
>    One specific attack scenario deserves special mention here: with the
>    arrival of the "XMLHttpRequest" API (see [WD-XMLHttpRequest]), user
>    agents have acquired the capability to submit arbitrary HTTP requests
>    against the server the content was obtained from.  With the well-
>    known semantics of HTTP verbs such as PUT and DELETE, the following
>    attack becomes possible:
>
>    1.  Alice prepares an HTML page with embedded Javascript code that
>        will submit a DELETE request against the URI
>        http://www.example.com/users/bob/ (a resource she has not write
>        access to).
>
>    2.  Alice stores this HTML page at
>        http://www.example.com/users/alice/readme.html, a resource she
>        has write access to.
>
>    3.  Alice emails Bob a link to
>        http://www.example.com/users/alice/readme.html, for which he has
>        read access once authenticated.
>
>    4.  Bob follows the link, authenticates, and the embedded script code
>        executes the DELETE request against
>        http://www.example.com/users/bob/ while being authenticated as
>        Bob.

You should say Bob has write access to http://www.example.com/users/bob/
I missed that at first and wondered what the point here might be.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 4 Mar 2007 20:56
Picon
Picon

Re: Proposed resolution for Issue 237 (new attack scenario based on XmlHttpRequest object)


Bjoern Hoehrmann schrieb:
> ...
> You should say Bob has write access to http://www.example.com/users/bob/
> I missed that at first and wondered what the point here might be.

OK, how about:

     1.  Alice prepares an HTML page with embedded Javascript code that
         will submit a DELETE request against the URI
         http://www.example.com/users/bob/ (a resource she has not write
         access to, but Bob has).

>>    o  Using user agents that follow Section 9.1.1 of [RFC2616], in that
>>       they do not allow unsafe methods to be executed without making the
>>       user aware of the consequences - unfortunately, none of today's
>>       browsers is doing that.
> 
> I don't think this is the best way to put it, but I don't have much
> better text at hand right now.

Proposals welcome. I think it's worthwhile to mention that RCF2616 is 
very clear about the user agent never to invoke an unsafe method without 
the user's consent, a principle that very clearly isn't followed by 
today's browsers when they allow unsafe methods without any user 
confirmation.

Best regards, Julian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 5 Mar 2007 11:05
Picon
Picon

Re: [Fwd: I-D ACTION:draft-ietf-webdav-bind-17.txt]


Julian Reschke schrieb:
> Hi,
> 
> this updated draft includes the IANA registration for the status codes 
> 208 and 506 (see 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-17.html#iana.considerations>). 
> 
> 
> Like the previous one, I think this should be either last called, or 
> directly sent to the IESG.
> 
> Best regards, Julian

Note that the RFC2518bis bug pointed out in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-17.html#rfc.section.A> 
is still present in 
<http://tools.ietf.org/html/draft-ietf-webdav-rfc2518bis-18#section-9.10.1>. 
Further note that this issue has been raised first over six months ago 
(see <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>), 
so it would be really nice if it could get fixed in RFC2518bis ASAP.

Best regards, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 7 Mar 2007 10:53
Picon
Picon

Informal Last Call ends for draft-reschke-webdav-search-11, was: Informal Last Call for WebDAV SEARCH [Fwd: I-D ACTION:draft-reschke-webdav-search-11.txt]


Julian Reschke schrieb:
> Hi,
> 
> as discussed previously, I think I am done with documenting unresolved 
> issues, updating contact information and fixing editorial issues.
> 
> Thus, I'd like to start an informal Last Call of the draft with the goal 
> to submit it to the RFC Editor for publication as Experimental Standard 
> in three weeks from now.
> 
> The normative ASCII version is here:
> 
> <http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-11.txt>
> 
> HTML versions and the issue list can be found here:
> 
> <http://greenbytes.de/tech/webdav/#draft-reschke-webdav-search>
> 
> Best regards,
> 
> Julian

OK, the three week last call period ended yesterday.

There is one single change I'd like to do before submitting the document 
for publication: currently we refer to draft-newman-i18n-comparator-14, 
which is being published as RFC any day now. That citation should be 
updated (see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.B.1>).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jari Urpalainen | 8 Mar 2007 14:32
Picon

xcap co-operation with dav

hi !

Sorry for cross-posting. I've updated the i-d: 
<http://www.ietf.org/internet-drafts/draft-urpalainen-simple-xcap-webdav-02.txt> 
which describes some conventions for XCAP usage with WebDAV. Any comments ?
thanks, jari
Permalink | Reply | 0 comments |
headers
Ted Hardie | 8 Mar 2007 23:54

RFC2518bis


Howdy,
	The Secretariat will announce this more formally on Monday,
but I wanted to let the working group know that the IESG's evaluation
of draft-ietf-webdav-rfc2518bis-18.txt was positive.  There was considerable
discussion in the weeks leading up to today's telechat about how
to handle the combination of concerns (issues raised, length of process,
number of active contributors).  Lisa and Cullen recused themselves from
the IESG ballot (as author and WG chair), and the single DISCUSS from Russ
was resolved in conversation.
	The end result of the ballot represents consensus among the IESG that
the current document was sufficiently solid to be published as Proposed Standard,
that there were enough improvements in it to replace 2518, and that the work
needed a checkpoint.  This last is, honestly, a management issue as much as a
standards one; by putting a stake in the ground that says:  "further discussions
start from here", you can avoid the energy for progress evaporating in discussions
that recycle around the same few hot spots.  To highlight that aspect, I have
added this to the write-up for publication:

>There does remain some dissent that this document is the best that could
>be achieved, and there were proposals to continue work based on other
>starting points. The number of  contributors committed to that course of
>action was, however, smaller than would be normal for an active working
>group.  Publication of this document provides  a checkpoint of improvements to
>serve as the basis of implementation and potential later work.  It does
>not close off later improvement.

	So, what are the steps from here?   The Secretariat will make an
announcement that the document was approved some time early
next week.  Shortly following that, I will ask them to close the working group
(Continue reading)

Permalink | Reply | 503 comments |
headers
Julian Reschke | 9 Mar 2007 20:35
Picon
Picon

Re: RFC2518bis


Hi Ted,

thanks for the information.

It's a pity that RFC2518bis as of draft 18 isn't better -- lots of 
issues have been raised before and during the Last Calls, and only some 
of them have been fixed, although proposed resolutions for many of them 
were available.

In particular, it's kind of embarrassing that the WG has a second 
document in the pipeline (draft-ietf-webdav-bind-17) which already has 
to fix a bug in RFC2518bis - a bug that has been reported over half a 
year ago (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-17.html#rfc.section.A>).

That being said I *do* agree with the decision to close the working 
group, as the previous years have clearly shown that the WG's 
productivity wasn't as good as it should have been.

Looking forward to submitting SEARCH and BIND, and then to go on working 
on RFC2518bisbis, RFC3253bis and RFC3744bis as private submissions.

Best regards, Julian
Permalink | Reply | 502 comments |

Gmane