Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

At Sun, 20 May 2007 15:04:54 +0200,
Julian Reschke wrote:
> 
> Tim Bray wrote:
> > On 5/18/07, Robert Sayre <sayrer@gmail.com> wrote:
> >> I think the substituted text is inadequate, because it is not clear
> >> which TLS version implementors MUST support. As I understand it, the
> >> fact that it is "tricky", implying there may be trade-offs, is not
> >> sufficient to avoid specifying a single, mandatory-to-implement TLS
> >> version.
> > 
> > Well Rob, I think the community at large and the IESG in particular
> > would welcome suggestions on what to do with this one.  In fact, we
> > know what's going to happen: implementors will use the default TLS
> > library for whatever platform they're on, and this will do the job,
> > most times.  However, I think that we have better-than-rough consensus
> > that the specification landscape is a mess, making normative
> > references  a bitch, and that this will probably bite nearly
> > everything in the Apps area from here on in.
> > 
> > I hope someone with the necessary expertise will take this bull by the
> > horns.  -Tim
> 
> ...and I would add that as the IESG got us into this situation, it's 
> their job to clarify.
> 
> Let me add one data point... Another spec recently *approved* by the 
> IESG says 
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#rfc.section.20.1>):
> 
> "20.1 Authentication of Clients
> 
> Due to their emphasis on authoring, WebDAV servers need to use 
> authentication technology to protect not just access to a network 
> resource, but the integrity of the resource as well. Furthermore, the 
> introduction of locking functionality requires support for authentication.
> 
> 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 example of a secure 
> connection would be a Transport Layer Security (TLS) connection 
> employing a strong cipher suite and server authentication.
> 
> WebDAV applications MUST support the Digest authentication scheme 
> [RFC2617]. Since Digest authentication verifies that both parties to a 
> communication know a shared secret, a password, without having to send 
> that secret in the clear, Digest authentication avoids the security 
> problems inherent in Basic authentication while providing a level of 
> authentication which is useful in a wide range of scenarios."
> 
> So apparently the whole mess involving RFC2818, RFC2246 and RFC4346 is 
> not really required.

Yes, the other option is to use Digest, which, as I recall, the Atompub
WG did not want to do.

-Ekr

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf