Subject: Draft -16 out now

From: Lisa Dusseault <[email-masked]>
Date: Sun, 26 Nov 2006 10:51:30 -0800

Draft -15 of RFC2518bis expired, and I knew we needed a live draft  
for any further action, so I spun up draft -16.  The major bugs to be  
fixed in this version were:
	- inconsistent use of "Lock-Token" header in an example, when the  
text requires "if" (the thread below)
	- bug in example of extending "all-prop" with "include" directive  
(bug 188 I think)

Also I went through the bugzilla issues raised since -15 (all post-WG- 
last-call).  I tried to make very conservative judgements about what  
textual/editorial improvements were clearly useful improvements and  
yet not destabilizing to the draft overall at this stage.

XML and text versions at http://ietf.osafoundation.org/xythoswfs/ 
webui/webdav/rfc2518bis until the version submitted to the Internet- 
Drafts repository goes up.

thx,
Lisa

On Jun 15, 2006, at 11:32 AM, Lisa Dusseault wrote:

>
> By the way, I'd fix this bug in a heartbeat if I thought this would  
> get us done.  The example is inconsistent, although the  
> precondition is correct as is -- the problem is not that the lock  
> token needed to be submitted (one was), the problem is that the  
> lock token does not match the resource.
>
> But rather than make just this one change to the document,  I'm  
> waiting for somebody to help us make progress on other issues or  
> somebody to agree that other issues are closed.  Jim, maybe if  
> you're less swamped now you can review the state?
>
> Lisa
>
> On May 21, 2006, at 1:18 PM, Julian Reschke wrote:
>
>> Lisa,
>>
>> thanks for the changes in draft 15. I still think that the  
>> precondition now doesn't fit anymore (it's not the Lock-Token  
>> header that was missing). Furthermore, the example is now  
>> inconsistent with the spec. Suggested changes:
>>
>> Section 9.10.6., para. 6:
>> OLD:
>>
>>     412 (Precondition Failed), with 'lock-token-matches-request-uri'
>>     precondition code - The LOCK request was made with a If header,
>>     indicating that the client wishes to refresh the given lock.
>>     However, the Request-URI did not fall within the scope of the  
>> lock
>>     identified by the token.  The lock may have a scope that does not
>>     include the Request-URI, or the lock could have disappeared,  
>> or the
>>     token may be invalid.
>>
>> NEW:
>>
>>     412 (Precondition Failed), with 'lock-token-submitted'  
>> precondition
>>     code - The LOCK request was made with an If header, indicating  
>> that
>>     the client wishes to refresh the given lock.  However, the  
>> Request-
>>     URI did not fall within the scope of the lock identified by the
>>     token.  The lock may have a scope that does not include the  
>> Request-
>>     URI, or the lock could have disappeared, or the token may be  
>> invalid.
>>
>>
>> Section 9.10.8., para. 2:
>> OLD:
>>
>>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>>       Host: example.com
>>       Timeout: Infinite, Second-4100000000
>>       Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
>>       Authorization: Digest username="ejw",
>>         realm="[email-masked]", nonce="...",
>>         uri="/workspace/webdav/proposal.doc",
>>         response="...", opaque="..."
>>
>> NEW:
>>
>>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>>       Host: example.com
>>       Timeout: Infinite, Second-4100000000
>>       If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
>>
>>       Authorization: Digest username="ejw",
>>         realm="[email-masked]", nonce="...",
>>         uri="/workspace/webdav/proposal.doc",
>>         response="...", opaque="..."
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Nov 2006 21:39:11 +0100

Lisa Dusseault schrieb:
> 
> Draft -15 of RFC2518bis expired, and I knew we needed a live draft for 
> any further action, so I spun up draft -16.  The major bugs to be fixed 
> in this version were:
> Also I went through the bugzilla issues raised since -15 (all 
> post-WG-last-call).  I tried to make very conservative judgements about 
> what textual/editorial improvements were clearly useful improvements and 

