At Sun, 20 May 2007 15:04:54 +0200,
Julian Reschke wrote:
Tim Bray wrote:
On 5/18/07, Robert Sayre <sayrer(_at_)gmail(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf