Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Eric Rescorla wrote: I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. I noticed that atompub is on next Thursday's IESG agenda. Any news on how this issue will be resolved? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On 2007-05-22 07:51, Philip Guenther wrote: On Mon, 21 May 2007, Jeffrey Hutzelman wrote: ... It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. We expect application protocols that require TLS to specify a mandatory- -to-implement ciphersuite to guarantee interoperability between clients and servers. How is the TLS version any different? A client that only supports TLS 1.0 will fail at handshake time if the server only supports TLS 1.1. Therefore, if interoperability is the goal, requiring support for a specific version is necessary. Since as you point out, TLS has version negotiation, don't you mean support for at least one specific version is necessary? And presumably that would be a version whose security is believed to be minimally adequate, with all earlier versions being forbidden. For example Implementations SHOULD support TLS 1.1 or later, MUST support TLS 1.0, MAY support SSLv3, and MUST NOT support SSLv2 or earlier. Brian -- NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Tue, 22 May 2007, Brian E Carpenter wrote: On 2007-05-22 07:51, Philip Guenther wrote: ... We expect application protocols that require TLS to specify a mandatory- -to-implement ciphersuite to guarantee interoperability between clients and servers. How is the TLS version any different? A client that only supports TLS 1.0 will fail at handshake time if the server only supports TLS 1.1. Therefore, if interoperability is the goal, requiring support for a specific version is necessary. Since as you point out, TLS has version negotiation, don't you mean support for at least one specific version is necessary? That's a clearer version of what I meant, yes. I certainly didn't mean must _only_ support specific version X.Y. It would probably be wise to have some canned words for this be provided by true TLS experts to avoid subtle failure modes. IIRC, a client that supports, say, TLS 1.2 and 1.0 but not 1.1 will not interoperate with a server that supports TLS 1.1 and 1.0. The client presumably violates some requirement, perhaps one for common sense, but I don't see it in a quick scan of the RFCs. (MUST request a version no smaller than X.Y and MUST support all versions between and including that version and X.Y?) And presumably that would be a version whose security is believed to be minimally adequate, with all earlier versions being forbidden. Yep. I was about to say and the same with cipher suites, but the ordering function for cipher suite security changes over time. sigh Philip Guenther ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Philip Guenther guenther plus ietfd at sendmail dot com wrote: That's a clearer version of what I meant, yes. I certainly didn't mean must _only_ support specific version X.Y. It would probably be wise to have some canned words for this be provided by true TLS experts to avoid subtle failure modes. IIRC, a client that supports, say, TLS 1.2 and 1.0 but not 1.1 will not interoperate with a server that supports TLS 1.1 and 1.0. The client presumably violates some requirement, perhaps one for common sense, but I don't see it in a quick scan of the RFCs. (MUST request a version no smaller than X.Y and MUST support all versions between and including that version and X.Y?) I remember MS-DOS software that would run under DOS version 3.3 or 5.0, but not 4.0. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On 5/19/07, Tim Bray [EMAIL PROTECTED] wrote: Well Rob, I think the community at large and the IESG in particular would welcome suggestions on what to do with this one. Sorry Tim, can't agree with that assertion. At least some people seem to be content with handwaving, if the current Atompub spec is any indication of consensus. In fact, we know what's going to happen: There's no need for the future tense, since a reasonable number of implementations exist. Here's a python implementation of TLS 1.1: http://pkgsrc.se/security/py-tlslite It comes with a demo HTTP server. See how many clients can connect when you use the mandatory cipher from TLS 1.1, and credentials that contain things like Chinese characters, Euro symbols, and smartquotes. On the plus side, you won't have any problems with authentication databases, because the credentials sent are reusable with any message and authentication scheme, at any time. -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla [EMAIL PROTECTED] wrote: I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Mon, 21 May 2007, Jeffrey Hutzelman wrote: ... It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. We expect application protocols that require TLS to specify a mandatory- -to-implement ciphersuite to guarantee interoperability between clients and servers. How is the TLS version any different? A client that only supports TLS 1.0 will fail at handshake time if the server only supports TLS 1.1. Therefore, if interoperability is the goal, requiring support for a specific version is necessary. While there are some potential library versioning issues for TLS, the fact that the protocol has version negotiation built in means the likely result is everyone will support old versions for longer than we all wish: how many clients send still send SSLv2-compatible handshake messages, even when using doing in-protocol upgrade (ala STARTTLS) where both ends are required to implement TLS? (This contrasts with the real versioning issues for Unicode libraries, where the lack of backwards compatibility with the normalization output of earlier versions has been an issue.) The TLS/SSL version/cipher-suite negotiation has its own risks, of course. If an earlier version and/or offered cipher-suite is catastrophically broken or just Too Weak, then the client cannot safely offer them. So, if the goal of the MtI requirement is security, then the spec needs to require a minimum version from servers *and* that clients not offer an earlier version, no? Back to your comment, I'm not sure what you mean by have to use completely different names. A name in DNS can have both A and records, as demonstrated by www.ietf.org. Code using getaddrinfo() may automatically try both, though the order they are returned in is an implementation detail. (That it's not clear whether getaddrinfo() is responsible for ordering them is probably another strike against it on Keith's list.) As for calling out a specific version of IP, there was recently a thread in the discussion around RFC 2821bis (821ter?) regarding whether it should have some normative wording against sending messages whose envelope sender (bounce address) can only be reached using IPv6**, as delivery failure notices might not be returnable. I believe the only conclusions reached were don't tie to IP revisions in this doc and yuck. Philip Guenther Sendmail, Inc. ** That is, where the envelope sender address's domain either has MX records that point to hosts that only have records, or which has no MX or A records but does have one or more records. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Tim Bray wrote: On 5/18/07, Robert Sayre [EMAIL PROTECTED] 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. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 [EMAIL PROTECTED] 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
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
At Sat, 19 May 2007 20:34:06 -0700, Tim Bray wrote: On 5/18/07, Robert Sayre [EMAIL PROTECTED] 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 I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert Sayre wrote: Here's a diff of the changes since last call: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-15-from-14.diff.html It's not clear whether there will be another last call, though I think there should be. So, I will leave my comments again. I didn't see any working group comments on the topic. ... http://www.imc.org/atom-protocol/mail-archive/threads.html#09386 Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On 3/14/07, EKR [EMAIL PROTECTED] wrote: Julian Reschke [EMAIL PROTECTED] writes: As pointed out before, that text really is confusing. As a reader. I'm left wondering whether I need to implement RFC2246 or RFC4346. Or both? I wish I knew the answer to this question as well... :) Seriously, we're shortly going three separate versions of TLS standardized, 1.0, 1.1, and 1.2, plus SSLv3. So, the question of what to require implementors to do is a tricky one that actually doesn't have that much to do with TLS :) Here's a diff of the changes since last call: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-15-from-14.diff.html It's not clear whether there will be another last call, though I think there should be. So, I will leave my comments again. I didn't see any working group comments on the topic. 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. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Hi Robert, --On March 13, 2007 3:23:22 PM -0400 Robert Sayre [EMAIL PROTECTED] wrote: This text is actively misleading, because it suggests RFC 4346 is included for informational purposes. The text should read: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818] and [RFC4346]. The text that got used in CalDAV (which is about to be published) is: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); with 2246, 2818 and 4346 all normative references. These type of up-references are not ideal and I believe there was some discussion going on somewhere about how better to deal with this type of situation. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On 2007-03-13 20:43, Cyrus Daboo wrote: Hi Robert, --On March 13, 2007 3:23:22 PM -0400 Robert Sayre [EMAIL PROTECTED] wrote: This text is actively misleading, because it suggests RFC 4346 is included for informational purposes. The text should read: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818] and [RFC4346]. The text that got used in CalDAV (which is about to be published) is: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); with 2246, 2818 and 4346 all normative references. These type of up-references are not ideal and I believe there was some discussion going on somewhere about how better to deal with this type of situation. You may be thinking of draft-klensin-norm-ref, which is in Last Call as BCP through Friday this week. Just to confirm: 2818 has already been downrefed so it can be used in this way without further formality. http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Brian E Carpenter schrieb: On 2007-03-13 20:43, Cyrus Daboo wrote: The text that got used in CalDAV (which is about to be published) is: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); with 2246, 2818 and 4346 all normative references. These type of up-references are not ideal and I believe there was some discussion going on somewhere about how better to deal with this type of situation. ... As pointed out before, that text really is confusing. As a reader. I'm left wondering whether I need to implement RFC2246 or RFC4346. Or both? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Julian Reschke [EMAIL PROTECTED] writes: Brian E Carpenter schrieb: On 2007-03-13 20:43, Cyrus Daboo wrote: The text that got used in CalDAV (which is about to be published) is: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); with 2246, 2818 and 4346 all normative references. These type of up-references are not ideal and I believe there was some discussion going on somewhere about how better to deal with this type of situation. ... As pointed out before, that text really is confusing. As a reader. I'm left wondering whether I need to implement RFC2246 or RFC4346. Or both? I wish I knew the answer to this question as well... :) Seriously, we're shortly going three separate versions of TLS standardized, 1.0, 1.1, and 1.2, plus SSLv3. So, the question of what to require implementors to do is a tricky one that actually doesn't have that much to do with TLS :) -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert == Robert Sayre [EMAIL PROTECTED] writes: Robert From the draft: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]. See [RFC4346] for more information on TLS. Robert I've discovered a small but potentially critical mistake Robert in the references here. RFC2818 is an informative Robert reference, so the text must read as specified by Robert [RFC4346]. My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Sam Hartman wrote: My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. Is RFC 2818 sufficient to ensure interoperability? It would be quite easy for two implementations to claim to implement TLS and fail to interoperate. RFC 4346 contains mandatory cipher suites. Without those, conformant implementations could fail during authentication setup, right? The same danger would exist if the draft claimed HTTP Authentication must be supported without specifying a scheme. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert == Robert Sayre [EMAIL PROTECTED] writes: Robert Sam Hartman wrote: My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. Robert Is RFC 2818 sufficient to ensure interoperability? It Robert would be quite easy for two implementations to claim to Robert implement TLS and fail to interoperate. RFC 4346 Robert contains mandatory cipher suites. Without those, Robert conformant implementations could fail during Robert authentication setup, right? The same danger would exist I think both 2818 and 4346 contain important details and need to be normative. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Sam Hartman wrote: I think both 2818 and 4346 contain important details and need to be normative. That makes sense to me. However, I initially thought the references had been mistakenly switched around. From the draft: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]. See [RFC4346] for more information on TLS. This text is actively misleading, because it suggests RFC 4346 is included for informational purposes. The text should read: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818] and [RFC4346]. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
