Re: Draft -16 out now

Cullen Jennings schrieb:
>> 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.
> 
> 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

Received on Tuesday, 28 November 2006 10:29:21 UTC