I don't think that any of the suggested changes would indeed 
"destabilize" the draft -- sorry, but this is just FUD.

> XML and text versions at 
> http://ietf.osafoundation.org/xythoswfs/webui/webdav/rfc2518bis until 
> the version submitted to the Internet-Drafts repository goes up.

Turns out that there's a normative change in there in the Security 
Requirements:

Section 20.1., para. 2:
OLD:

     A password sent in the clear over an insecure channel is an
     inadequate means for protecting the accessibility and integrity of a
     resource as the password may be intercepted.  Since Basic
     authentication for HTTP/1.1 performs essentially clear text
     transmission of a password, Basic authentication MUST NOT be used to
     authenticate a WebDAV client to a server unless the connection is
     secure.  Furthermore, a WebDAV server MUST NOT send Basic
     authentication credentials in a WWW-Authenticate header unless the
     connection is secure.  Examples of secure connections include a
     Transport Layer Security (TLS) connection employing a strong cipher
     suite with mutual authentication of client and server, or a
     connection over a network which is physically secure, for example, an
     isolated network in a building with restricted access.

NEW:

     A password sent in the clear over an insecure channel is an
     inadequate means for protecting the accessibility and integrity of a
     resource as the password may be intercepted.  Since Basic
     authentication for HTTP/1.1 performs essentially clear text
     transmission of a password, Basic authentication MUST NOT be used to
     authenticate a WebDAV client to a server unless the connection is
     secured by TLS.  Furthermore, a WebDAV server MUST NOT send a Basic
     authentication challenge in a WWW-Authenticate header unless the
     connection is secured by TLS.

Funny enough, the changes section claims...:

     Fixed factual errors in Security Considerations authentication
     section.

     ...

     Tighten requirements in Security Considerations section for
     authentication over secure channels.

So,

(1) please explain the nature of the factual error that was fixed 
(bugzilla issue?), and

(2) please clarify where there was a prior discussion about changing the 
security requirements (at this stage, if I may add...). Please also note 
that this would introduce a normative dependency on TLS, for which we'd 
need a reference.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Nov 2006 13:49:18 +0100

Cullen Jennings schrieb:
> 
> Hi - Julian - stuff inline. I'm sending this with my Webdav Chair hat on 
> ... Lisa and I did talk about this before and I have have have 
> conversations with security area folks and ADs on this topic.
> ...
> I think this referred to the description of a *server* sending 
> credentials with Basic - that was wrong the only way a server 
> authenticates itself is with TLS. This was fixed by moving "credential" 
> to "challenges"  - I think this was the original intent and this was 
> just a mistake in getting the words down.

OK, that's an editorial fix. Good.

>> (2) please clarify where there was a prior discussion about changing 
>> the security requirements (at this stage, if I may add...).
> 
> The only thing of relevance that seems to has changed here is removal of 
> the words around "or connection over a network which is physically 
> secure, for example, an isolated network in a building with restricted 
> access". The draft did not provide a way for a client or server to 
> detect that the complete network connection was secure in this form - in 
> general it does not seem that there is a way for to reliably detect that 
> the complete end to end connection is secure so I did not bother to ask 
> the WG to try and add this. There are many long threads on this topic 
> but the bottom line is that general IETF view is that sending passwords 
> over an unencrypted link like this causes more harm that the cost of 
> doing digest. If we want to change that, we would need to go make that 
> argument somewhere in the security area not in the webdav WG.

Well, no. Before, the specification allowed *any* kind of secure 
connection, and listed TLS and a network with restricted access as 
*examples*. This is why we didn't need a normative reference to TLS 
after all.

Now, Basic Auth MUST use TLS, which is a new requirement, that 
definitively hasn't been discussed here before.

Personally, I would propose not to mess with this section unless there's 
something clearly wrong with it.

>> Please also note that this would introduce a normative dependency on 
>> TLS, for which we'd need a reference.
> 
> Yes you are right - we depend in a normative way on TLS and need the 
> reference. I will work with Lisa on sorting this out. Note that servers 
> can be complaint servers without implementing or deploying TLS, they 
> just need to use digest instead of basic.

Well, maybe we should start eating our own dogfood then? Both 
http://www.webdav.org and http://ietf.osafoundation.org/ allow Basic 
Authentication over HTTP, after all.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Nov 2006 11:29:10 +0100

Cullen Jennings schrieb:
>> Personally, I would propose not to mess with this section unless 
>> there's something clearly wrong with it.
> 
> Ok - I see your point. At this point, my primary goal is getting a 
> document that is better than RFC 2518 off to the IESG. So I'm proposing 
> that I ask Lisa to replace the text with the flowing and I will provide 
> an explanation of why this text below.
> 
>   A password sent in the clear over an insecure channel
>   is an inadequate means for protecting the accessibility
>   and integrity of a resource as the password may be
>   intercepted. Since Basic authentication for HTTP/1.1
>   performs essentially clear text transmission of a
>   password, Basic authentication MUST NOT be used to
>   authenticate a WebDAV client to a server unless the
>   connection is secure. Furthermore, a WebDAV server
>   MUST NOT send a Basic authentication challenge in
>   a WWW-Authenticate header unless the connection
>   is secure. An examples of a secure connections
>   would be a Transport Layer Security (TLS) connection
>   employing a strong cipher suite and server authentication.
> 
> This text is some cut and pasted of what was in 15. I changed the 
> "credential" to "challenge" as that seemed to be a bug in the text. I 

Good.

> removed the "mutual" authentication because in TLS, "mutual" means that 
> the client would require a certificate and is not what is needed or what 
> I think the WG meant here. (Classic HTTPS connections are not "mutual" 
> in the TLS sense of the word). I removed the isolated building example 

Good.

> because there is no way for a webdav client or server to detect that it 
> is running in an environment such as this. I left the text open so that 

I'm not entirely happy with that, but it guess that if a server is 
running in an isolated environment, it's not on the Internet so 
compliance to the spec isn't really important.

> TLS is only one possible example and other examples of secure networks 
> are also allowed - SASL upgrade approaches come to mind. I would not be 
> surprised to see this text get some comments in IETF last call but if it 
> represents rough consensus in this WG, I would be glad to request 
> publication.
> 
> Could everyone in the WG let me know if you could live with this really 
> soon and I will ask Lisa to make this change.

I'm happy with this change, but I don't think the spec is ready at all. 
We have tons of open issues, many of them being raised in WG last call, 
some later, and also lots of editorial problems as well. See 
<http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED> 
which currently list 35 open bugs.

For many of them, there are proposed fixes in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>. 
If we *finally* get back to work, we should start addressing those.

As an example, have a look at 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=227>. This 
problem has been raised in February, there's a consensus how to resolve 
it, but it doesn't show up in draft 14, 15 or 16. I hope this explains 
why I'm so unhappy with how the draft has been developed in the previous 
months.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Nov 2006 10:54:14 -0800

For some reason, I am only seeing Julian's replies to Cullen; this reply
is really to Cullen, but applies to the whole thread.
At 11:29 AM +0100 11/28/06, Julian Reschke wrote:
>Cullen Jennings schrieb:
>>
>>Ok - I see your point. At this point, my primary goal is getting a document that is better than RFC 2518 off to the IESG.

I'm glad that this issue seems to have been so quickly resolved, and I hope others
can comment about whether the new text is okay.  But I think folks should really
be narrowing focus at this point.  This effort has been around for a long time, and
we agreed nearly a year ago to get this document through the last hump and out
the door.  The chair and document author both getting put on the IESG at the
same time pulled critical energy from the group during what should have been
its final clean-up.   Since that point, we have had only occasional bursts of energy,
and some of that has focused on areas that were not truly core to the work
(like the WEBDAV capabilities in HTML thread Jim raised--these are interesting,
but not chartered work).

I believe that we have had strong consensus for a long time to replace RFC 2518,
and I think the focus at this point has to narrow to places where the current document
isn't as clear as 2518.  Given the traffic since the WGLC on -14 back in February,
I just don't see the energy to take on more at this point.  I think putting the document
in front of the larger community and acknowledging that it isn't  perfect but
is a needed improvement is the way to go.

If the group cannot do that in a short period of time, I would have to seriously
consider closing it.  The amount of energy here would clearly not justify a new
working group; this one has continued despite that participation level partially
because of continuity and partly because of the issues in 2518.  I am not sure,
however, that there is enough energy to survive another AD transition, and
handing off to a new AD is March is a certainty.

I encourage everyone to focus on the highest priority items *only* at this point
and to keep in mind that not getting this out means 2518 stays as the standard
for this.  I do not think that is anyone's interest at this point.
				regards,
					Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Nov 2006 20:17:43 +0100

> is really to Cullen, but applies to the whole thread.

Yes, there's a known issue with Cullen's emails; maybe Jim Whitehead has 
got an idea why they aren't reaching the mailing list.

> the door.  The chair and document author both getting put on the IESG at the

The problem here is that once we got it out of the door (WGLC-wise), 
almost no follow up activities happened. There *were* LC comments, and 
most of them haven't been acted upon.

I spent a considerable amount of time maintaining a version of the draft 
  with issues and many potential resolutions, but, quite frankly, this 
doesn't seem to help in fixing the problems in the WG's version of the 
draft. I really have no idea why.

