[Ietf-caldav] References in draft-dusseault-caldav-12

[Lisa Dusseault]

I answered too fast and forgot one important point:  a single,  
mandatory-to-implement secure transport is necessary to have both  
interoperability and to meet the "no plain-text passwords in the  
clear" requirement.  If a server supported only IPSec and a client  
supported only TLS, that would not be interoperable.  I find TLS to  
be the preferable mandatory-to-implement solution.

It looks like our text could still do with some improvement however;  
something along the lines of "Servers MUST NOT offer BASIC over an  
unprotected channel.  Clients MUST support TLS in order to provide  
one channel-encryption mechanism that servers can rely on if they  
decide to offer BASIC."

lisa

On Jun 23, 2006, at 11:03 AM, Lisa Dusseault wrote:

>
> On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote:
>
>> Hello,
>>
>> I think it can be argued that since 4.1.1 states
>> that either TLS or IPSEC is valid to remedy the
>> situation, that the authors were suggesting that
>> the protocol's _use_ be protected and not that the
>> protocol itself has to supply protection. Ie.
>> plain-text CalDAV over an IPSEC VPN would satisfy
>> 4.1.1 in that case.
>>
>> In other words the CalDAV spec does not have to
>> mandate TLS but rather mandate that either TLS or
>> IPSEC be used when using the protocol.
>
> This is a very good point, thanks.
>
>> PS. + $0.02 :)  The Etag issue, this, and a recent
>> iCalendar issue seem to stem from CalDAV not
>> 'looking the other way' on deficiencies in
>> HTTP and iCalendar.
>>
>> This is commendable, but by doing this it forces
>> developers to investigate and modify components
>> that they otherwise would have been able to
>> utilize as 'black box' components.
>>
>> For example, clients who would simply call a HTTP
>> stack with a url, username and password will now
>> have to check the type of authorization is being
>> used and fail that connection if auth is basic.
>> Not to mention relay that to the user in a way
>> that is useful to them.  This is compounded by the
>> fact that the authorization layer may not be in
>> the developers control.  Eg. The client application
>> already supports WebDAV or some other HTTP protocol
>> and the CalDAV component or layer simply calls that
>> function with a simplified API interface.
>>
>> My point is maybe we should avoid conflicting with
>> lower level protocols if at all possible, for the
>> sake of adoption?
>
> A pragmatic approach, yes.  Philosophically I tend to agree with  
> you (there are too many cases to list, where we simply went with  
> what the underlying protocols provided, as that was our first  
> choice usually), but there are always a couple exceptions.  The  
> ETag ambiguity simply interfered too much with interoperability and  
> reliable synching.  And the secured transport (when using plain- 
> text passwords) is not only a good idea, it's important to get  
> CalDAV approved.
>
> Lisa