From owner-ietf-apps-tls Tue May 6 16:04:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA18408 for ietf-apps-tls-bks; Tue, 6 May 1997 16:04:09 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA18402 for ; Tue, 6 May 1997 16:04:05 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 16:01:55 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Welcome to the ietf-apps-tls mailing list Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Greetings. The purpose of this mailing list is to help facilitate discussion of how Internet applications should run over TLS (also known as SSL). I started the list after feeling the need for application-savvy developers to look over e To get things rolling, I've just submitted the -01 version of my draft to the Internet Drafts editor. The full text of the draft is fairly short, and is appended below. Of course, comments are welcome (that's why we're here!). --Paul Hoffman, Director --Internet Mail Consortium Internet Draft Paul Hoffman draft-hoffman-smtp-ssl-01.txt Internet Mail Consortium May 6, 1997 Expires six months later SMTP Service Extension for Secure SMTP over TLS Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. 2. Introduction SMTP [RFC-821] servers and clients normally communicate in the clear over the Internet. In many cases, this communication goes through one or more router that is not controlled or trusted by either entity. Such an untrusted router might allow a third party to monitor or alter the communications between the server and client. Further, there is often a desire for two SMTP agents to be able to authenticate each others' identities. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know. TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing TCP communications with privacy and authentication. TLS is in wide use with the HTTP protocol, and is also being used for adding security to many other common protocols that run over TCP. 2.1 Discussion of this Draft This draft is being discussed on the "ietf-apps-tls" mailing list. To subscribe, send a message to: ietf-apps-tls-request@imc.org witht the single word subscribe in the body of the message. There is a Web site for the mailing list at . 3. TLS Extension The TLS extension to SMTP is laid out as follows: (1) the name of the SMTP service defined here is TLS; (2) the EHLO keyword value associated with the extension is TLS; (3) the TLS keyword has an optional parameter that contains a space-separated list of tokens describing the type and version of TLS that can be used; (4) a new SMTP verb, "STARTTLS", and its parameter, are defined; (5) no additional parameters are added to any SMTP command. 4. The TLS Keyword The TLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS. It has one optional parameter: a space-separated list of tokens describing the type and version of TLS that can be used. Each token describes a TLS protocol that has a description that has been published by the IESG. The only tokens currently defined are: Protocol Token Reference -------- ----- --------- TLS 1.0 TLS1.0 [TLS] SSL 2.0 SSL2.0 SSL 3.0 SSL3.0 [SSL30] 5. The STARTTLS Command The format for the STARTTLS command is: STARTTLS token where the token parameter is one of the tokens described in Section 4. After the client gives the STARTTLS command, the server responds with one of the following reply codes: 220 - Ready to start TLS 501 - Syntax error (no parameter, more than one parameters) 504 - TLS not available due to the server not being able to use the specified protocol 554 - TLS not available due to some other reason A server SHOULD be able to accept other SMTP commands before receiving a STARTTLS command. After receiving a 220 response to a STARTTLS command, the client MUST start the TLS procedure immediately. After the TLS handshake has been completed, both parties MUST decide whether or not to continue based on the authentication and privacy achieved. The SMTP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy because most SMTP services are performed with no authentication and no privacy, but some SMTP clients or servers may want to continue only if a particular level of authentication and/or privacy was achieved. If the SMTP client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD issue an SMTP QUIT command immediately after the TLS negotiation is complete. If the SMTP server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code (with a possible text string such as "Command refused due to lack of security"). 6. Usage Example The following dialog illustrates how a client and server can start a TLS session on the first attempt: S: C: S: 220 mail.imc.org SMTP service ready C: EHLO mail.ietf.org S: 250-mail.imc.org is ever so glad you called S: 250 TLS TLS1.0 SSL3.0 C: STARTTLS TLS1.0 S: 220 Go ahead with TLS1.0 C & S: C & S: The following dialog illustrates how a client and server can start a TLS session after trying a TLS protocol the server doesn't support: S: C: S: 220 mail.imc.org SMTP service ready C: EHLO mail.ietf.org S: 250-mail.imc.org invites you into the living room S: 250 TLS C: STARTTLS SSL3.0 S: 504 Sorry, I don't know how to SSL3.0 C: STARTTLS TLS1.0 S: 220 Go ahead with TLS1.0 C & S: C & S: 7. Security Considerations It should be noted that SMTP is not an end-to-end mechanism. Thus, if an SMTP client/server pair decide to add TLS privacy, they are not securing the transport from the originating mail user agent to the recipient. Further, because delivery of a single piece of mail may go between more than two SMTP servers, adding TLS privacy to one pair of servers does not mean that the entire SMTP chain has been made private. Further, just because an SMTP server can authenticate a client, it does not mean that the mail from the client was authenticated by the client when the client received it. Both the STMP client and server must check the result of the TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. A server announcing in an EHLO response that it uses a particular TLS protocol should not pose any security issues, since any use of TLS will be at least as secure as no use of TLS. The SMTP client should note carefully the result of the TLS negotiation. If the negotiation results in no privacy, the client may choose to abort the SMTP session. Another draft, [SMTP-AUTH], proposes a different mechanism that can also add privacy and security to SMTP.[SMTP-AUTH] does not allow for using TLS, but instead describes how to enable other security protocols when using SMTP. A. References [RFC-821] "Simple Mail Transfer Protocol", RFC 821 [RFC-1869] "SMTP Service Extensions", RFC 1869 [SMTP-AUTH] "SMTP Service Extension for Authentication", draft-myers-smtp-auth [SSL30] "The SSL Protocol Version 3.0", draft-ietf-tls-ssl-version3 [TLS] "The TLS Protocol Version 1.0", draft-ietf-tls-protocol B. Outstanding Issues Need to create an IANA registry and vetting process for adding new tokens. C. Revision History ***Changes from -00 to -01: Added information about the mailing list discussing the draft. Added SSL 2.0 to token list. Reworded the end of Section 5 to better describe what a client must do after a 220 response. Added wording to Section 5 indicating that both parties must check the state of the connection after the TLS handshake before continuing. Also added this to Section 7 (Security). Added paragraph to Section 7 emphasizing that this does not give end-to-end security for email. D. Author's Address Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 (408) 426-9827 phoffman@imc.org From owner-ietf-apps-tls Tue May 6 16:51:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA18964 for ietf-apps-tls-bks; Tue, 6 May 1997 16:51:17 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA18958; Tue, 6 May 1997 16:51:15 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA12967; Tue, 6 May 1997 16:50:54 -0700 Date: Tue, 6 May 1997 16:50:53 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Welcome to the ietf-apps-tls mailing list To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Minor, but... The TLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS. It has one optional parameter: ^^^^^^^^ Then why do we have? 501 - Syntax error (no parameter, more than one parameters) ^^^^^^^^^^^^ ...and no description of a default if no parameter is supplied. Seems to me that the parameter isn't optional. From owner-ietf-apps-tls Tue May 6 17:23:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA19265 for ietf-apps-tls-bks; Tue, 6 May 1997 17:23:03 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA19261 for ; Tue, 6 May 1997 17:23:00 -0700 (PDT) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 17:23:05 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 4:50 PM -0700 5/6/97, Mike Macgirvin wrote: >Then why do we have? > > 501 - Syntax error (no parameter, more than one parameters) > ^^^^^^^^^^^^ Whoops. The 501 error is for more than one parameters only. I'll fix this in the next draft. (The example even shows using it with no parameter. What was I thinking?...) --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue May 6 18:26:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA20280 for ietf-apps-tls-bks; Tue, 6 May 1997 18:26:27 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA20273; Tue, 6 May 1997 18:26:22 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id SAA00650; Tue, 6 May 1997 18:26:20 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id SAA00396; Tue, 6 May 1997 18:26:18 -0700 (PDT) Message-Id: <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Tue, 6 May 97 18:26:15 -0700 To: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list cc: ietf-apps-tls@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > 7. Security Considerations > It may be worthwhile to note the potential impact of a MIM altering the TLS keyword parameters, e.g., nuke "TLS.10" and "SSL3.0" in lieu of "SSL2.0", or nuke the TLS keyword altogether. I didn't see anything in the draft that mentioned TLS parameter preferential order. I don't know if you want to impose an order. If you don't, you may want to explicitly say so. -dpg From owner-ietf-apps-tls Tue May 6 19:03:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA20763 for ietf-apps-tls-bks; Tue, 6 May 1997 19:03:05 -0700 (PDT) Received: from porta-sparc.portolacomm.com ([170.1.164.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA20759 for ; Tue, 6 May 1997 19:03:03 -0700 (PDT) Received: from jgm.portolacomm.com (jgm.portolacomm.com [170.1.164.26]) by porta-sparc.portolacomm.com (1.0.b2/8.8.5) with SMTP id TAA00465 for ; Tue, 6 May 1997 19:02:43 -0700 (PDT) Date: Tue, 6 May 1997 19:02:42 -0700 (PDT) From: John Gardiner Myers To: ietf-apps-tls@imc.org Subject: Re: Welcome to the ietf-apps-tls mailing list In-Reply-To: <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Tue, 6 May 1997, Dennis Glatting wrote: > It may be worthwhile to note the potential impact of a MIM > altering the TLS keyword parameters, e.g., nuke "TLS.10" and > "SSL3.0" in lieu of "SSL2.0", or nuke the TLS keyword > altogether. Given that anything implementing STARTTLS is "new", why support SSL2.0 at all? Is there a real need to negotiate the difference between SSL3.0 and TLS? It's kinda annoying the SSL folks apparently didn't figure out how to negotiate protocol extension stuff within the SSL/TLS protocol itself. From owner-ietf-apps-tls Tue May 6 19:22:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA20966 for ietf-apps-tls-bks; Tue, 6 May 1997 19:22:48 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA20961 for ; Tue, 6 May 1997 19:22:44 -0700 (PDT) Message-Id: In-Reply-To: References: <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 19:22:48 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 7:02 PM -0700 5/6/97, John Gardiner Myers wrote: >Given that anything implementing STARTTLS is "new", why support SSL2.0 >at all? There are toolkits for it that some people like. >Is there a real need to negotiate the difference between SSL3.0 and TLS? Yes. SSL3.0 and TLS have protocol differences, and some implementations might support one and not the other. >It's kinda annoying the SSL folks apparently didn't figure out how to >negotiate protocol extension stuff within the SSL/TLS protocol itself. This is the ietf-apps-tls list, not the ietf-tls list. :-) --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue May 6 19:22:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA20965 for ietf-apps-tls-bks; Tue, 6 May 1997 19:22:47 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA20957 for ; Tue, 6 May 1997 19:22:43 -0700 (PDT) Message-Id: In-Reply-To: <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 19:20:35 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 6:26 PM -0700 5/6/97, Dennis Glatting wrote: >It may be worthwhile to note the potential impact of a MIM >altering the TLS keyword parameters, e.g., nuke "TLS.10" and >"SSL3.0" in lieu of "SSL2.0", or nuke the TLS keyword >altogether. I'm not sure what you mean by "impact". Section 5 says: :After the TLS handshake has been completed, both parties MUST decide :whether or not to continue based on the authentication and privacy :achieved. This is a MUST, not a SHOULD. A MIM altering the keyword would still have to get by this final check. >I didn't see anything in the draft that mentioned TLS parameter >preferential order. I don't know if you want to impose an order. >If you don't, you may want to explicitly say so. I didn't think a preferred order was important; that is, if you list it, you should like it. Do others think an order is useful for something? --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue May 6 19:35:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA21387 for ietf-apps-tls-bks; Tue, 6 May 1997 19:35:14 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA21373; Tue, 6 May 1997 19:35:10 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id TAA02074; Tue, 6 May 1997 19:35:19 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id TAA00453; Tue, 6 May 1997 19:35:19 -0700 (PDT) Message-Id: <199705070235.TAA00453@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Tue, 6 May 97 19:35:16 -0700 To: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list cc: ietf-apps-tls@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Date: Tue, 6 May 1997 19:20:35 -0700 From: "Paul E. Hoffman" > At 6:26 PM -0700 5/6/97, Dennis Glatting wrote: > > >It may be worthwhile to note the potential impact of a MIM > >altering the TLS keyword parameters, e.g., nuke "TLS.10" and > >"SSL3.0" in lieu of "SSL2.0", or nuke the TLS keyword > >altogether. > > I'm not sure what you mean by "impact". Section 5 says: > :After the TLS handshake has been completed, both parties MUST decide > :whether or not to continue based on the authentication and privacy > :achieved. > This is a MUST, not a SHOULD. A MIM altering the keyword would still have > to get by this final check. > If two parties permit a given set of all types, e.g., they support all three types, and the set is altered by a MIM, then the selected type will probably be the strongest of the altered set. If two parties support non-TLS connections and TLS connections and the TLS keyword is nuked, then a non-TLS connection may be established. Of course, a party could have knowledge of the other's capabilities, which is certainly possible, but does not scale. -dpg From owner-ietf-apps-tls Tue May 6 21:06:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA26832 for ietf-apps-tls-bks; Tue, 6 May 1997 21:06:46 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA26824 for ; Tue, 6 May 1997 21:06:43 -0700 (PDT) Message-Id: In-Reply-To: <199705070235.TAA00453@imo.plaintalk.bellevue.wa.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 21:03:54 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Welcome to the ietf-apps-tls mailing list Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 7:35 PM -0700 5/6/97, Dennis Glatting wrote: >If two parties permit a given set of all types, e.g., they >support all three types, and the set is altered by a MIM, then the >selected type will probably be the strongest of the altered >set. In my mind, this still fits in the category of "OK", since both sides decide after the handshake if they are happy with where they ended up (and possibly how they ended up there). >If two parties support non-TLS connections and TLS >connections and the TLS keyword is nuked, then a non-TLS >connection may be established. True. I'll add this to the next draft. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 7 00:29:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA01643 for ietf-apps-tls-bks; Wed, 7 May 1997 00:29:48 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA01638; Wed, 7 May 1997 00:29:45 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA16156; Wed, 7 May 1997 00:29:21 -0700 Date: Wed, 7 May 1997 00:29:21 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Welcome to the ietf-apps-tls mailing list To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > >If two parties permit a given set of all types, e.g., they > >support all three types, and the set is altered by a MIM, then the > >selected type will probably be the strongest of the altered > >set. > > In my mind, this still fits in the category of "OK", since both sides > decide after the handshake if they are happy with where they ended up (and > possibly how they ended up there). > > >If two parties support non-TLS connections and TLS > >connections and the TLS keyword is nuked, then a non-TLS > >connection may be established. > > True. I'll add this to the next draft. This is one of the conditions that gave us problems for TLS/IMAP. There doesn't seen to be any way out of this without prior client knowledge - or a separate port (which isn't an option for TLS/SMTP). It would seem that the submission agent needs to be configured for minimum security level. That's not a difficult problem. In the case of relays, it does get a bit more complicated. This appears to be ripe for a RCPT To: extension which can get passed along and provides an indication of what security level should be achieved, and how to react if it can't. We've come from a world where SMTP does everything in its power to get the message to the destination, but this is one place where it would be entirely reasonable for the sender to indicate that an abort was the only appropriate action if a secure channel could not be negotiated. This could be linked with DSN's for reporting. RCPT TO: TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \ ORCPT=rfc822;max@netscape.com indicates we try tls1.0, then sslv3 and drop the message (with a return DSN) if this cannot be achieved. Without the NOTIFY parameter, we just RTS. RCPT TO: TLS=TLS1.0,SSL3.0 indicates we try tls1.0, then sslv3 but allow the delivery to continue in any event with no reports. From owner-ietf-apps-tls Wed May 7 08:58:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA10271 for ietf-apps-tls-bks; Wed, 7 May 1997 08:58:19 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA10256 for ; Wed, 7 May 1997 08:58:09 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 7 May 1997 15:58:22 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id LAA06781 for ; Wed, 7 May 1997 11:59:19 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 7 May 1997 15:58:21 UT Received: from masey.ftp.com (massey.ftp.com [128.127.94.152]) by lbo.leftbank.com (8.7.5/8.7.3/http://www.LeftBank.Com) with SMTP id LAA09871 for ; Wed, 7 May 1997 11:58:20 -0400 (EDT) Message-Id: <3.0.1.32.19970507115636.0071f330@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 07 May 1997 11:56:36 -0400 To: ietf-apps-tls@imc.org From: Rodney Thayer Subject: Re: Welcome to the ietf-apps-tls mailing list In-Reply-To: References: < <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 07:22 PM 5/6/97 -0700, you wrote: >This is the ietf-apps-tls list, not the ietf-tls list. :-) > >--Paul E. Hoffman, Director And if we find a TLS problem we should share it on the TLS list or else they can't be expected to fix it now can they? From owner-ietf-apps-tls Wed May 7 08:58:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA10267 for ietf-apps-tls-bks; Wed, 7 May 1997 08:58:14 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA10254 for ; Wed, 7 May 1997 08:58:09 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 7 May 1997 15:58:22 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id LAA06777; Wed, 7 May 1997 11:59:18 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 7 May 1997 15:58:20 UT Received: from masey.ftp.com (massey.ftp.com [128.127.94.152]) by lbo.leftbank.com (8.7.5/8.7.3/http://www.LeftBank.Com) with SMTP id LAA09868; Wed, 7 May 1997 11:58:19 -0400 (EDT) Message-Id: <3.0.1.32.19970507115526.00720268@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 07 May 1997 11:55:26 -0400 To: John Gardiner Myers From: Rodney Thayer Subject: r.e. tls/ssl negotiation Cc: ietf-apps-tls@imc.org In-Reply-To: References: <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Are you asking for TLS to do more negotiation or for SSL3 to do more negotiation? At 07:02 PM 5/6/97 -0700, you wrote: >On Tue, 6 May 1997, Dennis Glatting wrote: >> It may be worthwhile to note the potential impact of a MIM >> altering the TLS keyword parameters, e.g., nuke "TLS.10" and >> "SSL3.0" in lieu of "SSL2.0", or nuke the TLS keyword >> altogether. > >Given that anything implementing STARTTLS is "new", why support SSL2.0 >at all? > >Is there a real need to negotiate the difference between SSL3.0 and TLS? > >It's kinda annoying the SSL folks apparently didn't figure out how to >negotiate protocol extension stuff within the SSL/TLS protocol itself. > > > > > From owner-ietf-apps-tls Wed May 7 10:13:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA11765 for ietf-apps-tls-bks; Wed, 7 May 1997 10:13:05 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA11760; Wed, 7 May 1997 10:13:02 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIL1VFV8N699GXTK@INNOSOFT.COM>; Wed, 7 May 1997 10:12:13 PDT Date: Wed, 07 May 1997 10:13:44 -0700 (PDT) From: Chris Newman Subject: New keywords In-reply-to: To: "Paul E. Hoffman" Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Tue, 6 May 1997, Paul E. Hoffman wrote: > B. Outstanding Issues > > Need to create an IANA registry and vetting process for adding new > tokens. I disagree. If TLS1.0 is designed correctly, there won't be any more new versions. So no registry is needed since the spec will have a complete list. On the off change that yet-another new version is created, you can always revise the spec. In short, I think the right thing to do is to punt this issue. From owner-ietf-apps-tls Wed May 7 10:26:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA12030 for ietf-apps-tls-bks; Wed, 7 May 1997 10:26:10 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA12026 for ; Wed, 7 May 1997 10:26:07 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIL2CM0QHC99GXTK@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 7 May 1997 10:25:17 PDT Date: Wed, 07 May 1997 10:26:47 -0700 (PDT) From: Chris Newman Subject: Re: Welcome to the ietf-apps-tls mailing list In-reply-to: To: Mike Macgirvin Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Wed, 7 May 1997, Mike Macgirvin wrote: > This is one of the conditions that gave us problems for TLS/IMAP. There > doesn't seen to be any way out of this without prior client knowledge - or a > separate port (which isn't an option for TLS/SMTP). A separate port doesn't solve the problem as one can always muck with the TLS negotiation. > It would seem that the submission agent needs to be configured for > minimum security level. That's not a difficult problem. In the case of relays, > it does get a bit more complicated. Every client and server needs to be configured with a minimum security level, regardless of the protocols or negotiation mechanisms used. > This appears to be ripe for a RCPT To: extension which can get passed > along and provides an indication of what security level should be achieved, and > how to react if it can't. We've come from a world where SMTP does everything in > its power to get the message to the destination, but this is one place where it > would be entirely reasonable for the sender to indicate that an abort was the > only appropriate action if a secure channel could not be negotiated. This could > be linked with DSN's for reporting. > > RCPT TO: TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \ > ORCPT=rfc822;max@netscape.com > > indicates we try tls1.0, then sslv3 and drop the message (with a return > DSN) if this cannot be achieved. Without the NOTIFY parameter, we just RTS. > > RCPT TO: TLS=TLS1.0,SSL3.0 > > indicates we try tls1.0, then sslv3 but allow the delivery to continue > in any event with no reports. This proposal would lead the the appearance of having end-to-end security, without actually having it. For that reason, I think it's a bad idea. We should all be using standards-track message object security such as defined in RFC 2015 for real end-to-end security. Besides, this proposal also fails to mention things like what key length is acceptable and which encryption algorithms are acceptable (I'd probably request that key-escrow, key-recovery, and trade-secret algorithms not be used since their security characteristics are unknown.) From owner-ietf-apps-tls Wed May 7 10:54:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA12540 for ietf-apps-tls-bks; Wed, 7 May 1997 10:54:06 -0700 (PDT) Received: from porta-sparc.portolacomm.com ([170.1.164.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA12535 for ; Wed, 7 May 1997 10:54:03 -0700 (PDT) Received: from jgm.portolacomm.com (jgm.portolacomm.com [170.1.164.26]) by porta-sparc.portolacomm.com (1.0.b2/8.8.5) with SMTP id KAA11651 for ; Wed, 7 May 1997 10:53:46 -0700 (PDT) Date: Wed, 7 May 1997 10:53:45 -0700 (PDT) From: John Gardiner Myers To: ietf-apps-tls@imc.org Subject: Re: Welcome to the ietf-apps-tls mailing list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Tue, 6 May 1997, Paul E. Hoffman wrote: > At 7:02 PM -0700 5/6/97, John Gardiner Myers wrote: > >Given that anything implementing STARTTLS is "new", why support SSL2.0 > >at all? > > There are toolkits for it that some people like. Do any of these toolkits allow SSL to be started up on an already-existing connection? I was under the impression that SSL toolkits would need a little upgrading in order to be able to support STARTTLS, at which point it is not unreasonable to also expect them to support at least SSL3.0. The ink may still be damp on TLS, but SSL3.0 has been out for a while. > >Is there a real need to negotiate the difference between SSL3.0 and TLS? > > Yes. SSL3.0 and TLS have protocol differences, and some implementations > might support one and not the other. But is it necessary to negotiate this outside of the SSL/TLS handshake? Since TLS was given a version number of "3.1" instead of "4.0", this would lead me to consider it likely that a 3.0 implementation and a 3.1 implementation would be able to successfully talk to each other. From owner-ietf-apps-tls Wed May 7 11:00:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12602 for ietf-apps-tls-bks; Wed, 7 May 1997 11:00:20 -0700 (PDT) Received: from porta-sparc.portolacomm.com ([170.1.164.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA12596 for ; Wed, 7 May 1997 11:00:15 -0700 (PDT) Received: from jgm.portolacomm.com (jgm.portolacomm.com [170.1.164.26]) by porta-sparc.portolacomm.com (1.0.b2/8.8.5) with SMTP id KAA11692 for ; Wed, 7 May 1997 10:59:57 -0700 (PDT) Date: Wed, 7 May 1997 10:59:56 -0700 (PDT) From: John Gardiner Myers To: ietf-apps-tls@imc.org Subject: Re: Welcome to the ietf-apps-tls mailing list In-Reply-To: <199705070235.TAA00453@imo.plaintalk.bellevue.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Tue, 6 May 1997, Dennis Glatting wrote: > If two parties support non-TLS connections and TLS > connections and the TLS keyword is nuked, then a non-TLS > connection may be established. An implementation which accepts both TLS and non-TLS connections is vulnerable to this attack, regardless of the method used for selecting TLS. It is not specific to STARTTLS. For example, if TLS and non-TLS connections are done on separate ports, a MIM attacker could cause the connection to the TLS port to fail with a fake ICMP Port Unreachable ("connection refused") error. Then, a non-TLS connection may be established. From owner-ietf-apps-tls Wed May 7 11:04:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12734 for ietf-apps-tls-bks; Wed, 7 May 1997 11:04:56 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA12730 for ; Wed, 7 May 1997 11:04:53 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id LAA07096; Wed, 7 May 1997 11:04:58 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id LAA00747; Wed, 7 May 1997 11:04:57 -0700 (PDT) Message-Id: <199705071804.LAA00747@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Wed, 7 May 97 11:04:54 -0700 To: John Gardiner Myers Subject: Re: Welcome to the ietf-apps-tls mailing list cc: ietf-apps-tls@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Date: Wed, 7 May 1997 10:59:56 -0700 (PDT) From: John Gardiner Myers > On Tue, 6 May 1997, Dennis Glatting wrote: > > If two parties support non-TLS connections and TLS > > connections and the TLS keyword is nuked, then a non-TLS > > connection may be established. > > An implementation which accepts both TLS and non-TLS > connections is vulnerable to this attack, regardless of the > method used for selecting TLS. It is not specific to STARTTLS. > > For example, if TLS and non-TLS connections are done on > separate ports, a MIM attacker could cause the connection to > the TLS port to fail with a fake ICMP Port Unreachable > ("connection refused") error. Then, a non-TLS connection may > be established. > I whole heartily agree. I am suggesting it be included in the Security Issues section of the draft. -dpg From owner-ietf-apps-tls Wed May 7 11:14:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12886 for ietf-apps-tls-bks; Wed, 7 May 1997 11:14:01 -0700 (PDT) Received: from porta-sparc.portolacomm.com ([170.1.164.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA12882 for ; Wed, 7 May 1997 11:13:55 -0700 (PDT) Received: from jgm.portolacomm.com (jgm.portolacomm.com [170.1.164.26]) by porta-sparc.portolacomm.com (1.0.b2/8.8.5) with SMTP id LAA11905 for ; Wed, 7 May 1997 11:13:36 -0700 (PDT) Date: Wed, 7 May 1997 11:13:35 -0700 (PDT) From: John Gardiner Myers To: ietf-apps-tls@imc.org Subject: Re: r.e. tls/ssl negotiation In-Reply-To: <3.0.1.32.19970507115526.00720268@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Wed, 7 May 1997, Rodney Thayer wrote: > Are you asking for TLS to do more negotiation or for SSL3 to do more > negotiation? I was expressing frustration at a rather annoying design flaw in SSL, which seems to also exist in TLS. This flaw is the failure of the protocol to be forward-compatible, as evidenced by the need to negotiate outside of SSL which version of the protocol is to be used. As Paul Hoffman aptly points out, this is not something this forum can fix in TLS. So, we express hold our noses and deal with it at the application layer. From owner-ietf-apps-tls Wed May 7 11:52:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA13373 for ietf-apps-tls-bks; Wed, 7 May 1997 11:52:35 -0700 (PDT) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA13369 for ; Wed, 7 May 1997 11:52:32 -0700 (PDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id NAA22722; Wed, 7 May 1997 13:50:54 -0500 (CDT) Received: from kcx-ks9-27.ix.netcom.com(198.211.69.91) by dfw-ix1.ix.netcom.com via smap (V1.3) id sma022674; Wed May 7 13:50:29 1997 Message-ID: <33707A16.3665@ix.netcom.com> Date: Wed, 07 May 1997 13:48:22 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: Rodney Thayer CC: IETF LDAP , ietf-apps-tls@imc.org Subject: Re: Welcome to the ietf-apps-tls mailing list References: < <199705070126.SAA00396@imo.plaintalk.bellevue.wa.us> <3.0.1.32.19970507115636.0071f330@pop3.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Rodney and all, Rodney Thayer wrote: > > At 07:22 PM 5/6/97 -0700, you wrote: > >This is the ietf-apps-tls list, not the ietf-tls list. :-) > > > >--Paul E. Hoffman, Director > > And if we find a TLS problem we should share it on the TLS list or else > they can't be expected to fix it now can they? My sentiments exactly. I had wondered why this issue wasn't brought up with Win T. ? Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. Phone :913-294-2375 (v- office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Wed May 7 11:55:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA13404 for ietf-apps-tls-bks; Wed, 7 May 1997 11:55:19 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA13400 for ; Wed, 7 May 1997 11:55:12 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA17650; Wed, 7 May 1997 11:54:32 -0700 Date: Wed, 7 May 1997 11:54:32 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Welcome to the ietf-apps-tls mailing list To: Chris Newman cc: Mike Macgirvin , ietf-apps-tls@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > > This is one of the conditions that gave us problems for TLS/IMAP. > > There > > doesn't seen to be any way out of this without prior client knowledge - > > or a separate port (which isn't an option for TLS/SMTP). > > A separate port doesn't solve the problem as one can always muck with the > TLS negotiation. True, but less of a concern than a server which may or may not do TLS and we knew it once did - saying it doesn't do it anymore. If we're talking to a TLS (port) service, we will either agree that we're talking to who we think we are, or we say bye-bye (and not fall back on a non-TLS service on the normal port). In any event, a separate port isn't on the table. Paul H has given some very good reasons in past discussions why this should be avoided at all costs. > Every client and server needs to be configured with a minimum security > level, regardless of the protocols or negotiation mechanisms used. Certainly. > > RCPT TO: TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \ > > ORCPT=rfc822;max@netscape.com > > > > indicates we try tls1.0, then sslv3 and drop the message (with a > > return > > DSN) if this cannot be achieved. Without the NOTIFY parameter, we just > > RTS. > > RCPT TO: TLS=TLS1.0,SSL3.0 > > > > indicates we try tls1.0, then sslv3 but allow the delivery to > > continue > > in any event with no reports. > > This proposal would lead the the appearance of having end-to-end security, > without actually having it. For that reason, I think it's a bad idea. We > should all be using standards-track message object security such as > defined in RFC 2015 for real end-to-end security. Hmmm. Then you recommend that once we've gone through the trouble of establishing a trust channel with the first MTA in the chain, that we then just throw our message to the wolves once it's left that system. I'm typically not too worried about the wire going from me to the nearest server. In most places I've worked, I could physically inspect it if I wanted. I'm REAL worried about the other 100 wires between that server and my message destination. Object security has a high cost in perceived delay time to the end user during message retrieval. Certainly it's more secure and easier to maintain than a set of trust/verify relationships, but it bites hard on dialups if your mailbox is suddenly 90% base64. It also does not address security tunneling via the message envelope and header; which often betray the contents. I believe each approach has its place; and will appeal to different customers. ...Some might even want both. > Besides, this proposal also fails to mention things like what key length > is acceptable and which encryption algorithms are acceptable (I'd > probably request that key-escrow, key-recovery, and trade-secret > algorithms not be used since their security characteristics are unknown.) I suppose this means that my midnight ramblings weren't polished enough for an RFC or draft submission... sigh... and I tried so hard.... ;=) From owner-ietf-apps-tls Wed May 7 13:14:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA14471 for ietf-apps-tls-bks; Wed, 7 May 1997 13:14:39 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA14467 for ; Wed, 7 May 1997 13:14:36 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIL88IJEEG99GZ7L@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 7 May 1997 13:13:46 PDT Date: Wed, 07 May 1997 13:15:16 -0700 (PDT) From: Chris Newman Subject: Re: Welcome to the ietf-apps-tls mailing list In-reply-to: To: Mike Macgirvin Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Wed, 7 May 1997, Mike Macgirvin wrote: > Hmmm. Then you recommend that once we've gone through the trouble of > establishing a trust channel with the first MTA in the chain, that we then just > throw our message to the wolves once it's left that system. I'm typically not > too worried about the wire going from me to the nearest server. In most places > I've worked, I could physically inspect it if I wanted. I'm REAL worried about > the other 100 wires between that server and my message destination. The problem is that once the message gets to the other end of the wire, it's unencrypted. So the message is vulnerable at every node, it's only secure when in transit between nodes. It order to get a secure path, one has to trust every node, which is unlikely from a policy standpoint, especially considering lack of DNS security and MX fallback issues. It's dangerous to advertise something as secure when it really it's really less secure than users will assume. > Object security has a high cost in perceived delay time to the end user during > message retrieval. Certainly it's more secure and easier to maintain than a set > of trust/verify relationships, but it bites hard on dialups if your mailbox is > suddenly 90% base64. It also does not address security tunneling via the > message envelope and header; which often betray the contents. We're working on a proposal to do "application/batch-smtp" wrapped up in a multipart/encrypted to get MTA to MTA secure tunnelling. That allows one to pass the message through untrusted nodes, yet still decode it before dropping it in the recipient's mailstore. From owner-ietf-apps-tls Wed May 7 18:05:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA17517 for ietf-apps-tls-bks; Wed, 7 May 1997 18:05:42 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA17505 for ; Wed, 7 May 1997 18:05:38 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 18:05:49 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Servers that just want to have TLS Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is related to Mike Macgirvin's question, and something that I don't have in the current SMTP/TLS draft. The resolution of it shoul be applicable to all apps over TLS topics. What should a server do if it *only* wants to talk TLS? This is a server on the standard port, not a TLS-only port. I considered adding something to the SMTP draft that said someting to the effect of: If the client doesn't give a STARTTLS command and the server will only talk after a sucessful TLS handshake, the server should constantly reply to every command with 567 (or some such new number) codes until the client either issues a STARTTLS or issues a QUIT. Now, this clearly won't work for an SMTP server that is the terminal relay for any domain that the outside world wants to send mail to. But it could be desired, or even required, within some closed systems, such as for mail submission. Further, such a server might be used by private agreement, and it wants to tell anyone outside the private agreement to go away. The issue is more valuable for things like IMAP servers. I can certainly see some companies having two IMAP servers, one at "tls.imap.foo.com" and the other at "unsafe.imap.foo.com". Only certain logins would be allowed at "unsafe." (such as for public mailboxes or low-priority people) while all logins would be accepted at "tls.". The server needs a way to tell a client that doesn't do a STARTTLS (or whatever we end up putting into the IMAP/TLS spec) "tell me to start TLS, or go away". As you can tell, I'm not completely settled on this. Comments are welcome. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 7 18:05:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA17518 for ietf-apps-tls-bks; Wed, 7 May 1997 18:05:47 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA17498 for ; Wed, 7 May 1997 18:05:37 -0700 (PDT) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 17:52:44 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: New keywords Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 10:13 AM -0700 5/7/97, Chris Newman wrote: >I disagree. If TLS1.0 is designed correctly, there won't be any more new >versions. So no registry is needed since the spec will have a complete >list. Except that at the Memphis meeting they already started talking about many things that would go into TLS 1.1 that would make it incompatible with 1.0. This is not to say I *want* and IANA registry: I would rather not have one. It just seems appropriate if we know that there is some work that we will want to reference but we can't yet. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 7 20:56:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA19479 for ietf-apps-tls-bks; Wed, 7 May 1997 20:56:25 -0700 (PDT) Received: from cryptsoft.com (pandora.cryptsoft.com [203.56.44.11]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA19473 for ; Wed, 7 May 1997 20:56:13 -0700 (PDT) Received: (from tjh@localhost) by cryptsoft.com (8.8.3/8.7.3) id NAA02185; Thu, 8 May 1997 13:56:47 +1000 (EST) From: Tim Hudson Message-Id: <199705080356.NAA02185@cryptsoft.com> Subject: Re: Welcome to the ietf-apps-tls mailing list To: jgm@portolacomm.com (John Gardiner Myers) Date: Thu, 8 May 1997 13:56:46 +1000 (EST) Cc: ietf-apps-tls@imc.org Reply-To: tjh@cryptsoft.com In-Reply-To: from "John Gardiner Myers" at May 7, 97 10:53:45 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk According to John Gardiner Myers: > > There are toolkits for it that some people like. > Do any of these toolkits allow SSL to be started up on an > already-existing connection? SSLeay supports this and has done so for two years now. SSLtelnet and SSLftp exist and support either direct non-negotiated SSL connections or negotiation via extensions of the existing extensions for doing encryption. There is a document draft-murray-auth-ftp-ssl-01.txt that details an expansion of the system used in SSLftp to cater for a wider set of requirements than what I had went I wrote the original code. > I was under the impression that SSL toolkits would need a little > upgrading in order to be able to support STARTTLS, at which point it > is not unreasonable to also expect them to support at least SSL3.0. SSL2 is widely deployed. SSL3 is also widely deployed for https only. There are interesting quirks in the existing implementation that add a number of challenges when trying to interoperate and do serious work with client certificates. SSLeay with support for SSL3 will be in general release as of July 1 at which point in time all the existing products (freeware, shareware and commercial) built on top of it will rapidly be upgraded to supporting SSL3. Building an infrastructure that doesn't allow for the widely deployed toolkits available in source form is not sensible given that reference implementations need to be generally available to get rapid deployment and restricting things to in essence a USA only market would not be a smart move in my opinion. A framework should support existing and future use. Tim. (naturally this is just my opinion ...) From owner-ietf-apps-tls Thu May 8 06:52:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA26755 for ietf-apps-tls-bks; Thu, 8 May 1997 06:52:16 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA26751 for ; Thu, 8 May 1997 06:52:12 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 8 May 1997 13:52:29 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id JAA21355 for ; Thu, 8 May 1997 09:53:26 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 8 May 1997 13:52:27 UT Received: from masey.ftp.com (massey.ftp.com [128.127.94.152]) by lbo.leftbank.com (8.7.5/8.7.3/http://www.LeftBank.Com) with SMTP id JAA13420 for ; Thu, 8 May 1997 09:52:26 -0400 (EDT) Message-Id: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 08 May 1997 09:48:54 -0400 To: ietf-apps-tls@imc.org From: Rodney Thayer Subject: Re: Servers that just want to have TLS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk What to do if a server JUST wants to talk TLS.... I was thinking that one valid implementation path would be to simply always use the TLS code. So, if someone tried to talk to you in the clear, you'd fail negotiation. End of story. Just like if you telnet to www.openmarket.com port 443 (a/k/a ) with a generic Telnet client. From owner-ietf-apps-tls Thu May 8 08:43:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA28313 for ietf-apps-tls-bks; Thu, 8 May 1997 08:43:36 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA28309 for ; Thu, 8 May 1997 08:43:33 -0700 (PDT) Message-Id: In-Reply-To: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 08:42:18 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Servers that just want to have TLS Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 6:48 AM -0700 5/8/97, Rodney Thayer wrote: >What to do if a server JUST wants to talk TLS.... > >I was thinking that one valid implementation path would be to simply always >use the TLS code. So, if someone tried to talk to you in the clear, you'd >fail negotiation. End of story. Just like if you telnet to >www.openmarket.com port 443 (a/k/a ) with a >generic Telnet client. So in the SMTP case, you are saying: S: C: C & S: C & S: S: 220 mail.imc.org SMTP service ready I tend think this is a bad idea on any well-known port for which a client might expect a non-TLS session. In the case of a non-TLS client, it would start getting a stream of gibberish that it could not deal with at all. A well-crafted SMTP client should do something like "The first thing it said to me wasn't 220, so I'll just leave", but I'm not sure that many will do this if handed a binary stream from the server. In this case, maybe the first thing out of the server's mouth should be something like "287 Give a STARTTLS command before I talk to you at all". And, I still want a general model for application protocols where the client talks first. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu May 8 09:35:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA29039 for ietf-apps-tls-bks; Thu, 8 May 1997 09:35:59 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA29031; Thu, 8 May 1997 09:35:56 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA29369; Thu, 8 May 1997 09:35:41 -0700 Date: Thu, 8 May 1997 09:35:41 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Servers that just want to have TLS To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > S: > C: > C & S: > C & S: > S: 220 mail.imc.org SMTP service ready > > I tend think this is a bad idea on any well-known port for which a client > might expect a non-TLS session. In the case of a non-TLS client, it would > start getting a stream of gibberish that it could not deal with at all. A > well-crafted SMTP client should do something like "The first thing it said > to me wasn't 220, so I'll just leave", but I'm not sure that many will do > this if handed a binary stream from the server. The cleanest approach is a 5xx error message on anything but EHLO and STARTTLS ...and perhaps AUTH XXX, where XXX is some form of authentication which offers equivalent protection services. From owner-ietf-apps-tls Thu May 8 10:30:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA29870 for ietf-apps-tls-bks; Thu, 8 May 1997 10:30:40 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA29865; Thu, 8 May 1997 10:30:36 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id KAA08781; Thu, 8 May 1997 10:30:49 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id KAA01653; Thu, 8 May 1997 10:30:47 -0700 (PDT) Message-Id: <199705081730.KAA01653@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Thu, 8 May 97 10:30:45 -0700 To: "Paul E. Hoffman" Subject: Re: Servers that just want to have TLS cc: ietf-apps-tls@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a bit off the subject but the message spurred the thought... For SMTP with TLS, does it make sense to have each peer hash the contents of what it sends and receives before a secure connection is established then the peers compare those hashes after establishment? (Similar to TLS.) I am tempted to conclude the value is marginal. Specifically, it may detect key word tampering but not removal of the TLS keyword itself. -dpg From owner-ietf-apps-tls Thu May 8 11:14:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00776 for ietf-apps-tls-bks; Thu, 8 May 1997 11:14:00 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA00772 for ; Thu, 8 May 1997 11:13:56 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 8 May 1997 18:14:13 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id OAA27123 for ; Thu, 8 May 1997 14:15:10 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 8 May 1997 18:14:11 UT Received: from massey.ftp.com (massey.ftp.com [128.127.94.152]) by lbo.leftbank.com (8.7.5/8.7.3/http://www.LeftBank.Com) with SMTP id OAA14414 for ; Thu, 8 May 1997 14:14:10 -0400 (EDT) Message-Id: <3.0.1.32.19970508140741.00721494@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 08 May 1997 14:07:41 -0400 To: ietf-apps-tls@imc.org From: Rodney Thayer Subject: Re: Servers that just want to have TLS In-Reply-To: References: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk I think we're looking at this question from different points of view. As far as I'm concerned, if you say "apps", I mean any application. HTML viewers (a/k/a browsers) are a subset of that. SMTP servers are a subset of that. If I build my own custom application I don't think I have to do negotiation. If I build an application which claims to be what is generally referred to as a standard SMTP server, then I should act like "an SMTP server" and I agree with what you're saying. At 08:42 AM 5/8/97 -0700, Paul E. Hoffman wrote: >At 6:48 AM -0700 5/8/97, Rodney Thayer wrote: >>What to do if a server JUST wants to talk TLS.... >> >>I was thinking that one valid implementation path would be to simply always >>use the TLS code. So, if someone tried to talk to you in the clear, you'd >>fail negotiation. End of story. Just like if you telnet to >>www.openmarket.com port 443 (a/k/a ) with a >>generic Telnet client. > >So in the SMTP case, you are saying: > >S: >C: >C & S: >C & S: >S: 220 mail.imc.org SMTP service ready > >I tend think this is a bad idea on any well-known port for which a client >might expect a non-TLS session. In the case of a non-TLS client, it would >start getting a stream of gibberish that it could not deal with at all. A >well-crafted SMTP client should do something like "The first thing it said >to me wasn't 220, so I'll just leave", but I'm not sure that many will do >this if handed a binary stream from the server. > >In this case, maybe the first thing out of the server's mouth should be >something like "287 Give a STARTTLS command before I talk to you at all". > >And, I still want a general model for application protocols where the >client talks first. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > From owner-ietf-apps-tls Thu May 8 11:39:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA01204 for ietf-apps-tls-bks; Thu, 8 May 1997 11:39:17 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA01199 for ; Thu, 8 May 1997 11:39:15 -0700 (PDT) Message-Id: In-Reply-To: <3.0.1.32.19970508140741.00721494@pop3.pn.com> References: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 11:39:27 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Servers that just want to have TLS Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 11:07 AM -0700 5/8/97, Rodney Thayer wrote: >If I build my own custom application I don't think I have to do negotiation. > >If I build an application which claims to be what is generally referred to >as a standard SMTP server, then I should act like "an SMTP server" and I >agree with what you're saying. Ah, yes. I should say "apps that are already deployed and well-known". The ones that are furthest forward in my brain right now are SMTP, IMAP, and LDAP. In all three cases, I think it's inappropriate to start a TLS negotiation on the well-known port without some "normal" footsieing first. However, I think that there should be a way for a server to insist on TLS immediately after the preliminary footsie. I'm looking for a model for that. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu May 8 12:35:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA02175 for ietf-apps-tls-bks; Thu, 8 May 1997 12:35:41 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA02170; Thu, 8 May 1997 12:35:39 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIML5NXWVO99G2YR@INNOSOFT.COM>; Thu, 8 May 1997 12:34:53 PDT Date: Thu, 08 May 1997 12:36:24 -0700 (PDT) From: Chris Newman Subject: Re: Servers that just want to have TLS In-reply-to: To: "Paul E. Hoffman" Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Thu, 8 May 1997, Paul E. Hoffman wrote: > And, I still want a general model for application protocols where the > client talks first. First we need to realize that SMTP is a special case since it's an unauthenticated protocol by default. Second, there's a more general problem of indicate that a higher security level is required. For application protocols, the right thing to do is say NO to LOGIN/AUTHENTICATE commands until the right level of security is achieved for the desired user. With IMAP, you'd get: A001 NO [ENCRYPT-REQUIRED] Access not permitted without encryption or A001 NO [INTEGRITY-REQUIRED] Access not permitted without integrity protection then you know STARTTLS or an equivalent SASL mechanism is needed. From owner-ietf-apps-tls Thu May 8 13:19:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA02901 for ietf-apps-tls-bks; Thu, 8 May 1997 13:19:28 -0700 (PDT) Received: from Networking.Stanford.EDU (networking.Stanford.EDU [36.53.0.155]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA02897 for ; Thu, 8 May 1997 13:19:25 -0700 (PDT) From: Jeff.Hodges@Stanford.edu Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by Networking.Stanford.EDU (8.8.5/8.6.6) with SMTP id NAA03309; Thu, 8 May 1997 13:19:42 -0700 Date: Thu, 8 May 1997 13:19:42 -0700 (PDT) Reply-To: Jeff.Hodges@Stanford.edu Subject: Re: Servers that just want to have TLS To: Chris Newman cc: ietf-apps-tls@imc.org, jeff.hodges@Stanford.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > Chris Newman said.. > First we need to realize that SMTP is a special case since it's an > unauthenticated protocol by default. It's not alone, LDAP is also such a case. > Paul Hoffman said.. > In all three cases, I think it's inappropriate to start a TLS negotiation > on the well-known port without some "normal" footsieing first. However, I > think that there should be a way for a server to insist on TLS immediately > after the preliminary footsie. I'm looking for a model for that. With LDAPv3, the spec explicitly allows for unlimited unathenticated footsieing (see section 4.2.1 of draft-ietf-asid-ldapv3-protocol-04.txt), but it also explicitly states that a server might require a bind as the first operation and only allow further ops if the client binds successfully. The model for this is that the server will return an "operationsError" result to everything except a bind request. So, to build on this model for TLS, one can imagine that the LDAP protocol could include a new request.. StartTLSRequest ::= [APPLICATION XX] {} And also a new resultCode of.. LDAPResult ::= SEQUENCE { resultCode ENUMERATED { . . tlsRequired (XX), . . } } Then if a server is configured to require TLS on all sessions regardless, it could return "tlsRequired" to all requests except for a StartTLSRequest. And then, it may or may not be configured to require a bind before handling further ops, and the "bind is required first" model of above applies if so. Jeff From owner-ietf-apps-tls Thu May 8 13:40:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03319 for ietf-apps-tls-bks; Thu, 8 May 1997 13:40:00 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03312 for ; Thu, 8 May 1997 13:39:57 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id PAA28444; Thu, 8 May 1997 15:39:09 -0500 (CDT) Received: from kcx-ks9-60.ix.netcom.com(198.211.69.124) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma028426; Thu May 8 15:38:49 1997 Message-ID: <3371E1CF.1B69@ix.netcom.com> Date: Thu, 08 May 1997 15:23:12 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: Rodney Thayer CC: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS References: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> <3.0.1.32.19970508143130.00726230@pop3.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Rodney, Rodney Thayer wrote: > > Interesting. Again I find that I'm thinking APPLICATIONS and other people > are thinking PUBLIC SERVERS. Well I think what we or some are talking about is applications on server platforms. > > I agree with you, an ISP might not want to set this up for their SMTP (or > other public server). Yes. And we need to fand a "Path of least resistance" to be encouraging at least to facilitate this form an application point of view on any server platform. This could be wraped up in the standard if handled properly. But my biggist concern is that if don in this manner, the standard will either be ignored by a larg segment of the ISP community or alternitive standards will be draft that are not inclusive. > > Of course, an ENLIGHTNED ISP might want to *sell* this feature as it's > spam-defensible... Good point! We need to set this as part of the benifits of the standard. > > At 09:29 AM 5/8/97 +0100, you wrote: > >Rodney, > > > >Rodney Thayer wrote: > >> > >> What to do if a server JUST wants to talk TLS.... > >> > >> I was thinking that one valid implementation path would be to simply always > >> use the TLS code. So, if someone tried to talk to you in the clear, you'd > >> fail negotiation. End of story. Just like if you telnet to > >> www.openmarket.com port 443 (a/k/a ) with a > >> generic Telnet client. > > > > On the serfice this sounds sensable. I guess my concern would be that > >many ISP's would not wish to be limited to "TLS Only". Hence I would > >perpose a common interface structure, similar to what we built and use > >that can support multipul security protocols. >;) > > Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. Phone :913-294-2375 (v- office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Thu May 8 13:39:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03301 for ietf-apps-tls-bks; Thu, 8 May 1997 13:39:34 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03294 for ; Thu, 8 May 1997 13:39:31 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id PAA28471; Thu, 8 May 1997 15:39:12 -0500 (CDT) Received: from kcx-ks9-60.ix.netcom.com(198.211.69.124) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma028433; Thu May 8 15:39:02 1997 Message-ID: <3371E2D1.6A9A@ix.netcom.com> Date: Thu, 08 May 1997 15:27:29 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: Chris Newman CC: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Chris, I think you are absolutely correct here. Well put! Chris Newman wrote: > > On Thu, 8 May 1997, Paul E. Hoffman wrote: > > And, I still want a general model for application protocols where the > > client talks first. > > First we need to realize that SMTP is a special case since it's an > unauthenticated protocol by default. > > Second, there's a more general problem of indicate that a higher security > level is required. > > For application protocols, the right thing to do is say NO to > LOGIN/AUTHENTICATE commands until the right level of security is achieved > for the desired user. > > With IMAP, you'd get: > > A001 NO [ENCRYPT-REQUIRED] Access not permitted without encryption > > or > > A001 NO [INTEGRITY-REQUIRED] Access not permitted without integrity > protection > > then you know STARTTLS or an equivalent SASL mechanism is needed. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. Phone :913-294-2375 (v- office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Thu May 8 13:39:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03289 for ietf-apps-tls-bks; Thu, 8 May 1997 13:39:30 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03281; Thu, 8 May 1997 13:39:27 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id PAA28446; Thu, 8 May 1997 15:39:09 -0500 (CDT) Received: from kcx-ks9-60.ix.netcom.com(198.211.69.124) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma028427; Thu May 8 15:38:53 1997 Message-ID: <3371E270.6D03@ix.netcom.com> Date: Thu, 08 May 1997 15:25:52 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: "Paul E. Hoffman" CC: TLS , ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS References: <3.0.1.32.19970508094854.006e9510@pop3.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul, Paul E. Hoffman wrote: > > At 11:07 AM -0700 5/8/97, Rodney Thayer wrote: > >If I build my own custom application I don't think I have to do negotiation. > > > >If I build an application which claims to be what is generally referred to > >as a standard SMTP server, then I should act like "an SMTP server" and I > >agree with what you're saying. > > Ah, yes. I should say "apps that are already deployed and well-known". The > ones that are furthest forward in my brain right now are SMTP, IMAP, and > LDAP. > > In all three cases, I think it's inappropriate to start a TLS negotiation > on the well-known port without some "normal" footsieing first. However, I > think that there should be a way for a server to insist on TLS immediately > after the preliminary footsie. I'm looking for a model for that. I am not so sure that this is necesary. TLS has an assinged port currently. You may want to take this up with Win Tereese. > > --Paul E. Hoffman, Director > --Internet Mail Consortium Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. Phone :913-294-2375 (v- office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Thu May 8 13:47:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03442 for ietf-apps-tls-bks; Thu, 8 May 1997 13:47:21 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03433 for ; Thu, 8 May 1997 13:47:18 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIMNNJ6C2U99G2YR@INNOSOFT.COM> for ietf-apps-tls@imc.org; Thu, 8 May 1997 13:46:34 PDT Date: Thu, 08 May 1997 13:48:04 -0700 (PDT) From: Chris Newman Subject: Re: Servers that just want to have TLS In-reply-to: To: Jeff.Hodges@Stanford.edu Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Thu, 8 May 1997 Jeff.Hodges@Stanford.edu wrote: > > Chris Newman said.. > > First we need to realize that SMTP is a special case since it's an > > unauthenticated protocol by default. > > It's not alone, LDAP is also such a case. I thought of that, but anything accessible via LDAP without authentication doesn't need to be encrypted, since it's public anyway. From owner-ietf-apps-tls Thu May 8 13:58:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03622 for ietf-apps-tls-bks; Thu, 8 May 1997 13:58:43 -0700 (PDT) Received: from laser.cps.softex.br (lasertec@laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03614 for ; Thu, 8 May 1997 13:58:40 -0700 (PDT) Received: from localhost (lasertec@localhost) by laser.cps.softex.br (8.8.5/v3.2) with SMTP id RAA06096; Thu, 8 May 1997 17:52:57 -0300 Date: Thu, 8 May 1997 17:52:55 -0300 (EST) From: "E. Gerck" To: Chris Newman cc: Jeff.Hodges@Stanford.edu, ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Thu, 8 May 1997, Chris Newman wrote: > On Thu, 8 May 1997 Jeff.Hodges@Stanford.edu wrote: > > > Chris Newman said.. > > > First we need to realize that SMTP is a special case since it's an > > > unauthenticated protocol by default. > > > > It's not alone, LDAP is also such a case. > > I thought of that, but anything accessible via LDAP without authentication > doesn't need to be encrypted, since it's public anyway. > Yes, but public does not mean it should be left open for mitm and other attacks. You don't need authentication to encrypt. You are just guaranteeing a private and secure channel. I think that LDAP could most surely benefit from that, specially in situations like blind signatures. Yours, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br http://novaware.cps.softex.br P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533 From owner-ietf-apps-tls Thu May 8 15:17:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04893 for ietf-apps-tls-bks; Thu, 8 May 1997 15:17:09 -0700 (PDT) Received: from Networking.Stanford.EDU (networking.Stanford.EDU [36.53.0.155]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA04889 for ; Thu, 8 May 1997 15:17:06 -0700 (PDT) From: Jeff.Hodges@Stanford.edu Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by Networking.Stanford.EDU (8.8.5/8.6.6) with SMTP id PAA04275 for ; Thu, 8 May 1997 15:17:24 -0700 Date: Thu, 8 May 1997 15:17:24 -0700 (PDT) Reply-To: Jeff.Hodges@Stanford.edu Subject: Re: Servers that just want to have TLS To: ietf-apps-tls@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > Yes, but public does not mean it should be left open for mitm and other > attacks. Precisely. Jeff From owner-ietf-apps-tls Fri May 9 02:30:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA15697 for ietf-apps-tls-bks; Fri, 9 May 1997 02:30:03 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id CAA15686 for ; Fri, 9 May 1997 02:29:50 -0700 (PDT) Received: from lock (lock [192.122.221.188]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id KAA26727; Fri, 9 May 1997 10:26:20 +0100 (BST) Message-Id: <2.2.32.19970509092833.00363c74@eng-mail> X-Sender: darundel@eng-mail X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 May 1997 09:28:33 +0000 To: "E. Gerck" , Chris Newman From: Donal Arundel Subject: Re: Servers that just want to have TLS Cc: Jeff.Hodges@Stanford.edu, ietf-apps-tls@imc.org Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 17:52 08/05/97 -0300, E. Gerck wrote: >Yes, but public does not mean it should be left open for mitm and other >attacks. > >You don't need authentication to encrypt. You are just guaranteeing a >private and secure channel. > >I think that LDAP could most surely benefit from that, specially in >situations like blind signatures. Yes, but encryption without authentication doesn't actually guarantee you a private channel. It just gives you a private channel to an unauthenticated endpoint and thus is subject to a man in the middle attack. The mitm can just listen and pass data to and from the intended recipient. > >Yours, > >Ed Gerck Regards, Donal ---------------------------------------------------------------------------- Donal Arundel email: darundel@iona.com IONA Technologies tel : (Dublin) +353 1 6625255 x2418 The IONA Building (US) 1-800-orbix4u (6724948) 8-10 Lower Pembroke St fax : +353 1 6625244 Dublin 2, Ireland ---------------------------------------------------------------------------- From owner-ietf-apps-tls Fri May 9 12:04:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA22812 for ietf-apps-tls-bks; Fri, 9 May 1997 12:04:30 -0700 (PDT) Received: from laser.cps.softex.br (lasertec@laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA22806 for ; Fri, 9 May 1997 12:04:25 -0700 (PDT) Received: from localhost (lasertec@localhost) by laser.cps.softex.br (8.8.5/v3.2) with SMTP id PAA09329; Fri, 9 May 1997 15:58:36 -0300 Date: Fri, 9 May 1997 15:58:35 -0300 (EST) From: "E. Gerck" To: Donal Arundel cc: Chris Newman , Jeff.Hodges@Stanford.edu, ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS In-Reply-To: <2.2.32.19970509092833.00363c74@eng-mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Fri, 9 May 1997, Donal Arundel wrote: > > > At 17:52 08/05/97 -0300, E. Gerck wrote: > >Yes, but public does not mean it should be left open for mitm and other > >attacks. > > > >You don't need authentication to encrypt. You are just guaranteeing a > >private and secure channel. > > > >I think that LDAP could most surely benefit from that, specially in > >situations like blind signatures. > > Yes, but encryption without authentication doesn't actually guarantee > you a private channel. It just gives you a private channel to an > unauthenticated endpoint and thus is subject to a man in the middle > attack. The mitm can just listen and pass data to and from the > intended recipient. > No, you are mixing up concepts. I don't know if this is the right forum to discuss this, but I will elaborate. As I said, encryption guarantees you a private and secure channel with an anonymous user, which is much better than no encryption with an anonymous user, which was the situation I was replying to (but you snipped off) ! Better, it can avoid mitm -- yes -- (which the other situation can't, of course), even without user authentication, if the anonymous user knows for sure a quality of the LDAP server -- which can be public. It is a common misconception to think that you need two authenticated endpoints to avoid mitm. Better still, it can avoid mitm also if the user does not know for sure a quality of the server but can use multiple communication channels to access the server, with an estimate that above three channels the probability of a mitm attack can be almost zero. It is a much more common misconception to think that you need at least one authenticated endpoint to avoid mitm. As I said, it could be very useful for LDAP, specially with blind signatures. Yours, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br http://novaware.cps.softex.br P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533 From owner-ietf-apps-tls Fri May 9 12:54:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA23535 for ietf-apps-tls-bks; Fri, 9 May 1997 12:54:48 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA23531 for ; Fri, 9 May 1997 12:54:45 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id PAA23763 for ; Fri, 9 May 1997 15:54:43 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma023761; Fri May 9 15:54:14 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id PAA09012 for ; Fri, 9 May 1997 15:51:22 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id PAA05292; Fri, 9 May 1997 15:53:44 -0400 Date: Fri, 9 May 1997 15:53:44 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705091953.PAA05292@argon.ncsc.mil> To: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS X-Sun-Charset: US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > From: "E. Gerck" > > Better, it can avoid mitm -- yes -- (which the other situation can't, of > course), even without user authentication, if the anonymous user knows for > sure a quality of the LDAP server -- which can be public. The thing the user knows about the server must (not "can") be public. Otherwise, by definition, you would be doing shared-secret authentication. > It is a much more common misconception to think that you need at least one > authenticated endpoint to avoid mitm. I'm afraid I suffer from that misconception. Could you post references to a protocol that defeats mitm attacks without authenticating either endpoint? From owner-ietf-apps-tls Fri May 9 13:00:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA23593 for ietf-apps-tls-bks; Fri, 9 May 1997 13:00:29 -0700 (PDT) Received: from berzerk.rs.itd.umich.edu (smtp@berzerk.rs.itd.umich.edu [141.211.63.17]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA23587 for ; Fri, 9 May 1997 13:00:21 -0700 (PDT) Received: by berzerk.rs.itd.umich.edu (8.7.5/3.0-mailhub) id QAA17157; Fri, 9 May 1997 16:00:37 -0400 (EDT) Received: from qmailr@lukyduk.ifs.umich.edu(141.211.168.44) by berzerk.rs.itd.umich.edu via smap (2.0-umich) id xma017143; Fri, 9 May 97 16:00:32 -0400 Received: (qmail 5880 invoked by uid 41335); 9 May 1997 20:00:26 -0000 Date: Fri, 9 May 1997 16:00:25 -0400 (EDT) From: Douglas Song X-Sender: dugsong@lukyduk.ifs.umich.edu To: "David P. Kemp" cc: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS In-Reply-To: <199705091953.PAA05292@argon.ncsc.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Fri, 9 May 1997, David P. Kemp wrote: > I'm afraid I suffer from that misconception. Could you post references > to a protocol that defeats mitm attacks without authenticating either > endpoint? diffie-hellman with the interlock protocol. this is used, for instance, in the stel (secure telnet) package from CERT-Italy. --- Dug Song University of Michigan ITD Systems Research Programmer http://www-personal.umich.edu/~dugsong From owner-ietf-apps-tls Fri May 9 13:08:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA23705 for ietf-apps-tls-bks; Fri, 9 May 1997 13:08:16 -0700 (PDT) Received: from berzerk.rs.itd.umich.edu (smtp@berzerk.rs.itd.umich.edu [141.211.63.17]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA23700 for ; Fri, 9 May 1997 13:08:10 -0700 (PDT) Received: by berzerk.rs.itd.umich.edu (8.7.5/3.0-mailhub) id QAA18347; Fri, 9 May 1997 16:08:07 -0400 (EDT) Received: from qmailr@lukyduk.ifs.umich.edu(141.211.168.44) by berzerk.rs.itd.umich.edu via smap (2.0-umich) id xma018304; Fri, 9 May 97 16:07:48 -0400 Received: (qmail 5970 invoked by uid 41335); 9 May 1997 20:07:45 -0000 Date: Fri, 9 May 1997 16:07:44 -0400 (EDT) From: Douglas Song X-Sender: dugsong@lukyduk.ifs.umich.edu To: "David P. Kemp" cc: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk i take that back. shared secret. i can't think of a mitm-resistant key exchange protocol that doesn't do some authentication of the parties either... i don't think this is possible, by the nature of a mitm attack. On Fri, 9 May 1997, Douglas Song wrote: > diffie-hellman with the interlock protocol. this is used, for instance, in > the stel (secure telnet) package from CERT-Italy. --- Dug Song University of Michigan ITD Systems Research Programmer http://www-personal.umich.edu/~dugsong From owner-ietf-apps-tls Fri May 9 19:23:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA28116 for ietf-apps-tls-bks; Fri, 9 May 1997 19:23:07 -0700 (PDT) Received: from laser.cps.softex.br (lasertec@laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA28112 for ; Fri, 9 May 1997 19:23:04 -0700 (PDT) Received: from localhost (lasertec@localhost) by laser.cps.softex.br (8.8.5/v3.2) with SMTP id XAA10520; Fri, 9 May 1997 23:18:03 -0300 Date: Fri, 9 May 1997 23:18:03 -0300 (EST) From: "E. Gerck" To: "David P. Kemp" cc: ietf-apps-tls@imc.org Subject: Re: Servers that just want to have TLS In-Reply-To: <199705091953.PAA05292@argon.ncsc.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Fri, 9 May 1997, David P. Kemp wrote: > > From: "E. Gerck" > > > > Better, it can avoid mitm -- yes -- (which the other situation can't, of > > course), even without user authentication, if the anonymous user knows for > > sure a quality of the LDAP server -- which can be public. > > The thing the user knows about the server must (not "can") be public. > Otherwise, by definition, you would be doing shared-secret authentication. > This may be just a play of words, but I did not restrain my example to an anonymous server, just an anonymous user, which was the original question (hey, could someone just stop chopping off those first lines? ;-)) But there are some other interesting points. In the case of a non-anon server, the anon user can know a private value of the server without itself becoming non-anon. For example, a person might have an account at a Bank, say he is called Skywalker (he is non-anon in that capacity, of course), with his address and so on. The Bank sends him a private value, to be used only by people that have accounts in the Bank, for e-cash deposits. The Bank also maintains services for people that are not clients, that do not have this number. Now, Skywalker wants to contact the bank but does not want to give his name because he wants to give the Bank some e-cash with a blind signature, that he wants to have as anonymous credit in his account. He can do that with the private value he received from the bank, which is private to the public but known to the e-cash account owners. That is why I wrote "can". It can be must, if you may ;-) > > > It is a much more common misconception to think that you need at least one > > authenticated endpoint to avoid mitm. > > I'm afraid I suffer from that misconception. Could you post references > to a protocol that defeats mitm attacks without authenticating either > endpoint? > Apparently, you are not alone ;-) The Meta-Certificate protocol that is being discussed in the MCG (http://novaware.cps.softex.br/mcg.htm). The idea is to use multiple channels, similar in a way to spread spectrum techniques used in communications. Suppose you can open 3 indepedent channels of communication between you and the server. Though it is not necessary, suppose one is a radio link over modem, another is a cable-modem link and another a dial-up link. If all three channels agreee on nonce exchanges (i.e., all 3 give correct results, which will be different for each) and if the probability of attack by mitm is 10% (say) per channel, then this means you should have a risk of 0.1% of being affected by mitm, though both sides are perfectly anonymous. This can be reduced to almost zero if you use virtual channels within one channel (multiple messages time-multiplexed in different channels). You can even use one channel if you have cooperative targets between channel changes and you use the virtual channel technique as above. This can applied to avoid other attacks also. It can be applied to check multiple CAs for a certificate (a spoofing attack would change all at once). Yours, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br http://novaware.cps.softex.br P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533 From owner-ietf-apps-tls Sat May 10 06:04:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA03929 for ietf-apps-tls-bks; Sat, 10 May 1997 06:04:22 -0700 (PDT) Received: from laser.cps.softex.br (lasertec@laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA03925 for ; Sat, 10 May 1997 06:04:18 -0700 (PDT) Received: from localhost (lasertec@localhost) by laser.cps.softex.br (8.8.5/v3.2) with SMTP id JAA11008; Sat, 10 May 1997 09:59:18 -0300 Date: Sat, 10 May 1997 09:59:18 -0300 (EST) From: "E. Gerck" To: ietf-apps-tls@imc.org cc: "David P. Kemp" Subject: Re: Servers that just want to have TLS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is an errata for three letters that were missing when this msg was posted yesterday, but which are necessary for a clear understanding. The letters are "NOT" and the sentence to be corrected is at the end. It was: "multiple CAs for a certificate (a spoofing attack would change all at once)." It should be (of course): "multiple CAs for a certificate (a spoofing attack would NOT change all at once)." Yours, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br http://novaware.cps.softex.br P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533 From owner-ietf-apps-tls Tue May 13 17:45:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21684 for ietf-apps-tls-bks; Tue, 13 May 1997 17:45:18 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA21680 for ; Tue, 13 May 1997 17:45:16 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 17:46:02 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: New version of draft-hoffman-smtp-tls Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Hi again. After our discussion here, as well as discussions with other TLS folks, I've revised the draft. The new version is available at . It will appear in the Internet Drafts directory soon, I assume. The differences from the -01 draft are: C. Revision History ***Changes from -01 to -02: Fixed the error message for the 501 error. Added the word "temporary" to the 554 error. Added the ability for a server to require TLS in Section 5. Used the word "publicly-referenced" to differentiate types of servers. Added the pipelining discussion in Section 5. Added the 5.1 header to make the long section more readable. Added the certificate acceptance paragraph in new 5.1. Added the local decision wording in Section 7. Added man-in-the-middle warning in Section 7. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 14 08:59:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA01892 for ietf-apps-tls-bks; Wed, 14 May 1997 08:59:56 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA01888 for ; Wed, 14 May 1997 08:59:53 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 09:00:41 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: New version of draft-hoffman-smtp-tls Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 5:46 PM -0700 5/13/97, Paul E. Hoffman wrote: >. Er, make that: I chose the archaic name for the first draft, and I guess it gets to stick with us forever... --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 14 10:03:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA02837 for ietf-apps-tls-bks; Wed, 14 May 1997 10:03:29 -0700 (PDT) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA02833 for ; Wed, 14 May 1997 10:03:26 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 14 May 1997 10:04:01 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: ietf-apps-tls@imc.org Subject: Reply codes in the smtp-ssl draft Date: Wed, 14 May 1997 10:04:09 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-apps-tls@imc.org Precedence: bulk The 554 reply code in the draft, if it really is to be an indication of a temporary condition, should be changed to something like 453. The '5' prefix indicates a permanent failure which will not succeed on retry, whereas the '4' prefix indicates a temporary condition. The 560 reply code, as has been pointed out over on the ietf-smtp list, is also probably not appropriate. Perhaps 555 would be a better choice. Even better, perhaps it's time to come up with some codes which mean "here's the general category of response - for more information, check out the enhanced status code per RFC 1893 and RFC 2034." -- jeff From owner-ietf-apps-tls Wed May 14 10:27:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA03266 for ietf-apps-tls-bks; Wed, 14 May 1997 10:27:06 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA03260 for ; Wed, 14 May 1997 10:27:02 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 10:27:51 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Reply codes in the smtp-ssl draft Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Yes, I agree with both of your suggestions. I'll put out a -03 sometime soon with the changes. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 14 11:26:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA04146 for ietf-apps-tls-bks; Wed, 14 May 1997 11:26:59 -0700 (PDT) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA04141; Wed, 14 May 1997 11:26:56 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 14 May 1997 11:27:29 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: "'Paul E. Hoffman'" , ietf-apps-tls@imc.org Subject: RE: Reply codes in the smtp-ssl draft Date: Wed, 14 May 1997 11:24:37 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Since the SASL/SMTP-AUTH draft (draft-myers-smtp-auth-05.txt) also deals with encryption for SMTP, it might be a good idea to coordinate reply codes with it and come up with a generic "Secure channel required" reply code. That draft doesn't yet deal with the issue of what to do in response to SMTP commands if the server requires security but the client hasn't initiated it. I've suggested that something similar to what you've suggested be included in the draft and that the reply codes be coordinated with the STARTTLS code. -- jeff > -----Original Message----- > From: Paul E. Hoffman [SMTP:phoffman@imc.org] > Sent: Wednesday, May 14, 1997 10:28 AM > To: ietf-apps-tls@imc.org > Subject: Re: Reply codes in the smtp-ssl draft > > Yes, I agree with both of your suggestions. > > I'll put out a -03 sometime soon with the changes. > > --Paul E. Hoffman, Director > --Internet Mail Consortium > From owner-ietf-apps-tls Thu May 15 16:21:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA11402 for ietf-apps-tls-bks; Thu, 15 May 1997 16:21:51 -0700 (PDT) Received: from felix.austin.isode.com (felix.austin.isode.com [198.214.11.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA11398 for ; Thu, 15 May 1997 16:21:48 -0700 (PDT) Received: from prev.critical-angle.com by felix.austin.isode.com with Internet SMTP (IC MTA); Thu, 15 May 1997 18:22:31 -0500 From: Mark Wahl To: ietf-apps-tls@imc.org Reply-To: Mark Wahl Subject: returning to the previous state Date: Thu, 15 May 1997 18:13:42 -0500 Message-ID: <22137.863738022@prev.critical-angle.com> Sender: owner-ietf-apps-tls@imc.org Precedence: bulk After a TLS connection has been established over top of an existing protocol's TCP connection, as could be done using draft-hoffman-smtp-ssl-02, is the meaning of the "close_notify" alert in TLS that the sender will revert back to using the protocol (such as SMTP) in the state from before TLS was established? E.g. with SMTP S: C: S: 220 mail.imc.org SMTP service ready | plain text C: EHLO mail.ietf.org S: 250-mail.imc.org is ever so glad you called S: 250 TLS TLS1.0 SSL3.0 C: STARTTLS TLS1.0 S: 220 Go ahead with TLS1.0 C & S: C & S: ] inside TLS C: MAIL FROM: nobody ] S: 550 Submission from nobody not permitted ] C: ] C: MAIL FROM: nobody | plain text again S: 250 OK Thanks in advance, Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-apps-tls Fri May 16 06:50:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA20436 for ietf-apps-tls-bks; Fri, 16 May 1997 06:50:41 -0700 (PDT) Received: from Breakaway.Stanford.EDU (breakaway.Stanford.EDU [36.53.0.203]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA20432 for ; Fri, 16 May 1997 06:50:38 -0700 (PDT) Received: from localhost (hodges@localhost) by Breakaway.Stanford.EDU (8.8.5/8.8.5) with ESMTP id GAA04140; Fri, 16 May 1997 06:51:25 -0700 Message-Id: <199705161351.GAA04140@Breakaway.Stanford.EDU> X-Mailer: exmh version 1.6.9 8/22/96 Subject: support for SSL 2.0 in StartTLS-capable apps? To: ietf-apps-tls@imc.org cc: Jeff.Hodges@stanford.edu, Bob.Morgan@stanford.edu From: Jeff.Hodges@stanford.edu X-Office: Pine Hall Rm 161; +1-415-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 May 1997 06:51:24 -0700 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk We'd noted that Paul included support for SSL 2.0 in draft-hoffman-smtp-ssl-02.txt. We included support for it in our proposed mods to the LDAPv3 protocol (included below for context, and perhaps feedback). Is support for SSL 2.0 a requirement in general for StartTLS schemes? What do you folks think? It was pointed out to us that TLS 1.0 protocol-02.txt has negotiation already, as described in appendix E: | TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both | is easy. TLS clients who wish to negotiate with SSL 3.0 servers | should send client hello messages using the SSL 3.0 record format | and client hello structure, sending {3, 1} for the version field to | note that they support TLS 1.0. If the server supports only SSL 3.0, | it will respond with an SSL 3.0 server hello; if it supports TLS, | with a TLS server hello. The negotiation then proceeds as | appropriate for the negotiated protocol. So, since the TLS spec doesn't mention SSL 2.0 in the section above, and since there doesn's seem to be an RFC or ID for it, then a client wishing to be able to support it in a StartTLS operation would need some way to let the server know that is what it was going to do. Hence our having a "tlsVersion" component to the StartTLSRequest.. StartTLSRequest ::= [APPLICATION 30] SEQUENCE { tlsVersion LDAPString } But, if we dropped support for SSL 2.0, and only (implicityl) supported SSL 3.0 and TLS 1.0 (by referencing the TLS spec), then we could conceivably reduce our StartTLS request to only.. StartTLSRequest ::= [APPLICATION 30] Feedback? thanks, Jeff Hodges RL "Bob" Morgan Stanford ps: our proposed mods to LDAPv3 to support TLS on the standard port and to the URL format to support security policy expression is being discussed on the ietf-asid@umich.edu list. From owner-ietf-apps-tls Fri May 16 07:02:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA20612 for ietf-apps-tls-bks; Fri, 16 May 1997 07:02:40 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA20603 for ; Fri, 16 May 1997 07:02:37 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id HAA08881; Fri, 16 May 1997 07:03:16 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id HAA01405; Fri, 16 May 1997 07:03:14 -0700 (PDT) Message-Id: <199705161403.HAA01405@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Fri, 16 May 97 07:03:12 -0700 To: Jeff.Hodges@stanford.edu Subject: Re: support for SSL 2.0 in StartTLS-capable apps? cc: ietf-apps-tls@imc.org, Bob.Morgan@stanford.edu Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705161351.GAA04140@Breakaway.Stanford.EDU> Sender: owner-ietf-apps-tls@imc.org Precedence: bulk SSL 2.0 has several weaknesses. Since there are few--if any--implementations of SMTP with SSL it would be better to exclude it. The same argument may be true for SSL 3.0. -dpg From owner-ietf-apps-tls Fri May 16 14:53:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA26053 for ietf-apps-tls-bks; Fri, 16 May 1997 14:53:48 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA26045 for ; Fri, 16 May 1997 14:53:45 -0700 (PDT) Message-Id: In-Reply-To: <199705161403.HAA01405@imo.plaintalk.bellevue.wa.us> References: <199705161351.GAA04140@Breakaway.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 14:40:57 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: support for SSL 2.0 in StartTLS-capable apps? Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 7:03 AM -0700 5/16/97, Dennis Glatting wrote: >SSL 2.0 has several weaknesses. Since there are few--if >any--implementations of SMTP with SSL it would be better to >exclude it. The same argument may be true for SSL 3.0. Actually, with the method that Jeff and Bob are suggesting, there is no need to "exclude" SSL 3.0. The quote they gave shows a way for the client to essentially query the server for which version it runs and take whatever the server hands back. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sat May 17 16:16:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA11794 for ietf-apps-tls-bks; Sat, 17 May 1997 16:16:09 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA11790 for ; Sat, 17 May 1997 16:16:06 -0700 (PDT) Message-Id: In-Reply-To: <22137.863738022@prev.critical-angle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 May 1997 16:17:13 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: returning to the previous state Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 4:13 PM -0700 5/15/97, Mark Wahl wrote: >After a TLS connection has been established over top of an existing protocol's >TCP connection, as could be done using draft-hoffman-smtp-ssl-02, is the >meaning of the "close_notify" alert in TLS that the sender will revert >back to >using the protocol (such as SMTP) in the state from before TLS was >established? That's outside of the specs. :-) But seriously, it really is. There is nothing in the TLS spec that says anything about the API that is used to tell the higher-level protocol (in our case, SMTP). So, for example, when I say in the SMTP/TLS spec "you must check whether the level of privacy you got from the TLS handshake is enough to go on", I do not say how to check this because that is an API issue. I've been told that, to date, all TLS implementations have an API that would prevent a TLS close_notify alert (that's in Section 6.2.1 of the TLS spec) from allowing the higher-level protocol from continuing on, period. After the close_notify, you can't say or hear anything without doing another negotiation. However, it is conceivable that some future (very bad) implementation of TLS would not do anything after a close_notify. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sat May 17 23:26:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA13756 for ietf-apps-tls-bks; Sat, 17 May 1997 23:26:19 -0700 (PDT) Received: from ozemail.com.au (server3.syd.mail.ozemail.net [203.108.7.41]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA13751; Sat, 17 May 1997 23:26:15 -0700 (PDT) Received: from mail.ccur.com.au (mail.ccur.com.au [203.32.201.21]) by ozemail.com.au (8.8.4/8.6.12) with SMTP id QAA28967; Sun, 18 May 1997 16:27:01 +1000 (EST) Received: from 203.108.82.22 by mail.ccur.com.au id aa29616; 18 May 97 16:30 EST Message-Id: <3.0.1.32.19970518162642.006b2dcc@mail.ccur.com.au> X-Sender: jimlw@mail.ccur.com.au X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 18 May 1997 16:26:42 +1000 To: "Paul E. Hoffman" From: Jim Lawson Williams Subject: Re: returning to the previous state Cc: ietf-apps-tls@imc.org In-Reply-To: References: <22137.863738022@prev.critical-angle.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk G'day! At 04:17 PM 5/17/97 -0700, Paul E. Hoffman wrote: >There is nothing in the TLS spec that says >anything about the API that is used to tell the higher-level protocol (in >our case, SMTP). Oh, dear! No man's land. "Mere implementation detail, m'boy! Don't you worry about that!" I would have hoped that this might have been the forum to express what developers expect from an API: timer-management, for example. To take the specification cited, 6.2.1 states The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack... ...Each party is required to send a close_notify alert before closing the write side of the connection. but skirts assigning responsibilities for what's supposed to happen at the client-end if the server's close_notify response seems to be lost, stolen, or strayed. I, for one, think the proper place for such time-outs is down in the TLS impementation. I would, however, like to see some level of control vested in the application layer. I would like the options of saying "TLS, you take care of this connection and manage the whole thing", or, alternatively, in the extreme, "TLS, accumulate statistics on the initial hand-shake round-trip times. Set a default time-out from them, and tell me the average and maximum round-trips, and what timeout you're about to set so that I can override that last value should I want to. Tell me if a close-notify time-out occurs so that I can decide whether to wait a little longer, or to terminate the session with extreme prejudice." I appreciate that the immediate concern is the swift deployment of SMTP/TLS rather than some obscure and currently theoretical application for one list-member, but if this is not the place to discuss an "application view" of TLS APIs, where is? Regards, Jim LW >From the BBC's "Barchester Chronicles": "I know that ultimately we are not supposed to understand. But I also know that we must try." -- the Reverend Septimus Harding, crypt-analyst, art-critic, tax-consultant, C++ programmer, humanitarian (If vegetarians eat vegetables, what do humanitarians eat? Humane beans, perhaps?) From owner-ietf-apps-tls Sun May 18 10:03:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA18408 for ietf-apps-tls-bks; Sun, 18 May 1997 10:03:03 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA18403; Sun, 18 May 1997 10:02:59 -0700 (PDT) Message-Id: In-Reply-To: <3.0.1.32.19970518162642.006b2dcc@mail.ccur.com.au> References: <22137.863738022@prev.critical-angle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 May 1997 10:04:13 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: returning to the previous state Cc: ietf-apps-tls@imc.org Sender: owner-ietf-apps-tls@imc.org Precedence: bulk >I appreciate that the immediate concern is the swift deployment >of SMTP/TLS rather than some obscure and currently theoretical >application for one list-member, but if this is not the place to >discuss an "application view" of TLS APIs, where is? Well, I beleive that the TLS WG would be the better place because they understand the vagaries of TLS better than we apps folk do. They also understand what naive apps writers might ignore that would in fact lead to disasterous security problems. On the other hand, we can probably come up with a good set of requirements for them. Either way, this comes down to a request for a TLS API, and the IETF is notoriously bad at creating APIs. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sun May 18 14:20:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA20071 for ietf-apps-tls-bks; Sun, 18 May 1997 14:20:33 -0700 (PDT) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA20067 for ; Sun, 18 May 1997 14:20:30 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id QAA11222; Sun, 18 May 1997 16:20:46 -0500 (CDT) Received: from kcx-ks11-04.ix.netcom.com(206.214.130.100) by dfw-ix15.ix.netcom.com via smap (V1.3) id sma011206; Sun May 18 16:20:36 1997 Message-ID: <337F1D6A.FB5@ix.netcom.com> Date: Sun, 18 May 1997 16:16:58 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Jim Lawson Williams CC: TLS , ietf-apps-tls@imc.org, Moshe Rozenblit Subject: Re: returning to the previous state References: <22137.863738022@prev.critical-angle.com> <3.0.1.32.19970518162642.006b2dcc@mail.ccur.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Jim and all, First of all let me preface my comments with the fact that most Telco's and large ISP/C's are very slightly concerned with SMTP connectionsm hence this discussion line has very little concern to the internet community with respect to security concerns with LDAP. That is not to say that there is not a need however... Moshe, please feel free to coment here.. Ok? Jim Lawson Williams wrote: > > G'day! > > At 04:17 PM 5/17/97 -0700, Paul E. Hoffman wrote: > >There is nothing in the TLS spec that says > >anything about the API that is used to tell the higher-level protocol > (in > >our case, SMTP). > > Oh, dear! No man's land. "Mere implementation detail, m'boy! Don't you > > worry about that!" Good satyre here. >;) > > I would have hoped that this might have been the forum to express what > > developers expect from an API: timer-management, for example. To take > the > specification cited, 6.2.1 states > > The client and the server must share knowledge that the > connection is ending in order to avoid a truncation attack... > ...Each party is required to send a close_notify alert before > closing the write side of the connection. > > but skirts assigning responsibilities for what's supposed to > happen at the client-end if the server's close_notify response > seems to be lost, stolen, or strayed. I, for one, think the > proper place for such time-outs is down in the TLS impementation. > I would, however, like to see some level of control vested in the > application layer. I agree, TLS is where this control ought to be, Jim. > > I would like the options of saying "TLS, you take care of this > connection and manage the whole thing", or, alternatively, in the > extreme, "TLS, accumulate statistics on the initial hand-shake > round-trip times. Set a default time-out from them, and tell me > the average and maximum round-trips, and what timeout you're > about to set so that I can override that last value should I want > to. Tell me if a close-notify time-out occurs so that I can > decide whether to wait a little longer, or to terminate the > session with extreme prejudice." Real good alternitive suggestion. Maybe this should be brought up with Win Tereese's group(TLS)? I like it. > > I appreciate that the immediate concern is the swift deployment > of SMTP/TLS rather than some obscure and currently theoretical > application for one list-member, but if this is not the place to > discuss an "application view" of TLS APIs, where is? Well I think that there is some overlap here. As you can tell by the headers on this reply I am copying the TLS group on this reply, in that it seems to me that you have a point. But better and closer interaction between LDAP and TLS WG's is in order here. Win T, any comments here? > > Regards, > Jim LW > > >From the BBC's "Barchester Chronicles": > > "I know that ultimately we are not supposed to understand. > But I also know that we must try." > > -- the Reverend Septimus Harding, > crypt-analyst, art-critic, tax-consultant, C++ programmer, > humanitarian > > (If vegetarians eat vegetables, what do humanitarians eat? > Humane beans, perhaps?) Regards, -- Jeffrey A. Williams DIR. Internet Network En