> (like the WEBDAV capabilities in HTML thread Jim raised--these are interesting,

Yes.

 From my point of view, activities went away when it became clear that 
no matter how much work is done in categorizing the issues and 
discussing resolutions, none of that work made it into the WG's draft. 
Which, in fact, just expired a few weeks ago, so there was no "official" 
WG activity on the draft for over 6 months.

As a matter of fact, I was seriously considering submitting "my" version 
of the draft as a private submission just this weekend, just to get 
things going again.

> is a needed improvement is the way to go.

The problem aren't things that haven't improved, but changes that 
actually make it worse (in some parts). For instance, I'm insisting on 
exact language about locking *because* the lock of clarity was a problem 
in RFC2518.

> for this.  I do not think that is anyone's interest at this point.

I would suggest to review the changes proposed in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>. 
That document also lists open LC issues (with no proposed resolution), 
and any kind of constructive feedback on those would be very welcome. 
Alternatively, reviewing the open issue list at 
<http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis> 
would be useful as well.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 10:13:07 +0100

(forwarding to the list, as requested by Cullen)

Cullen Jennings schrieb:
> 
> On Nov 28, 2006, at 11:17 AM, Julian Reschke wrote:
> 
>> Ted Hardie schrieb:
>> Yes, there's a known issue with Cullen's emails; maybe Jim Whitehead 
>> has got an idea why they aren't reaching the mailing list.
>>
> 
> Jim and I are working on this but in the mean time, Julian or Lisa, feel 
> free to forward this to the list.
> 
>>>>> document that is better than RFC 2518 off to the IESG.
>> I spent a considerable amount of time maintaining a version of the 
>> draft  with issues and many potential resolutions, but, quite frankly, 
>> this doesn't seem to help in fixing the problems in the WG's version 
>> of the draft. I really have no idea why.
>>
> 
> I'm appreciative of the review and raising issues you do - and do 
> quickly. I view the problem as, for many of the issues, we can't get to 
> the point where more than a handful of people agree on the resolution to 
> them. More below ...
> 
>> Which, in fact, just expired a few weeks ago, so there was no 
>> "official" WG activity on the draft for over 6 months.
>>
>> As a matter of fact, I was seriously considering submitting "my" 
>> version of the draft as a private submission just this weekend, just 
>> to get things going again.
>>
>> exact language about locking *because* the lock of clarity was a 
>> problem in RFC2518.
> 
> We have spent a huge number of hours discussing locking - I doubt that 
> more time on this is going to significantly change people from their 
> current position.
> 
>>
> I went through every change in the version of this from a week or so ago 
> and compared them to the draft. For each one I asked myself, is this 
> critical that we fix this before publication? Is their clear consensus 
> on how this should be? is this a "typo" type change that everyone would 
> agree to and we just need to fix? For the ones that I came up with a 
> "Yes" to one of these questions, I asked Lisa to change and she did. 
> Now, I no doubt made some mistakes along the way but we have to realize 
> this document would be better finished than perfect. I tried to focus on 
> things that would cause implementers to end up creating software that 
> did not interoperate.
> 
> The one change that did not fall into one of these categories was the 
> change around the basic with secure/TLS. You rightly pointed out that 
> change did not have consensus and was a non trivial normative change.
> 
> 
> I also when thought that whole list (but not the stuff that was added in 
> November) and asked similar questions. I tried to focus on issues that 
> were raised before the end of the WGLC. One of the problems with any 
> document is we can always find yet one more problem with it so I try to 
> focus on things before WGLC. I do realize that if we fine a total show 
> stopper bug at any point, we do have to deal with it. (I just had to 
> deal with a very bad bug that was found promptly after the RFC was 
> published).
> 
> Once we sort out this secure network text, I want to request publication 
> of this. All complex drafts reach a point where you need to enough has 
> been done, it's not perfect, but it is worth publishing. I feel the time 
> has come for this draft (actually I think it is long past). The rate of 
> incremental improvement is approaching the limit. The time and energy 
> the WG has is small. The draft is a significant improvement over the 
> previous RFC. Publishing this does not mean we can' every publish a bis 
> draft to fix/improve the problems with this draft.
> 
> Once publication is requested, Ted as the AD would have the opportunity 
> to review and ask us to correct problems and it would go for IETF LC. 
> This would be another opportunity to identify any true show stopper 
> problems that absolutely needed to be fixed.
> 
> Cullen <with me chair hat on>
> 
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 14:00:42 +0100

> the point where more than a handful of people agree on the resolution to 

Well, as a matter of fact it seems we don't even have a handful of 
people reviewing that stuff anymore. I think that one of the reasons is 
that people just think: "what's the point?". In the last months, many 
issues have been raised, but nothing has been done. Why should people 
continue to participate if there's no sign that this leads anywhere?

> more time on this is going to significantly change people from their 

The things I was referring to are actual *bugs* in the spec. That is, 
the spec doesn't say what the consensus was.

For instance:

Issue 244: 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=244> (lock 
creator vs owner)

Issue 251:
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251> (lock 
root being a URI, not a resource)

I do agree that there are other issue with locking which will be harder 
to resolve, but just because some of the open issues are harder 
shouldn't stop us from resolving the simpler ones right away (and 
discuss the harder ones separately).

> things that would cause implementers to end up creating software that 

Well, it seems that I need to do a better job in explaining *why* many 
of these are critical, then. When I have time, I will go through the 
list myself and re-raise the issues on the mailing list then.

> change did not have consensus and was a non trivial normative change.

Thanks.

> deal with a very bad bug that was found promptly after the RFC was 

Cullen, the date when something was entered into Bugzilla doesn't 
indicate when it was raised first. Keep in mind that people raised 
issues on the mailing list, not Bugzilla. The fact that they *are* in 
Bugzilla at all is because I tried to keep track of open issues in a 
systematic way.

> draft to fix/improve the problems with this draft.

I respectfully disagree. Many parts of the current document are a mess, 
and although it fixes many issues from RFC2518, it introduces lots of 
new ones. At this stage, I think a short errata document for RFC2518 
would be much more valuable than publishing this draft.

> Cullen <with me chair hat on>

My experience is that comments sent during IETF Last Call aren't 
tracked, and the people submitting them frequently get zero feedback 
from the authors and the IESG (last experienced with XCAP). That being 
said, I don't think it's a good quality check for a document anymore.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 29 Nov 2006 14:55:38 +0100

Am 28.11.2006 um 19:54 schrieb Ted Hardie:

> [...]
> consider closing it.

+1 for closing.

//Stefan

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Nov 2006 17:08:58 -0800

On Nov 28, 2006, at 11:17 AM, Julian Reschke wrote:

> Yes, there's a known issue with Cullen's emails; maybe Jim  
> Whitehead has got an idea why they aren't reaching the mailing list.
>

Jim and I are working on this but in the mean time, Julian or Lisa,  
feel free to forward this to the list.

>>>> Ok - I see your point. At this point, my primary goal is getting  
>>>> a document that is better than RFC 2518 off to the IESG.
> The problem here is that once we got it out of the door (WGLC- 
> wise), almost no follow up activities happened. There *were* LC  
> comments, and most of them haven't been acted upon.
>
> draft  with issues and many potential resolutions, but, quite  
> frankly, this doesn't seem to help in fixing the problems in the  
> WG's version of the draft. I really have no idea why.
>

I'm appreciative of the review and raising issues you do - and do  
quickly. I view the problem as, for many of the issues, we can't get  
to the point where more than a handful of people agree on the  
resolution to them. More below ...

> From my point of view, activities went away when it became clear  
> that no matter how much work is done in categorizing the issues and  
> discussing resolutions, none of that work made it into the WG's  
> draft. Which, in fact, just expired a few weeks ago, so there was  
> no "official" WG activity on the draft for over 6 months.
>
> version of the draft as a private submission just this weekend,  
> just to get things going again.
>
> actually make it worse (in some parts). For instance, I'm insisting  
> on exact language about locking *because* the lock of clarity was a  
> problem in RFC2518.

We have spent a huge number of hours discussing locking - I doubt  
that more time on this is going to significantly change people from  
their current position.

> I would suggest to review the changes proposed in <http:// 
> greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis- 
> latest.html>.

I went through every change in the version of this from a week or so  
ago and compared them to the draft. For each one I asked myself, is  
this critical that we fix this before publication? Is their clear  
consensus on how this should be? is this a "typo" type change that  
everyone would agree to and we just need to fix? For the ones that I  
came up with a "Yes" to one of these questions, I asked Lisa to  
change and she did. Now, I no doubt made some mistakes along the way  
but we have to realize this document would be better finished than  
perfect. I tried to focus on things that would cause implementers to  
end up creating software that did not interoperate.

> That document also lists open LC issues (with no proposed  
> resolution), and any kind of constructive feedback on those would  
> be very welcome. Alternatively, reviewing the open issue list at  
> <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi? 
> product=WebDAV-RFC2518-bis> would be useful as well.

I also when thought that whole list (but not the stuff that was added  
in November) and asked similar questions. I tried to focus on issues  
that were raised before the end of the WGLC. One of the problems with  
any document is we can always find yet one more problem with it so I  
try to focus on things before WGLC. I do realize that if we fine a  
total show stopper bug at any point, we do have to deal with it. (I  
just had to deal with a very bad bug that was found promptly after  
the RFC was published).

Once we sort out this secure network text, I want to request  
publication of this. All complex drafts reach a point where you need  
to enough has been done, it's not perfect, but it is worth  
publishing. I feel the time has come for this draft (actually I think  
it is long past). The rate of incremental improvement is approaching  
the limit. The time and energy the WG has is small. The draft is a  
significant improvement over the previous RFC. Publishing this does  
not mean we can' every publish a bis draft to fix/improve the  
problems with this draft.

Once publication is requested, Ted as the AD would have the  
opportunity to review and ask us to correct problems and it would go  
for IETF LC. This would be another opportunity to identify any true  
show stopper problems that absolutely needed to be fixed.