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 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 Mon May 19 08:40:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA29952 for ietf-apps-tls-bks; Mon, 19 May 1997 08:40:49 -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 IAA29947; Mon, 19 May 1997 08:40:46 -0700 (PDT) Received: from prev.critical-angle.com by felix.austin.isode.com with Internet SMTP (IC MTA); Mon, 19 May 1997 10:41:37 -0500 From: Mark Wahl To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org Subject: Re: returning to the previous state In-reply-to: Your message of "Sat, 17 May 1997 16:17:13 PDT." Date: Mon, 19 May 1997 10:41:23 -0500 Message-ID: <23328.864056483@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' >>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'm sorry my original message wasn't clear. My concern is not about APIs, but on the interaction between protocol components when a TLS module has been inserted into the protocol stack. Section 6.2.1 of draft-ietf-tls-protocol-02.txt > Each party is required to send a close_notify alert before closing > the write side of the connection. It is required that the other > party respond with a close_notify alert of its own and close down > the connection immediately, discarding any pending writes. It is not > required for the initiator of the close to wait for the responding > close_notify alert before closing the read side of the connection. > NB: It is assumed that closing a connection reliably delivers > pending data before destroying the transport. If one were to insert the TLS module into, for example, the LDAP protocol, then before the insertion, the protocol would be layered as: Client Server LDAP LDAP (LDAP connection) | | TCP ------->TCP (TCP connection) After the two ends of TLS have negotiated, the protocol would be layered as: Client Server LDAP LDAP (LDAP connection) | | TLS TLS (TLS connection) | | TCP ------->TCP (TCP connection) The client sends a close_notify alert. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. This means the client falls back to Client LDAP | TCP The server will receive the client's close_notify. The server is required to send a close_notify of its own. However, since the client has closed the read side of the TLS connection, this means the server's close_notify will be delivered to the LDAP module in the client. This is a protocol violation since a TLS close_notify is not a valid LDAP response. This appears to me to be a defect in the TLS specification. I would have expected it to read something like: > It _is_ required for the initiator of the close to wait for the responding > close_notify alert before closing the read side of the connection. That way the client will drain off all TLS messages before restoring the protocol to its original pre-TLS state. I wished to check with this mailing list on application use of TLS to see if other protocol designers had encountered this same problem. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-apps-tls Mon May 19 08:59:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA00280 for ietf-apps-tls-bks; Mon, 19 May 1997 08:59:19 -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 IAA00275 for ; Mon, 19 May 1997 08:59:17 -0700 (PDT) Message-Id: In-Reply-To: <23328.864056483@prev.critical-angle.com> References: Your message of "Sat, 17 May 1997 16:17:13 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 09:00:37 -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 8:41 AM -0700 5/19/97, Mark Wahl wrote: > . . . [lots of good description of the TLS setup and teardown] . . . >This appears to me to be a defect in the TLS specification. I would have >expected it to read something like: > >> It _is_ required for the initiator of the close to wait for the responding >> close_notify alert before closing the read side of the connection. I agree with you that the TLS protocol should not let one side send a TLS message to another side that is no longer expecting it. My guess is that this crept in due to "separate port" thinking: after the client sent it's close_notify, it might immediately shut down the TCP connection. However, this seems to be the only place in the TLS spec (...I say hopefully...) that this kind of false assumption is made. >I wished to check with this mailing list on application use of TLS to see if >other protocol designers had encountered this same problem. Well, if we haven't yet, we certainly will, unless all the TLS 1.0 API designers take this into account and don't close the client side until they've heard the server's close_notify. I'd certainly like to see this change in TLS 1.1, if not in 1.0. TLS 1.0 is going to go into IESG last call soon, so we have time to bring this up and maybe get it fixed. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Mon May 19 10:00:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA00944 for ietf-apps-tls-bks; Mon, 19 May 1997 10:00:35 -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 KAA00940 for ; Mon, 19 May 1997 10:00:32 -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; 19 May 1997 17:01:30 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 NAA08688 for ; Mon, 19 May 1997 13:02:33 -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; 19 May 1997 17:01:27 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 NAA06117 for ; Mon, 19 May 1997 13:01:26 -0400 (EDT) Message-Id: <3.0.1.32.19970519125617.0072293c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 19 May 1997 12:56:17 -0400 To: ietf-apps-tls@imc.org From: Rodney Thayer Subject: TLS API discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk I think we need to talk about TLS "API" descriptions somewhere. I offered the idea of a "service definition" document in Memphis, this was based on feedback from the floor at the San Jose meeting. I think this is an appropriate place to talk about this but I wonder what the list manager thinks? I do *not* think the alleged IETF congenital allergy to "API Specifications" is a reason to not talk about the subject. >Date: Sun, 18 May 1997 16:26:42 +1000 >From: Jim Lawson Williams >Subject: Re: returning to the previous state >I would have hoped that this might have been the forum to express what >developers expect from an API From owner-ietf-apps-tls Mon May 19 14:30:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA04128 for ietf-apps-tls-bks; Mon, 19 May 1997 14:30:53 -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 OAA04123; Mon, 19 May 1997 14:30:49 -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 HAA11217; Tue, 20 May 1997 07:31:46 +1000 (EST) Received: from 203.108.82.27 by mail.ccur.com.au id aa01098; 20 May 97 7:35 EST Message-Id: <3.0.1.32.19970520073150.00694c8c@mail.ccur.com.au> X-Sender: jimlw@mail.ccur.com.au X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 07:31:50 +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: <23328.864056483@prev.critical-angle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk G'day! At 09:00 AM 5/19/97 -0700, Paul E. Hoffman wrote: >At 8:41 AM -0700 5/19/97, Mark Wahl wrote: >> . . . [lots of good description of the TLS setup and teardown] . . . > >>This appears to me to be a defect in the TLS specification. I would have >>expected it to read something like: >> >>> It _is_ required for the initiator of the close to wait for the responding >>> close_notify alert before closing the read side of the connection. > >I agree with you that the TLS protocol should not let one side send a TLS >message to another side that is no longer expecting it. My guess is that >this crept in due to "separate port" thinking: after the client sent it's >close_notify, it might immediately shut down the TCP connection. However, >this seems to be the only place in the TLS spec (...I say hopefully...) >that this kind of false assumption is made. > >>I wished to check with this mailing list on application use of TLS to see if >>other protocol designers had encountered this same problem. > >Well, if we haven't yet, we certainly will, unless all the TLS 1.0 API >designers take this into account and don't close the client side until >they've heard the server's close_notify. I'd certainly like to see this >change in TLS 1.1, if not in 1.0. TLS 1.0 is going to go into IESG last >call soon, so we have time to bring this up and maybe get it fixed. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > I guess, since my reading of that spec. is different, it needs clarification. The way I read it is "The writer (i.e. client, sender) cannot consider the session successfully closed until the reader (i.e. server, receiver) has acknowledged session- end with a close_notify reply. If, however, the reader decides to close the connection prematurely for whatever reason, then it need not necessarily wait for the writer's matching close_notify." Regards, Jim LW From owner-ietf-apps-tls Mon May 19 15:37:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04882 for ietf-apps-tls-bks; Mon, 19 May 1997 15:37:04 -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 PAA04874 for ; Mon, 19 May 1997 15:37:00 -0700 (PDT) Message-Id: In-Reply-To: <3.0.1.32.19970519125617.0072293c@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 15:38:14 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: TLS API discussion Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 9:56 AM -0700 5/19/97, Rodney Thayer wrote: >I think we need to talk about TLS "API" descriptions somewhere. I offered >the idea of a "service definition" document in Memphis, this was based on >feedback from the floor at the San Jose meeting. I think this is an >appropriate place to talk about this but I wonder what the list manager >thinks? I do *not* think the alleged IETF congenital allergy to "API >Specifications" is a reason to not talk about the subject. I agree that it should be talked about, but the question is where it would get the most attention from the best people. My suggestion is to float it by the TLS Working Group, asking them if they want it talked about there as a work item. If not, you're welcome to bring it back here, although I hope you can drag a few more TLS experts with you on the round trip. If the applications developers on this list can help with this, all the better. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Mon May 19 15:41:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04913 for ietf-apps-tls-bks; Mon, 19 May 1997 15:41:27 -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 PAA04909 for ; Mon, 19 May 1997 15:41:24 -0700 (PDT) Message-Id: In-Reply-To: <3.0.1.32.19970520073150.00694c8c@mail.ccur.com.au> References: <23328.864056483@prev.critical-angle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 15:42:44 -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 2:31 PM -0700 5/19/97, Jim Lawson Williams wrote: >I guess, since my reading of that spec. is different, it needs clarification. >The way I read it is > > "The writer (i.e. client, sender) cannot consider the session successfully > closed until the reader (i.e. server, receiver) has acknowledged session- > end with a close_notify reply. If, however, the reader decides to close > the connection prematurely for whatever reason, then it need not > necessarily wait for the writer's matching close_notify." The difference being: "you don't have to wait for a response after saying you're going to tear down the connection in the normal fashion" vs. "if you're about to die, say so first, but you don't have to wait around for a response" I'd like to see some clarification from the TLS WG on which this means, because the second one makes much more sense and probably will be invoked much more rarely than the first. That is, the second interpretation is for emergencies, and the first is for sloppy programming. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue May 20 00:03:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA08509 for ietf-apps-tls-bks; Tue, 20 May 1997 00:03: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 AAA08504; Tue, 20 May 1997 00:03:07 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJ2MEOD40K9X3O8W@INNOSOFT.COM>; Tue, 20 May 1997 00:03:04 PDT Date: Tue, 20 May 1997 00:04:38 -0700 (PDT) From: Chris Newman Subject: Re: TLS API discussion 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 Mon, 19 May 1997, Paul E. Hoffman wrote: > I agree that it should be talked about, but the question is where it would > get the most attention from the best people. My suggestion is to float it > by the TLS Working Group, asking them if they want it talked about there as > a work item. If not, you're welcome to bring it back here, although I hope > you can drag a few more TLS experts with you on the round trip. If the > applications developers on this list can help with this, all the better. I think it would be a mistake to design it in the TLS group. I suspect the simplicity requirements for application programmers would get ignored and junk like ASN.1 and OIDs might creep in too far and make it unusable. Actually I think it's a mistake to design an API by committee. We should identify one visionary who's good at APIs and give him a few basic requirements (one of which would be to hide ASN.1 and OIDs from the caller as much as possible). I've never seen a good API from a committee (and rarely seen a good API in general). So how's the SSLeay API? If it's good we could just document that and standardize it. --- Chris Newman A paragraph from ASN.1 standard: "The resulting type and value of an instance of use of the new value notation is determined by the value (and the type of the value) finally assigned to the distinguished local value reference identified by the keyword VALUE, according to the processing of the macrodefinition for the new type notation followed by that for the new value notation." From owner-ietf-apps-tls Tue May 20 10:58:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA16699 for ietf-apps-tls-bks; Tue, 20 May 1997 10:58:10 -0700 (PDT) Received: from consensus.com (Administrator@mail.consensus.com [157.22.240.7]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA16692 for ; Tue, 20 May 1997 10:58:06 -0700 (PDT) Received: from dynamic-addr-191.consensus.com (157.22.240.191) by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Tue, 20 May 1997 09:58:07 -0700 Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Tue, 20 May 1997 11:00:07 -0700 To: Chris Newman From: Christopher Allen Subject: Re: TLS API discussion Cc: "Paul E. Hoffman" , ietf-apps-tls@imc.org Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 12:04 AM -0700 5/20/97, Chris Newman wrote: >So how's the SSLeay API? If it's good we could just document that and >standardize it. I'm not so hot on the SSLeay API. I'm not sure that I'd be completely happy even if we standardized on the SSLRef 3.0 API (which we wrote). There are just so many platform specific considerations -- SSLRef 3.0 API had to be somewhat of a least common denominator to minimize cross platform issues. What do you think of the SSLRef 3.0 API? It is also the base for our SSL Plus API. In any case, if there is going to be a standards effort on an TLS API, we'll be participating. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. From owner-ietf-apps-tls Tue May 20 11:47:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA17173 for ietf-apps-tls-bks; Tue, 20 May 1997 11:47:15 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA17168 for ; Tue, 20 May 1997 11:47:07 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id NAA16859; Tue, 20 May 1997 13:47:33 -0500 (CDT) Received: from kcx-ks5-17.ix.netcom.com(204.30.70.177) by dfw-ix10.ix.netcom.com via smap (V1.3) id sma016768; Tue May 20 13:46:51 1997 Message-ID: <33819C5E.5CE2@ix.netcom.com> Date: Tue, 20 May 1997 13:43:10 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Chris Newman CC: ietf-apps-tls@imc.org Subject: Re: TLS API discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Chris, Chris Newman wrote: > > On Mon, 19 May 1997, Paul E. Hoffman wrote: > > I agree that it should be talked about, but the question is where it would > > get the most attention from the best people. My suggestion is to float it > > by the TLS Working Group, asking them if they want it talked about there as > > a work item. If not, you're welcome to bring it back here, although I hope > > you can drag a few more TLS experts with you on the round trip. If the > > applications developers on this list can help with this, all the better. > > I think it would be a mistake to design it in the TLS group. I suspect > the simplicity requirements for application programmers would get ignored > and junk like ASN.1 and OIDs might creep in too far and make it unusable. I don't agree with this assesment compleatly. I do think that some coordination between TLS and the LDAP group would be in order though. > > Actually I think it's a mistake to design an API by committee. We should > identify one visionary who's good at APIs and give him a few basic > requirements (one of which would be to hide ASN.1 and OIDs from the > caller as much as possible). I've never seen a good API from a committee > (and rarely seen a good API in general). You hit on a very good point here. I too, don't believe in API's being desinged by committee either. It would seem more practical and wise for the IETF to set up a group for this perpose(S). With compotant leadership and enough openess for input. But mot and Ad Hoc commitee. > > So how's the SSLeay API? If it's good we could just document that and > standardize it. I believe it is very good. Should be looked at. > > --- > Chris Newman > > A paragraph from ASN.1 standard: "The resulting type and value of an > instance of use of the new value notation is determined by the value > (and the type of the value) finally assigned to the distinguished > local value reference identified by the keyword VALUE, according to > the processing of the macrodefinition for the new type notation > followed by that for the new value notation." 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 Tue May 20 16:02:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA19708 for ietf-apps-tls-bks; Tue, 20 May 1997 16:02:44 -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 QAA19703; Tue, 20 May 1997 16:02:38 -0700 (PDT) Received: (from tjh@localhost) by cryptsoft.com (8.8.3/8.7.3) id JAA02673; Wed, 21 May 1997 09:04:05 +1000 (EST) From: Tim Hudson Message-Id: <199705202304.JAA02673@cryptsoft.com> Subject: Re: TLS API discussion To: ChristopherA@consensus.com (Christopher Allen) Date: Wed, 21 May 1997 09:04:04 +1000 (EST) Cc: Chris.Newman@INNOSOFT.COM, phoffman@imc.org, ietf-apps-tls@imc.org Reply-To: tjh@cryptsoft.com In-Reply-To: from "Christopher Allen" at May 20, 97 11:00:07 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 Christopher Allen: > I'm not so hot on the SSLeay API. I'm not sure that I'd be completely happy > even if we standardized on the SSLRef 3.0 API (which we wrote). There are > just so many platform specific considerations -- SSLRef 3.0 API had to be > somewhat of a least common denominator to minimize cross platform issues. Given that SSLeay is used to build applications under the following platforms I think that the hint that SSLRef 3.0 API is better because it had to deal with cross platform issues is a little wierd. SSLeay builds and runs on the following platforms: - WIN16 - WIN32 - Unix (pretty much every varient) - VMS - MVS - MacOS It supports blocking and non-blocking I/O on each platform. It is thread-safe across WIN32, Unix and VMS (I don't know about the status of thread support under MVS and MacOS myself). Standarising on a single API for in essence doing all of the above is a non-trivial issue and certainly picking an API from the existing packages or picking a particular products API would be a bold move IMHO. I think that SSL library API issues belong in a separate group. Tim. From owner-ietf-apps-tls Tue May 20 17:10:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA20248 for ietf-apps-tls-bks; Tue, 20 May 1997 17:10:38 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA20244 for ; Tue, 20 May 1997 17:10:35 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id TAA03489; Tue, 20 May 1997 19:10:17 -0500 (CDT) Received: from kcx-ks12-15.ix.netcom.com(206.214.130.143) by dfw-ix10.ix.netcom.com via smap (V1.3) id sma003396; Tue May 20 19:10:04 1997 Message-ID: <3381E81A.6EFA@ix.netcom.com> Date: Tue, 20 May 1997 19:06:18 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: tjh@cryptsoft.com CC: ietf-apps-tls@imc.org Subject: Re: TLS API discussion References: <199705202304.JAA02673@cryptsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Tim, Tim Hudson wrote: > > According to Christopher Allen: > > I'm not so hot on the SSLeay API. I'm not sure that I'd be completely happy > > even if we standardized on the SSLRef 3.0 API (which we wrote). There are > > just so many platform specific considerations -- SSLRef 3.0 API had to be > > somewhat of a least common denominator to minimize cross platform issues. > Given that SSLeay is used to build applications under the following > platforms I think that the hint that SSLRef 3.0 API is better because it > had to deal with cross platform issues is a little wierd. > SSLeay builds and runs on the following platforms: > - WIN16 > - WIN32 > - Unix (pretty much every varient) > - VMS > - MVS > - MacOS > It supports blocking and non-blocking I/O on each platform. It is > thread-safe across WIN32, Unix and VMS (I don't know about the status > of thread support under MVS and MacOS myself). Both MVS and MacOs are supported I believe. > > Standarising on a single API for in essence doing all of the above > is a non-trivial issue and certainly picking an API from the existing > packages or picking a particular products API would be a bold move IMHO. I agree. IMHO, this should be left up to a seperate development group or the implimentors, in some cases. > > I think that SSL library API issues belong in a separate group. To a degree I agree. IMHO, this forum should be open enough to discuss these issues however. If a seperate group is set up to deal with SSL lib. API issues, than possibly at that point a seperate forum should be established. > > Tim. 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 Tue May 20 19:42:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA21672 for ietf-apps-tls-bks; Tue, 20 May 1997 19:42:27 -0700 (PDT) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA21668 for ; Tue, 20 May 1997 19:42:25 -0700 (PDT) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id VAA20518 for ; Tue, 20 May 1997 21:42:56 -0500 (CDT) Message-Id: <199705210242.VAA20518@dfw-ix13.ix.netcom.com> Received: from pax-ca27-05.ix.netcom.com(207.93.145.37) by dfw-ix13.ix.netcom.com via smap (V1.3) id sma020479; Tue May 20 21:42:47 1997 Date: Tue, 20 May 1997 19:40:26 -0700 From: David Brownell <"brownell"@ix.dot.netcom.com> Organization: Dave's VAX X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: Re: TLS API discussion References: <199705202304.JAA02673@cryptsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk If portability is a primary concern, I've got a rather portable Java API to present! :-) Before an API (in some language) is settled on, it strikes me there ought to be some agreements on exactly what features should be exposed, and how. If those can't be agreed on, then there may be no real virtue in trying to focus on some specific C/C++/Java/... interface set. Sessions and associated data (active cipher suite, peer cert chain, creation time, etc) seem like no-brainers ... but then, how are applications supposed to associate data with those sessions? It'll be important to let apps be involved in session creation/destruction, both by providing policies (must/mustn't create a new session here, invalidate now, invalidate after N hours not in use, etc) and notifications (just created/destroyed this session etc). Handshaking seems to me to be a lot easier. Even there, one finds issues. It's easy to say "enable only these cipher suites", or "handshake now" (and tell me when it's finished). But surely some folk will claim it's important for clients to prioritize suites, or for servers to choose amongst clients' prioritized suites, at the application level ... and such policy flexibility is annoying to get well tested. (Similarly, "re-key after every N Megabytes.") Stuff like peer authentication is curiously tricky too. Where is the agreed standard for X509v3 certificate APIs? That's unrelated to SSL, but one sort of needs an API there to use SSL well. How do applications say whether they accept the cert chain proferred during handshaking? How does the TLS layer get access to the N different private keys (and associated cert chains) it may need to authenticate itself? How do clients choose which of the M appropriate cert chains to send? Plus, oddly enough, there are languages where TLS sockets "need" to work differently from other sockets. Hmm. Even C++ can't do what Java does, since there's no 100% standard "Socket" class which is used by everyone. So, there are clearly going to be some areas where the API functionality needs to differ between different languages. The discussion I've seen so far on this list seems focussed on low level issues ... what about policies for how the data exposed by TLS gets used? For example, isn't the whole point of TLS-izing SMTP to create a "trusted" mail network, used to ensure that senders, forwarding agents, and recipients are who they say they are? Thus being able to do stuff like exclude forgers and abusers (SPAM SPAM SPAM)?? (I'm not forgetting privacy-in-transit, but remember that forwarding agents get the plaintext anyway.) We need to be thinking more broadly about how the capabilities of TLS get used by applications ... and then ensure they get exposed in the TLS APIs. We can of course try to expose every protocol feature in a "basic" API, but that quickly get unwieldy. So ... how do YOU think applications should use TLS sessions? Or use peer authentication? What control do they need over handshaking? - Dave From owner-ietf-apps-tls Tue May 20 20:54:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA22154 for ietf-apps-tls-bks; Tue, 20 May 1997 20:54:13 -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 UAA22149; Tue, 20 May 1997 20:54:05 -0700 (PDT) Message-Id: In-Reply-To: <199705202304.JAA02673@cryptsoft.com> References: from "Christopher Allen" at May 20, 97 11:00:07 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 20:55:32 -0700 To: tjh@cryptsoft.com, ChristopherA@consensus.com (Christopher Allen) From: "Paul E. Hoffman" Subject: Re: TLS API discussion Cc: ietf-apps-tls@imc.org Sender: owner-ietf-apps-tls@imc.org Precedence: bulk I'd like to propose something in the spirit of cooperative competition and the Good Of The Internet: Cyptosoft and Consensus get together off this list and see how close you two can get. This may be 0%, this may be 50%, this might be 90%. You two clearly have differences, but you also both have strong followings. Take a week or two, spend a bit of money on trans-Pacific phone bills if needed, but see how close you two can get. You probably don't need commentary from the rest of us, at least at this point, until you come back with some results. Even "we couldn't get anywhere because xxx" would be useful information for the rest of us. We promise to stay out of your hair until we hear from you. I believe that the two of you probably can work much of this out quickly, and then we can then help on the last bits. Starting with a blank sheet in this group or in the TLS WG is probably a bad way to get going; having the creators of two popular implementations is probably a very good way to get going. A little time spent on this now could save each of you (and the rest of us!) lots of time in the future. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed May 21 01:34:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA00876 for ietf-apps-tls-bks; Wed, 21 May 1997 01:34:13 -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 BAA00868 for ; Wed, 21 May 1997 01:34:09 -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 SAA13582 for <@smtp.ozemail.com.au:ietf-apps-tls@imc.org>; Wed, 21 May 1997 18:35:00 +1000 (EST) Received: from 203.108.82.29 by mail.ccur.com.au id aa03743; 21 May 97 18:38 EST Message-Id: <3.0.1.32.19970521183448.006a0304@mail.ccur.com.au> X-Sender: jimlw@mail.ccur.com.au X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 18:34:48 +1000 To: David Brownell From: Jim Lawson Williams Subject: Re: TLS API discussion Cc: ietf-apps-tls@imc.org In-Reply-To: <199705210242.VAA20518@dfw-ix13.ix.netcom.com> References: <199705202304.JAA02673@cryptsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk G'day! At 07:40 PM 5/20/97 -0700, David Brownell wrote: ...cogently and at length -- hear! hear! > >So ... how do YOU think applications should use TLS sessions? Or use >peer authentication? What control do they need over handshaking? > >- Dave > Well put! I'll be putting down some thoughts over the next couple of days. Regards, Jim LW From owner-ietf-apps-tls Wed May 21 07:28:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA05900 for ietf-apps-tls-bks; Wed, 21 May 1997 07:28:13 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA05895; Wed, 21 May 1997 07:28:10 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id JAA00870; Wed, 21 May 1997 09:28:43 -0500 (CDT) Received: from kcx-ks4-10.ix.netcom.com(204.30.70.138) by dfw-ix3.ix.netcom.com via smap (V1.3) id sma000857; Wed May 21 09:28:20 1997 Message-ID: <3382B145.7DF3@ix.netcom.com> Date: Wed, 21 May 1997 09:24:37 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "Paul E. Hoffman" CC: ietf-apps-tls@imc.org Subject: Re: TLS API discussion References: from "Christopher Allen" at May 20, 97 11:00:07 am Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul, I guess we see the world through diffrent prisims... Sigh... Paul E. Hoffman wrote: > > I'd like to propose something in the spirit of cooperative competition and > the Good Of The Internet: Cyptosoft and Consensus get together off this > list and see how close you two can get. This may be 0%, this may be 50%, > this might be 90%. You two clearly have differences, but you also both have > strong followings. There is some merit in this approach. I would be concerned if some sort of reporting mechnisim is not in place as part of procedure, however. > > Take a week or two, spend a bit of money on trans-Pacific phone bills if > needed, but see how close you two can get. You probably don't need > commentary from the rest of us, at least at this point, until you come back > with some results. Even "we couldn't get anywhere because xxx" would be > useful information for the rest of us. We promise to stay out of your hair > until we hear from you. > > I believe that the two of you probably can work much of this out quickly, > and then we can then help on the last bits. Starting with a blank sheet in > this group or in the TLS WG is probably a bad way to get going; having the > creators of two popular implementations is probably a very good way to get > going. A little time spent on this now could save each of you (and the rest > of us!) lots of time in the future. Ok not a bad idea, but you leave out the rest of the WORLD and other solutions that may have a great deal to offer. > > --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 Wed May 21 07:25:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA05811 for ietf-apps-tls-bks; Wed, 21 May 1997 07:25:07 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA05806 for ; Wed, 21 May 1997 07:25:05 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id JAA00683; Wed, 21 May 1997 09:25:35 -0500 (CDT) Received: from kcx-ks4-10.ix.netcom.com(204.30.70.138) by dfw-ix3.ix.netcom.com via smap (V1.3) id sma000661; Wed May 21 09:25:18 1997 Message-ID: <3382B08E.69FE@ix.netcom.com> Date: Wed, 21 May 1997 09:21:34 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: David Brownell CC: TLS , ietf-apps-tls@imc.org Subject: Re: TLS API discussion References: <199705202304.JAA02673@cryptsoft.com> <199705210242.VAA20518@dfw-ix13.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk David Brownell wrote: > > If portability is a primary concern, I've got a rather portable > Java API to present! :-) Yea, so do we. Love to see what you got there Dave! :) > > Before an API (in some language) is settled on, it strikes me there > ought to be some agreements on exactly what features should be > exposed, and how. If those can't be agreed on, then there may be > no real virtue in trying to focus on some specific C/C++/Java/... > interface set. Absolutely right. > > Sessions and associated data (active cipher suite, peer cert chain, > creation time, etc) seem like no-brainers ... but then, how are > applications supposed to associate data with those sessions? It'll > be important to let apps be involved in session creation/destruction, > both by providing policies (must/mustn't create a new session here, > invalidate now, invalidate after N hours not in use, etc) and > notifications (just created/destroyed this session etc). IMHO, and interface facility better services these needs. Also more flexible and easier to impliment. > > Handshaking seems to me to be a lot easier. Even there, one finds > issues. It's easy to say "enable only these cipher suites", or > "handshake now" (and tell me when it's finished). But surely some > folk will claim it's important for clients to prioritize suites, > or for servers to choose amongst clients' prioritized suites, at the > application level ... and such policy flexibility is annoying to get > well tested. (Similarly, "re-key after every N Megabytes.") Same comment as above. > > Stuff like peer authentication is curiously tricky too. Where is the > agreed standard for X509v3 certificate APIs? That's unrelated to SSL, > but one sort of needs an API there to use SSL well. How do applications > say whether they accept the cert chain proferred during handshaking? > How does the TLS layer get access to the N different private keys > (and associated cert chains) it may need to authenticate itself? How > do clients choose which of the M appropriate cert chains to send? Again, same as above but with a twist. The interface can easily provide for these considerations and additional considerations as they present themselves. Chenging a standard for some of these type of requirnments seems a bit lengthy a process to me. > > Plus, oddly enough, there are languages where TLS sockets "need" to > work differently from other sockets. Hmm. Even C++ can't do what > Java does, since there's no 100% standard "Socket" class which is > used by everyone. So, there are clearly going to be some areas where > the API functionality needs to differ between different languages. > > The discussion I've seen so far on this list seems focussed on low > level issues ... what about policies for how the data exposed by TLS > gets used? For example, isn't the whole point of TLS-izing SMTP to > create a "trusted" mail network, used to ensure that senders, forwarding > agents, and recipients are who they say they are? Thus being able to > do stuff like exclude forgers and abusers (SPAM SPAM SPAM)?? (I'm not > forgetting privacy-in-transit, but remember that forwarding agents get > the plaintext anyway.) Good point. > > We need to be thinking more broadly about how the capabilities of TLS > get used by applications ... and then ensure they get exposed in the > TLS APIs. We can of course try to expose every protocol feature in > a "basic" API, but that quickly get unwieldy. I have been saying this sience the conception of TLS itself. Sigh... > > So ... how do YOU think applications should use TLS sessions? Or use > peer authentication? What control do they need over handshaking? I don't necessarly see any need for any limitations on how TLS should use sessions necessarly. Controls are, of course going to very depending on implimentation needs. > > - Dave 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 21 08:02:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA06440 for ietf-apps-tls-bks; Wed, 21 May 1997 08:02:50 -0700 (PDT) Received: from laser.cps.softex.br (lasertec@[143.106.29.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA06434 for ; Wed, 21 May 1997 08:02:46 -0700 (PDT) Received: from localhost (lasertec@localhost) by laser.cps.softex.br (8.8.5/v3.2) with SMTP id LAA09040; Wed, 21 May 1997 11:57:11 -0300 Date: Wed, 21 May 1997 11:57:11 -0300 (EST) From: "E. Gerck" To: Jeff Williams cc: David Brownell , TLS , ietf-apps-tls@imc.org Subject: Re: TLS API discussion In-Reply-To: <3382B08E.69FE@ix.netcom.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, 21 May 1997, Jeff Williams wrote: > David Brownell wrote: > > > > If portability is a primary concern, I've got a rather portable > > Java API to present! :-) > > Yea, so do we. Love to see what you got there Dave! :) Yes, I second that! I even think that a concrete API, as a type of prototype, might help making ideas more concrete. So, this would reverse your arguments by using a prototype API to leverage specifications. 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 Wed May 21 08:23:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA06745 for ietf-apps-tls-bks; Wed, 21 May 1997 08:23:13 -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 IAA06741 for ; Wed, 21 May 1997 08:23:10 -0700 (PDT) Message-Id: In-Reply-To: <3382B145.7DF3@ix.netcom.com> References: from "Christopher Allen" at May 20, 97 11:00:07 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 08:24:39 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: TLS API discussion Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 1:24 AM -0700 5/21/97, Jeff Williams wrote: > Ok not a bad idea, but you leave out the rest of the WORLD and other >solutions that may have a great deal to offer. Please reread my message. This leaves out the "WORLD" for the two companies seeing if they can agree on something given their extensive experience with their own APIs. If you have a proposal for your own API, you're still welcome to propose it as a draft, and it might be better than whatever the established players come up with. What I'm proposing is that someone start with something concrete, and these two companies already have their own work that might have a lot of good overlap. If we have other concrete proposals to start with, that's fine too. What I'm proposing against is us yakking here without focus. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sun Jun 1 15:05:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21999 for ietf-apps-tls-bks; Sun, 1 Jun 1997 15:05: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 PAA21992 for ; Sun, 1 Jun 1997 15:05:14 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Jun 1997 15:05:58 -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. More discussions, more drafts. I've fixed the blunders I made on the error codes. Further, after the extensive discussion going on in the ASID WG about how they are going to handle LDAP over TLS, we discovered that by ignoring SSL2, the STARTTLS command can be made simpler. The new version is available at . It will appear in the Internet Drafts directory soon, I assume. The differences from the -02 draft are: C. Revision History ***Changes from -021 to -03: Changed the TLS keyword and the STARTTLS command to not have any parameters. The side-effect of this was to disallow SSL 2.0, which was never documented in the IETF and is known to be much less secure than SSL 3.0 or TLS 1.0. This also simplifies the protocol, always a nice thing. Changed the 554 response code to 454 because 4xx is for temporary errors. Changed the 560 response code to 505 because it was just plain dumb to go into the x6x range. Added the enhanced error code as well. Changed the example to show that the client starts the TLS negotiation, and that the client speaks first aftwards. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sun Jun 1 15:21:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA22379 for ietf-apps-tls-bks; Sun, 1 Jun 1997 15:21:58 -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 PAA22371 for ; Sun, 1 Jun 1997 15:21:55 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Jun 1997 15:23:44 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Do we need IMAP/TLS or POP/TLS? Sender: owner-ietf-apps-tls@imc.org Precedence: bulk When I started this mailing list, I knew that we would be talking about SMTP over TLS and LDAP over TLS without having to use a second port for each. Further, I assumed that we would also discuss doing similar work for IMAP and POP over TLS. However, in retrospect, it occurs to me that we might have good reason to leave IMAP and POP over TLS on a separate port. The main reason we want a single port for SMTP and LDAP is because clients do not necessarily have a previous relationship with the servers, and thus won't know whether or not to try the TLS port first if they want to do TLS. IMAP and POP clients, however, by definition have a pre-existing relationship with the server. That is, the server must know about them before they attach, and therefore this prior knowledge can be used in setting up the client. The only exception I can think of is public, anonymous IMAP mailboxes. In this case, however, you wouldn't be using TLS, since there is no authentication and no need for privacy. Thus, my current belief is that in situations where the client and server have some prior knowledge of each other, having two ports is not bad. It isn't good (we want to conserve ports), so new protocols should have both their non-TLS and TLS done on one port if possible, but there doesn't seem to be nearly as compelling a reason to create STARTLS-like commands for IMAP and POP as there is for SMTP and LDAP. Does this jive with what others are thinking? --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sun Jun 1 21:11:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA28066 for ietf-apps-tls-bks; Sun, 1 Jun 1997 21:11:34 -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 VAA28061; Sun, 1 Jun 1997 21:11:29 -0700 (PDT) Received: from eleanor.innosoft.com ("port 56073"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJKM6TSMTA9X4K26@INNOSOFT.COM>; Sun, 1 Jun 1997 21:11:01 PDT Date: Sun, 01 Jun 1997 21:12:37 -0700 (PDT) From: Chris Newman Subject: Re: Do we need IMAP/TLS or POP/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 Sun, 1 Jun 1997, Paul E. Hoffman wrote: > IMAP and POP clients, however, by definition have a pre-existing > relationship with the server. That is, the server must know about them > before they attach, and therefore this prior knowledge can be used in > setting up the client. It's bad enough that clients need to be configured with the name of the IMAP/POP server itself. Forcing users to also decide whether or not to connect to a TLS port when setting up a client is completely unacceptable in my book. > The only exception I can think of is public, anonymous IMAP mailboxes. In > this case, however, you wouldn't be using TLS, since there is no > authentication and no need for privacy. I disagree. I might very well want to prevent observers from seeing what I fetch from an anonymous IMAP server. --- Chris Newman A paragraph from ASN.1 standard: "The resulting type and value of an instance of use of the new value notation is determined by the value (and the type of the value) finally assigned to the distinguished local value reference identified by the keyword VALUE, according to the processing of the macrodefinition for the new type notation followed by that for the new value notation." From owner-ietf-apps-tls Mon Jun 2 01:42:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA02614 for ietf-apps-tls-bks; Mon, 2 Jun 1997 01:42:51 -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 BAA02606; Mon, 2 Jun 1997 01:42:48 -0700 (PDT) Received: from decadence.stanford.edu (Decadence.Stanford.EDU [36.178.0.199]) by Networking.Stanford.EDU (8.8.5/8.6.6) with SMTP id BAA26769; Mon, 2 Jun 1997 01:44:36 -0700 Date: Mon, 02 Jun 1997 01:44:26 -0700 From: "RL \"Bob\" Morgan "@networking.stanford.edu To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org Subject: Re: Do we need IMAP/TLS or POP/TLS? Message-ID: <93444244.3074204666@decadence.stanford.edu> X-Mailer: Mulberry (MacOS) [1.2.0, s/n Evaluation] X-Authenticated: morgan by networking.stanford.edu X-Licensed-To: Unlicensed - for evaluation only MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk --On Sun, Jun 1, 1997 3:23 PM -0700 "Paul E. Hoffman" wrote: > The only exception I can think of is public, anonymous IMAP mailboxes. In > this case, however, you wouldn't be using TLS, since there is no > authentication and no need for privacy. To add to what Chris wrote, I note that I might want integrity protection and authentication of the server when I go to a public site, even if I don't care about privacy. Repeat after me: TLS is not just about encryption ... Furthermore, I wouldn't equate public and anonymous. We've all seen lots of "public" web sites that ask us to register in order to use them. I might well go to a public IMAP server looking for something, and it would ask me to authenticate using TLS, and I would do so using my credit-card-based certificate since I want to see what it has and I don't care if it knows who I am. It would be nice for this scenario to work via IMAP-protocol-based negotiation. As we've discussed on the ASID list, the two-port scheme really hoses URLs. This is reason enough to avoid it in just about any protocol, IMHO. If it's worth doing a protocol on TLS, it's worth doing it right and integrating it with the rest of the protocol's operations. - RL "Bob" From owner-ietf-apps-tls Mon Jun 2 09:38:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA14015 for ietf-apps-tls-bks; Mon, 2 Jun 1997 09:38:38 -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 JAA14009 for ; Mon, 2 Jun 1997 09:38:34 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id LAA21063; Mon, 2 Jun 1997 11:39:51 -0500 (CDT) Received: from kcx-ks3-21.ix.netcom.com(204.30.70.117) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma020991; Mon Jun 2 11:39:31 1997 Message-ID: <3392A1AE.4D0A@ix.netcom.com> Date: Mon, 02 Jun 1997 11:34:22 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Chris Newman CC: ietf-apps-tls@imc.org Subject: Re: Do we need IMAP/TLS or POP/TLS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Chris, Chris Newman wrote: > > On Sun, 1 Jun 1997, Paul E. Hoffman wrote: > > IMAP and POP clients, however, by definition have a pre-existing > > relationship with the server. That is, the server must know about them > > before they attach, and therefore this prior knowledge can be used in > > setting up the client. > > It's bad enough that clients need to be configured with the name of the > IMAP/POP server itself. Forcing users to also decide whether or not to > connect to a TLS port when setting up a client is completely unacceptable > in my book. I agree. But it seems that that is the direction of the WG at this point. But there are always work arounds. Our MLPI is a good example. :) > > > The only exception I can think of is public, anonymous IMAP mailboxes. In > > this case, however, you wouldn't be using TLS, since there is no > > authentication and no need for privacy. > > I disagree. I might very well want to prevent observers from seeing what > I fetch from an anonymous IMAP server. Yep, that is a definate possibility. > > --- > Chris Newman > > A paragraph from ASN.1 standard: "The resulting type and value of an > instance of use of the new value notation is determined by the value > (and the type of the value) finally assigned to the distinguished > local value reference identified by the keyword VALUE, according to > the processing of the macrodefinition for the new type notation > followed by that for the new value notation." You got it! Thanks for speaking up. I thought I was th only one on this limb. :) Regards -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Mon Jun 2 09:46:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA14249 for ietf-apps-tls-bks; Mon, 2 Jun 1997 09:46:02 -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 JAA14245 for ; Mon, 2 Jun 1997 09:45:59 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id LAA22160; Mon, 2 Jun 1997 11:47:07 -0500 (CDT) Received: from kcx-ks3-21.ix.netcom.com(204.30.70.117) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma022151; Mon Jun 2 11:46:44 1997 Message-ID: <3392A35F.5D3F@ix.netcom.com> Date: Mon, 02 Jun 1997 11:41:35 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "RL \"Bob\" Morgan "@networking.stanford.edu CC: TLS , LDAP M List , ietf-apps-tls@imc.org Subject: Re: Do we need IMAP/TLS or POP/TLS? References: <93444244.3074204666@decadence.stanford.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Bob, RL "Bob" Morgan @networking.stanford.edu wrote: > > --On Sun, Jun 1, 1997 3:23 PM -0700 "Paul E. Hoffman" > wrote: > > > The only exception I can think of is public, anonymous IMAP > mailboxes. In > > this case, however, you wouldn't be using TLS, since there is no > > authentication and no need for privacy. > > To add to what Chris wrote, I note that I might want integrity > protection and authentication of the server when I go to a public site, > even if I don't care about privacy. Repeat after me: TLS is not just > about encryption ... > > Furthermore, I wouldn't equate public and anonymous. We've all seen > lots of "public" web sites that ask us to register in order to use > them. I might well go to a public IMAP server looking for something, > and it would ask me to authenticate using TLS, and I would do so using > my credit-card-based certificate since I want to see what it has and I > don't care if it knows who I am. It would be nice for this scenario to > work via IMAP-protocol-based negotiation. I see your point and agree. I would also take it one step further, that being that there should not necessarly be any tie to ANY protocol in particular. This can be achieved is several ways, which I have posted befor and WE chose to develope and "Interface Facility" (MLPI) for just this and other perposes. :) > > As we've discussed on the ASID list, the two-port scheme really hoses > URLs. This is reason enough to avoid it in just about any protocol, > IMHO. If it's worth doing a protocol on TLS, it's worth doing it right > and integrating it with the rest of the protocol's operations. I agree. See my comment just above. :) > > - RL "Bob" Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Mon Jun 2 11:12:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA16637 for ietf-apps-tls-bks; Mon, 2 Jun 1997 11:12:54 -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 LAA16633 for ; Mon, 2 Jun 1997 11:12:51 -0700 (PDT) Received: from eleanor.innosoft.com ("port 56490"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJLFLBPV7M9X4N0R@INNOSOFT.COM> for ietf-apps-tls@imc.org; Mon, 2 Jun 1997 11:13:27 PDT Date: Mon, 02 Jun 1997 11:15:03 -0700 (PDT) From: Chris Newman Subject: Re: Do we need IMAP/TLS or POP/TLS? In-reply-to: <3392A1AE.4D0A@ix.netcom.com> To: Jeff Williams 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 Mon, 2 Jun 1997, Jeff Williams wrote: > I agree. But it seems that that is the direction of the WG at this point. Which WG? I suspect if I posted the question on the IMAP protocol mailing list that almost everyone would want a STARTTLS command within IMAP. And the IMAP protocol mailing list includes the people who actually write IMAP clients and servers. > But there are always work arounds. Our MLPI is a good example. :) I don't know what MLPI is. --- Chris Newman A paragraph from ASN.1 standard: "The resulting type and value of an instance of use of the new value notation is determined by the value (and the type of the value) finally assigned to the distinguished local value reference identified by the keyword VALUE, according to the processing of the macrodefinition for the new type notation followed by that for the new value notation." From owner-ietf-apps-tls Mon Jun 2 14:42:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA19973 for ietf-apps-tls-bks; Mon, 2 Jun 1997 14:42:09 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA19968; Mon, 2 Jun 1997 14:42:05 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA00678; Mon, 2 Jun 1997 17:43:51 -0400 (EDT) Message-Id: <199706022143.RAA00678@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-apps-tls@imc.org, moore@cs.utk.edu Subject: Re: Do we need IMAP/TLS or POP/TLS? In-reply-to: Your message of "Sun, 01 Jun 1997 15:23:44 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jun 1997 17:43:50 -0400 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > However, in retrospect, it occurs to me that we might have good reason to > leave IMAP and POP over TLS on a separate port. The main reason we want a > single port for SMTP and LDAP is because clients do not necessarily have a > previous relationship with the servers, and thus won't know whether or not > to try the TLS port first if they want to do TLS. There's another reason for using only one port: it makes it much easier to configure the clients if they can automagically determine when TLS is available. And it's much easier to secure existing applications protocols if new "TLS aware" clients can use the same configuration (host, port#, etc.) as the old "pre-TLS" clients. And no matter what the service, the "try the TLS port first and fall back to another port" is trivially vulernable to denial-of-service attacks on the TLS port. The separate port idea has always been a botch and must be fixed ASAP. I've already asked IANA to consult with the APPS ADs before defining any more "FOO+TLS" ports for applications. My highest priority as APPS AD is to fix as many existing apps as possible, to negotiate TLS in-band. Keith From owner-ietf-apps-tls Mon Jun 2 17:14:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21855 for ietf-apps-tls-bks; Mon, 2 Jun 1997 17:14:41 -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 RAA21850 for ; Mon, 2 Jun 1997 17:14:38 -0700 (PDT) Message-Id: In-Reply-To: <199706022143.RAA00678@spot.cs.utk.edu> References: Your message of "Sun, 01 Jun 1997 15:23:44 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Jun 1997 17:16:33 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Do we need IMAP/TLS or POP/TLS? Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Well, it looks like my attempt to dodge the work failed. :-) Seriously, I didn't think that there was this much sentiment in favor of the STARTTLS commands in IMAP and POP. I'll take care of getting these written in the near future. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed Jun 4 07:03:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA02179 for ietf-apps-tls-bks; Wed, 4 Jun 1997 07:03:56 -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 HAA02175 for ; Wed, 4 Jun 1997 07:03:52 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id KAA27299; Wed, 4 Jun 1997 10:05:23 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma027296; Wed Jun 4 10:05:15 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 KAA28728; Wed, 4 Jun 1997 10:02:25 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id KAA02332; Wed, 4 Jun 1997 10:04:44 -0400 Date: Wed, 4 Jun 1997 10:04:44 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199706041404.KAA02332@argon.ncsc.mil> To: ietf-apps-tls@imc.org Subject: Re: Do we need IMAP/TLS or POP/TLS? Cc: ietf-tls@consensus.com X-Sun-Charset: US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > From: Keith Moore > To: "Paul E. Hoffman" > > > However, in retrospect, it occurs to me that we might have good reason to > > leave IMAP and POP over TLS on a separate port. The main reason we want a > > single port for SMTP and LDAP is because clients do not necessarily have a > > previous relationship with the servers, and thus won't know whether or not > > to try the TLS port first if they want to do TLS. > > There's another reason for using only one port: it makes it much > easier to configure the clients if they can automagically determine > when TLS is available. And it's much easier to secure existing > applications protocols if new "TLS aware" clients can use the same > configuration (host, port#, etc.) as the old "pre-TLS" clients. > > And no matter what the service, the "try the TLS port first and fall > back to another port" is trivially vulernable to denial-of-service > attacks on the TLS port. > > The separate port idea has always been a botch and must be fixed ASAP. > I've already asked IANA to consult with the APPS ADs before defining > any more "FOO+TLS" ports for applications. Bravo!! > My highest priority as APPS AD is to fix as many existing apps as > possible, to negotiate TLS in-band. > > Keith I cc'd ietf-tls because the separate port thread has been discussed there since the dawn of tls, and this is not just an apps issue. I suggest that the discussion continue only on ietf-tls, to avoid spamming both lists. The three alternatives, in order of increasing "goodness", are: 1) duplicate FOO+TLS ports 2) individual application negotiation 3) session layer negotiation The SASL document describes the difficulties in negotiating TLS protection from the application. It's obvious that requiring every application protocol specification to define an explicit TLS mode is not optimal either. And involving application developers in the normal-mode/TLS-mode negotiation and switching process is guaranteed to introduce security holes -- this was the reason for defining separate ports in the first place. I believe that the most appropriate long-term architecture is to set the session security protocol in the same manner as the rest of the network stack: Just as PPP has a "next protocol" field to specify the network layer protocol (IP, IPX, ...), and IP has a next field to specify the transport layer protocol (TCP, UDP, ...), TCP should have a "next" parameter to specify the session layer protocol. I propose that a one-byte TCP option be defined which specifies the next higher protocol. If the option is absent or has the value 0, TCP would operate as it does now, without a session layer protocol. The option value 1 would specify TLS, and the values 2-255 (or 2-240, to allow a private/experimental protocol space) would be reserved to IANA. This mechanism would allow applications to simply use setsockopt/getsockopt to allow or force the use of TLS for a particular connection, instead of requiring each application to parse application-specific "STARTTLS"-type commands. It avoids requiring the application to either: * close the existing normal TCP connection and open a TLS connection, or * synchronize the start of TLS handshake over an existing TCP connection. And it doesn't require significant kernel or network stack mods, it only requires that the application be able to get/set TCP options through the socket interface. (This may already be possible in some OSs, but at least in Solaris, the documentation says "Options may exist at multiple protocol levels" but it doesn't define any option names for manipulating IP or TCP options). The TCP-option method would also allow different types of implementations to interoperate - one containing the TLS code as part of the network stack and the other linking TLS into the application. The separate-port method already allows this, but the application-negotiation method could not be built into a TLS network stack. Although the duplicate-port and application-negotiation methods are the only available options today, I believe it would be a better use of IETF resources to define and encourage the implementation of a TLS TCP option, than to embark on a campaign to modify every application protocol to enable/negotiate the use of TLS. The ietf-apps-tls effort is clearly needed as a short term solution, but we should also be designing long term solutions, not just fighting fires. From owner-ietf-apps-tls Wed Jun 4 14:41:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA13354 for ietf-apps-tls-bks; Wed, 4 Jun 1997 14:41:34 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA13350 for ; Wed, 4 Jun 1997 14:41:31 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1577.8) id ; Wed, 4 Jun 1997 14:43:32 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: ietf-apps-tls@imc.org Subject: Piggybacking client hello on STARTTLS Date: Wed, 4 Jun 1997 14:43:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1577.8) Content-Type: text/plain Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Not that I'm actually advocating this, but seems that we ought to at least bring up the possibility of piggy-backing the TLS client hello on the STARTTLS command in order to save a round trip. Personally, I'm against it because it would also involve merging the SMTP reply code to STARTTLS with (perhaps) a TLS server hello in the response. It just makes something that was nice and clean messier without (IMHO) gaining all that much. Do others agree? -- jeff From owner-ietf-apps-tls Wed Jun 4 16:14:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA15268 for ietf-apps-tls-bks; Wed, 4 Jun 1997 16:14:41 -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 QAA15263 for ; Wed, 4 Jun 1997 16:14:37 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id SAA16575; Wed, 4 Jun 1997 18:15:56 -0500 (CDT) Received: from kcx-ks11-14.ix.netcom.com(206.214.130.110) by dfw-ix15.ix.netcom.com via smap (V1.3) id sma016558; Wed Jun 4 18:15:27 1997 Message-ID: <3395A167.78D3@ix.netcom.com> Date: Wed, 04 Jun 1997 18:10:00 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "Jeff Stephenson (Exchange)" CC: ietf-apps-tls@imc.org Subject: Re: Piggybacking client hello on STARTTLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Jeff, Jeff Stephenson (Exchange) wrote: > > Not that I'm actually advocating this, but seems that we ought to at > least bring up the possibility of piggy-backing the TLS client hello on > the STARTTLS command in order to save a round trip. Personally, I'm > against it because it would also involve merging the SMTP reply code to > STARTTLS with (perhaps) a TLS server hello in the response. It just > makes something that was nice and clean messier without (IMHO) gaining > all that much. Do others agree? No I am not for doing this. Two reasons, 1.) Not necessary and 2.) as you say, You are really not gaining much, in fact nothing at all. There are several other methods of handeling this problem. I have posted some of what IMHO, would be much better approaches. Others have as well. It just seems that there is not any consensus on which method to use. Sigh... > > -- jeff Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Wed Jun 4 17:37:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA16717 for ietf-apps-tls-bks; Wed, 4 Jun 1997 17:37:14 -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 RAA16713; Wed, 4 Jun 1997 17:37:09 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Jun 1997 17:39:16 -0700 To: "Jeff Stephenson (Exchange)" , ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: Piggybacking client hello on STARTTLS Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 2:43 PM -0700 6/4/97, Jeff Stephenson (Exchange) wrote: >Not that I'm actually advocating this, but seems that we ought to at >least bring up the possibility of piggy-backing the TLS client hello on >the STARTTLS command in order to save a round trip. Personally, I'm >against it because it would also involve merging the SMTP reply code to >STARTTLS with (perhaps) a TLS server hello in the response. It just >makes something that was nice and clean messier without (IMHO) gaining >all that much. Do others agree? Nope, for lots of reasons including the ones you gave. The SMTP model is that every client command gets a response; what if the SMTP server decides it can't TLS? It's a protocol level violation. One round trip is minor in an SMTP session. And so on. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu Jun 12 15:08:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA02341 for ietf-apps-tls-bks; Thu, 12 Jun 1997 15:08:26 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA02330; Thu, 12 Jun 1997 15:07:45 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1608.0) id ; Thu, 12 Jun 1997 15:10:18 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050E8254@DINO> From: "Jeff Stephenson (Exchange)" To: "'John Gardiner Myers'" , "'Paul E. Hoffman'" Cc: "'ietf-sasl@imc.org'" , "'ietf-apps-tls@imc.org'" Subject: SMTP servers requiring security/authentication Date: Thu, 12 Jun 1997 15:10:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1608.0) Content-Type: text/plain Sender: owner-ietf-apps-tls@imc.org Precedence: bulk The SMTP AUTH draft (draft-myers-smtp-auth-05.txt), while providing a mechanism for a submitting client to authenticate to the server and establish a secure session, doesn't contain a provision for the server to inform the client that authentication or security are _required_ for submission. I'd like to see an addition to the draft which addresses how an SMTP server responds to SMTP commands when authentication or security are required but the client has not successfully issued an appropriate AUTH command. The current STARTTLS command (draft-hoffman-smtp-ssl-03.txt) has a provision along these lines, specifying a response of "505 Must issue a STARTTLS command first" to any command other than STARTTLS or QUIT if the server requires TLS. This might best be generalized to "505 Secure SMTP session required" and used in both the SMTP AUTH and STARTTLS worlds. Similarly, a server which required the client to authenticate could respond with "506 Authentication required" to anything but a command which could establish authentication. Clearly there are some ordering problems to be worked out here - if someone wants to do a STARTTLS to establish security (but not client identity) and an AUTH command to authenticate, we don't want the STARTTLS rejected because of lack of authentication. From owner-ietf-apps-tls Thu Jun 12 15:51:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA02866 for ietf-apps-tls-bks; Thu, 12 Jun 1997 15:51:53 -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 PAA02861; Thu, 12 Jun 1997 15:51:48 -0700 (PDT) Received: from eleanor.innosoft.com ("port 60679"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJZOAN9VUOANBWR7@INNOSOFT.COM>; Thu, 12 Jun 1997 15:53:14 PDT Date: Thu, 12 Jun 1997 15:54:52 -0700 (PDT) From: Chris Newman Subject: smtp-tls In-reply-to: <2FBF98FC7852CF11912A000000000001050E8254@DINO> To: Application/TLS IETF List , Paul Hoffman Cc: John Hemming , iana@isi.edu 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, 12 Jun 1997, Jeff Stephenson (Exchange) wrote: > The current STARTTLS command (draft-hoffman-smtp-ssl-03.txt) has a That reminds me of a suggestion I have for that document: ---- 7. Secure SMTP Over a Separate Port An IANA port registration was made for an "smtps" port for use as a TLS-negotiated SMTP port. The email community has reached rough concensus that widespread use of such a port will be harmful to the performance, interoperability and security of SMTP. This document hereby revokes the IANA registration of the "smtps" port and forbids future registration of a port for any "secure SMTP" service. IANA is directed to replace the port registration with an indication that the port registration was revoked, including the effective date. Two years after the effective date of revocation, the port may be re-registered for a different purpose. ---- This would take effect as soon as the SMTP STARTTLS document is approved as a proposed standard. This is legitimate because IANA policy is set by IETF standards track documents. From owner-ietf-apps-tls Thu Jun 12 16:04:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03068 for ietf-apps-tls-bks; Thu, 12 Jun 1997 16:04:55 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA03063; Thu, 12 Jun 1997 16:04:51 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id SAA14422; Thu, 12 Jun 1997 18:06:27 -0500 (CDT) Received: from kcx-ks6-21.ix.netcom.com(204.30.70.213) by dfw-ix10.ix.netcom.com via smap (V1.3) id sma014375; Thu Jun 12 18:05:54 1997 Message-ID: <33A02B1D.32C2@ix.netcom.com> Date: Thu, 12 Jun 1997 18:00:13 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "Jeff Stephenson (Exchange)" CC: "'John Gardiner Myers'" , "'Paul E. Hoffman'" , "'ietf-sasl@imc.org'" , "'ietf-apps-tls@imc.org'" Subject: Re: SMTP servers requiring security/authentication References: <2FBF98FC7852CF11912A000000000001050E8254@DINO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Jeff, Jeff Stephenson (Exchange) wrote: > > The SMTP AUTH draft (draft-myers-smtp-auth-05.txt), while providing a > mechanism for a submitting client to authenticate to the server and > establish a secure session, doesn't contain a provision for the server > to inform the client that authentication or security are _required_ for > submission. I'd like to see an addition to the draft which addresses > how an SMTP server responds to SMTP commands when authentication or > security are required but the client has not successfully issued an > appropriate AUTH command. This is absolutely a good idea and we have included this ability already in our "Interface Facility" or MLPI to facilitate this through a direct call passing the command(S) that can be defined. But I agree with Jeff here, this should be part of the Draft. > > The current STARTTLS command (draft-hoffman-smtp-ssl-03.txt) has a > provision along these lines, specifying a response of "505 Must issue a > STARTTLS command first" to any command other than STARTTLS or QUIT if > the server requires TLS. This might best be generalized to "505 Secure > SMTP session required" and used in both the SMTP AUTH and STARTTLS > worlds. Similarly, a server which required the client to authenticate > could respond with "506 Authentication required" to anything but a > command which could establish authentication. Agreed again here. And again, we do include this capability in our "Interface Facility? or MLPI. Yet I might add that limiting the diffrent "Start Commands", for simplifacation here, should not just be limited to TLS for SMTP. And we do provide this capability as well that can be defined in addition to any other command structure,or in addition to existing command structure that may already exist. >;) > > Clearly there are some ordering problems to be worked out here - if > someone wants to do a STARTTLS to establish security (but not client > identity) and an AUTH command to authenticate, we don't want the > STARTTLS rejected because of lack of authentication. This is very simply workable. Many diffrent approaches can be used to achiev this consideration. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Thu Jun 12 16:49:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03609 for ietf-apps-tls-bks; Thu, 12 Jun 1997 16:49:14 -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 QAA03605 for ; Thu, 12 Jun 1997 16:49:11 -0700 (PDT) Message-Id: In-Reply-To: References: <2FBF98FC7852CF11912A000000000001050E8254@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 1997 16:52:05 -0700 To: ietf-apps-tls@imc.org From: "Paul E. Hoffman" Subject: Re: smtp-tls Sender: owner-ietf-apps-tls@imc.org Precedence: bulk >This document hereby revokes the >IANA registration of the "smtps" port and forbids future registration of a >port for any "secure SMTP" service. IANA is directed to replace the port >registration with an indication that the port registration was revoked, >including the effective date. Two years after the effective date of >revocation, the port may be re-registered for a different purpose. I like it, even if I don't really like demaning things from the esteemed Dr. Postel... Do other folks have an opinion on this? And are we reaching closure on the draft? --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Fri Jun 13 08:07:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA14723 for ietf-apps-tls-bks; Fri, 13 Jun 1997 08:07:31 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA14718; Fri, 13 Jun 1997 08:07:28 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1608.0) id ; Fri, 13 Jun 1997 08:10:01 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050E825B@DINO> From: "Jeff Stephenson (Exchange)" To: "'Paul E. Hoffman'" , ietf-apps-tls@imc.org Subject: RE: smtp-tls Date: Fri, 13 Jun 1997 08:10:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1608.0) Content-Type: text/plain Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Yes and yes. Add the language to deregister the port, and let's move forward. > -----Original Message----- > From: Paul E. Hoffman [SMTP:phoffman@imc.org] > Sent: Thursday, June 12, 1997 4:52 PM > To: ietf-apps-tls@imc.org > Subject: Re: smtp-tls > > >This document hereby revokes the > >IANA registration of the "smtps" port and forbids future registration > of a > >port for any "secure SMTP" service. IANA is directed to replace the > port > >registration with an indication that the port registration was > revoked, > >including the effective date. Two years after the effective date of > >revocation, the port may be re-registered for a different purpose. > > I like it, even if I don't really like demaning things from the > esteemed > Dr. Postel... > > Do other folks have an opinion on this? > > And are we reaching closure on the draft? > > --Paul E. Hoffman, Director > --Internet Mail Consortium > From owner-ietf-apps-tls Thu Jul 24 16:40:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA27730 for ietf-apps-tls-bks; Thu, 24 Jul 1997 16:40:22 -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 QAA27726 for ; Thu, 24 Jul 1997 16:40:17 -0700 (PDT) Received: from prev.critical-angle.com by felix.austin.isode.com with Internet SMTP (IC MTA); Thu, 24 Jul 1997 18:43:44 -0500 From: Mark Wahl To: ietf-apps-tls@imc.org Cc: Mark Wahl Subject: ACAP/TLS Date: Thu, 24 Jul 1997 18:40:38 -0500 Message-ID: <13251.869787638@prev.critical-angle.com> Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Hello, Is there a specification for using ACAP in combination with TLS, either on a separate port or with a Start-TLS command? (A goal would be to establish a confidential association between the client and server and use the SASL "EXTERNAL" mechanism to pick up the client's identity from its certificate path.) Thanks in advance, Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-apps-tls Mon Jul 28 07:39:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA21789 for ietf-apps-tls-bks; Mon, 28 Jul 1997 07:39:47 -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 HAA21778 for ; Mon, 28 Jul 1997 07:39:40 -0700 (PDT) Received: from eleanor.innosoft.com ("port 49365"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILRGK35TBY8WX8PH@INNOSOFT.COM> for ietf-apps-tls@imc.org; Mon, 28 Jul 1997 07:42:28 PDT Date: Mon, 28 Jul 1997 07:44:19 -0700 (PDT) From: Chris Newman Subject: Re: ACAP/TLS In-reply-to: <13251.869787638@prev.critical-angle.com> To: Application Use of TLS IETF List 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, 24 Jul 1997, Mark Wahl wrote: > Is there a specification for using ACAP in combination with TLS, either on > a separate port or with a Start-TLS command? > > (A goal would be to establish a confidential association between the client > and server and use the SASL "EXTERNAL" mechanism to pick up the client's > identity from its certificate path.) There isn't a STARTTLS command defined yet. When TLS gets closer to proposed standard, I'll write one if nobody else volunteers. - Chris From owner-ietf-apps-tls Mon Aug 11 07:07:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA27904 for ietf-apps-tls-bks; Mon, 11 Aug 1997 07:07:34 -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 HAA27900 for ; Mon, 11 Aug 1997 07:07:28 -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; 11 Aug 1997 14:12:07 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 KAA03075; Mon, 11 Aug 1997 10:13:43 -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; 11 Aug 1997 14:12:04 UT Received: from Laptop-static-rodney.ietf.de (Laptop-static-rodney.ietf.de [195.27.194.28]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id KAA23496; Mon, 11 Aug 1997 10:12:02 -0400 (EDT) Message-Id: <3.0.1.32.19970811160316.007c2810@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 11 Aug 1997 16:03:16 -0400 To: ietf-tls@consensus.com, ietf-apps-tls@imc.org From: Rodney Thayer Subject: rump session in Munich? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Are any folks getting together in Munich? Inquiring beer consumers want to know... I'm staying at the Sheraton, leave me email or a message at the hotel. From owner-ietf-apps-tls Wed Aug 27 08:56:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA10762 for ietf-apps-tls-bks; Wed, 27 Aug 1997 08:56:43 -0700 (PDT) Received: from webmail.ihub.com (webmail.ihub.com [199.29.68.71]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA10755 for ; Wed, 27 Aug 1997 08:56:38 -0700 (PDT) Message-ID: <82E3CB3001010000@webmail.ihub.com> X-SMF-Message-ID: 82E3CB3001010000 X-SMF-Hop-Count: 1 Date: Wed, 27 Aug 97 12:03:00 -0400 From: Brett Warthen To: ietf-apps-tls Subject: Any drafts for IMAP4/TLS and/or POP3/TLS Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-disposition: inline Content-Transfer-Encoding: 7BIT X-Mailer: InterChange (Hydra) SMTP v3.01.02 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk I'm interested in implementing both IMAP4 & POP3 over SSL. But rather than dedicating a separate port for SSL access (where the client would always have to specify what port was to be used) ... I'd like to use an approach like in the SMTP-TLS where the connection starts off unencrypted, and the client can then switch over to an encrypted session. Are there any draft specifications available? - Brett Warthen Infinite Technologies mailto:Brett_Warthen@infinite.ihub.com http://www.ihub.com From owner-ietf-apps-tls Wed Aug 27 12:24:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA14099 for ietf-apps-tls-bks; Wed, 27 Aug 1997 12:24:06 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA14092 for ; Wed, 27 Aug 1997 12:24:01 -0700 (PDT) Received: from eleanor.innosoft.com ("port 41460"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IMXNAUDTZQ94EG0A@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 27 Aug 1997 12:29:07 PDT Date: Wed, 27 Aug 1997 12:31:03 -0700 (PDT) From: Chris Newman Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS In-reply-to: <82E3CB3001010000@webmail.ihub.com> To: Brett Warthen Cc: ietf-apps-tls Message-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-872710263=:2282" Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-959030623-872710263=:2282 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 27 Aug 1997, Brett Warthen wrote: > I'm interested in implementing both IMAP4 & POP3 over SSL. > > But rather than dedicating a separate port for SSL access (where the client > would always have to specify what port was to be used) ... I'd like to use > an approach like in the SMTP-TLS where the connection starts off > unencrypted, and the client can then switch over to an encrypted session. > > Are there any draft specifications available? I just got tired of people asking for this, so I wrote it. Note that such a draft can't proceed on the standards track until TLS is completed. - Chris ---559023410-959030623-872710263=:2282 Content-Type: TEXT/plain; name="imaptls.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4gTmV3bWFuDQpJbnRl cm5ldCBEcmFmdDogUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9QMyBDb25uZWN0 aW9ucyAgICAgICAgICAgSW5ub3NvZnQNCkRvY3VtZW50OiBkcmFmdC1uZXdt YW4tdGxzLWltYXBwb3AtMDAudHh0ICAgICAgICAgICAgICAgICAgICBBdWd1 c3QgMTk5Nw0KDQoNCiAgICAgICAgICAgICAgICAgUHJvdGVjdGluZyBJTUFQ NCBhbmQgUE9QMyBDb25uZWN0aW9ucw0KDQoNClN0YXR1cyBvZiB0aGlzIG1l bW8NCg0KICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICAgIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVU RiksIGl0cyBhcmVhcywNCiAgICAgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0K ICAgICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoN CiAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXgNCiAgICAgbW9udGhzIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0K ICAgICBkb2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluDQogICAgIHByb2dyZXNzLiINCg0KICAgICBUbyB2aWV3IHRoZSBlbnRp cmUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cywgcGxlYXNlIGNo ZWNrDQogICAgIHRoZSAiMWlkLWFic3RyYWN0cy50eHQiIGxpc3RpbmcgY29u dGFpbmVkIGluIHRoZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgU2hhZG93IERp cmVjdG9yaWVzIG9uIGZ0cC5pcy5jby56YSAoQWZyaWNhKSwgZnRwLm5vcmR1 Lm5ldA0KICAgICAoRXVyb3BlKSwgbXVubmFyaS5vei5hdSAoUGFjaWZpYyBS aW0pLCBkcy5pbnRlcm5pYy5uZXQgKFVTIEVhc3QNCiAgICAgQ29hc3QpLCBv ciBmdHAuaXNpLmVkdSAoVVMgV2VzdCBDb2FzdCkuDQoNCg0KSW50cm9kdWN0 aW9uDQoNCiAgICAgVGhlIFRMUyBwcm90b2NvbCBbVExTXSAoZm9ybWVybHkg a25vd24gYXMgU1NMKSBwcm92aWRlcyBhIHdheSB0bw0KICAgICBzZWN1cmUg YSBjb25uZWN0aW9uIGZyb20gdGFtcGVyaW5nIGFuZCBldmVzZHJvcHBpbmcu ICBPYnZpb3VzbHksDQogICAgIHN1Y2ggc2VjdXJpdHkgaXMgZGVzaXJhYmxl IGZvciBJTUFQIFtJTUFQNF0gYW5kIFBPUCBbUE9QM10uDQogICAgIEFsdGhv dWdoIGFkdmFuY2VkIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgW0lNQVAt QVVUSCwgUE9QLUFVVEhdDQogICAgIGNhbiBwcm92aWRlIHRoaXMgc2Vydmlj ZSB3aXRoIGxlc3MgY29tcGxleGl0eSB0aGFuIFRMUywgVExTIGlzDQogICAg IHVzZWZ1bCBpbiBjb21iaW5hdGlvbiB3aXRoIHBsYWludGV4dCBwYXNzd29y ZCBsb2dpbnMgYW5kIG90aGVyDQogICAgIHNpbXBsZSBtZWNoYW5pc21zIGFz IGl0IGRvZXNuJ3QgcmVxdWlyZSBhIHNpdGUgdG8gdXBncmFkZSBpdHMNCiAg ICAgYXV0aGVudGljYXRpb24gZGF0YWJhc2UuDQoNCiAgICAgVGhlIGNvbW1v biBwcmFjdGljZSBvZiB1c2luZyBhIHNlcGFyYXRlIHBvcnQgZm9yIGEgc2Vj dXJlIHZlcnNpb24NCiAgICAgb2YgZWFjaCBwcm90b2NvbCBoYXMgYSBudW1i ZXIgb2YgZGlzYWR2YW50YWdlcyBpbiB0aGUgSU1BUCBbSU1BUDRdDQogICAg IGFuZCBQT1AgW1BPUDNdIGVudmlyb25tZW50LiAgUmF0aGVyIHRoYW4gdXNp bmcgdGhlIGJlc3Qgc2VjdXJpdHkNCiAgICAgYXZhaWxhYmxlLCBpdCBtZWFu cyB0aGF0IGNsaWVudHMgaGF2ZSB0byBiZSBleHBsaWNpdGx5IGNvbmZpZ3Vy ZWQNCiAgICAgdG8gdXNlIHRoZSBzZXBhcmF0ZSBzZWN1cmUgcG9ydCBvciBz dWZmZXIgdGhlIHBlcmZvcm1hbmNlIGxvc3Mgb2YNCiAgICAgcHJvYmluZyBm b3IgYWN0aXZlIHBvcnRzLiAgRm9yIElNQVAsIHRoaXMgaXMgZXZlbiBtb3Jl IHNlcmlvdXMgYXMNCiAgICAgaXQgd291bGQgcmVxdWlyZSB0aGUgZGVmaW5p dGlvbiBvZiBhIG5ldyBVUkwgc2NoZW1lIHdoaWNoIHdvdWxkDQogICAgIHJl cXVpcmUgc3VwcG9ydCBmb3IgVExTIGluIG9yZGVyIHRvIGdhaW4gYWNjZXNz Lg0KDQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklu dGVybmV0IERyYWZ0ICAgUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9QMyBDb25u ZWN0aW9ucyAgICAgICBBdWd1c3QgMTk5Nw0KDQoNCiAgICAgVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgZXh0ZW5zaW9ucyB0byBJTUFQNCBhbmQgUE9Q MyB3aGljaA0KICAgICBhY3RpdmF0ZSBUTFMuICBJdCBkZWZpbmVzIGEgc2V0 IG9mIHNlcnZlciBzZWN1cml0eSBwb2xpY3kgcmVzcG9uc2UNCiAgICAgY29k ZXMgZm9yIHVzZSB3aXRoIElNQVA0LCBhbmQgZXh0ZW5kcyBQT1AzIHRvIHBl cm1pdCBzdWNoIHJlc3BvbnNlDQogICAgIGNvZGVzLiAgVGhlIHJlc3BvbnNl IGNvZGVzIE1BWSBiZSB1c2VkIGluZGVwZW5kZW50bHkgb2YgdGhlIFRMUw0K ICAgICBleHRlbnNpb24uDQoNCg0KMC4gT3BlbiBJc3N1ZXMNCg0KICAgICAx LiBUaGUgY2lwaGVyIHN1aXRlIHJlcXVpcmVtZW50IGlzIGluY2x1ZGVkIHRv IG1lZXQgdGhlIGRlY2lzaW9ucw0KICAgICBtYWRlIGF0IHRoZSBNdW5pY2gg YW5kIERhbnZlcnMgSUVURiBtZWV0aW5ncy4gIFRoZSBhZGRpdGlvbmFsIHRl eHQNCiAgICAgYWJvdXQgZXhwb3J0YWJsZSBjaXBoZXJzIGlzIG15IGludmVu dGlvbiB0byBob3BlZnVsbHkgaW1wcm92ZQ0KICAgICBpbnRlcm9wZXJhYmls aXR5LiAgQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCiAgICAgMi4gU2hvdWxk IEkgZXhwbGljaXRseSByZXZva2UgcmVnaXN0cmF0aW9uIG9mIHRoZSBJTUFQ K1NTTCBwb3J0Pw0KICAgICBJJ20gbm90IGluY2xpbmVkIHRvIGRvIHNvIGFz IHRoaXMgaXNuJ3QgYXMgc2VyaW91cyBhIGRlc2lnbiBmbGF3IGFzDQogICAg IHRoZSBTTVRQK1NTTCBwb3J0LCBhbmQgdGhlcmUgYXJlIGFscmVhZHkgZGVw bG95ZWQgSU1BUCtTU0wNCiAgICAgaW1wbGVtZW50YXRpb25zLg0KDQogICAg IDMuIEFueSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBJIG1pc3NlZD8NCg0K DQoxLiBDb252ZW50aW9ucyBVc2VkIGluIHRoaXMgRG9jdW1lbnQNCg0KICAg ICBUaGUga2V5IHdvcmRzICJSRVFVSVJFRCIsICJNVVNUIiwgIk1VU1QgTk9U IiwgIlNIT1VMRCIsICJTSE9VTEQNCiAgICAgTk9UIiwgYW5kICJNQVkiIGlu IHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZA0KICAgICBpbiAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMiDQogICAgIFtLRVlXT1JEU10u DQoNCiAgICAgRm9ybWFsIHN5bnRheCBpcyBkZWZpbmVkIHVzaW5nIEFCTkYg W0FCTkZdLg0KDQogICAgIEluIGV4YW1wbGVzLCAiQzoiIGFuZCAiUzoiIGlu ZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNCiAgICAgc2Vy dmVyIHJlc3BlY3RpdmVseS4NCg0KDQoyLiBJTUFQNCBTVEFSVFRMUyBleHRl bnNpb24NCg0KICAgICBXaGVuIHRoZSBUTFMgZXh0ZW5zaW9uIGlzIHByZXNl bnQgaW4gSU1BUDQsICJTVEFSVFRMUyIgaXMgbGlzdGVkIGFzDQogICAgIGEg Y2FwYWJpbGl0eSBpbiByZXNwb25zZSB0byB0aGUgQ0FQQUJJTElUWSBjb21t YW5kLiAgVGhpcyBleHRlbnNpb24NCiAgICAgYWRkcyBhIHNpbmdsZSBjb21t YW5kLCAiU1RBUlRUTFMiIHRvIHRoZSBJTUFQNCBwcm90b2NvbCB3aGljaCBp cw0KICAgICB1c2VkIHRvIGJlZ2luIGEgVExTIG5lZ290aWF0aW9uLg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0N CgwNCkludGVybmV0IERyYWZ0ICAgUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9Q MyBDb25uZWN0aW9ucyAgICAgICBBdWd1c3QgMTk5Nw0KDQoNCjIuMS4gU1RB UlRUTFMgQ29tbWFuZA0KDQogICBBcmd1bWVudHM6ICBub25lDQoNCiAgIFJl c3BvbnNlczogIG5vIHNwZWNpZmljIHJlc3BvbnNlcyBmb3IgdGhpcyBjb21t YW5kDQoNCiAgIFJlc3VsdDogICAgIE9LIC0gYmVnaW4gVExTIG5lZ290aWF0 aW9uDQogICAgICAgICAgICAgICBOTyAtIHNlY3VyaXR5IGxheWVyIGFscmVh ZHkgYWN0aXZlDQogICAgICAgICAgICAgICBCQUQgLSBjb21tYW5kIHVua25v d24gb3IgYXJndW1lbnRzIGludmFsaWQNCg0KICAgICAgQSBUTFMgbmVnb3Rp YXRpb24gYmVnaW5zIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBDUkxGIGF0IHRo ZSBlbmQgb2YNCiAgICAgIHRoZSB0YWdnZWQgT0sgcmVzcG9uc2UgZnJvbSB0 aGUgc2VydmVyLiAgVGhlIFNUQVJUVExTIGNvbW1hbmQgTUFZDQogICAgICBi ZSB1c2VkIGluIGFueSBzdGF0ZS4gIEhvd2V2ZXIsIGEgTk8gcmVzcG9uc2Ug TUFZIHJlc3VsdCBpZiBhDQogICAgICBzZWN1cml0eSBsYXllciBpcyBhbHJl YWR5IGFjdGl2ZS4gIE9uY2UgYSBjbGllbnQgaXNzdWVzIGEgU1RBUlRUTFMN CiAgICAgIGNvbW1hbmQsIGl0IE1VU1QgTk9UIGlzc3VlIGZ1cnRoZXIgY29t bWFuZHMgdW50aWwgYSBzZXJ2ZXINCiAgICAgIHJlc3BvbnNlIGlzIHNlZW4u DQoNCiAgICAgIElmIFNUQVJUVExTIGlzIGlzc3VlZCBpbiBub24tYXV0aGVu dGljYXRlZCBzdGF0ZSwgdGhlIHNlcnZlcg0KICAgICAgcmVtYWlucyBpbiBu b24tYXV0aGVudGljYXRlZCBzdGF0ZSwgZXZlbiBpZiBjbGllbnQgY3JlZGVu dGlhbHMgYXJlDQogICAgICBzdXBwbGllZCBkdXJpbmcgdGhlIFRMUyBuZWdv dGlhdGlvbi4gIFRoZSBTQVNMIFtTQVNMXSBFWFRFUk5BTA0KICAgICAgbWVj aGFuaXNtIE1BWSBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBvbmNlIFRMUyBj bGllbnQgY3JlZGVudGlhbHMNCiAgICAgIGFyZSBzdWNjZXNzZnVsbHkgZXhj aGFuZ2VkLCBidXQgc2VydmVycyBzdXBwb3J0aW5nIHRoZSBTVEFSVFRMUw0K ICAgICAgY29tbWFuZCBhcmUgbm90IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhl IEVYVEVSTkFMIG1lY2hhbmlzbS4NCg0KICAgICAgU3VwcG9ydCBmb3IgdGhl IFRMUyBtZWNoYW5pc20gVExTX0RIRV9EU1NfV0lUSF8zREVTX0VERV9DQkNf U0hBIGlzDQogICAgICBSRVFVSVJFRCBieSBhbGwgSU1BUCBzb2Z0d2FyZSBp bXBsZW1lbnRpbmcgdGhpcyBleHRlbnNpb24uDQogICAgICBJbXBsZW1lbnRh dGlvbnMgTVVTVCBOT1QgYXNzdW1lIGFueSBvdGhlciBjaXBoZXIgc3VpdGUg aXMgcHJlc2VudC4NCiAgICAgIFVuZm9ydHVuYXRlbHksIGl0IGlzIHBvc3Np YmxlIHRoYXQgZHVlIHRvIGNlcnRhaW4gZ292ZXJubWVudA0KICAgICAgZXhw b3J0IHJlc3RyaWN0aW9ucyBzb21lIG5vbi1jb21wbGlhbnQgdmVyc2lvbnMg b2YgdGhpcyBleHRlbnNpb24NCiAgICAgIGNvdWxkIGJlIGRlcGxveWVkLiAg SW1wbGVtZW50YXRpb25zIHdpc2hpbmcgdG8gaW50ZXJvcGVyYXRlIHdpdGgN CiAgICAgIHN1Y2ggbm9uLWNvbXBsaWFudCB2ZXJzaW9ucyBNQVkgb2ZmZXIg dGhlDQogICAgICBUTFNfREhFX0RTU19FWFBPUlRfV0lUSF9ERVM0MF9DQkNf U0hBIG1lY2hhbmlzbS4gIEhvd2V2ZXIsIHNpbmNlDQogICAgICA0MCBiaXQg Y2lwaGVycyBhcmUga25vd24gdG8gYmUgdnVsbmVyYWJsZSB0byBhdHRhY2sg YnkgY3VycmVudA0KICAgICAgdGVjaG5vbG9neSwgYW55IGNsaWVudCB3aGlj aCBhY3RpdmVzIGEgNDAgYml0IGNpcGhlciBNVVNUIE5PVA0KICAgICAgaW5k aWNhdGUgdG8gdGhlIHVzZXIgdGhhdCB0aGUgY29ubmVjdGlvbiBpcyBzZWN1 cmUgZnJvbQ0KICAgICAgZXZlc2Ryb3BwaW5nLg0KDQogICAgICBUaGUgZm9y bWFsIHN5bnRheCBmb3IgSU1BUDQgaXMgYW1lbmRlZCBhcyBmb2xsb3dzOg0K DQogICAgICAgIGNvbW1hbmRfYW55ICAgPS8gICJTVEFSVFRMUyINCg0KICAg RXhhbXBsZTogICAgQzogYTAwMSBDQVBBQklMSVRZDQogICAgICAgICAgICAg ICBTOiAqIENBUEFCSUxJVFkgSU1BUDRyZXYxIFNUQVJUVExTDQogICAgICAg ICAgICAgICBTOiBhMDAxIE9LIENBUEFCSUxJVFkgY29tcGxldGVkDQogICAg ICAgICAgICAgICBDOiBhMDAyIFNUQVJUVExTDQogICAgICAgICAgICAgICBT OiBhMDAyIE9LIEJlZ2luIFRMUyBuZWdvdGlhdGlvbiBub3cNCiAgICAgICAg ICAgICAgIDxUTFMgbmVnb3RhdGlvbiBiZWdpbnMsIGZ1dGhlciBjb21tYW5k cyBzZW50IHVuZGVyIFRMUyBsYXllcj4NCiAgICAgICAgICAgICAgIEM6IGEw MDMgTE9HSU4gam9lIHBhc3N3b3JkDQoNCg0KDQpOZXdtYW4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgM10NCgwNCkludGVybmV0IERyYWZ0ICAgUHJvdGVjdGluZyBJ TUFQNCBhbmQgUE9QMyBDb25uZWN0aW9ucyAgICAgICBBdWd1c3QgMTk5Nw0K DQoNCiAgICAgICAgICAgICAgIFM6IGEwMDMgT0sgTE9HSU4gY29tcGxldGVk DQoNCjMuIE5ldyBJTUFQNCByZXNwb25zZSBjb2Rlcw0KDQogICAgICBUaGlz IHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aHJlZSBuZXcgSU1BUDQgcmVzcG9u c2UgY29kZXMgd2hpY2gNCiAgICAgIE1BWSBiZSB1c2VkIHRvIGNvbW11bmlj YXRlIHNlcnZlciBzZWN1cml0eSBwb2xpY3kgdG8gdGhlIGNsaWVudC4NCiAg ICAgIFRoZXNlIE1BWSBiZSBpbXBsZW1lbnRlZCBpbmRlcGVuZGVudGx5IG9m IHRoZSBTVEFSVFRMUyBjb21tYW5kLg0KDQoNCiAgICAgIEVOQ1JZUFQtTkVF REVEIFRoaXMgb2NjdXJzIG9uIGEgdGFnZ2VkIE5PIHJlc3BvbnNlIHRvIGFu DQogICAgICAgICAgICAgICAgICAgICBBVVRIRU5USUNBVEUgb3IgTE9HSU4g Y29tbWFuZCBhbmQgaW5kaWNhdGVzIHRoYXQNCiAgICAgICAgICAgICAgICAg ICAgIHRoZSByZXF1ZXN0ZWQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlz IG9ubHkNCiAgICAgICAgICAgICAgICAgICAgIHBlcm1pdHRlZCB1bmRlcm5l YXRoIGEgc2VjdXJpdHkgbGF5ZXIuICBUaGUgY2xpZW50DQogICAgICAgICAg ICAgICAgICAgICBNQVkgdGhlbiBpc3N1ZSB0aGUgU1RBUlRUTFMgY29tbWFu ZCBhbmQgcmVwZWF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgc2FtZSBB VVRIRU5USUNBVEUgb3IgTE9HSU4gY29tbWFuZCwgb3IgdHJ5IGFuDQogICAg ICAgICAgICAgICAgICAgICBBVVRIRU5USUNBVEUgY29tbWFuZCB3aXRoIGEg c3Ryb25nZXIgbWVjaGFuaXNtLg0KICAgICAgICAgICAgICAgICAgICAgVGhl IGNsaWVudCBTSE9VTEQgcmVjb3JkIHRoZSBmYWN0IHRoYXQgZW5jcnlwdGlv bg0KICAgICAgICAgICAgICAgICAgICAgaXMgbmVlZGVkIGZvciB0aGF0IHVz ZXIsIHNlcnZlciBhbmQgbWVjaGFuaXNtDQogICAgICAgICAgICAgICAgICAg ICBjb21iaW5hdGlvbi4NCg0KICAgICAgQVVUSC1UT08tV0VBSyAgVGhpcyBv Y2N1cnMgb24gYSB0YWdnZWQgTk8gcmVzcG9uc2UgdG8gYW4NCiAgICAgICAg ICAgICAgICAgICAgIEFVVEhFTlRJQ0FURSBvciBMT0dJTiBjb21tYW5kIGFu ZCBpbmRpY2F0ZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgdGhlIG1l Y2hhbmlzbSBpcyB0b28gd2VhayBhbmQgaXMgbm8gbG9uZ2VyDQogICAgICAg ICAgICAgICAgICAgICBwZXJtaXR0ZWQgZm9yIHRoYXQgdXNlciBieSBzaXRl IHBvbGljeS4gIFRoaXMNCiAgICAgICAgICAgICAgICAgICAgIGFsbG93cyBh IG1lY2hhbmlzbSB0byBiZSBkaXNhYmxlZCBvbiBhIHBlci11c2VyDQogICAg ICAgICAgICAgICAgICAgICByYXRoZXIgdGhhbiBhIHBlci1zZXJ2ZXIgbGV2 ZWwgd2hpY2ggaXMgdXNlZnVsIGlmDQogICAgICAgICAgICAgICAgICAgICBk aWZmZXJlbnQgdXNlcnMgaGF2ZSBkaWZmZXJlbnQgc2VjdXJpdHkNCiAgICAg ICAgICAgICAgICAgICAgIHJlcXVpcmVtZW50cyBvciBmb3IgdHJhbnNpdGlv bmluZyBmcm9tIHBsYWludGV4dA0KICAgICAgICAgICAgICAgICAgICAgTE9H SU4gdG8gYSBtb3JlIHNlY3VyZSBtZWNoYW5pc20uICBUaGUgY2xpZW50DQog ICAgICAgICAgICAgICAgICAgICBTSE9VTEQgcmVjb3JkIHRoZSBmYWN0IHRo YXQgdGhlIHVzZXIsIHNlcnZlciBhbmQNCiAgICAgICAgICAgICAgICAgICAg IG1lY2hhbmlzbSBjb21iaW5hdGlvbiBpcyBubyBsb25nZXIgcGVybWl0dGVk Lg0KDQogICAgICBUUkFOU0lUSU9OLU5FRURFRA0KICAgICAgICAgICAgICAg ICAgICAgVGhpcyBvY2N1cnMgb24gYSB0YWdnZWQgTk8gcmVzcG9uc2UgdG8g YW4NCiAgICAgICAgICAgICAgICAgICAgIEFVVEhFTlRJQ0FURSBjb21tYW5k LiAgSXQgaW5kaWNhdGVzIHRoYXQgdGhlIHNlcnZlcg0KICAgICAgICAgICAg ICAgICAgICAgaGFzIGFuIGVudHJ5IGZvciB0aGUgc3BlY2lmaWVkIHVzZXIg aW4gYSBsZWdhY3kNCiAgICAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0 aW9uIGRhdGFiYXNlIGJ1dCBkb2VzIG5vdCB5ZXQgaGF2ZQ0KICAgICAgICAg ICAgICAgICAgICAgY3JlZGVudGlhbHMgdG8gb2ZmZXIgdGhlIHJlcXVlc3Rl ZCBtZWNoYW5pc20uICBBDQogICAgICAgICAgICAgICAgICAgICBjbGllbnQg d2hpY2ggcmVjZWl2ZXMgdGhpcyBlcnJvciBjb2RlIE1BWSBkbyBhDQogICAg ICAgICAgICAgICAgICAgICBvbmUtdGltZSBsb2dpbiB1c2luZyB0aGUgTE9H SU4gY29tbWFuZCBvciBhbm90aGVyDQogICAgICAgICAgICAgICAgICAgICBw bGFpbnRleHQgbWVjaGFuaXNtIChwcmVmZXJhYmx5IHByb3RlY3RlZCBieSB0 aGUNCiAgICAgICAgICAgICAgICAgICAgIFNUQVJUVExTIGNvbW1hbmQpIHRv IGluaXRpYWxpemUgY3JlZGVudGlhbHMgZm9yIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgcmVxdWVzdGVkIG1lY2hhbmlzbS4NCg0KDQoNCg0KDQoNCg0K DQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERy YWZ0ICAgUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9QMyBDb25uZWN0aW9ucyAg ICAgICBBdWd1c3QgMTk5Nw0KDQoNCjQuIFBPUDMgU1RBUlRUTFMgZXh0ZW5z aW9uDQoNCiAgIFRoZSBQT1AzIFNUQVJUVExTIGV4dGVuc2lvbiBhZGRzIHRo ZSBTVExTIGNvbW1hbmQgdG8gUE9QMyBzZXJ2ZXJzLg0KDQogICAgICBTVExT DQoNCiAgICAgICAgIEFyZ3VtZW50czogbm9uZQ0KDQogICAgICAgICBSZXN0 cmljdGlvbnM6DQogICAgICAgICAgICAgTUFZIGJlIGdpdmVuIGluIGFueSBz dGF0ZSwgYnV0IE1BWSBmYWlsIGlmIGEgc2VjdXJpdHkgbGF5ZXINCiAgICAg ICAgICAgICBpcyBhbHJlYWR5IGFjdGl2ZS4NCg0KICAgICAgICAgRGlzY3Vz c2lvbjoNCiAgICAgICAgICAgICBBIFRMUyBuZWdvdGlhdGlvbiBiZWdpbnMg aW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIENSTEYgYXQgdGhlDQogICAgICAgICAg ICAgZW5kIG9mIHRoZSArT0sgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLiAg QSAtRVJSIHJlc3BvbnNlDQogICAgICAgICAgICAgTUFZIHJlc3VsdCBpZiBh IHNlY3VyaXR5IGxheWVyIGlzIGFscmVhZHkgYWN0aXZlLiAgT25jZSBhDQog ICAgICAgICAgICAgY2xpZW50IGlzc3VlcyBhIFNUTFMgY29tbWFuZCwgaXQg TVVTVCBOT1QgaXNzdWUgZnVydGhlcg0KICAgICAgICAgICAgIGNvbW1hbmRz IHVudGlsIGEgc2VydmVyIHJlc3BvbnNlIGlzIHNlZW4uDQoNCiAgICAgICAg ICAgICBJZiBTVExTIGlzIGlzc3VlZCBpbiBhdXRob3JpemF0aW9uIHN0YXRl LCB0aGUgc2VydmVyDQogICAgICAgICAgICAgcmVtYWlucyBpbiBhdXRob3Jp emF0aW9uIHN0YXRlLCBldmVuIGlmIGNsaWVudCBjcmVkZW50aWFscw0KICAg ICAgICAgICAgIGFyZSBzdXBwbGllZCBkdXJpbmcgdGhlIFRMUyBuZWdvdGlh dGlvbi4gIFRoZSBBVVRIIGNvbW1hbmQNCiAgICAgICAgICAgICBbUE9QMy1B VVRIXSB3aXRoIHRoZSBFWFRFUk5BTCBtZWNoYW5pc20gW1NBU0xdIE1BWSBi ZSB1c2VkDQogICAgICAgICAgICAgdG8gYXV0aGVudGljYXRlIG9uY2UgVExT IGNsaWVudCBjcmVkZW50aWFscyBhcmUNCiAgICAgICAgICAgICBzdWNjZXNz ZnVsbHkgZXhjaGFuZ2VkLCBidXQgc2VydmVycyBzdXBwb3J0aW5nIHRoZSBT VExTDQogICAgICAgICAgICAgY29tbWFuZCBhcmUgbm90IHJlcXVpcmVkIHRv IHN1cHBvcnQgdGhlIEVYVEVSTkFMIG1lY2hhbmlzbS4NCg0KICAgICAgICAg ICAgIFN1cHBvcnQgZm9yIHRoZSBUTFMgbWVjaGFuaXNtDQogICAgICAgICAg ICAgVExTX0RIRV9EU1NfV0lUSF8zREVTX0VERV9DQkNfU0hBIGlzIFJFUVVJ UkVEIGJ5IGFsbCBQT1AzDQogICAgICAgICAgICAgc29mdHdhcmUgaW1wbGVt ZW50aW5nIHRoaXMgZXh0ZW5zaW9uLiAgSW1wbGVtZW50YXRpb25zIE1VU1QN CiAgICAgICAgICAgICBOT1QgYXNzdW1lIGFueSBvdGhlciBjaXBoZXIgc3Vp dGUgaXMgcHJlc2VudC4NCiAgICAgICAgICAgICBVbmZvcnR1bmF0ZWx5LCBp dCBpcyBwb3NzaWJsZSB0aGF0IGR1ZSB0byBjZXJ0YWluDQogICAgICAgICAg ICAgZ292ZXJubWVudCBleHBvcnQgcmVzdHJpY3Rpb25zIHNvbWUgbm9uLWNv bXBsaWFudCB2ZXJzaW9ucw0KICAgICAgICAgICAgIG9mIHRoaXMgZXh0ZW5z aW9uIGNvdWxkIGJlIGRlcGxveWVkLiAgSW1wbGVtZW50YXRpb25zDQogICAg ICAgICAgICAgd2lzaGluZyB0byBpbnRlcm9wZXJhdGUgd2l0aCBzdWNoIG5v bi1jb21wbGlhbnQgdmVyc2lvbnMNCiAgICAgICAgICAgICBNQVkgb2ZmZXIg dGhlIFRMU19ESEVfRFNTX0VYUE9SVF9XSVRIX0RFUzQwX0NCQ19TSEENCiAg ICAgICAgICAgICBtZWNoYW5pc20uICBIb3dldmVyLCBzaW5jZSA0MCBiaXQg Y2lwaGVycyBhcmUga25vd24gdG8gYmUNCiAgICAgICAgICAgICB2dWxuZXJh YmxlIHRvIGF0dGFjayBieSBjdXJyZW50IHRlY2hub2xvZ3ksIGFueSBjbGll bnQNCiAgICAgICAgICAgICB3aGljaCBhY3RpdmVzIGEgNDAgYml0IGNpcGhl ciBNVVNUIE5PVCBpbmRpY2F0ZSB0byB0aGUgdXNlcg0KICAgICAgICAgICAg IHRoYXQgdGhlIGNvbm5lY3Rpb24gaXMgc2VjdXJlIGZyb20gZXZlc2Ryb3Bw aW5nLg0KDQogICAgICAgICBQb3NzaWJsZSBSZXNwb25zZXM6DQogICAgICAg ICAgICAgK09LIC1FUlINCg0KICAgICAgICAgRXhhbXBsZXM6DQogICAgICAg ICAgICAgQzogU1RMUw0KICAgICAgICAgICAgIFM6ICtPSyBCZWdpbiBUTFMg bmVnb3RpYXRpb24NCiAgICAgICAgICAgICA8VExTIG5lZ290aWF0aW9uIGJl Z2lucz4NCg0KDQoNCk5ld21hbiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0K SW50ZXJuZXQgRHJhZnQgICBQcm90ZWN0aW5nIElNQVA0IGFuZCBQT1AzIENv bm5lY3Rpb25zICAgICAgIEF1Z3VzdCAxOTk3DQoNCg0KICAgICAgICAgICAg ICAgLi4uDQogICAgICAgICAgICAgQzogU1RMUw0KICAgICAgICAgICAgIFM6 IC1FUlIgU2VjdXJpdHkgTGF5ZXIgYWxyZWFkeSBhY3RpdmUNCg0KNS4gUE9Q MyByZXNwb25zZSBjb2RlIGV4dGVuc2lvbg0KDQogICAgIFBPUDMgaXMgY3Vy cmVudGx5IG9ubHkgY2FwYWJsZSBvZiBpbmRpY2F0aW5nIHN1Y2Nlc3Mgb3Ig ZmFpbHVyZSB0bw0KICAgICBtb3N0IGNvbW1hbmRzLiAgVW5mb3J0dW5hdGVs eSwgY2xpZW50cyBvZnRlbiBuZWVkIHRvIGtub3cgbW9yZQ0KICAgICBpbmZv cm1hdGlvbiBhYm91dCB0aGUgY2F1c2Ugb2YgYSBmYWlsdXJlIGluIG9yZGVy IHRvIGdyYWNlZnVsbHkNCiAgICAgcmVjb3Zlci4gIFRoZSBzZWN1cml0eSBw b2xpY3kgcmVzcG9uc2UgY29kZXMgZGVmaW5lZCBmb3IgSU1BUCBpbg0KICAg ICBzZWN0aW9uIDMgYXJlIGEgc3BlY2lmaWMgZXhhbXBsZSBvZiB0aGlzLg0K DQogICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBhbWVuZHMgdGhlIFBPUDMgc3Rh bmRhcmQgdG8gcGVybWl0IGFuIG9wdGlvbmFsDQogICAgIHJlc3BvbnNlIGNv ZGUsIGVuY2xvc2VkIGluIHNxdWFyZSBicmFja2V0cywgYXQgdGhlIGJlZ2lu bmluZyBvZiB0aGUNCiAgICAgaHVtYW4gcmVhZGFibGUgdGV4dCBwb3J0aW9u IG9mIGEgIitPSyIgb3IgIi1FUlIiIHJlc3BvbnNlLiAgQ2xpZW50cw0KICAg ICBzdXBwb3J0aW5nIHRoaXMgZXh0ZW5zaW9uIE1BWSByZW1vdmUgYW55IGlu Zm9ybWF0aW9uIGVuY2xvc2VkIGluDQogICAgIHNxdWFyZSBicmFja2V0cyBw cmlvciB0byBkaXNwbGF5aW5nIGh1bWFuIHJlYWRhYmxlIHRleHQgdG8gdGhl DQogICAgIHVzZXIuICBJbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIG9wZW4g c3F1YXJlIGJyYWNrZXQgIlsiIGNoYXJhY3Rlcg0KICAgICBpcyBhIHJlc3Bv bnNlIGNvZGUgd2hpY2ggaXMgaW50ZXJwcmV0ZWQgaW4gYSBjYXNlLWluc2Vu c2l0aXZlDQogICAgIGZhc2hpb24gYnkgdGhlIGNsaWVudC4NCg0KICAgICBU aGUgcmVzcG9uc2UgY29kZSBpcyBoaWVyYXJjaGljYWwsIHdpdGggYSAiLyIg c2VwYXJhdGluZyBsZXZlbHMgb2YNCiAgICAgZGV0YWlsIGFib3V0IHRoZSBl cnJvci4gIENsaWVudHMgTVVTVCBpZ25vcmUgdW5rbm93biBoaWVyYXJjaGlj YWwNCiAgICAgZGV0YWlsIGFib3V0IHRoZSByZXNwb25zZSBjb2RlLiAgVGhp cyBpcyBpbXBvcnRhbnQsIGFzIGl0IGNvdWxkIGJlDQogICAgIG5lY2Vzc2Fy eSB0byBwcm92aWRlIGZ1cnRoZXIgZGV0YWlsIGZvciByZXNwb25zZSBjb2Rl cyBpbiB0aGUNCiAgICAgZnV0dXJlLiAgRm9yIGV4YW1wbGUsIEVOQ1JZUFQt TkVFREVEL1RMUyBhbmQgRU5DUllQVC1ORUVERUQvU1NIDQogICAgIG1pZ2h0 IGluZGljYXRlIGEgc3VnZ2VzdGlvbiB0byB1c2UgdGhlIFRMUyBvciBTU0gg cHJvdG9jb2xzDQogICAgIHJlc3BlY3RpdmVseSBmb3IgZW5jcnlwdGlvbi4N Cg0KICAgICBFeGFtcGxlczoNCiAgICAgICAgIEM6IFVTRVIgbXJvc2UNCiAg ICAgICAgIFM6IC1FUlIgW0VOQ1JZUFQtTkVFREVEXSBZb3UgbmVlZCB0byBh Y3RpdmF0ZSBlbmNyeXB0aW9uIGJlZm9yZQ0KICAgICAgICAgICAgICAgICBs b2dnaW5nIGluLg0KDQoNCjUuMS4gUE9QMyByZXNwb25zZSBjb2Rlcw0KDQog ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aHJlZSBuZXcgUE9Q MyByZXNwb25zZSBjb2RlcyB3aGljaCBNQVkNCiAgICAgIGJlIHVzZWQgdG8g Y29tbXVuaWNhdGUgc2VydmVyIHNlY3VyaXR5IHBvbGljeSB0byB0aGUgY2xp ZW50Lg0KICAgICAgVGhlc2UgTUFZIGJlIGltcGxlbWVudGVkIGluZGVwZW5k ZW50bHkgb2YgdGhlIFNUQVJUVExTIGV4dGVuc2lvbi4NCg0KDQogICAgICBF TkNSWVBULU5FRURFRCBUaGlzIG9jY3VycyBvbiBhbiAtRVJSIHJlc3BvbnNl IHRvIGFuIEFVVEgsIFVTRVIgb3INCiAgICAgICAgICAgICAgICAgICAgIEFQ T1AgY29tbWFuZCBhbmQgaW5kaWNhdGVzIHRoYXQgdGhlIHJlcXVlc3RlZA0K ICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt IGlzIG9ubHkgcGVybWl0dGVkDQogICAgICAgICAgICAgICAgICAgICB1bmRl cm5lYXRoIGEgc2VjdXJpdHkgbGF5ZXIuICBUaGUgY2xpZW50IE1BWSB0aGVu DQogICAgICAgICAgICAgICAgICAgICBpc3N1ZSB0aGUgU1RMUyBjb21tYW5k IGFuZCByZXBlYXQgdGhlIHNhbWUgQVVUSCwNCiAgICAgICAgICAgICAgICAg ICAgIFVTRVIgb3IgQVBPUCBjb21tYW5kIG9yIHRyeSBhbiBBVVRIIGNvbW1h bmQgd2l0aCBhDQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0N CgwNCkludGVybmV0IERyYWZ0ICAgUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9Q MyBDb25uZWN0aW9ucyAgICAgICBBdWd1c3QgMTk5Nw0KDQoNCiAgICAgICAg ICAgICAgICAgICAgIHN0cm9uZ2VyIG1lY2hhbmlzbS4gIFRoZSBjbGllbnQg U0hPVUxEIHJlY29yZCB0aGUNCiAgICAgICAgICAgICAgICAgICAgIGZhY3Qg dGhhdCBlbmNyeXB0aW9uIGlzIG5lZWRlZCBmb3IgdGhhdCB1c2VyLA0KICAg ICAgICAgICAgICAgICAgICAgc2VydmVyIGFuZCBtZWNoYW5pc20gY29tYmlu YXRpb24uDQoNCiAgICAgIEFVVEgtVE9PLVdFQUsgIFRoaXMgb2NjdXJzIG9u IGFuIC1FUlIgcmVzcG9uc2UgdG8gYW4gQVVUSCwgVVNFUiBvcg0KICAgICAg ICAgICAgICAgICAgICAgQVBPUCBjb21tYW5kIGFuZCBpbmRpY2F0ZXMgdGhh dCB0aGUgbWVjaGFuaXNtIGlzDQogICAgICAgICAgICAgICAgICAgICB0b28g d2VhayBhbmQgaXMgbm8gbG9uZ2VyIHBlcm1pdHRlZCBmb3IgdGhhdCB1c2Vy DQogICAgICAgICAgICAgICAgICAgICBieSBzaXRlIHBvbGljeS4gIFRoaXMg YWxsb3dzIGEgbWVjaGFuaXNtIHRvIGJlDQogICAgICAgICAgICAgICAgICAg ICBkaXNhYmxlZCBvbiBhIHBlci11c2VyIHJhdGhlciB0aGFuIGEgcGVyLXNl cnZlcg0KICAgICAgICAgICAgICAgICAgICAgbGV2ZWwgd2hpY2ggaXMgdXNl ZnVsIGlmIGRpZmZlcmVudCB1c2VycyBoYXZlDQogICAgICAgICAgICAgICAg ICAgICBkaWZmZXJlbnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9yIGZvcg0K ICAgICAgICAgICAgICAgICAgICAgdHJhbnNpdGlvbmluZyBmcm9tIHBsYWlu dGV4dCBVU0VSL1BBU1MgdG8gYSBtb3JlDQogICAgICAgICAgICAgICAgICAg ICBzZWN1cmUgbWVjaGFuaXNtLiAgVGhlIGNsaWVudCBTSE9VTEQgcmVjb3Jk IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgZmFjdCB0aGF0IHRoZSB1c2Vy LCBzZXJ2ZXIgYW5kIG1lY2hhbmlzbQ0KICAgICAgICAgICAgICAgICAgICAg Y29tYmluYXRpb24gaXMgbm8gbG9uZ2VyIHBlcm1pdHRlZC4NCg0KICAgICAg VFJBTlNJVElPTi1ORUVERUQNCiAgICAgICAgICAgICAgICAgICAgIFRoaXMg b2NjdXJzIG9uIGFuIC1FUlIgcmVzcG9uc2UgdG8gYW4gQVVUSCBvciBBUE9Q DQogICAgICAgICAgICAgICAgICAgICBjb21tYW5kLiAgSXQgaW5kaWNhdGVz IHRoYXQgdGhlIHNlcnZlciBoYXMgYW4gZW50cnkNCiAgICAgICAgICAgICAg ICAgICAgIGZvciB0aGUgc3BlY2lmaWVkIHVzZXIgaW4gYSBsZWdhY3kgYXV0 aGVudGljYXRpb24NCiAgICAgICAgICAgICAgICAgICAgIGRhdGFiYXNlIGJ1 dCBkb2VzIG5vdCB5ZXQgaGF2ZSBjcmVkZW50aWFscyB0byBvZmZlcg0KICAg ICAgICAgICAgICAgICAgICAgdGhlIHJlcXVlc3RlZCBtZWNoYW5pc20uICBB IGNsaWVudCB3aGljaCByZWNlaXZlcw0KICAgICAgICAgICAgICAgICAgICAg dGhpcyBlcnJvciBjb2RlIE1BWSBkbyBhIG9uZS10aW1lIGxvZ2luIHVzaW5n IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgVVNFUi9QQVNTIGNvbW1hbmRz IG9yIGFub3RoZXIgcGxhaW50ZXh0IG1lY2hhbmlzbQ0KICAgICAgICAgICAg ICAgICAgICAgKHByZWZlcmFibHkgcHJvdGVjdGVkIGJ5IHRoZSBTVExTIGNv bW1hbmQpIHRvDQogICAgICAgICAgICAgICAgICAgICBpbml0aWFsaXplIGNy ZWRlbnRpYWxzIGZvciB0aGUgcmVxdWVzdGVkIG1lY2hhbmlzbS4NCg0KDQo2 LiBpbWFwcyBhbmQgcG9wM3MgcG9ydHMNCg0KICAgICBVc2Ugb2YgdGhlIHJl Z2lzdGVyZWQgImltYXBzIiBhbmQgInBvcDNzIiBwb3J0cyBpcyBoZXJlYnkg c3Ryb25nbHkNCiAgICAgZGlzY291cmFnZWQgYW5kIGNvbnNpZGVyZWQgbm9u LXN0YW5kYXJkIGJlaGF2aW9yLg0KDQoNCjcuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQoNCiAgICAgVGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQgb25seSBhcHBseSB0byBwcm90ZWN0aW5nDQogICAgIGEg c2luZ2xlIGNvbm5lY3Rpb24uICBNZXNzYWdlcyBhcmUgc3RpbGwgYXZhaWxh YmxlIHRvIHNlcnZlcg0KICAgICBhZG1pbmlzdHJhdG9ycyBhbmQgdXN1YWxs eSBzdWJqZWN0IHRvIGV2ZXNkcm9wcGluZywgdGFtcGVyaW5nIGFuZA0KICAg ICBmb3JnZXJ5IHdoZW4gdHJhbnNtaXR0ZWQgdGhyb3VnaCBTTVRQIG9yIE5O VFAuICBQcm90ZWN0aW5nIG1lc3NhZ2VzDQogICAgIHJlcXVpcmVzIGFuIG9i amVjdCBzZWN1cml0eSBtZWNoYW5pc20gc3VjaCBhcyBQR1AgTUlNRSBbUEdQ LU1JTUVdLg0KDQogICAgIEFuIGFjdGl2ZSBhdHRhY2tlciBmb3IgSU1BUCBj YW4gcmVtb3ZlIFNUQVJUVExTIGZyb20gdGhlIElNQVANCiAgICAgQ0FQQUJJ TElUWSBsaXN0LCBvciBjYXVzZSB0aGUgUE9QMyBTVExTIGNvbW1hbmQgdG8g ZmFpbCB3aXRoIGENCiAgICAgbWVzc2FnZSBzdWNoIGFzICItRVJSIFVua25v d24gY29tbWFuZC4iICBJbiBvcmRlciB0byBkZXRlY3Qgc3VjaCBhbg0KICAg ICBhdHRhY2ssIGNsaWVudHMgU0hPVUxEIGVpdGhlciB3YXJuIHRoZSB1c2Vy IHdoZW4gc2Vzc2lvbiBwcm90ZWN0aW9uDQogICAgIGlzIG5vdCBhY3RpdmUs IG9yIGJlIGNvbmZpZ3VyYWJsZSB0byByZWZ1c2UgdG8gcHJvY2VlZCB3aXRo b3V0IGFuDQogICAgIGFjY2VwdGFibGUgbGV2ZWwgb2Ygc2VjdXJpdHkuDQoN Cg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0 IERyYWZ0ICAgUHJvdGVjdGluZyBJTUFQNCBhbmQgUE9QMyBDb25uZWN0aW9u cyAgICAgICBBdWd1c3QgMTk5Nw0KDQoNCiAgICAgSWYgYSBjbGllbnQgdXNl cyBhIHdlYWsgbWVjaGFuaXNtIHdoaWNoIHNlbmRzIHRoZSB1c2VyIG5hbWUg YXQgdGhlDQogICAgIHNhbWUgdGltZSBhcyB0aGUgYXV0aGVudGljYXRpb24g Y3JlZGVudGlhbHMsIHN1Y2ggYXMgSU1BUDQncyBMT0dJTg0KICAgICBjb21t YW5kLCB0aGUgRU5DUllQVC1ORUVERUQgb3IgQVVUSC1UT08tV0VBSyBlcnJv ciBjb2RlcyB3aWxsIG5vdA0KICAgICBwcmV2ZW50IGV4cG9zdXJlLiAgRm9y IHRoaXMgcmVhc29uLCBjbGllbnRzIFNIT1VMRCByZWNvcmQgdGhlIGZhY3QN CiAgICAgdGhhdCB0aGF0IHVzZXIsIHNlcnZlciBhbmQgbWVjaGFuaXNtIGNv bWJpbmF0aW9uIGlzIHVuYWNjZXB0YWJsZSB0bw0KICAgICBwcmV2ZW50IGZ1 dHVyZSBleHBvc3VyZSBvciBiZSBjb25maWd1cmFibGUgdG8gdHJ5IHN0cm9u Z2VyDQogICAgIG1lY2hhbmlzbXMgb3IgYWN0aXZhdGUgZW5jcnlwdGlvbiBm aXJzdC4NCg0KICAgICBBbiBhY3RpdmUgYXR0YWNrZXIgY291bGQgY2F1c2Ug YSBib2d1cyBUUkFOU0lUSU9OLU5FRURFRCByZXNwb25zZQ0KICAgICB0byBh IHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbS4gIEZvciB0aGlz IHJlYXNvbnMsIGNsaWVudHMNCiAgICAgU0hPVUxEIGVpdGhlciBhY3RpdmF0 ZSBUTFMgcHJpb3IgdG8gYXV0aGVudGljYXRpb24gb3IgZ2V0IGV4cGxpY2l0 DQogICAgIHBlcm1pc3Npb24gZnJvbSB0aGUgdXNlciBwcmlvciB0byB1c2lu ZyBhIHBsYWludGV4dCBtZWNoYW5pc20gZm9yDQogICAgIGF1dG9tYXRlZCB0 cmFuc2l0aW9uLg0KDQogICAgIEFuIGF0dGFja2VyIG1pZ2h0IHByb2JlIGZv ciB1c2VycyBhdCBhIHNpdGUgYnkgdHJ5aW5nIGEgc3Ryb25nDQogICAgIGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3aGljaCBjb3VsZCByZXN1bHQgaW4g VFJBTlNJVElPTi1ORUVERUQNCiAgICAgZm9yIHNvbWUgdXNlcnMuICBTdHJv bmcgbWVjaGFuaXNtcyBjYW4gcHJvZ3Jlc3MgcGFydHdheSB0aHJvdWdoDQog ICAgIG5lZ290aWF0aW9uIHByaW9yIHRvIGlzc3VpbmcgdGhlIFRSQU5TSVRJ T04tTkVFREVEIGZhaWx1cmUgbWVzc2FnZQ0KICAgICBpbiBvcmRlciB0byBh dm9pZCB0aGlzIHByb2JsZW0uDQoNCiAgICAgQW4gYXR0YWNrZXIgbWlnaHQg cHJvYmUgZm9yIHVzZXJzIHVzaW5nIHRoZSBQT1AzIFVTRVIgY29tbWFuZCB0 bw0KICAgICBwcm9iZSBmb3IgQVVUSC1UT08tV0VBSyBvciBFTkNSWVBULU5F RURFRC4gIFNlcnZlciBpbXBsZW1lbnRhdGlvbnMNCiAgICAgY291bGQgdXNl IHRoZXNlIGVycm9yIGNvZGVzIGZvciB1bmtub3duIHVzZXJzIHRvIGRlZmVh dCB0aGlzDQogICAgIGF0dGFjay4gIERlbGF5aW5nIHRoZSBlcnJvciB1bnRp bCBhZnRlciB0aGUgUEFTUyBjb21tYW5kIGlzDQogICAgIHN1cHBsaWVkIHdv dWxkIHVubmVjZXNzYXJpbHkgcmV2ZWFsIGEgdXNlcidzIHBhc3N3b3JkIGFu ZCB0aHVzDQogICAgIHdvdWxkIGJlIGEgZmFyIG1vcmUgc2VyaW91cyBwcm9i bGVtIHRoYW4gcHJvYmluZyBmb3IgdXNlcnMuDQoNCiAgICAgQW4gYWN0aXZl IGF0dGFja2VyIGNhbiBhbHdheXMgY2F1c2UgYSBkb3duLW5lZ290aWF0aW9u IHRvIHRoZQ0KICAgICB3ZWFrZXN0IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bSBvciBjaXBoZXIgc3VpdGUgYXZhaWxhYmxlLiAgRm9yDQogICAgIHRoaXMg cmVhc29uLCBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBiZSBjb25maWd1cmFi bGUgdG8gcmVmdXNlIHdlYWsNCiAgICAgbWVjaGFuaXNtcyBvciBjaXBoZXIg c3VpdGVzLg0KDQoNCjguIFJlZmVyZW5jZXMNCg0KICAgICBbQUJORl0gQ3Jv Y2tlciwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVjaWZpY2F0aW9u czogQUJORiIsIHdvcmsNCiAgICAgaW4gcHJvZ3Jlc3MuDQoNCiAgICAgW0lN QUlMXSBDcm9ja2VyLCBELiwgIlN0YW5kYXJkIGZvciB0aGUgRm9ybWF0IG9m IEFycGEgSW50ZXJuZXQgVGV4dA0KICAgICBNZXNzYWdlcyIsIFJGQyA4MjIs IFVuaXZlcnNpdHkgb2YgRGVsYXdhcmUsIEF1Z3VzdCAxOTgyLg0KDQogICAg ICAgICAgPGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZjODIyLnR4dD4N Cg0KICAgICBbSU1BUDRdIENyaXNwaW4sIE0uLCAiSW50ZXJuZXQgTWVzc2Fn ZSBBY2Nlc3MgUHJvdG9jb2wgLSBWZXJzaW9uIDRyZXYxIiwNCiAgICAgUkZD IDIwNjAsIFVuaXZlcnNpdHkgb2YgV2FzaGluZ3RvbiwgRGVjZW1iZXIgMTk5 Ni4NCg0KICAgICAgICAgPGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZj MjA2MC50eHQ+DQoNCg0KDQoNCk5ld21hbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4 XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICBQcm90ZWN0aW5nIElNQVA0IGFuZCBQ T1AzIENvbm5lY3Rpb25zICAgICAgIEF1Z3VzdCAxOTk3DQoNCg0KICAgICBb SU1BUC1BVVRIXSBNeWVycywgSi4sICJJTUFQNCBBdXRoZW50aWNhdGlvbiBN ZWNoYW5pc20iLCBSRkMgMTczMSwNCiAgICAgQ2FybmVnaWUtTWVsbG9uIFVu aXZlcnNpdHksIERlY2VtYmVyIDE5OTQuDQoNCiAgICAgICAgIDxmdHA6Ly9k cy5pbnRlcm5pYy5uZXQvcmZjL3JmYzE3MzEudHh0Pg0KDQogICAgIFtLRVlX T1JEU10gQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGUgUmVxdWlyZW1lbnQNCiAgICAgTGV2ZWxzIiwgUkZDIDIxMTks IEhhcnZhcmQgVW5pdmVyc2l0eSwgTWFyY2ggMTk5Ny4NCg0KICAgICAgICAg PGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZjMjExOS50eHQ+DQoNCiAg ICAgW1BHUC1NSU1FXSBFbGtpbnMsIE0uLCAiTUlNRSBTZWN1cml0eSB3aXRo IFByZXR0eSBHb29kIFByaXZhY3kgKFBHUCkiLA0KICAgICBSRkMgMjAxNSwg VGhlIEFlcm9zcGFjZSBDb3Jwb3JhdGlvbiwgT2N0b2JlciAxOTk2Lg0KDQog ICAgICAgICAgPGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZjMjAxNS50 eHQ+DQoNCiAgICAgW1BPUDNdIE15ZXJzLCBKLiwgUm9zZSwgTS4sICJQb3N0 IE9mZmljZSBQcm90b2NvbCAtIFZlcnNpb24gMyIsIFJGQw0KICAgICAxOTM5 LCBDYXJuZWdpZSBNZWxsb24sIERvdmVyIEJlYWNoIENvbnN1bHRpbmcsIElu Yy4sIE1heSAxOTk2Lg0KDQogICAgICAgICAgICAgPGZ0cDovL2RzLmludGVy bmljLm5ldC9yZmMvcmZjMTkzOS50eHQ+DQoNCiAgICAgW1BPUC1BVVRIXSBN eWVycywgIlBPUDMgQVVUSGVudGljYXRpb24gY29tbWFuZCIsIFJGQyAxNzM0 LCBDYXJuZWdpZQ0KICAgICBNZWxsb24sIERlY2VtYmVyIDE5OTQuDQoNCiAg ICAgICAgIDxmdHA6Ly9kcy5pbnRlcm5pYy5uZXQvcmZjL3JmYzE3MzQudHh0 Pg0KDQogICAgIFtTQVNMXSBNeWVycywgIlNpbXBsZSBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wpIiwgV29yaw0KICAgICBpbiBw cm9ncmVzcy4NCg0KICAgICBbVExTXSBEaWVya3MsIEFsbGVuLCAiVGhlIFRM UyBQcm90b2NvbCBWZXJzaW9uIDEuMCIsIFdvcmsgaW4gcHJvZ3Jlc3MuDQoN Cg0KOS4gQXV0aG9yJ3MgQWRkcmVzcw0KDQogICAgIENocmlzIE5ld21hbg0K ICAgICBJbm5vc29mdCBJbnRlcm5hdGlvbmFsLCBJbmMuDQogICAgIDEwNTAg TGFrZXMgRHJpdmUNCiAgICAgV2VzdCBDb3ZpbmEsIENBIDkxNzkwIFVTQQ0K DQogICAgIEVtYWlsOiBjaHJpcy5uZXdtYW5AaW5ub3NvZnQuY29tDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug OV0NCgwNCg0K ---559023410-959030623-872710263=:2282-- From owner-ietf-apps-tls Wed Aug 27 15:05:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA01026 for ietf-apps-tls-bks; Wed, 27 Aug 1997 15:05:46 -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.7/8.7.3) with ESMTP id PAA01022 for ; Wed, 27 Aug 1997 15:05:42 -0700 (PDT) Received: from Netscape.COM (metal.mcom.com [205.217.228.164]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29188; Wed, 27 Aug 1997 15:10:45 -0700 Message-ID: <3404A575.91CF1FC4@Netscape.COM> Date: Wed, 27 Aug 1997 15:08:53 -0700 From: Mike Macgirvin Organization: Netscape Communications Corporation X-Mailer: Mozilla 4.02b8 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Chris Newman , ietf-apps-tls Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS References: Content-Type: multipart/mixed; boundary="------------105C1BB03C04FECCDB44D0EC" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------105C1BB03C04FECCDB44D0EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 2. Should I explicitly revoke registration of the IMAP+SSL port? I'm not inclined to do so as this isn't as serious a design flaw as the SMTP+SSL port, and there are already deployed IMAP+SSL implementations. Obviously I'd suggest that this wouldn't be a tremendously productive thing to do. I've heard a few arguments for maintaining a second port service even if STARTTLS is available on 143. These mostly have to do with allowing a firewall to pass certain outside users through a secure service while providing insecure connections to 143 internally. Yes, this could be solved in other ways, but perhaps not as elegantly. I don't think there's any disagreement that SMTP+TLS should be a single port solution, and that the SMTP/TLS port should be revoked or otherwise forcefully deprecated; although I think the IANA is limited to marking it "historical"). 1. The cipher suite requirement is included to meet the decisions made at the Munich and Danvers IETF meetings. The additional text about exportable ciphers is my invention to hopefully improve interoperability. Comments are welcome. --- Support for the TLS mechanism TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is REQUIRED by all IMAP software implementing this extension. Implementations MUST NOT assume any other cipher suite is present. Unfortunately, it is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to interoperate with such non-compliant versions MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is secure from evesdropping. I would argue against mandating !any! ciphers. I see this as completely a site policy or even a product issue. It is possible that I might consider TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be too weak for my needs; or that it presents a problem in certain countries in which I wish to sell products, such as France. How do we reconcile this? I laud the goal of ensuring that there is a common cipher in all implementations, but think that a response to the STARTTLS command to the effect of A001 NO [AUTH-TOO-WEAK] Cannot negotiate a mutually acceptable cipher would be a better choice - although the TLS negotiation would have determined this already; so the message might be redundant and NO is all that's required. Q: Should we indicate presence of IMAP TLS with a CAPABILITY? I could see the answer to this go either way. It would prevent clients from issuing STARTTLS on a server where it isn't implemented. One round trip, big deal - but it's an extra round trip. For POP we have no choice. The con side is that advertising a security capability isn't generally perceived as a good thing. --------------105C1BB03C04FECCDB44D0EC Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Macgirvin Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mike Macgirvin n: Macgirvin;Mike org: Netscape Communications Corporation adr: Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA email;internet: MAX@Netscape.COM title: Postmaster General tel;work: (650) 937-3798 tel;home: (650) 964-7340 note: http://people.netscape.com/max/ x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------105C1BB03C04FECCDB44D0EC-- From owner-ietf-apps-tls Wed Aug 27 16:13:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA01764 for ietf-apps-tls-bks; Wed, 27 Aug 1997 16:13:20 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA01756 for ; Wed, 27 Aug 1997 16:13:13 -0700 (PDT) Received: from eleanor.innosoft.com ("port 41543"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IMXVAYAQ9294EZRB@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 27 Aug 1997 16:18:16 PDT Date: Wed, 27 Aug 1997 16:20:12 -0700 (PDT) From: Chris Newman Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS In-reply-to: <3404A575.91CF1FC4@Netscape.COM> To: Mike Macgirvin Cc: ietf-apps-tls 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, 27 Aug 1997, Mike Macgirvin wrote: > I've heard a few arguments for maintaining a second port service even if > STARTTLS is available on 143. If you think what's in section 6 is too strong, please suggest alternate wording which we can discuss. > I would argue against mandating !any! ciphers. We have two choices: 1) Standards track with mandatory-to-implement strong Diffie-Hellman based cipher suite. 2) Not standards track. I prefer (1). The "strong" part was decided in the IETF plenary in Danvers and the "Diffie-Hellman" part was decided in the IETF plenary in Munich. The "mandatory" part comes from the IESG refusing to standardize protocols which don't interoperate. > I see this as completely a site policy or even a product issue. It's the "Internet" Engineering Task Force, not the "Intranet" Engineering Task Force or "Single-Vendor-Solution" Task Force. If it's possible to build a compliant client which can't interoperate with a compliant server, then the standard is broken. I'll also mention that the TLS spec got remanded from the IESG back to the WG because it failed to have a mandatory cipher suite. The TLS WG has three options to meet the interoperability requirement -- either mandate 3DES Diffie-Hellman, in which case I'm willing to remove the paragraph from this spec, or mandate that any use of TLS with a standards track protocol MUST have a profile including a mandatory-to-implement cipher suite. > It is possible that I might consider > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be too weak for my needs; There isn't a stronger mechanism defined, so I suspect you're making a strawman argument. > or that it > presents a problem in certain countries in which I wish to sell products, > such as France. How do we reconcile this? This issue was decided at the Danvers IETF plenary. The quality of standards isn't to be compromised by governmental whims. If a country prevents you from selling compliant software somewhere, then you need to make a special non-complaint version for that country. I'll ask you directly, given a choice between (1) or (2) above, which do you prefer? > Q: Should we indicate presence of IMAP TLS with a CAPABILITY? I could see > the answer to this go either way. It would prevent clients from issuing > STARTTLS on a server where it isn't implemented. One round trip, big deal - > but it's an extra round trip. For POP we have no choice. The con side is > that advertising a security capability isn't generally perceived as a good > thing. I don't see any practical security difference between announcing and probing. Either way, it's possible to discover if TLS is implemented prior to authenticating. I'm inclined to keep the text about announcing the "STARTTLS" capability as is, unless a security expert can explain a real advantage of probing over announcing. - Chris From owner-ietf-apps-tls Thu Aug 28 13:15:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA15882 for ietf-apps-tls-bks; Thu, 28 Aug 1997 13:15:25 -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.7/8.7.3) with ESMTP id NAA15878 for ; Thu, 28 Aug 1997 13:15:21 -0700 (PDT) Received: from Netscape.COM (metal.mcom.com [205.217.228.164]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA86; Thu, 28 Aug 1997 13:20:33 -0700 Message-ID: <3405DD21.9541F0E7@Netscape.COM> Date: Thu, 28 Aug 1997 13:18:41 -0700 From: Mike Macgirvin Organization: Netscape Communications Corporation X-Mailer: Mozilla 4.02b8 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Chris Newman CC: ietf-apps-tls Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS References: Content-Type: multipart/mixed; boundary="------------FA0841CA45E94799C2A6EE71" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------FA0841CA45E94799C2A6EE71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > We have two choices: > 1) Standards track with mandatory-to-implement strong Diffie-Hellman based > cipher suite. > 2) Not standards track. I believe that 1 is the preferable choice given the two. > I'll also mention that the TLS spec got remanded from the IESG back to the > WG because it failed to have a mandatory cipher suite. The TLS WG has > three options to meet the interoperability requirement -- either mandate > 3DES Diffie-Hellman, in which case I'm willing to remove the paragraph > from this spec, or mandate that any use of TLS with a standards track > protocol MUST have a profile including a mandatory-to-implement cipher > suite. What's the third? Anyway, I'd like to see this thrown back on TLS, and any restrictions imposed there, rather than here. I know you've tried to cover the export problem by suggesting that an implementation might try 40bit in a non-US environment; but vendors are stuck between a rock and a hard place because it is _impossible_ to be compliant to this spec overseas. I understand your dilemna, but hope you can see ours as well. Can you think of any other ways to pull the munitions issue out of the compliance requirements? > However, since > 40 bit ciphers are known to be vulnerable to attack by current > technology, any client which actives a 40 bit cipher MUST NOT > indicate to the user that the connection is secure from > evesdropping. This paragraph is likewise troubling. Obviously, we'd like to market our products as offering _some_ level of security, and 40 bit encrypted streams are significantly harder for an intruder to browse than a plaintext stream, so it *is* secure from "casual" eavesdropping. It's all a matter of degree. Rather than MUST NOT indicate this is secure, I'd prefer to see something that says MUST indicate or MUST make available an indication of the relative level of security. > 6. imaps and pop3s ports > > Use of the registered "imaps" and "pop3s" ports is hereby strongly > discouraged and considered non-standard behavior. I would leave it as just "discouraged" or leave this section out. Incidentally I was asked to draft an "experimental" or "informational" RFC covering the separate port case as an "interim technology" - but have not done so precisely to keep it from propogating. I can now see a small possibility of continuing life as a very specialized service; and there may yet be a need to define its operation in a standards forum. Let's just not slam that door yet. You've got my word that any such definition will point to this specification as the standard and acceptable way to perform IMAP/TLS; and that we otherwise intend to deprecate the second port. I believe Microsoft is committed to the same track. > > It is possible that I might consider > > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be too weak for my needs; > > There isn't a stronger mechanism defined, so I suspect you're making a > strawman argument. It may also be the case that site policy mandates a particular key escrow technology, and since D-H is the strongest mechanism available (and mandated to be available) it will always end up to be the default cypher - regardless that the company requires a _weaker_ cypher. I'm not going to try and justify this, but I'm throwing out other reasons why the mandating of specific cyphers may cause conflicts. If that's the way it's got to be, all right; but it just gives folks more reasons to go with non-standard solutions; because the "standard" solution was short-sighted and/or too heavy-handed and/or unworkable. That's what I'm trying to avoid. --------------FA0841CA45E94799C2A6EE71 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Macgirvin Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mike Macgirvin n: Macgirvin;Mike org: Netscape Communications Corporation adr: Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA email;internet: MAX@Netscape.COM title: Postmaster General tel;work: (650) 937-3798 tel;home: (650) 964-7340 note: http://people.netscape.com/max/ x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------FA0841CA45E94799C2A6EE71-- From owner-ietf-apps-tls Thu Aug 28 16:11:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA18032 for ietf-apps-tls-bks; Thu, 28 Aug 1997 16:11:56 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA18028 for ; Thu, 28 Aug 1997 16:11:51 -0700 (PDT) Received: from eleanor.innosoft.com ("port 42034"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IMZ9K9M3CC94F403@INNOSOFT.COM> for ietf-apps-tls@imc.org; Thu, 28 Aug 1997 16:17:26 PDT Date: Thu, 28 Aug 1997 16:19:22 -0700 (PDT) From: Chris Newman Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS In-reply-to: <3405DD21.9541F0E7@Netscape.COM> To: Mike Macgirvin Cc: ietf-apps-tls 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, 28 Aug 1997, Mike Macgirvin wrote: > > I'll also mention that the TLS spec got remanded from the IESG back to the > > WG because it failed to have a mandatory cipher suite. The TLS WG has > > three options to meet the interoperability requirement -- either mandate > > 3DES Diffie-Hellman, in which case I'm willing to remove the paragraph > > from this spec, or mandate that any use of TLS with a standards track > > protocol MUST have a profile including a mandatory-to-implement cipher > > suite. > > What's the third? Third option is to do an Informational RFC rather than standards track. > Anyway, I'd like to see this thrown back on TLS, and any > restrictions imposed there, rather than here. Somebody from Netscape just decided to support this on the TLS list and so far there haven't been any dissenting statements on the list. One can hope... > Can you think of any other ways to pull the munitions issue out of the > compliance requirements? Three possibilities I can see. One idea I had was to define levels of compliance -- "U.S. Export weak compliance" and "full compliance". It might just get past the IESG, but I'm doubtful as it harms interoperability in practice. Next choice would be to stack the IETF nominations committee for two years in a row with people who would oppose anyone on the IESG/IAB not willing to compromise on the issue. That would require a lot of volunteers and even then might not work--it could also have a nasty backlash and it's too late to do it this year. Final choice would be to fix government export policy. I prefer option 3 :-) > This paragraph is likewise troubling. Obviously, we'd like to market our > products as offering _some_ level of security, and 40 bit encrypted streams > are significantly harder for an intruder to browse than a plaintext stream, > so it *is* secure from "casual" eavesdropping. It's all a matter of degree. > Rather than MUST NOT indicate this is secure, I'd prefer to see something > that says MUST indicate or MUST make available an indication of the > relative level of security. Point taken. The main issue is that products which don't distinguish between 40-bit and real encryption should be declared non-compliant. It's a really bad thing to do as it results in interoperability problems and user confusion. > Incidentally I was asked to draft an "experimental" or "informational" RFC > covering the separate port case as an "interim technology" - but have not > done so precisely to keep it from propogating. I can now see a small > possibility of continuing life as a very specialized service; and there may > yet be a need to define its operation in a standards forum. Let's just not > slam that door yet. With the caveat that I will strongly oppose standardization of an imaps URL scheme, I guess I can live with this. What do others think? > It may also be the case that site policy mandates a particular key escrow > technology, and since D-H is the strongest mechanism available (and > mandated to be available) it will always end up to be the default cypher - > regardless that the company requires a _weaker_ cypher. A mandatory-to-implement mechanism is not a mandatory-to-use mechanism. That site will preferentially buy products which can be configured to require their key escrow mechanism. Ditto for sites which need faster ciphers. > If that's the > way it's got to be, all right; but it just gives folks more reasons to go > with non-standard solutions; because the "standard" solution was > short-sighted and/or too heavy-handed and/or unworkable. That's what I'm > trying to avoid. I sympathize. From owner-ietf-apps-tls Fri Aug 29 15:32:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA02544 for ietf-apps-tls-bks; Fri, 29 Aug 1997 15:32:55 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA02539 for ; Fri, 29 Aug 1997 15:32:43 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id SAA08526; Fri, 29 Aug 1997 18:38:00 -0400 (EDT) Message-Id: <199708292238.SAA08526@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mike Macgirvin cc: Chris Newman , ietf-apps-tls , moore@cs.utk.edu Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS In-reply-to: Your message of "Thu, 28 Aug 1997 13:18:41 PDT." <3405DD21.9541F0E7@Netscape.COM> Date: Fri, 29 Aug 1997 18:38:00 -0400 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > This paragraph is likewise troubling. Obviously, we'd like to market our > products as offering _some_ level of security, and 40 bit encrypted streams > are significantly harder for an intruder to browse than a plaintext stream, > so it *is* secure from "casual" eavesdropping. It's all a matter of degree. Indeed. But I'd have a hard time supporting the claim that 40 bit crypto is secure from casual eavesdropping. It's no more secure, for instance, than a poorly chosen password on UNIX if the hashed password file is world readable -- because the time required to mount a thorough dictionary attack on hashed passwords is similar to that required to BFS 40-bit RC4. And we've seen plenty of examples of the former to demonstrate that such attacks are quite feasible, even commonplace. So while I understand why netscape would like to claim that 40bit crypto is "secure" in some sense of the word, IETF will not support such a claim. Keith From owner-ietf-apps-tls Sat Aug 30 09:18:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08974 for ietf-apps-tls-bks; Sat, 30 Aug 1997 09:18:19 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08969 for ; Sat, 30 Aug 1997 09:18:15 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id LAA02766; Sat, 30 Aug 1997 11:23:05 -0500 (CDT) Received: from pax-ca4-06.ix.netcom.com(199.35.217.134) by dfw-ix12.ix.netcom.com via smap (V1.3) id sma002742; Sat Aug 30 11:22:46 1997 Message-ID: <340848D2.23CF@ix.netcom.com> Date: Sat, 30 Aug 1997 09:22:42 -0700 From: David Brownell Reply-To: db@eng.sun.com Organization: Last in, first out (LIFO) X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: Chris Newman CC: ietf-apps-tls@imc.org, jdn@eng.sun.com, db@eng.sun.com Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk A handful of comments ... as well as a "thank you for writing this!" First, I'd like an explicit statement that when the TLS connection ends, so does the IMAP4 or POP3 connection. You don't now have a STOPTLS command, which would be necessary to do that securely; and I think it's fine (and desirable!) that there be no such command. Second, fine language on the ciphers and export issues. Third, I think some language is necessary with respect to X.509 certificate profiling. Probably these five things would suffice: - A reference to the PKIX Part-1 (05) work ... overdue to publish, but almost "ready" last I heard. They seem to have finished changing the OID to use with DSS, for one very significant point!! - A requirement that the signature on DSS certificates (by the CAs) MUST be DSS signatures. (It's not sufficient just to have the certified keys be DSS, with the signature being some unspecified RSA signature variant !!) - A requirement that any IMAP4/POP3 server's use of TLS client authentication MUST support the "dss_sign" certificate type, which should be summarized to mean that it's a DSS key with a DSS signature on the key's certificate. - And something analagous to the way HTTPS now manages the binding between the host name and the certificate. Maybe even the same thing: "CN=" holds the fully qualified DNS name for the IMAP4/POP3/... server. This is needed so that at least some level of policy checking can be automated; I see no particular reason to preclude using the same cert for HTTP, IMAP4, POP3, etc. - There should be a statement, pro or con, re any requirement for additional X.509v3 certificate attributes in support of a server's ability to offer IMAP4 or POP3 service. Ideally, "con" -- clients MUST NOT reject a server certificate which is part of a currently valid certificate chain, and meets the above two requirements. But if "pro", it should describe the specific X.509v3 cert extension (ASN.1 and OID) which MUST be a critical extension enabling clients to accept this as an IMAP4 or POP3 server. Similarly, even if this is a non-critical extension. One could argue that TLS or PKIX should address this fourth set of issues, but I'd say otherwise. All of them are cert policy issues which affect interop for this application, but perhaps not for others. For example I exchanged E-Mail earlier this week with a CA vendor on that aspect of the "pure DSS cert" issue; the CA cert they use will be DSS, signed with their existing RSA root key. So many folk wouldn't be able to verify that "DSS root"; not really an issue, but if that were also true of customer DSS certs, whoops! Similarly, the "CN=" convention (for HTTPS) is currently documented only on a Netscape website, and would be needed in an HTTPS profile. It's not bad or burdensome, it's just not yet in an RFC. What's worrisome is that I've seen a bunch of X.509 extensions that seem to relate to HTTPS and SSL capabilities ... I shudder to think of the interop problems if anyone starts enforcing them. Hence my desire to head off that disaster for mailbox protocols! Finally, I wonder where one would want to put a conventional set of Diffie-Hellman parameters (modulus, exponent) that "MAY" be used by TLS servers implementing this spec. The virtue of having such a set which "MAY" be used is that to the extent they're widely used, clients can precompute their private keys, producing better TLS session setup times (one less prime search, one less modExp). Of course the idea is not to mandaate ("MUST") such parameters. There are both security and performance implications to the modulus (specifically, its size) being used. Arguably such a set of parameters should be in the TLS spec. But, it's not there now, and not looking to be. Perhaps it'd be approprate as a separate informational RFC, rather than as part of either the IETF's TLS or {IMAP4,POP3}/TLS specs. - Dave From owner-ietf-apps-tls Tue Sep 2 06:39:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA07962 for ietf-apps-tls-bks; Tue, 2 Sep 1997 06:39:05 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA07957 for ; Tue, 2 Sep 1997 06:39:01 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA27179 for ; Tue, 2 Sep 1997 09:44:38 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma027177; Tue Sep 2 09:44:33 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 JAA20987 for ; Tue, 2 Sep 1997 09:41:39 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA06558; Tue, 2 Sep 1997 09:43:38 -0400 Date: Tue, 2 Sep 1997 09:43:38 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199709021343.JAA06558@argon.ncsc.mil> To: ietf-apps-tls@imc.org Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS X-Sun-Charset: US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > From: David Brownell > > [many good points snipped ..] > > Finally, I wonder where one would want to put a conventional set > of Diffie-Hellman parameters (modulus, exponent) that "MAY" be used > by TLS servers implementing this spec. The virtue of having such a > set which "MAY" be used is that to the extent they're widely used, > clients can precompute their private keys, producing better TLS > session setup times (one less prime search, one less modExp). > Of course the idea is not to mandaate ("MUST") such parameters. > There are both security and performance implications to the modulus > (specifically, its size) being used. > > Arguably such a set of parameters should be in the TLS spec. > But, it's not there now, and not looking to be. Perhaps it'd > be approprate as a separate informational RFC, rather than as > part of either the IETF's TLS or {IMAP4,POP3}/TLS specs. If the IMAP/POP profile were to specify one or a few fixed DH parameters, it may be worthwhile referencing the exponential groups in the IPsec Oakley protocol, instead of writing up another document with different parameters. From owner-ietf-apps-tls Tue Sep 2 08:25:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA09200 for ietf-apps-tls-bks; Tue, 2 Sep 1997 08:25:01 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA09193 for ; Tue, 2 Sep 1997 08:24:57 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id KAA03070; Tue, 2 Sep 1997 10:30:25 -0500 (CDT) Received: from pax-ca25-13.ix.netcom.com(207.92.151.77) by dfw-ix12.ix.netcom.com via smap (V1.3) id sma002956; Tue Sep 2 10:28:40 1997 Message-ID: <340C309E.7790@ix.netcom.com> Date: Tue, 02 Sep 1997 08:28:30 -0700 From: David Brownell Organization: Last in, first out (LIFO) X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: "David P. Kemp" CC: ietf-apps-tls@imc.org Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS References: <199709021343.JAA06558@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk David P. Kemp wrote: > > If the IMAP/POP profile were to specify one or a few fixed DH > parameters, it may be worthwhile referencing the exponential groups in > the IPsec Oakley protocol, instead of writing up another document > with different parameters. For example, the appendices in ftp://ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt One issue with those is that they're still (!) draft documents. They're probably appropriate for implementor's guidelines at this time, but such draft references shouldn't be in a standard. That does bring out the point, however, that maybe those groups don't belong in the Oakley documents at all. They don't relate purely to IPSEC. - Dvae From owner-ietf-apps-tls Thu Sep 4 09:34:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA12068 for ietf-apps-tls-bks; Thu, 4 Sep 1997 09:34:16 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA12063 for ; Thu, 4 Sep 1997 09:34:12 -0700 (PDT) Received: from eleanor.innosoft.com ("port 44379"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IN8NP2IFFA94F9CO@INNOSOFT.COM> for ietf-apps-tls@imc.org; Thu, 4 Sep 1997 09:39:19 PDT Date: Thu, 04 Sep 1997 09:41:14 -0700 (PDT) From: Chris Newman Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS In-reply-to: <340848D2.23CF@ix.netcom.com> To: db@eng.sun.com Cc: Application Use of TLS IETF List , jdn@eng.sun.com 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 Sat, 30 Aug 1997, David Brownell wrote: > First, I'd like an explicit statement that when the TLS connection > ends, so does the IMAP4 or POP3 connection. You don't now have a > STOPTLS command, which would be necessary to do that securely; and > I think it's fine (and desirable!) that there be no such command. The TLS session layer includes an "end TLS" message which doesn't explicitly end the underlying TCP connection. If you think it should, please suggest wording. I'll note that LDAPv3 group has decided that it shouldn't end the TCP connection. > Third, I think some language is necessary with respect to X.509 > certificate profiling. Probably these five things would suffice: > > One could argue that TLS or PKIX should address this fourth set > of issues, but I'd say otherwise. All of them are cert policy > issues which affect interop for this application, but perhaps > not for others. My general inclination is that most of this stuff really belongs in the TLS specification, as part of the definition of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite. Otherwise this would have to be duplicated in every profile, which seems silly to me. Is there really a reason to use TLS without binding the certs to the hostname, or using the same algorithm to certify the key that the key uses to sign values? I'm not trying to brush these issues under the carpet because I agree they're very important, but I'd prefer these issues were addressed in one place, as the vast majority of TLS profiles will have exactly the same requirements. In addition, I know very little about X.509 certs (I'm an IMAP/POP guy -- not an OSI/ASN.1 guy), so I don't believe I could write good text to address the issues you've raised. If you would be willing to write text describing a TCP/TLS profile for the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, I'm sure we'll be able to find a home for it. If the TLS group doesn't want it, it could either be a standalone document which TLS profiles can reference or I'll drop it in this profile if people think that's a good idea. > Arguably such a set of parameters should be in the TLS spec. > But, it's not there now, and not looking to be. Perhaps it'd > be approprate as a separate informational RFC, rather than as > part of either the IETF's TLS or {IMAP4,POP3}/TLS specs. It sounds like the sort of thing that would make a useful informational RFC. In fact, why not go a bit futher and include a suggested file format for storing them. See the section on /etc/tpasswd.conf at for want seems like a reasonable proposal to me. - Chris From owner-ietf-apps-tls Thu Sep 4 20:20:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA19030 for ietf-apps-tls-bks; Thu, 4 Sep 1997 20:20:12 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id UAA19026 for ; Thu, 4 Sep 1997 20:20:09 -0700 (PDT) Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA23719; Thu, 4 Sep 1997 20:25:48 -0700 Received: from shorter.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA20329; Thu, 4 Sep 1997 20:25:45 -0700 Received: from argon.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA01896; Thu, 4 Sep 1997 20:26:05 -0700 Received: by argon.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA22039; Thu, 4 Sep 1997 20:26:04 -0700 Date: Thu, 4 Sep 1997 20:26:04 -0700 From: David.Brownell@Eng.Sun.COM (David Brownell) Message-Id: <199709050326.UAA22039@argon.eng.sun.com> To: Chris.Newman@INNOSOFT.COM Subject: Re: Any drafts for IMAP4/TLS and/or POP3/TLS Cc: ietf-apps-tls@imc.org, jdn@Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Hi Chris, > > Third, I think some language is necessary with respect to X.509 > > certificate profiling. Probably these five things would suffice: > > > > One could argue that TLS or PKIX should address this fourth set > > of issues, but I'd say otherwise. All of them are cert policy > > issues which affect interop for this application, but perhaps > > not for others. > > My general inclination is that most of this stuff really belongs in the > TLS specification, as part of the definition of the > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite. Otherwise this would have > to be duplicated in every profile, which seems silly to me. As I said originally, I think these aren't appropriate to standardize at those lower levels. But I agree that if this is done "right", it'd be easily shared by multiple protocols ... if I understand the goals and constraints correctly! > Is there > really a reason to use TLS without binding the certs to the hostname, or > using the same algorithm to certify the key that the key uses to sign > values? Yes on the first -- any class of user-to-user applications will have a CN= field that doesn't include a hostname! It's only user-to-host style applications which could adopt a CN=hostname policy. Yes also to the second, and in fact my note gave an example of a situation (with a CA) where it was desirable. Another example is found in the DH_DSS key exchange algorithm, where the key in the certificate can't be used to create digital signatures. (Similarly, DH_RSA.) One could make the general point that the trust hierarchies identified by the cert chains are completely unrelated to the technical issues of of which technologies a given CA happens to use right now ... when folk start to deploy public keys with elliptical-curve DSS variants, it'll be important to be able to meld those keys into the existing trust hierarchies rather than force creation of a new root CAs. > I'm not trying to brush these issues under the carpet because I > agree they're very important, but I'd prefer these issues were addressed > in one place, as the vast majority of TLS profiles will have exactly the > same requirements. I sympathize, but that place shouldn't be TLS. And since you want this to be a standards document, such issues either belong in an application profile for TLS, or belong in some other standards-track document. > In addition, I know very little about X.509 certs (I'm an IMAP/POP guy -- > not an OSI/ASN.1 guy), so I don't believe I could write good text to > address the issues you've raised. If you would be willing to write text > describing a TCP/TLS profile for the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA > cipher suite, I'm sure we'll be able to find a home for it. If the TLS > group doesn't want it, it could either be a standalone document which TLS > profiles can reference or I'll drop it in this profile if people think > that's a good idea. I'll see if I can find time to craft some text, aiming to be as generic as possible. When it's available we can figure out if it's realistic to have it be a separate document. In fact, I can't think of anything there that the HTTPS profile shouldn't use ... the main body of the text could say "here is the generic TLS profile", then the HTTPS spec might well be a single page document saying "it uses that profile". > > Arguably such a set of parameters should be in the TLS spec. > > But, it's not there now, and not looking to be. Perhaps it'd > > be approprate as a separate informational RFC, rather than as > > part of either the IETF's TLS or {IMAP4,POP3}/TLS specs. > > It sounds like the sort of thing that would make a useful informational > RFC. Or, put it into a "generic TLS profile" as a "MAY" reccomendation. - Dave From owner-ietf-apps-tls Tue Nov 4 11:20:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11518 for ietf-apps-tls-bks; Tue, 4 Nov 1997 11:20:09 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11514 for ; Tue, 4 Nov 1997 11:20:05 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id LAA21636 for ; Tue, 4 Nov 1997 11:17:39 -0800 (PST) Message-Id: <3.0.3.32.19971104111958.009c41d0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Nov 1997 11:19:58 -0800 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: New version of SMTP/TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk There is a new version of the SMTP/TLS draft available at . I think this covers all previous comments. If we're all happy with the draft, I'd like to send it in for IETF last call next week. Please speak up if you have any issues with this. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue Nov 4 17:31:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA17662 for ietf-apps-tls-bks; Tue, 4 Nov 1997 17:31:02 -0800 (PST) Received: from eemail.microsoft.com (eemail.microsoft.com [131.107.1.244]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA17654; Tue, 4 Nov 1997 17:30:58 -0800 (PST) Received: from ims.microsoft.com - 131.107.1.244 by eemail.microsoft.com with Microsoft SMTPSVC(5.5.1774.274.2); Tue, 4 Nov 1997 17:31:12 -0800 Received: from cassatt - 157.55.232.171 by ims.microsoft.com with Microsoft SMTPSVC(5.5.1774.274.2); Tue, 4 Nov 1997 17:31:12 -0800 From: "Jeff Stephenson" To: "Paul Hoffman / IMC" , Subject: Re: New version of SMTP/TLS Date: Tue, 4 Nov 1997 17:28:28 -0800 Message-ID: <01bce98a$1ea32be0$abe8379d@cassatt.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk -----Original Message----- From: Paul Hoffman / IMC To: Date: Tuesday, November 04, 1997 11:22 AM Subject: New version of SMTP/TLS >If we're all happy with the draft, I'd like to send it in for IETF last >call next week. Please speak up if you have any issues with this. Paul, The sooner this goes to last call the better, as far as I'm concerned. A few points I noticed in the latest draft, though: In section (5) on the STARTTLS command, in the paragraph after the error codes, it says "After receiving a 220 response to a STARTTLS command, the client SHOULD issue a STARTTLS command before giving any other SMTP commands." That looks unworkably circular to me - am I missing something? Why the change from "After receiving a 220 response to a STARTTLS command, the client MUST start the TLS procedure immediately."? Also, at the end of section (7) you say that SMTP-AUTH doesn't allow for using TLS. SASL _does_ allow for mechanisms such as TLS, though, through the EXTERNAL method. -- jeff From owner-ietf-apps-tls Tue Nov 4 17:55:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA17930 for ietf-apps-tls-bks; Tue, 4 Nov 1997 17:55:35 -0800 (PST) Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA17925; Tue, 4 Nov 1997 17:55:31 -0800 (PST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id UAA15922; Tue, 4 Nov 1997 20:54:55 -0500 (EST) Date: Tue, 4 Nov 1997 20:54:55 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: New version of SMTP/TLS To: Jeff Stephenson cc: Paul Hoffman / IMC , ietf-apps-tls@imc.org In-Reply-To: <01bce98a$1ea32be0$abe8379d@cassatt.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > -----Original Message----- > From: Paul Hoffman / IMC > To: > Date: Tuesday, November 04, 1997 11:22 AM > Subject: New version of SMTP/TLS > > > >If we're all happy with the draft, I'd like to send it in for IETF last > >call next week. Please speak up if you have any issues with this. > > > Paul, > > The sooner this goes to last call the better, as far as I'm concerned. A > few points I noticed in the latest draft, though: > > In section (5) on the STARTTLS command, in the paragraph after the error > codes, it says "After receiving a 220 response to a STARTTLS command, the > client SHOULD issue a STARTTLS command before giving any other SMTP > commands." That looks unworkably circular to me - am I missing something? > Why the change from "After receiving a 220 response to a STARTTLS command, > the client MUST start the TLS procedure immediately."? > > Also, at the end of section (7) you say that SMTP-AUTH doesn't allow for > using TLS. SASL _does_ allow for mechanisms such as TLS, though, through > the EXTERNAL method. Just to clarify...the EXTERNAL method in SASL appears useful when attempting to authorize a connection using different credentials than were used during authentication. Such distinctions might be important when coming through a firewall. Then again, maybe not ;-). If distinguishing authorization credentials from authentication credentials is deemed important, it should be addressed in this spec (perhaps referencing SASL), IMO. /msb > > -- jeff > > > From owner-ietf-apps-tls Wed Nov 5 09:20:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA02289 for ietf-apps-tls-bks; Wed, 5 Nov 1997 09:20:23 -0800 (PST) Received: from eleanor.innosoft.com (ELEANOR.INNOSOFT.COM [192.160.253.79]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA02284; Wed, 5 Nov 1997 09:20:15 -0800 (PST) Received: from localhost by eleanor.innosoft.com (PMDF V5.2-0 #13579) with SMTP id <0EJ500G02DWR5B@eleanor.innosoft.com>; Tue, 4 Nov 1997 16:41:15 -0800 (PST) Date: Tue, 04 Nov 1997 16:41:14 -0800 (PST) From: Chris Newman Subject: Re: New version of SMTP/TLS In-reply-to: <3.0.3.32.19971104111958.009c41d0@mail.imc.org> Originator-info: login-id=chris; server=thor.innosoft.com To: Paul Hoffman / IMC Cc: ietf-apps-tls@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Tue, 4 Nov 1997, Paul Hoffman / IMC wrote: > There is a new version of the SMTP/TLS draft available at > . I think this covers all > previous comments. > > If we're all happy with the draft, I'd like to send it in for IETF last > call next week. Please speak up if you have any issues with this. Some comments on the draft: You need to define what a publicly referenced SMTP server is, something like: A publicly referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet email address. Can anyone else do better? I recognize this is slightly circular due to the definition of an Internet email address. > 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. I'd prefer that the word "authenticated" be struck from this paragraph as I believe it is misleading. SSL/TLS is rarely used for client authentication and this extension can't be used for authenticated delivery of email or authenticated authorship -- it can only authenticate one hop. > 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. This needs to be worded much more carefully. Here's an attempt: A publicly referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver email locally. This rule prevents this extension from damaging the interoperability of the Internet's SMTP infrastructure. However, an SMTP server MAY refuse to accept messages for relay based on authentication supplied during the TLS negotiation. > 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. This is false. TLS is not used at all with the HTTP protocol. TLS is not SSL. You might instead say that TLS is a newer standards-track version of the non-standard SSL protocol. >A man-in-the-middle attack can be launched by deleting the "250 TLS" >response from the server. This would cause the client not to try >to start a TLS session. I suggest adding: A client can protect against this attack by recording the fact that a particular server offers TLS and generating an alarm if it does not appear in the EHLO response for a session. This SHOULD NOT result in the bouncing of email, although it MAY result in delayed processing. >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. I suggest instead: This extension is not suitable for authenticated delivery of email, nor is it suitable for authenticating the author of an email message. Another proposal [SMTP-AUTH] can be used to authenticate delivery and MIME security multiparts [MIME-SEC] can be used to authenticate the author of an email message. In addition, the [SMTP-AUTH] proposal offers simpler and more flexible options to authenticate an SMTP client and the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the STARTTLS command to provide an authorization identity. - Chris From owner-ietf-apps-tls Wed Nov 5 17:39:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA11949 for ietf-apps-tls-bks; Wed, 5 Nov 1997 17:39:06 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA11944 for ; Wed, 5 Nov 1997 17:39:02 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id RAA02677; Wed, 5 Nov 1997 17:36:29 -0800 (PST) Message-Id: <3.0.5.32.19971105173849.00a91a90@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 Nov 1997 17:38:49 -0800 To: Chris Newman From: Paul Hoffman / IMC Subject: Re: New version of SMTP/TLS Cc: ietf-apps-tls@imc.org In-Reply-To: References: <3.0.3.32.19971104111958.009c41d0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 04:41 PM 11/4/97 -0800, Chris Newman wrote: >You need to define what a publicly referenced SMTP server is, something >like: > >A publicly referenced SMTP server is an SMTP server which runs on port >25 of an Internet host listed in the MX record (or A record if an MX >record is not present) for the domain name on the right hand side of an >Internet email address. Yes, that's clumsy, but it's better that what I have (nothing) and better that what I came up with before I punted. Do others like this? >> 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. > >I'd prefer that the word "authenticated" be struck from this paragraph as >I believe it is misleading. SSL/TLS is rarely used for client >authentication and this extension can't be used for authenticated delivery >of email or authenticated authorship -- it can only authenticate one hop. While I agree that this isn't used often now, I think it will get used a lot more in the future, particularly for server-to-server authentication. I think I've made it pretty clear throughout the document that the privacy and authentication you get is for one hop only; I'd be happy to add it again, if you point out where. >> 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. > >This needs to be worded much more carefully. Here's an attempt: > >A publicly referenced SMTP server MUST NOT require use of the STARTTLS >extension in order to deliver email locally. This rule prevents this >extension from damaging the interoperability of the Internet's SMTP >infrastructure. However, an SMTP server MAY refuse to accept messages for >relay based on authentication supplied during the TLS negotiation. I like your wording, but it doesn't get all of what I had. As a different replacement, I suggest: A publicly referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents this extension from damaging the interoperability of the Internet's SMTP infrastructure. Any SMTP server MAY refuse to accept messages for relay based on authentication supplied during the TLS negotiation. An SMTP server that is not publicly referenced MAY refuse to accept any messages for relay or local delivery based on authentication supplied during the TLS negotiation. >> 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. > >This is false. TLS is not used at all with the HTTP protocol. TLS is not >SSL. You might instead say that TLS is a newer standards-track version >of the non-standard SSL protocol. That's no my understanding. I was told that TLS would become SSL v3.1. Is there a Netscapeoid in the house who can clarify this? >>A man-in-the-middle attack can be launched by deleting the "250 TLS" >>response from the server. This would cause the client not to try >>to start a TLS session. > >I suggest adding: > >A client can protect against this attack by recording the fact that a >particular server offers TLS and generating an alarm if it does not appear >in the EHLO response for a session. This SHOULD NOT result in the >bouncing of email, although it MAY result in delayed processing. I like that, but would like to reword it as: An SMTP client can protect against this attack by recording the fact that a particular SMTP server offers TLS during one session and generating an alarm if it does not appear in the EHLO response for a later session. The lack of TLS during a session SHOULD NOT result in the bouncing of email, although it could result in delayed processing. >>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. > >I suggest instead: > >This extension is not suitable for authenticated delivery of email, nor is >it suitable for authenticating the author of an email message. Again, I disagree. SMTP/TLS is suitable for authenticated delivery of email. And, if every hop including the submission hop is authenticated, it is suitable for authenticating the author of an email message, even though the draft should not be positioned this way. I think the rest of your replacement below is good: >Another >proposal [SMTP-AUTH] can be used to authenticate delivery and MIME >security multiparts [MIME-SEC] can be used to authenticate the author of >an email message. In addition, the [SMTP-AUTH] proposal offers simpler >and more flexible options to authenticate an SMTP client and the >SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the >STARTTLS command to provide an authorization identity. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu Nov 6 09:01:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA24918 for ietf-apps-tls-bks; Thu, 6 Nov 1997 09:01:38 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA24910; Thu, 6 Nov 1997 09:01:33 -0800 (PST) Received: from eleanor.innosoft.com ("port 58460"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IPOMQ5D87W9JEZA2@INNOSOFT.COM>; Thu, 6 Nov 1997 09:00:51 PST Date: Thu, 06 Nov 1997 09:03:03 -0800 (PST) From: Chris Newman Subject: Re: New version of SMTP/TLS In-reply-to: <3.0.5.32.19971105173849.00a91a90@mail.imc.org> To: Paul Hoffman / IMC 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, 5 Nov 1997, Paul Hoffman / IMC wrote: > I like your wording, but it doesn't get all of what I had. As a different > replacement, I suggest: > > A publicly referenced SMTP server MUST NOT require use of the STARTTLS > extension in order to deliver mail locally. This rule prevents this > extension from damaging the interoperability of the Internet's SMTP > infrastructure. Any SMTP server MAY refuse to accept messages for > relay based on authentication supplied during the TLS negotiation. An SMTP > server that is not publicly referenced MAY refuse to accept any messages for > relay or local delivery based on authentication supplied during the TLS > negotiation. I'm not sure the last sentence is necessary. It's implicitly permitted by the first sentence, but I'm not sure it's a good idea to encourage it by stating it explicitly. But I could live with this wording. > An SMTP client can protect against this attack by recording the fact that a > particular SMTP server offers TLS during one session and generating an alarm > if it does not appear in the EHLO response for a later session. The lack of > TLS during a session SHOULD NOT result in the bouncing of email, although > it could result in delayed processing. Sounds good to me. > Again, I disagree. SMTP/TLS is suitable for authenticated delivery of email. I disagree. There's no way to know what authentication identity was used by the initial submittor. Therefore the final receipient only knows whether or not the last hop was authenticated. The SMTP AUTH extension, on the other hand, does provide for an authentication identity parameter on MAIL FROM. This means there is an authentication identity associated with the message on final delivery, thus one can know who it really came from. SMTP/TLS doesn't allow a distinction between last hop authentication and valid authentication at every hop. Now this may be simply that we had different ideas of what "authenticated delivery" means. To me it means that I know it came from a specific user, matches site/inter-site policy and thus is suitable for use with things like the post ("p") ACL bit in the IMAP ACL extension. - Chris From owner-ietf-apps-tls Thu Nov 6 10:17:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA26379 for ietf-apps-tls-bks; Thu, 6 Nov 1997 10:17:28 -0800 (PST) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA26369; Thu, 6 Nov 1997 10:17:23 -0800 (PST) Received: from Netscape.COM (metal.mcom.com [205.217.228.164]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA23385; Thu, 6 Nov 1997 10:16:55 -0800 Message-ID: <34620996.51C5FAFC@Netscape.COM> Date: Thu, 06 Nov 1997 10:16:54 -0800 From: Mike Macgirvin Organization: Netscape Communications Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Chris Newman CC: Paul Hoffman / IMC , ietf-apps-tls@imc.org Subject: Re: New version of SMTP/TLS References: Content-Type: multipart/mixed; boundary="------------76EFA5B98AFAEB1DEE0D8EFA" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------76EFA5B98AFAEB1DEE0D8EFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> Again, I disagree. SMTP/TLS is suitable for authenticated delivery of email. > I disagree. There's no way to know what authentication identity was used > by the initial submittor. Therefore the final receipient only knows > whether or not the last hop was authenticated. The SMTP AUTH extension, > on the other hand, does provide for an authentication identity parameter > on MAIL FROM. This means there is an authentication identity associated > with the message on final delivery, thus one can know who it really came > from. SMTP/TLS doesn't allow a distinction between last hop > authentication and valid authentication at every hop. SMTP/TLS can authenticate the first (or any subsequent) hop, as could SASL. SMTP AUTH (specifically the auth identity parameter to MAIL FROM) can pass the originator info down the line, regardless of how each hop authenticates. --------------76EFA5B98AFAEB1DEE0D8EFA Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Macgirvin Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mike Macgirvin n: Macgirvin;Mike org: Netscape Communications Corporation adr: Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA email;internet: MAX@Netscape.COM title: Postmaster General tel;work: (650) 937-3798 tel;home: (650) 964-7340 note;quoted-printable:=0D=0A= http://people.netscape.com= /max/=0D=0A=
=0D=0A= =0D=0A= Only dead fish "go with the flow".=0D=0A= x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------76EFA5B98AFAEB1DEE0D8EFA-- From owner-ietf-apps-tls Thu Nov 6 10:34:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA27196 for ietf-apps-tls-bks; Thu, 6 Nov 1997 10:34:36 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA27189 for ; Thu, 6 Nov 1997 10:34:30 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id KAA05136; Thu, 6 Nov 1997 10:32:00 -0800 (PST) Message-Id: <3.0.5.32.19971106103422.00b37a70@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Nov 1997 10:34:22 -0800 To: Chris Newman From: Paul Hoffman / IMC Subject: Re: New version of SMTP/TLS Cc: ietf-apps-tls@imc.org In-Reply-To: References: <3.0.5.32.19971105173849.00a91a90@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk >I disagree. There's no way to know what authentication identity was used >by the initial submittor.... > >Now this may be simply that we had different ideas of what "authenticated >delivery" means. Yup, we had a disconnect. How about I add the following where I deleted yours: This extension is not suitable for authenticating the author of an email message unless every hop in the delivery chain, including the submission to the first SMTP server, is authenticated; it is not anticipated that this scenario will see widespread deployment. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu Nov 6 11:57:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA00139 for ietf-apps-tls-bks; Thu, 6 Nov 1997 11:57:16 -0800 (PST) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA00130; Thu, 6 Nov 1997 11:57:12 -0800 (PST) Received: from Netscape.COM (metal.mcom.com [205.217.228.164]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA23813; Thu, 6 Nov 1997 11:56:43 -0800 Message-ID: <346220FB.FD1E3F42@Netscape.COM> Date: Thu, 06 Nov 1997 11:56:43 -0800 From: Mike Macgirvin Organization: Netscape Communications Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Chris Newman , ietf-apps-tls@imc.org Subject: Re: New version of SMTP/TLS References: <3.0.5.32.19971105173849.00a91a90@mail.imc.org> <3.0.5.32.19971106103422.00b37a70@mail.imc.org> Content-Type: multipart/mixed; boundary="------------2BABBFE795ADE66EB9B537B9" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------2BABBFE795ADE66EB9B537B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd certainly be happier if you could perhaps leave out the final clause (below - "it is not anticipated..."). That's making a lot of assumptions which I for one don't entirely agree with, and is an opinion which is not technically relevant to the draft. I think I wrote in an earlier message that yes, we need the MAIL FROM: AUTH= parameter to pass along the original submittor identity, but each point in the chain _could_ be authenticated to the next using either SASL or TLS, doesn't matter. There are certain advantages to having TLS in the chain, as one can tunnel across insecure network elements. Paul Hoffman / IMC wrote: > > >I disagree. There's no way to know what authentication identity was used > >by the initial submittor.... > > > >Now this may be simply that we had different ideas of what "authenticated > >delivery" means. > > Yup, we had a disconnect. How about I add the following where I deleted yours: > > This extension is not suitable for authenticating the author of an email message > unless every hop in the delivery chain, including the submission to the first > SMTP server, is authenticated; it is not anticipated that this scenario > will see widespread deployment. > > --Paul Hoffman, Director > --Internet Mail Consortium --------------2BABBFE795ADE66EB9B537B9 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Macgirvin Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mike Macgirvin n: Macgirvin;Mike org: Netscape Communications Corporation adr: Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA email;internet: MAX@Netscape.COM title: Postmaster General tel;work: (650) 937-3798 tel;home: (650) 964-7340 note;quoted-printable:=0D=0A= http://people.netscape.com= /max/=0D=0A=
=0D=0A= =0D=0A= Only dead fish "go with the flow".=0D=0A= x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------2BABBFE795ADE66EB9B537B9-- From owner-ietf-apps-tls Tue Nov 11 18:36:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA25025 for ietf-apps-tls-bks; Tue, 11 Nov 1997 18:36:15 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA25021 for ; Tue, 11 Nov 1997 18:36:10 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA04134 for ; Tue, 11 Nov 1997 18:35:56 -0800 (PST) Received: from netscape.com ([205.217.229.208]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA19737 for ; Tue, 11 Nov 1997 18:35:54 -0800 Message-ID: <3469160C.4B013A3@netscape.com> Date: Tue, 11 Nov 1997 18:35:56 -0800 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: STARTTLS document nits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk EHLO and NOOP should be added to the set of commands which can not result in a 505/5.7.0 error. In the SMTP AUTH draft, I reused the 505 response, giving it the name "Authentication required". I want to check that this is OK with this list. From owner-ietf-apps-tls Wed Nov 12 10:06:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07792 for ietf-apps-tls-bks; Wed, 12 Nov 1997 10:06:04 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07786 for ; Wed, 12 Nov 1997 10:06:00 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id KAA21250; Wed, 12 Nov 1997 10:03:49 -0800 (PST) Message-Id: <3.0.5.32.19971112100617.00811b60@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 12 Nov 1997 10:06:17 -0800 To: jgmyers@Netscape.COM (John Myers), ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: Re: STARTTLS document nits In-Reply-To: <3469160C.4B013A3@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 06:35 PM 11/11/97 -0800, John Myers wrote: >EHLO and NOOP should be added to the set of commands which can not >result in a 505/5.7.0 error. Yup, that sounds right to me. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue Nov 18 08:15:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA18269 for ietf-apps-tls-bks; Tue, 18 Nov 1997 08:15:10 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA18263 for ; Tue, 18 Nov 1997 08:15:05 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id IAA09355 for ; Tue, 18 Nov 1997 08:13:08 -0800 (PST) Message-Id: <3.0.5.32.19971118081552.009125f0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Nov 1997 08:15:52 -0800 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: And another new version of SMTP/TLS In-Reply-To: <3.0.3.32.19971104111958.009c41d0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk There is another new version of the SMTP/TLS draft available at . I think this covers all the comments in the past few weeks on the current draft. Please look it over and let me know if there's any reason why I shouldn't turn it into the IESG for an IETF last call in the next few weeks. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Thu Dec 18 00:30:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA04679 for ietf-apps-tls-bks; Thu, 18 Dec 1997 00:30:45 -0800 (PST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA04669 for ; Thu, 18 Dec 1997 00:30:40 -0800 (PST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id DAA29092; Thu, 18 Dec 1997 03:16:25 -0500 (EST) Date: Thu, 18 Dec 1997 03:16:25 -0500 (EST) Message-Id: <199712180816.DAA29092@ns.owlseye.com> From: owl@owlseye.com To: ietf-apps-tls@imc.org Reply-To: owl@owlseye.com Subject: Is Your Web Site A Secret? Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite, Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan, Manufacturers Information Network, Net Happenings, Net Mall, Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The Information Exchange, Web 100, Web Crawler, Web Walker, Web World Internet Directory, WebVenture Hotlist, What's New, WhatUSeek, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, YelloWWWeb, Your WebScout HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl@secretwebsite.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (SE7N09) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system. Then we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===================================================================== Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye@secretwebsite.com From owner-ietf-apps-tls Fri Dec 19 07:36:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08892 for ietf-apps-tls-bks; Fri, 19 Dec 1997 07:36:14 -0800 (PST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA08879 for ; Fri, 19 Dec 1997 07:36:07 -0800 (PST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id KAA11101; Fri, 19 Dec 1997 10:22:06 -0500 (EST) Date: Fri, 19 Dec 1997 10:22:06 -0500 (EST) Message-Id: <199712191522.KAA11101@ns.owlseye.com> From: owl@owlseye.com To: ietf-apps-tls@imc.org Reply-To: owl@owlseye.com Subject: Is Your Web Site A Secret? Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite, Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan, Manufacturers Information Network, Net Happenings, Net Mall, Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The Information Exchange, Web 100, Web Crawler, Web Walker, Web World Internet Directory, WebVenture Hotlist, What's New, WhatUSeek, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, YelloWWWeb, Your WebScout HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl@secretwebsite.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (SE7N09) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system. Then we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===================================================================== Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye@secretwebsite.com From owner-ietf-apps-tls Sun Jan 4 16:57:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA07676 for ietf-apps-tls-bks; Sun, 4 Jan 1998 16:57:10 -0800 (PST) Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA07672 for ; Sun, 4 Jan 1998 16:57:06 -0800 (PST) Received: from cisco.com (syd-robo-6.cisco.com [171.68.97.233]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id UAA22345; Sun, 4 Jan 1998 20:00:02 -0500 (EST) Message-ID: <34B013D4.BF3585DE@cisco.com> Date: Sun, 04 Jan 1998 16:57:24 -0600 From: Michael Boe Organization: cisco Systems X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: [Fwd: I-D ACTION:draft-ietf-tn3270e-telnet-tls-00.txt] Content-Type: multipart/mixed; boundary="------------9661B5A970ACF9B7525A3884" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------9661B5A970ACF9B7525A3884 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI.... Internet-Drafts@ns.ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telnet TN3270 Enhancements Working Group > of the IETF. > > Title : TLS-based Telnet Security > Author(s) : M. Boe > Filename : draft-ietf-tn3270e-telnet-tls-00.txt > Pages : 14 > Date : 30-Dec-97 > > Telnet service has long been a standard Internet protocol. However, a > standard way of ensuring privacy and integrity of Telnet sessions has > been lacking. This document proposes a standard method for Telnet > servers and clients to use the Transport Layer Security (TLS) protocol. > It describes how two Telnet participants can decide whether or not to > attempt TLS negotiation, and how the two participants should process > authentication credentials exchanged as a part of TLS startup. > > Internet-Drafts are available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-tn3270e-telnet-tls-00.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt". > > NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <19971230160250.I-D@ietf.org> --------------9661B5A970ACF9B7525A3884 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: owner-tn3270e@LIST.NIH.GOV Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id KAA13141 for ; Wed, 31 Dec 1997 10:11:06 -0500 (EST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA16573; Wed, 31 Dec 1997 07:10:59 -0800 (PST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id HAA00880; Wed, 31 Dec 1997 07:10:58 -0800 (PST) Received: from list.nih.gov(165.112.130.6) by proxy3.cisco.com via smap (V2.0) id xma000844; Wed, 31 Dec 97 15:10:50 GMT Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id KAA20829; Wed, 31 Dec 1997 10:05:19 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 3645891 for TN3270E@LIST.NIH.GOV; Wed, 31 Dec 1997 10:05:16 -0500 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id JAA20499 for ; Wed, 31 Dec 1997 09:55:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA25888; Wed, 31 Dec 1997 09:55:12 -0500 (EST) Message-Id: <199712311455.JAA25888@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: tn3270e@LIST.NIH.GOV From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-tn3270e-telnet-tls-00.txt Date: Wed, 31 Dec 1997 09:55:12 -0500 Sender: owner-tn3270e@LIST.NIH.GOV --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telnet TN3270 Enhancements Working Group of the IETF. Title : TLS-based Telnet Security Author(s) : M. Boe Filename : draft-ietf-tn3270e-telnet-tls-00.txt Pages : 14 Date : 30-Dec-97 Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tn3270e-telnet-tls-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971230160250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tn3270e-telnet-tls-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971230160250.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------9661B5A970ACF9B7525A3884-- From owner-ietf-apps-tls Fri Jan 16 06:14:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA18830 for ietf-apps-tls-bks; Fri, 16 Jan 1998 06:14:41 -0800 (PST) Received: from booz-mail.bah.com (booz-mail.bah.com [156.80.5.250]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA18820 for ; Fri, 16 Jan 1998 06:14:32 -0800 (PST) Received: from bah.com (smtpnt-al1.bah.com [156.80.9.200]) by booz-mail.bah.com (8.8.8/8.7.3) with SMTP id JAA00007; Fri, 16 Jan 1998 09:18:40 -0500 (EST) Date: Fri, 16 Jan 1998 9:28 -0500 From: "Hapeman Dale" To: ietf-tls@consensus.com Cc: ietf-apps-tls@imc.org Subject: Re: TLS extension to support print-by-reference. Message-ID: <84F076D5@asq8po2.bah.com> Sender: owner-ietf-apps-tls@imc.org Precedence: bulk All, There is a mail list for discussing the use of TLS to provide security services to applications. It is at . This topic sounds like a perfect use of THAT list. The TLS protocol should not be EXTENDED to support IPP, it might be valuable as a secure transport mechanism and could therefore be USED as a tool to support IPP. From the view of TLS, there is one connection from the client to the printer and one connection from the printer to the file server. The fact that the client has to prove to the file server that it is OK for this printer to come and get this file is handled by some protocol that rides through a couple of TLS-secured pipes. Dale ---------- >From: Ran Canetti >To: ietf-tls >Subject: Re: TLS extension to support print-by-reference. >Date: Thursday, January 15, 1998 10:06PM > >Indeed, this is a special case of delegation. >Ran > >Tom Weinstein wrote: > >> >> Daniel Manchala wrote: >> > >> > Back at the Washington IETF, we had a little discussion on how TLS >> > protocol could be extended to support print-by-reference for the Internet >> > Print Protocol (IPP). I am including a typical application scenario of >> > print-by-reference. Has anyone already thought about making an extended >> > TLS protocol to support this? Is anyone working on this already? We are >> > planning to write a protocol based on this scenario. >> There are some aspects of delegation that would be better adressed by the >> PKIX working group. I'm not sure if they've thought much about the >> problem. Perhaps someone who follows PKIX more closely can fill us in? >> From owner-ietf-apps-tls Fri Jan 16 10:34:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24462 for ietf-apps-tls-bks; Fri, 16 Jan 1998 10:34:29 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA24445 for ; Fri, 16 Jan 1998 10:34:16 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA05939 for ; Fri, 16 Jan 1998 10:38:11 -0800 (PST) Received: from netscape.com ([206.222.233.75]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA11390; Fri, 16 Jan 1998 10:38:09 -0800 Message-ID: <34BFA911.91CB09C3@netscape.com> Date: Fri, 16 Jan 1998 10:38:09 -0800 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 5.0b1 [en] (X11; I; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: ietf-tls@consensus.com CC: ietf-apps-tls@imc.org Subject: Re: TLS extension to support print-by-reference. References: <84F076D5@asq8po2.bah.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Hapeman Dale wrote: > > All, > > There is a mail list for discussing the use of TLS to provide security > services to applications. It is at . This topic > sounds like a perfect use of THAT list. > > The TLS protocol should not be EXTENDED to support IPP, it might be > valuable as a secure transport mechanism and could therefore be USED as a > tool to support IPP. From the view of TLS, there is one connection from > the client to the printer and one connection from the printer to the file > server. The fact that the client has to prove to the file server that it > is OK for this printer to come and get this file is handled by some > protocol that rides through a couple of TLS-secured pipes. Not necessarily. It is not unreasonable to consider extending the TLS protocol to better support delegation. This is not a problem that is specific to IPP. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | tomw@netscape.com transcending structure. -- The Tao of Programming | From owner-ietf-apps-tls Fri Jan 30 10:17:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA26494 for ietf-apps-tls-bks; Fri, 30 Jan 1998 10:17:04 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA26490 for ; Fri, 30 Jan 1998 10:17:00 -0800 (PST) Received: from elwood.innosoft.com ("port 54905"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISZGC3EWXG9AMFOJ@INNOSOFT.COM> for ietf-apps-tls@imc.org; Fri, 30 Jan 1998 10:21:59 PST Date: Fri, 30 Jan 1998 10:24:00 -0800 (PST) From: Chris Newman Subject: draft-newman-tls-imappop-02.txt To: Application Use of TLS IETF List 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 I plan on asking that: Using TLS with IMAP4, POP3 and ACAP move to the standards track. This version includes changes to the Cipher Suite Requirements, to the discussion of the "imaps" and "pop3s" ports, adds STARTTLS for ACAP, and adds a PLAIN SASL mechanism for use with ACAP under TLS. - Chris From owner-ietf-apps-tls Fri Jan 30 10:52:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA26806 for ietf-apps-tls-bks; Fri, 30 Jan 1998 10:52:23 -0800 (PST) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA26801 for ; Fri, 30 Jan 1998 10:52:19 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by scruz.net (8.8.5/1.34) with SMTP id KAA12430 for ; Fri, 30 Jan 1998 10:57:30 -0800 (PST) Message-Id: <199801301857.KAA12430@scruz.net> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 30 Jan 1998 10:55:42 -0800 To: From: Paul Hoffman / IMC Subject: Re: draft-newman-tls-imappop-02.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk >This version includes changes to the Cipher Suite Requirements ...which I feel are not acceptable. The insertion of heavy-handed politics into this draft is inappropriate, given that no one on this list asked for them. The first paragraph of section 2 is fine; the second and third paragraphs should be removed. In the second paragraph, you mandate user interface requirements, which I think is a first for you, Chris. :-) It does not belong in a standards-track document. The third paragraph is just hyperbole, including a phrase in all capital letters for developers who can't read phrases in mixed case. The first paragraph clearly states the requirements, and that is good enough for the protocol. Please remove the junk and put out another draft that we can look at before you submit this to the IESG. , to the >discussion of the "imaps" and "pop3s" ports, adds STARTTLS for ACAP, and >adds a PLAIN SASL mechanism for use with ACAP under TLS. Another note. You have the following paragraph buried in the security section: An active attacker can always cause a down-negotiation to the weakest authentication mechanism or cipher suite available. For this reason, implementations need to be configurable to refuse weak mechanisms or cipher suites. There was a desire on this list to put that kind of wording in the normative text portion of the SMTP/TLS draft. That would be harder for you, because you'd have to put it in three times, but you should still consider it. This is the one aspect of foo/TLS that was of most interest to people on the TLS mailing list, and was probably the most carefully scrutinized during the SMTP/TLS discussion. Maybe you just got too worked up about the 40-bit stuff... --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Fri Jan 30 16:41:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA29444 for ietf-apps-tls-bks; Fri, 30 Jan 1998 16:41:37 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA29439; Fri, 30 Jan 1998 16:41:32 -0800 (PST) Received: from elwood.innosoft.com ("port 55846"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISZTQ7GXJG9AMFOJ@INNOSOFT.COM>; Fri, 30 Jan 1998 16:45:59 PST Date: Fri, 30 Jan 1998 16:47:58 -0800 (PST) From: Chris Newman Subject: Re: draft-newman-tls-imappop-02.txt In-reply-to: <199801301857.KAA12430@scruz.net> To: Paul Hoffman / IMC 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 Fri, 30 Jan 1998, Paul Hoffman / IMC wrote: > ...which I feel are not acceptable. The insertion of heavy-handed politics > into this draft is inappropriate, given that no one on this list asked > for them. I've been trying to distill all the conversation I've heard on the topic on various IETF lists I follow. It's quite possible the result was a dismal failure, so comments are welcome. > The first paragraph of section 2 is fine; the second and third paragraphs > should be removed. What do others think? > In the second paragraph, you mandate user interface requirements, which I > think is a first for you, Chris. :-) It isn't a first. A number of my documents include UI recommendations or requirements -- often in the security considerations sections. I'm always skeptical of attempts to rule certain classes of issues as out-of-scope for the IETF. I happen to think there are cases when it is a good idea to include UI requirements. Deliberately misleading a user into believing that their data is secure when it isn't certainly meets the rules in RFC 2119 by my reading. If there is rough concensus to remove that comment, I'll go along in this case, but I disagree with the general idea that UI issues are out of scope. They are often vital to correct interoperability or user access to the underlying service. > The first paragraph clearly states the requirements, and that is good enough > for the protocol. Please remove the junk and put out another draft that we can > look at before you submit this to the IESG. I'm willing to tone it down at your request, but I'll sit on it until I hear more comments. > Another note. You have the following paragraph buried in the security section: > > An active attacker can always cause a down-negotiation to the > weakest authentication mechanism or cipher suite available. For > this reason, implementations need to be configurable to refuse weak > mechanisms or cipher suites. > > There was a desire on this list to put that kind of wording in the normative > text portion of the SMTP/TLS draft. That would be harder for you, because > you'd > have to put it in three times, but you should still consider it. This is the > one aspect of foo/TLS that was of most interest to people on the TLS mailing > list, and was probably the most carefully scrutinized during the SMTP/TLS > discussion. Ok, I'll move it up front with the cipher suite requirements. - Chris From owner-ietf-apps-tls Mon Feb 9 15:38:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.8.5) id PAA00203 for ietf-apps-tls-bks; Mon, 9 Feb 1998 15:38:50 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-apps-tls@imc.imc.org using -f Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.8.5) with ESMTP id PAA00199 for ; Mon, 9 Feb 1998 15:38:46 -0800 (PST) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id SAA06659; Mon, 9 Feb 1998 18:34:06 -0500 (EST) Message-Id: <199802092334.SAA06659@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Weinstein cc: David Brownell , ietf-tls@consensus.com, moore@cs.utk.edu, ekr@terisa.com, ietf-apps-tls@imc.org Subject: Re: HTTP/TLS over a separate port draft In-reply-to: Your message of "Mon, 09 Feb 1998 14:58:24 PST." <34DF8A10.98259559@netscape.com> Date: Mon, 09 Feb 1998 18:33:57 -0500 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > Here's my reasoning, please correct me if I'm wrong. In all cases, use of > HTTP involves referencing a URL. perhaps now, but not for long. URNs, for instance, don't have hostnames. and there are good reasons why a document provider might want to resolve a URN directly into a document, rather than first providing a URL. applications based on top of HTTP, which use SRV records in DNS to indicate service locations on several different hosts, should authenticate the service, not the host. Keith From owner-ietf-apps-tls Mon Feb 9 15:36:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.8.5) id PAA00188 for ietf-apps-tls-bks; Mon, 9 Feb 1998 15:36:45 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-apps-tls@imc.imc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.5/8.8.5) with SMTP id PAA00184 for ; Mon, 9 Feb 1998 15:36:41 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA02898; Mon, 9 Feb 1998 14:27:58 -0800 Received: from shorter.eng.sun.com (shorter.Eng.Sun.COM [129.144.174.35]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07264; Mon, 9 Feb 1998 14:27:55 -0800 Received: from argon.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05693; Mon, 9 Feb 1998 14:27:54 -0800 Received: by argon.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20141; Mon, 9 Feb 1998 14:27:54 -0800 Date: Mon, 9 Feb 1998 14:27:54 -0800 From: David.Brownell@Eng.Sun.COM (David Brownell) Message-Id: <199802092227.OAA20141@argon.eng.sun.com> To: ietf-tls@consensus.com, tomw@Netscape.COM Subject: Re: HTTP/TLS over a separate port draft Cc: moore@cs.utk.edu, ekr@terisa.com, ietf-apps-tls@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Per Tom Weinstein: > This prevents an attack where Alice hijacks Bob's connection to > www.bofa.com (who's cert is signed by VeriSign) but presents her own > cert for www.badgirl.org, which has also been signed by VeriSign. ... > > From this example, it's pretty clear that the DNS name check requires > either: > a) the application protocol (HTTP) gets the cert from the TLS layer, > and then checks the name in the cert against what it was > expecting, or > b) the application protocol informs the TLS layer of the hostname it > was connecting to, and then TLS does the name check. > > It seems to me that option a) is the best way to do this, since this name > check is not appropriate for all protocols. But for some appropriate usages of the term, HTTP(S) isn't the application protocol -- it's just a request/response protocol with a fair degree of infrastructure to dance through firewalls when that's needed. In this case I'd say "web browsing" is the application, and the role of HTTPS is to be application infrastructure. The role of the PKI here is just to authenticate. The application (web browser sometimes, but not always) needs to support some kind of authorization policy. I'd be happy adopting a policy that for "host oriented services" the DNS name check SHOULD be the norm, particularly if other services adopted that policy. (LDAP/TLS, SMTP/TLS, etc.) Of course, my "personal" web server should probably have my own name there, not the name currently assigned by my ISP. - Dave From owner-ietf-apps-tls Mon Feb 9 15:51:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.8.5) id PAA00300 for ietf-apps-tls-bks; Mon, 9 Feb 1998 15:51:05 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-apps-tls@imc.imc.org using -f Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.5/8.8.5) with ESMTP id PAA00296 for ; Mon, 9 Feb 1998 15:51:00 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA16984 for ; Mon, 9 Feb 1998 14:58:25 -0800 (PST) Received: from netscape.com ([208.12.62.95]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29333; Mon, 9 Feb 1998 14:58:24 -0800 Message-ID: <34DF8A10.98259559@netscape.com> Date: Mon, 09 Feb 1998 14:58:24 -0800 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 6.2 IP22) MIME-Version: 1.0 To: David Brownell CC: ietf-tls@consensus.com, moore@cs.utk.edu, ekr@terisa.com, ietf-apps-tls@imc.org Subject: Re: HTTP/TLS over a separate port draft References: <199802092227.OAA20141@argon.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk David Brownell wrote: > > But for some appropriate usages of the term, HTTP(S) isn't the > application protocol -- it's just a request/response protocol with a > fair degree of infrastructure to dance through firewalls when that's > needed. In this case I'd say "web browsing" is the application, and > the role of HTTPS is to be application infrastructure. > > The role of the PKI here is just to authenticate. The application (web > browser sometimes, but not always) needs to support some kind of > authorization policy. I'd be happy adopting a policy that for "host > oriented services" the DNS name check SHOULD be the norm, particularly > if other services adopted that policy. (LDAP/TLS, SMTP/TLS, etc.) > > Of course, my "personal" web server should probably have my own name > there, not the name currently assigned by my ISP. Here's my reasoning, please correct me if I'm wrong. In all cases, use of HTTP involves referencing a URL. Since a hostname is part of that URL, I would say that the hostname should be verified. In any case, there's a wider problem with authenticating servers that should be addressed in any implementation, and the name check is simply a special case. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | tomw@netscape.com transcending structure. -- The Tao of Programming | From owner-ietf-apps-tls Mon Mar 9 17:10:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA29580 for ietf-apps-tls-bks; Mon, 9 Mar 1998 17:10:46 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA29576 for ; Mon, 9 Mar 1998 17:10:45 -0800 (PST) Received: from elwood.innosoft.com ("port 58153"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IUGXM3EL949BVSNZ@INNOSOFT.COM> for ietf-apps-tls@imc.org; Mon, 9 Mar 1998 17:09:11 PST Date: Mon, 09 Mar 1998 17:11:02 -0800 (PST) From: Chris Newman Subject: URLs and TLS To: Application Use of TLS IETF List 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 The current model for URLs and TLS is that a URL either requires TLS to process or effectively forbids use of TLS to process. This is obviously not desirable. As we add "STARTTLS" commands to protocols this will change to a situation where the client may use TLS if present, but the URL is silent on the issue. I believe this is the most desirable default action. However, this raises the following questions: Is it ever useful to specify in a URL that some use of TLS is required? If so, what should the options be? The IMAP and ACAP URL schemes (RFC 2192 and RFC 2244) specify an ";AUTH=" parameter on the user name to require a strong SASL mechanism. I believe this is desirable as it forces every client to support a minimal level of security policy at least for the sake of interpreting URLs. I further believe that this model is also useful for TLS. Here's an initial strawman to shoot at: If a URL includes a ";TLS=" parameter after the user name, that means TLS support is required to resolve that URL. My initial proposal for values of this parameter is as follows: anon Anonymous encryption must be used to prevent passive attacks (?) integrity Server-side authentication and integrity protection must be used privacy Server-side authentication and encryption must be used auth Server and client certs must be used to mutually authenticate via TLS (takes precedence over any ";AUTH=" parameter) and integrity protect the session. full Same as "auth", except encryption must also be used. Resolution of the URL fails if the security requirements in the URL can't be met. The client is free to use a higher level of TLS facilities than the URL specifies. I plan to update the IMAP/POP/ACAP TLS spec to amend the IMAP and ACAP URL schemes appropriately. I will coordinate with the author of the POP URL scheme. Please comment whether or not you think this is a good idea. - Chris From owner-ietf-apps-tls Mon Mar 9 17:49:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA29969 for ietf-apps-tls-bks; Mon, 9 Mar 1998 17:49:51 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA29965 for ; Mon, 9 Mar 1998 17:49:50 -0800 (PST) Message-Id: <199803100149.RAA29965@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 09 Mar 1998 17:45:05 -0800 To: Application Use of TLS IETF List From: Paul Hoffman / IMC Subject: Re: URLs and TLS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Seems OK to me, but I'd add "none" to the list. This means "TLS is not at all required". This may be trivial, but it covers all of the bases so a URL emitter can always put the "TLS=" in the URLs it creates. I'm fine without it too. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Mon Mar 9 23:58:17 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA09779 for ietf-apps-tls-bks; Mon, 9 Mar 1998 23:58:17 -0800 (PST) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA09775 for ; Mon, 9 Mar 1998 23:58:16 -0800 (PST) Received: from Netscape.COM (metal.mcom.com [205.217.228.164]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29520; Mon, 9 Mar 1998 23:56:30 -0800 Message-ID: <3504F22C.17BB8FA7@Netscape.COM> Date: Mon, 09 Mar 1998 23:56:28 -0800 From: Mike Macgirvin Organization: The Internet Company X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Chris Newman CC: Application Use of TLS IETF List , jgmyers@Netscape.COM Subject: Re: URLs and TLS References: Content-Type: multipart/mixed; boundary="------------3A5B1E314A6FA64D6F88806E" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------3A5B1E314A6FA64D6F88806E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Here's an initial strawman to shoot at: > > If a URL includes a ";TLS=" parameter after the user name, that means TLS > support is required to resolve that URL. My initial proposal for values > of this parameter is as follows: > > anon Anonymous encryption must be used to prevent passive attacks (?) > integrity Server-side authentication and integrity protection must be used > privacy Server-side authentication and encryption must be used > auth Server and client certs must be used to mutually authenticate > via TLS (takes precedence over any ";AUTH=" parameter) and > integrity protect the session. > full Same as "auth", except encryption must also be used. > > Resolution of the URL fails if the security requirements in the URL > can't be met. The client is free to use a higher level of TLS facilities > than the URL specifies. This may not be quite sufficient to adequately specify the desired policy. Perhaps an additional minimum cipher length would be useful. ;MINCIPHER= with the most commonly used values being: 128, 40 and 0. 0 (or unspecified) means whatever can be agreed on, and doesn't guarantee that any encryption will occur. No doubt this will raise calls to include the entire cipher list; which may be the only way to completely specify the connection, but I'll toss it out as a counter strawman anyway. I'd hate to saddle the URL with something like TLSCIPHERS=+rsa_rc4_128_md5,+rsa_3des_sha,+rsa_des_sha,+rsa_rc4_40_md5,+rsa_rc2_40_md5 --------------3A5B1E314A6FA64D6F88806E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Macgirvin Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mike Macgirvin n: Macgirvin;Mike org: Netscape Communications Corporation adr: Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA email;internet: MAX@Netscape.COM title: Postmaster General tel;work: (650) 937-3798 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------3A5B1E314A6FA64D6F88806E-- From owner-ietf-apps-tls Tue Mar 10 00:56:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA14442 for ietf-apps-tls-bks; Tue, 10 Mar 1998 00:56:23 -0800 (PST) Received: from services.telepost.net (services.telepost.net [207.214.27.130]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA14438 for ; Tue, 10 Mar 1998 00:56:22 -0800 (PST) Received: from frode ([193.214.115.49]) by services.telepost.net (Post.Office MTA v3.1 release PO205e ID# 103-41064U100L2S100) with SMTP id AAA294; Tue, 10 Mar 1998 00:51:03 -0800 Message-ID: <004901bd4c02$2c8d3860$3173d6c1@frode.TelePost.net> From: frodeh@telepost.net (Frode Hernes) To: "Mike Macgirvin" , "Chris Newman" Cc: "Application Use of TLS IETF List" , Subject: Re: URLs and TLS Date: Tue, 10 Mar 1998 09:54:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Hi, I cannot see that putting TLS= or MINCHIPHER= in the URL solves anything as these have to be regarded as 'hints', not as 'orders'. The URL can indicate to the browser that security should / must be used, but it will always be up to the server serving the URL to accept or not accept the access to the URL. It should always be possible to access (type into the browser) the URL without any security info and from the server get access IF a secure connection can be established, or IF the server decides to let anonymous users to enter. Frode Hernes TelePost -----Original Message----- From: Mike Macgirvin To: Chris Newman Cc: Application Use of TLS IETF List ; jgmyers@Netscape.COM Date: Tuesday, March 10, 1998 9:11 AM Subject: Re: URLs and TLS >> Here's an initial strawman to shoot at: >> >> If a URL includes a ";TLS=" parameter after the user name, that means TLS >> support is required to resolve that URL. My initial proposal for values >> of this parameter is as follows: >> >> anon Anonymous encryption must be used to prevent passive attacks (?) >> integrity Server-side authentication and integrity protection must be used >> privacy Server-side authentication and encryption must be used >> auth Server and client certs must be used to mutually authenticate >> via TLS (takes precedence over any ";AUTH=" parameter) and >> integrity protect the session. >> full Same as "auth", except encryption must also be used. >> >> Resolution of the URL fails if the security requirements in the URL >> can't be met. The client is free to use a higher level of TLS facilities >> than the URL specifies. > >This may not be quite sufficient to adequately specify the desired policy. >Perhaps an additional minimum cipher length would be useful. > > ;MINCIPHER= > > with the most commonly used values being: 128, 40 and 0. > >0 (or unspecified) means whatever can be agreed on, and doesn't guarantee >that any encryption will occur. No doubt this will raise calls to include >the entire cipher list; which may be the only way to completely specify the >connection, but I'll toss it out as a counter strawman anyway. I'd hate to >saddle the URL with something like > >TLSCIPHERS=+rsa_rc4_128_md5,+rsa_3des_sha,+rsa_des_sha,+rsa_rc4_40_md5,+rsa _rc2_40_md5 From owner-ietf-apps-tls Tue Mar 10 07:33:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA20067 for ietf-apps-tls-bks; Tue, 10 Mar 1998 07:33:59 -0800 (PST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA20063 for ; Tue, 10 Mar 1998 07:33:58 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id JAA17432; Tue, 10 Mar 1998 09:32:04 -0600 (CST) Received: from pax-ca4-02.ix.netcom.com(199.35.217.130) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma017382; Tue Mar 10 09:31:39 1998 Message-ID: <35055BC6.8765DF91@dev.null> Date: Tue, 10 Mar 1998 07:27:02 -0800 From: Not Telling Organization: Yoyoydne Systems Labs, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Chris Newman CC: Application Use of TLS IETF List Subject: Re: URLs and TLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Chris Newman wrote: > > However, this raises the following questions: Is it ever useful to specify > in a URL that some use of TLS is required? If so, what should the options > be? There's the "http://" vs "https://" level of distinction; clearly that's useful today. The "s suffix" meta-scheme for URLs _could_ be continued, even when used with a single assigned port that needs to pay extra negotiation costs (STARTTLS). Equivalently, just a ";TLS" token in URLs that don't otherwise restrict the URL syntax. (HTTP is not such a candidate!) Re options ... no utility in duplicating what TLS provides, I'd say. The URL can be tampered with, unlike the TLS handshake. From owner-ietf-apps-tls Tue Mar 10 11:24:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA22210 for ietf-apps-tls-bks; Tue, 10 Mar 1998 11:24:51 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA22205; Tue, 10 Mar 1998 11:24:50 -0800 (PST) Received: from elwood.innosoft.com ("port 58191"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IUHZSTGAQK9BVT21@INNOSOFT.COM>; Tue, 10 Mar 1998 11:22:40 PST Date: Tue, 10 Mar 1998 11:24:30 -0800 (PST) From: Chris Newman Subject: Re: URLs and TLS In-reply-to: <199803100149.RAA29965@mail.proper.com> To: Paul Hoffman / IMC Cc: Application Use of TLS IETF List 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 Mon, 9 Mar 1998, Paul Hoffman / IMC wrote: > Seems OK to me, but I'd add "none" to the list. This means "TLS is not at > all required". This may be trivial, but it covers all of the bases so a URL > emitter can always put the "TLS=" in the URLs it creates. I'm fine without > it too. "none" is what you get when you omit the ";TLS=" parameter. Having a distinct "none" value wouldn't be backwards compatible with existing URL interpretors. - Chris From owner-ietf-apps-tls Tue Mar 10 12:01:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA22534 for ietf-apps-tls-bks; Tue, 10 Mar 1998 12:01:12 -0800 (PST) Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA22529; Tue, 10 Mar 1998 12:01:10 -0800 (PST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id OAA15321; Tue, 10 Mar 1998 14:58:48 -0500 (EST) Date: Tue, 10 Mar 1998 11:58:48 -0800 (PST) From: Michael Boe Reply-To: Michael Boe Subject: Re: URLs and TLS To: Chris Newman cc: Paul Hoffman / IMC , Application Use of TLS IETF 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 Mon, 9 Mar 1998, Paul Hoffman / IMC wrote: > > Seems OK to me, but I'd add "none" to the list. This means "TLS is not at > > all required". This may be trivial, but it covers all of the bases so a > > URL emitter can always put the "TLS=" in the URLs it creates. I'm fine > > without it too. > > "none" is what you get when you omit the ";TLS=" parameter. Having a > distinct "none" value wouldn't be backwards compatible with existing URL > interpretors. Chris, I'm trying to come up to speed on these UR[LN] issues, and would greatly appreciate it if you could provide a short list of web-accessible documents that you found to be the most helpful. Book titles/ISBN#s welcome too :-). thanks, /msb From owner-ietf-apps-tls Mon Mar 16 02:16:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA10768 for ietf-apps-tls-bks; Mon, 16 Mar 1998 02:16:36 -0800 (PST) Received: from alumni.caltech.edu (alumni.caltech.edu [131.215.50.234]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA10763; Mon, 16 Mar 1998 02:16:17 -0800 (PST) Received: (from khare@localhost) by alumni.caltech.edu (8.8.3/8.7.3) id CAA18637; Mon, 16 Mar 1998 02:13:59 -0800 (PST) Date: Mon, 16 Mar 1998 02:13:59 -0800 (PST) From: Rohit Khare Message-Id: <199803161013.CAA18637@alumni.caltech.edu> To: http-wg@cuckoo.hpl.hp.com, ekr@terisa.com, treese@OpenMarket.com, phoffman@imc.org, ietf-tls@consensus.com, moore@cs.utk.edu, ietf-apps-tls@imc.org Subject: Upgrading to TLS Within HTTP Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Upgrading to TLS Within HTTP Rohit Khare, UC Irvine, March 15, 1998 _________________________________________________________________ 0. Motivation At the [1]Washington DC IETF meeting last year, the Applications Area Directors indicated they would like to see a mechanism for applying Transport Layer Security [TLS] within an [2]HTTP connection, at the same port, instead of only being able to recommend a distinct port (443) and scheme (https). The TLS working group has moved forward with an extensive draft on properly implementing https ([3]draft-ietf-tls-https-00), but there is alternate precedent in SMTP and other applications of TLS ([4]draft-hoffman-smtp-ssl, [5]draft-newman-tls-imappop-03, [6]murray-auth-ftp-ssl-00). There has already been extensive debate on the [7]http-wg , [8]ietf-tls and [9]ietf-apps-tls mailing lists about the advisability of permitting optional 'upgrades' to secure connections within the same channel, primarily focusing on the thread of man-in-the-middle attacks. Our intent here is not to engage in this debate, but merely to document a proposed mechanism for doing either with HTTP. Several applications being built upon HTTP might use this mechanism, such as the [10]Internet Printing Protocol; we look to them for implementation guidance. 1. Introduction TLS, a/k/a SSL (Secure Sockets Layer) establishes a private end-to-end connection, optionally including strong mutual authentication, using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the remainder of the connection. The latter is intended to be completely transparent. For example, there is no dependency between TLS's record markers and or certificates and HTTP/1.1's chunked encoding or authentication. The need to 'secure' running connections is not merely 'running SSL over port 80', an early challenge for firewall developers answered by Ari Luotonen's [11]ssl-tunneling-02 draft in 1995. The HTTP/1.1 spec reserves CONNECT for future use, deferring to the more recent [12]draft-luotonen-web-proxy-tunneling-00 proposal. This technique perpetuates the concept that security is indicated by a magic port number -- CONNECT establishes a generic TCP tunnel, so port number is the only way to specify the layering of TLS with HTTP (https) or with NTTP (snews). Instead, the preferred mechanism to initiate and insert TLS in an HTTP/1.1 session should be the Upgrade: header, as defined in section 14.42 of rev-03. Ideally, TLS-capable clients should add "Upgrade: TLS/1.0" to their initial request, and TLS-capable servers may reply with "101 Switching Protocol", complete the handshake, and continue with the "normal" response to the original request. However, the specification quoth: "The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection." Aside from this minor semantic difference -- invoking TLS indeed changes the existing transport-layer connection -- this is an ideal application of Upgrade. This technique overlays the TLS-request on an HTTP method; requires client-initiation, and allows servers to choose whether or not to make the switch. Like the other examples of TLS-enabled application protocols, the original session is preserved across the TLS handshake; secured communications resumes with a servers' reply. The potential for a man-in-the-middle attack (wherein the "TLS/1.0" upgrade token is stripped out) is precisely the same as for mixed http/https use: 1. Removing the token is similar to rewriting web pages to change https:// links to http:// links. 2. The risk is only present if the server is willing to vend that information over an insecure channel in the first place 3. If the client knows for a fact that a server is TLS-compliant, it can insist on it by only connecting as https:// or by only sending an upgrade request on a no-op method like OPTIONS. Furthermore, for clients which do not actively try to invoke TLS, servers can use Upgrade: to advertise TLS compliance, too. Since TLS-compliance should be considered a feature of the server and not the resource at hand, it should be sufficient to send it once, and let clients cache that fact. 2. Potential Solution Define "TLS/x.y" as a reference to the TLS specification ([13]draft-ietf-tls-protocol-03), with x and y bound to its major and minor version numbers. Section 6.2.1 of the current draft explains why the TLS version would currently be defined as 1.0, not the actual parameters on the wire (which is "3.1" for backwards compatibility with SSL3). An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of the field-values of the Upgrade: header. The origin-server MAY respond with "101 Switching Protocols"; if so it MUST include the header "Upgrade: TLS/x.y" to indicate what it is switching to. Servers which can upgrade to TLS MAY include the header "TLS/x.y" in an Upgrade response header to inform the client; servers SHOULD include such indication in response to any OPTIONS request. Similarly, servers MAY require clients to switch to TLS first by responding with a new error code "418: Upgrade Required", which MUST specify the protocol to be supported, "TLS/x.y" in this case. While proxy servers MAY be able to initiate a TLS-secured connection, e.g. the outgoing firewall for a trusted subnetwork, proxy servers MUST NOT remove "TLS/x.y" from Upgrade header in the request or response and MUST NOT reply on behalf of the origin server (i.e. "Cache-control: no-cache" must be implied). 3. Next Steps I could proceed by formalizing Section 2 as an Internet-Draft, but under the jurisdiction of which IETF working group? Furthermore, I do not have access nor personal interest in a TLS-capable client/server pair to experiment with. N.B. I believe this work is completely separate from HTTP-extension work proceeding in the web evolution / http-extension working group. This uses Upgrade for its stated purpose -- to switch to an entirely different protocol -- not to define or modify HTTP methods and semantics. Please watch [14]http://www.ics.uci.edu/~rohit/http-tls for updates of this document and any Internet-Drafts relating to this proposal. 4. Acknowledgments Thanks to Paul Hoffman for his work on the STARTTLS command extension for ESMTP. Thanks to Roy Fielding for assistance with the rationale behind Upgrade: and OPTIONS. 5. References 1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html 2. http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt 3. http://ds.internic.net/internet-drafts/draft-ietf-tls-https-00.txt 4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl 5. http://ds.internic.net/internet-drafts/draft-newman-tls-imappop-03.txt 6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt 7. http://www.ics.uci.edu/pub/ietf/http/ 8. http://www.consensus.com/ietf-tls/ 9. http://www.imc.org/ietf-apps-tls/ 10. http://www.pwg.org/ipp/index.html 11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt 12. http://ds.internic.net/internet-drafts/draft-luotonen-web-proxy-tunneling-00.txt 13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt 14. http://www.ics.uci.edu/~rohit/http-tls [soon!] From owner-ietf-apps-tls Mon Mar 16 11:57:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA21358 for ietf-apps-tls-bks; Mon, 16 Mar 1998 11:57:26 -0800 (PST) Received: from consensus.com (mail.consensus.com [157.22.240.7]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA21353 for ; Mon, 16 Mar 1998 11:57:20 -0800 (PST) Received: from [157.22.240.64] by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 16 Mar 1998 12:59:37 -0700 Message-Id: In-Reply-To: <199803161013.CAA18637@alumni.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Mar 1998 11:49:12 -0800 To: Rohit Khare From: Tim Dierks Subject: Re: Upgrading to TLS Within HTTP Cc: http-wg@cuckoo.hpl.hp.com, ietf-tls@consensus.com, ietf-apps-tls@imc.org Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 2:13 AM -0800 3/16/98, Rohit Khare wrote: >Upgrading to TLS Within HTTP > > Rohit Khare, UC Irvine, March 15, 1998 Thanks for this detailed note. I have some questions. (Perhaps we could narrow this down to a smaller number of lists, as well.) - Upgrade is a "hop-by-hop" header. How do you propose to acheive end-to-end security in the presence of caches or proxies? - It seems to me that a straightforward implementation of this would expose the request with the Upgrade: field in it; this request would not be protected by encryption or authentication. Do you have suggestions on how to avoid this problem? Tim Dierks - timd@consensus.com - www.consensus.com Director of Engineering - Consensus Development Developer of SSL Plus: SSL 3.0 Integration Suite From owner-ietf-apps-tls Mon Mar 16 14:43:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA23219 for ietf-apps-tls-bks; Mon, 16 Mar 1998 14:43:43 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA23215 for ; Mon, 16 Mar 1998 14:43:42 -0800 (PST) Received: from elwood.innosoft.com ("port 39236"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IUQKJDDSIU8Y521I@INNOSOFT.COM> for ietf-apps-tls@imc.org; Mon, 16 Mar 1998 14:42:18 PST Date: Mon, 16 Mar 1998 14:44:06 -0800 (PST) From: Chris Newman Subject: Re: URLs and TLS In-reply-to: To: Application Use of TLS IETF List 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 Let me attempt to explain my motivations better for my TLS in URLs proposal. It is important that the default model is "use TLS if available and performance constraints permit." This is the reason there is pressure to move away from the separate port model which is basically "use TLS if and only if the resource requires it." However, I still think it is useful to be able to express "this resource requires TLS" in a URL without having to use a new URL scheme and separate port. First, this prevents the client from going through any unnecessary negotiation attempt which will fail. And second, it forces clients to implement a minimal level of client-enforced security policy (e.g., don't connect to this resource unless TLS is used). Remember that URLs are not always received from an insecure remote site -- they can be configured locally or through a secure channel and thus are a useful place for some minimal client-enforced security policy. Incidentally, this is the exact same justification as for the ";AUTH=" parameter in the IMAP and ACAP URL schemes (RFC 2192 & 2244). I consider this an important case, but not the default case. The difficult question is to what degree should client security policy for TLS be expressed in a URL? The minimal solution, which is not unreasonable, would be a ";TLS=required" option. Expressing which cipher suite or which options within a cipher suite is obviously ridiculous and should be left up to TLS's in-band negotiation. I think at least a distinction between "use TLS client auth" and "don't use TLS client auth" is a good idea. I also like expressing "integrity vs. privacy," as I proposed previously although I could live without that. I don't think going further is useful -- effective key bits is starting to get to a level of detail that changes quickly with time and is probably best negotiated via TLS in-band negotiation. Does this reasoning pass muster with others here? FYI, I'm bringing this up because the question was raised in the context of the POP3 URL scheme which is interesting because it's usually a reference to a non-public resource. However, it's important because it allows the abstract concept of an inbox resource to be modeled as a URL (either IMAP or POP). - Chris From owner-ietf-apps-tls Wed Mar 18 17:17:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA11666 for ietf-apps-tls-bks; Wed, 18 Mar 1998 17:17:16 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA11662 for ; Wed, 18 Mar 1998 17:17:15 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA12386 for ; Wed, 18 Mar 1998 17:16:00 -0800 (PST) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA140 for ; Wed, 18 Mar 1998 17:15:59 -0800 Message-ID: <351071D1.C26640D9@netscape.com> Date: Wed, 18 Mar 1998 17:16:01 -0800 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: What to advertise when mandatory ciphers not implemented Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Due to scheduling constraints, it is likely that some future release of Netscape's messaging server will be capable of supporting the STARTTLS mechanism in IMAP and SMTP, but will not be capable of supporting the ciphers which the TLS specification makes mandatory. I have two choices: 1) I can advertise the STARTTLS extension even though the extension does not conform to the mandatory-to-implement cipher requirements. 2) I can advertise a private XSTARTSSL extension which behaves exactly like STARTTLS, but does not have the mandatory cipher requirement. While it is ugly and nonconforming, I believe (1) will lead to better interoperability. To a client, it is indistinguishable from a conforming server which has had those ciphers disabled by the admin. (The trick is to keep marketing from claiming TLS conformance.) I'll do (2) if the community thinks it is the better choice. What do other people think? From owner-ietf-apps-tls Wed Mar 18 18:08:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA12344 for ietf-apps-tls-bks; Wed, 18 Mar 1998 18:08:40 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA12340 for ; Wed, 18 Mar 1998 18:08:39 -0800 (PST) Message-Id: <199803190208.SAA12340@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.319 (Beta) Date: Wed, 18 Mar 1998 18:07:42 -0800 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: Re: What to advertise when mandatory ciphers not implemented In-Reply-To: <351071D1.C26640D9@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 05:16 PM 3/18/98 -0800, John Myers wrote: >I have two choices: > >1) I can advertise the STARTTLS extension even though the extension does >not conform to the mandatory-to-implement cipher requirements. > >2) I can advertise a private XSTARTSSL extension which behaves exactly >like STARTTLS, but does not have the mandatory cipher requirement. > >While it is ugly and nonconforming, I believe (1) will lead to better >interoperability. I agree. >To a client, it is indistinguishable from a >conforming server which has had those ciphers disabled by the admin. >(The trick is to keep marketing from claiming TLS conformance.) Dream on. :-) >I'll do >(2) if the community thinks it is the better choice. It's a terrible choice. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed Mar 18 21:22:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA13604 for ietf-apps-tls-bks; Wed, 18 Mar 1998 21:22:45 -0800 (PST) Received: from pandora.cryptsoft.com (pandora.cryptsoft.com [203.56.44.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA13600 for ; Wed, 18 Mar 1998 21:22:41 -0800 (PST) Received: (from tjh@localhost) by pandora.cryptsoft.com (8.8.3/8.7.3) id PAA02334; Thu, 19 Mar 1998 15:21:33 +1000 (EST) From: Tim Hudson Message-Id: <199803190521.PAA02334@pandora.cryptsoft.com> Subject: Re: What to advertise when mandatory ciphers not implemented To: jgmyers@Netscape.COM (John Myers) Date: Thu, 19 Mar 1998 15:21:32 +1000 (EST) Cc: ietf-apps-tls@imc.org Reply-To: tjh@cryptsoft.com In-Reply-To: <351071D1.C26640D9@netscape.com> from "John Myers" at Mar 18, 98 05:16:01 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Sender: owner-ietf-apps-tls@imc.org Precedence: bulk According to John Myers: > Due to scheduling constraints, it is likely that some future release of > Netscape's messaging server will be capable of supporting the STARTTLS > mechanism in IMAP and SMTP, but will not be capable of supporting the > ciphers which the TLS specification makes mandatory. If it doesn't support the MUST sections of the TLS document then you should not call it TLS as it is not TLS by definition. It is that simple. > 1) I can advertise the STARTTLS extension even though the extension does > not conform to the mandatory-to-implement cipher requirements. This is not a smart thing to do ... if it isn't TLS then using STARTTLS is not the right approach. This certainly sets the wrong precedence. > 2) I can advertise a private XSTARTSSL extension which behaves exactly > like STARTTLS, but does not have the mandatory cipher requirement. One option is to just call it STARTSSL ... I did argue for this being acceptable in a number of public and private forums but was told that everyone will support TLS and SSLv3 is no longer relevant. Personally I think that adding a mechanism that allowed for SSLv3 *or* TLSv1 support would have avoiding the fun and games that are about to commence as TLS implementations start making their way into products. What sections of the TLS specification do you anticipate will not be supported? Are there plans to do a proper TLS implementation? > (The trick is to keep marketing from claiming TLS conformance.) You will be the first non-marketing person to achieve that in my experience ... how could you reasonably expect something that supports STARTTLS to not imply that TLS was supported? Certainly if you did achieve that then I'm sure others would be interesting in learning your secret :-) Tim. From owner-ietf-apps-tls Thu Mar 19 00:01:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA22387 for ietf-apps-tls-bks; Thu, 19 Mar 1998 00:01:45 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA22379 for ; Thu, 19 Mar 1998 00:01:44 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA18789 for ; Thu, 19 Mar 1998 00:00:48 -0800 (PST) Received: from netscape.com ([198.93.95.134]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA14AD for ; Thu, 19 Mar 1998 00:00:48 -0800 Message-ID: <3510D09D.F5324522@netscape.com> Date: Thu, 19 Mar 1998 01:00:30 -0700 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: Re: What to advertise when mandatory ciphers not implemented References: <199803190521.PAA02334@pandora.cryptsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Tim Hudson wrote: > If it doesn't support the MUST sections of the TLS document then you > should not call it TLS as it is not TLS by definition. It is that simple. I wasn't talking about calling it TLS, I was talking about piggybacking the IMAP and SMTP extensions named STARTTLS. The definitions of those extensions aren't yet carved in stone, my proposal could be made technically legal. > > > 1) I can advertise the STARTTLS extension even though the extension does > > not conform to the mandatory-to-implement cipher requirements. > This is not a smart thing to do ... if it isn't TLS then using STARTTLS > is not the right approach. This certainly sets the wrong precedence. IETF lore tends to set interoperability before elegance. Sounds like the right precedence to me. > One option is to just call it STARTSSL ... I did argue for this being > acceptable in a number of public and private forums but was told that everyone > will support TLS and SSLv3 is no longer relevant. Full TLS support has apparently taken longer than originally suspected. It is likely to miss a product release. In any case, this is a short-term issue, should it be solved by creating a potential long-term interoperability problem? > Personally I think that > adding a mechanism that allowed for SSLv3 *or* TLSv1 support would have > avoiding the fun and games that are about to commence as TLS implementations > start making their way into products. Likewise, and I think that this mechanism should be called STARTTLS. Interoperability is not served by having two different extensions, both of which are capable of negotiating TLSv1. > What sections of the TLS specification do you anticipate will not be > supported? Are there plans to do a proper TLS implementation? I don't have all the details, but it will likely be SSL v3.0, not v3.1. I've arranged it so that no SSL v2 ciphers will ever be offered by the server. Yes, there are plans on doing a proper TLS implementation. Of course, that implementation would only be available domestically. Is any of this relevant to the question at hand? > > (The trick is to keep marketing from claiming TLS conformance.) > You will be the first non-marketing person to achieve that in my > experience ... how could you reasonably expect something that supports > STARTTLS to not imply that TLS was supported? Certainly if you did achieve > that then I'm sure others would be interesting in learning your secret :-) When talking to marketing, I don't use the term "TLS", I use the term "SSL". I also volunteer to review their compliance document. From owner-ietf-apps-tls Thu Mar 26 21:39:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA02081 for ietf-apps-tls-bks; Thu, 26 Mar 1998 21:39:05 -0800 (PST) Received: from [12.11.162.5] (brl-gw-5.openmarket.com [12.11.162.5]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA02077 for ; Thu, 26 Mar 1998 21:39:04 -0800 (PST) Received: from relay.openmarket.com by [12.11.162.5] via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 27 Mar 1998 05:41:07 UT Received: from mail.openmarket.com (mail.openmarket.com [10.129.20.250]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id AAA10413 for ; Fri, 27 Mar 1998 00:39:13 -0500 Received: from cirocco.ne.mediaone.net ([10.145.30.6]) by mail.openmarket.com (8.7.4/8.7.3) with SMTP id AAA03590 for ; Fri, 27 Mar 1998 00:35:35 -0500 (EST) Message-Id: <3.0.5.32.19980327002136.0082de90@mail-60.OpenMarket.com> X-Sender: treese@mail-60.OpenMarket.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 00:21:36 -0500 To: ietf-apps-tls@imc.org From: Win Treese Subject: Internet Drafts related to TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Internet Drafts related to TLS (as of 26 March 1998) [Thanks to Chris Allen for compiling earlier lists.] The following drafts are under consideration by the TLS working group. The IETF Secretariat's up-to-date list of such drafts is at http://www.ietf.org/ids.by.wg/tls.html "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", M. Hur, A. Medvinsky, 02/25/1998. ftp://ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-02.txt This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication. "The TLS Protocol Version 1.0", C. Allen, T. Dierks, 11/13/1997. ftp://ietf.org/internet-drafts/draft-ietf-tls-protocol-05.txt This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "HTTP Over TLS", E. Rescorla, 03/13/1998. ftp://ietf.org/internet-drafts/draft-ietf-tls-https-01.txt This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the prede- cessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP. "TLS extensions for AttributeCertificate based authorization", S. Farrell, 03/02/1998. ftp://ietf.org/internet-drafts/draft-ietf-tls-attr-cert-00.txt Authorization support is required for various internet protocols including TLS (and its cosumers), IPSEC and others. This document presents requirements for providing such support as well as an outline specification for AttributeCertificate based authorization as an extension to the TLS protocol. Future versions of this specification will define an encoding for the data structures required (ASN.1 or not) and will refine the description of the use AttributeCertificates in the TLS protocol. "ECC Cipher Suites For TLS", T. Dierks, Bill Anderson, 03/16/1998. ftp://ietf.org/internet-drafts/draft-ietf-tls-ecc-00.txt This document describes additions to TLS to support the Elliptic Curve Cryptosystem (ECC). The document assumes that the reader is familiar with the TLS protocol. The document defines cipher suites which use the Elliptic Curve Encryption Scheme (ECES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV) key establishment algorithms. References to these algorithms can be found in section 13. Drafts Referring to TLS "Tunneling TCP based protocols through Web proxy servers", A. Luotonen, 02/25/1998. ftp://ietf.org/internet-drafts/draft-luotonen-web-proxy-tunneling-00.txt This document specifies a generic tunneling mechanism for TCP based protocols through Web proxy servers. This tunneling mechanism was initially introduced for the SSL protocol [SSL] to allow secure Web traffic to pass through firewalls, but its utility is not limited to SSL. Earlier drafts of this specification were titled ''Tunneling SSL through Web Proxy Servers". Implementations of this tunneling feature are commonly referred to as ''SSL tunneling'', although, again, it can be used for tunneling any TCP based protocol. A wide variety of existing client and proxy server implementations conform to this specification. The purpose of this specification is to describe the current practice, to propose some good practices for implementing this specification, and to document the security considerations that are involved with this protocol. "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", B. Morgan, J. Hodges, M. Wahl, 03/12/1998. ftp://ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-tls-00.txt This document defines the ''Start Transport Layer Security (TLS) Opera- tion'' for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- ment in an LDAP association and is defined in terms of an LDAP extended request. "Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson, Martin Carpenter, 01/29/1998. ftp://ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-03.txt This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by the IETF TLS working group and the extensions to the FTP protocol defined by the IETF CAT working group. It describes the subset of the extensions that are required and the parameters to be used; discusses some of the policy issues that clients and servers will need to take; considers some of the implications of those policies and discusses some expected behaviours of implementations to allow interoperation. TLS is not the only mechanism for securing file transfer, however it does offer some of the following positive attributes:- - Flexible security levels. TLS can support privacy, integrity, authentication or some combination of all of these. This allows clients and servers to dynamically, during a session, decide on the level of security required for a particular data transfer, - Formalised public key management. By use of X.509 public certificates during the authentication phase, certificate management can be built into a central function. Whilst this may not be desirable for all uses of secured file transfer, it offers advantages in certain structured environments such as access to corporate data sources. - Co-existence and interoperation with authentication mechanisms that are already in place for the HTTPS protocol. This allows web browsers to incorporate secure file transfer using the same infrastructure that has been set up to allow secure web browsing. The TLS protocol is a development of the Netscape Communication Corporation's SSL protocol and this document can be used to allow the FTP protocol to be used with either SSL or TLS. The actual protocol used will be decided by the negotiation of the protected session. "SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman, 11/17/1997. ftp://ietf.org/internet-drafts/draft-hoffman-smtp-ssl-05.txt 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. "Firewall Traversal authorization system", M. Richardson, K. Martius, 07/10/1997. ftp://ietf.org/internet-drafts/draft-richardson-ipsec-traversal-01.txt This document describes a public key certificate mechanism to authorize traversal of multiple security gateways (firewalls). This work is independant of transport layer in concept, and could apply to IPsec, TLS, or SecSH. It is applied here to IPsec. The SPKI certificate format is used here. "Using TLS with IMAP4, POP3 and ACAP", Chris Newman, 03/10/1998. ftp://ietf.org/internet-drafts/draft-newman-tls-imappop-03.txt The TLS protocol [TLS] (formerly known as SSL) provides a way to secure a connection from tampering and evesdropping. Obviously, the option of using such security is desirable for IMAP [IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] authentication mechanisms can provide a lightweight version of this service, TLS is a full service security layer and is also useful in combination with plaintext password logins and other simple mechanisms as it doesn't require a site to upgrade its authentication database. This specification defines extensions to IMAP4, ACAP and POP3 which activate TLS. It also defines a set of server security policy response codes for use with IMAP4. The response codes MAY be used independently of the TLS extension. Finally, this defines a simple PLAIN SASL mechanism for use underneath strong TLS encryption with ACAP. [NOTE: Public discussion of this mechanism may take place on the ietf-apps-tls@imc.org mailing list with a subscription address of ietf-apps-tls-request@imc.org. Private comments may be sent to the author]. "PPP EAP TLS Authentication Protocol", B. Aboba, D. Simon, 10/21/1997. ftp://ietf.org/internet-drafts/draft-ietf-pppext-eaptls-02.txt The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP. "TLS-based Telnet Security", Michael Boe, 12/30/1997. ftp://ietf.org/internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. "Secure Sockets Layer for SOCKS Version 5", M. VanHeyningen, 03/20/1997. ftp://ietf.org/internet-drafts/draft-ietf-aft-socks-ssl-00.txt This document specifies the use of SSL 3.0 and possible successor protocols as an authentication method for SOCKS Version 5. The design is similar to, and largely derived from, the integration of GSS-API into SOCKS5 [RFC 1961]. A framework is provided for future extensions, and the use of other 'subauthentication' methods inside SSL is supported. From owner-ietf-apps-tls Tue Mar 31 08:05:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA15427 for ietf-apps-tls-bks; Tue, 31 Mar 1998 08:05:13 -0800 (PST) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA15423 for ; Tue, 31 Mar 1998 08:05:12 -0800 (PST) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id IAA13132; Tue, 31 Mar 1998 08:05:45 -0800 (PST) Message-Id: <199803311605.IAA13132@Wind.Stanford.EDU> X-Mailer: exmh version 2.0zeta 7/24/97 Subject: discussion of StartTLS for LDAP To: ietf-apps-tls@imc.org cc: ietf-ldapext@Netscape.COM, ietf-tls@consensus.com cc: Jeff.Hodges@stanford.edu From: Jeff.Hodges@stanford.edu X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Mar 1998 08:05:44 -0800 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk We have an open question in the latest revision of the StartTLS for LDAP draft.. draft-ietf-ldapext-ldapv3-tls-00.txt ..which is the same as brought up by Eric in.. draft-ietf-tls-https-01.txt ..and is namely "Endpoint Identification: Server Identity" (section 3.1 in tls-https-01). Nominally, Bob & I feel that if it's appropriate for http, then it is likely appropriate for LDAP. We're interested in getting feedback on whether this is something that we should add to the ldapv3-tls doc prior to working group last call. thanks, Jeff ps: apologies for the wide dispersion of this msg, we also should figger out which list such a focused topic should be discussed - I'm not positive myself since it is an interdisciplinary problem. From owner-ietf-apps-tls Fri Apr 17 16:50:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA16282 for ietf-apps-tls-bks; Fri, 17 Apr 1998 16:50:32 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA16278 for ; Fri, 17 Apr 1998 16:50:31 -0700 (PDT) Received: from elwood.innosoft.com ("port 42047"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IVZED9P2I2984Y2Q@INNOSOFT.COM> for ietf-apps-tls@imc.org; Fri, 17 Apr 1998 16:51:13 PDT Date: Fri, 17 Apr 1998 16:52:54 -0700 (PDT) From: Chris Newman Subject: TLS and ACAP/IMAP/POP To: Application Use of TLS IETF List , IETF ACAP Mailing List 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 There was a brief discussion of this specification at the ACAP WG (it's not a WG document, but is related to the WG): At the meeting it was suggested that language be added concerning shutting down the TLS connection without shutting down the underlying TCP connection. I don't know how to write this or what needs to be said, if anything. There are other issues concerning restrictions on certificates and naming in certificates which were raised by others and may also not be well specified by reference. I see two choices: (1) Delay this indefinitely until a co-author volunteers who is comfortable writing the necessary text. I don't have time to learn all about variations in X.509 certs and SSL/TLS APIs which I consider necessary to write clear text on these topics. (2) Do an IETF 4 week last call on the current document, publish as a proposed standard RFC and if it is necessary to revise it later we can recycle at proposed status. I favor option (2) as I believe it is more important to have a standards track spec describing how to integrate TLS into these protocols than it is to have a perfect spec. If I get no complaints, I will ask for a last call on the current spec in one week. Otherwise I will wait for a volunteer (anyone who complains will be the obvious choice for co-author :-). Editorial comments or comments about other minor issues in the spec are welcome prior to IETF last call and I will do my best to address them. I plan to make one more editorial revision before asking for IETF 4 week last call. - Chris From owner-ietf-apps-tls Sat Apr 18 13:44:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA04743 for ietf-apps-tls-bks; Sat, 18 Apr 1998 13:44:58 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA04739; Sat, 18 Apr 1998 13:44:55 -0700 (PDT) Message-Id: <199804182044.NAA04739@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Sat, 18 Apr 1998 13:44:46 -0700 To: Application Use of TLS IETF List , IETF ACAP Mailing List From: Paul Hoffman / IMC Subject: Re: TLS and ACAP/IMAP/POP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 04:52 PM 4/17/98 -0700, Chris Newman wrote: >(2) Do an IETF 4 week last call on the current document, publish as a >proposed standard RFC and if it is necessary to revise it later we can >recycle at proposed status. This works for me. BTW, the TLS spec will be revised before publication to clear up the problems with closing the connection. This was agreed to on the TLS mailing list and the author forgot to put it into the draft. That's about to be cleared up. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Sat Apr 18 23:54:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA15341 for ietf-apps-tls-bks; Sat, 18 Apr 1998 23:54:37 -0700 (PDT) Received: from Qajaq.Stanford.EDU (Qajaq.Stanford.EDU [36.53.0.17]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA15337 for ; Sat, 18 Apr 1998 23:54:36 -0700 (PDT) Received: from Perq.Stanford.EDU (Perq-at-home.Stanford.EDU [171.64.10.149]) by Qajaq.Stanford.EDU (8.8.0/8.7.1) with SMTP id XAA20301; Sat, 18 Apr 1998 23:57:30 -0700 (PDT) Date: Sat, 18 Apr 1998 23:55:39 -0700 (PDT) From: RL Bob Morgan X-Sender: morgan@Perq.Stanford.EDU Reply-To: RL Bob Morgan To: Chris Newman cc: Application Use of TLS IETF List , IETF ACAP Mailing List Subject: Re: TLS and ACAP/IMAP/POP 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 Fri, 17 Apr 1998, Chris Newman wrote: > There was a brief discussion of this specification at the ACAP WG (it's > not a WG document, but is related to the WG): > > > > At the meeting it was suggested that language be added concerning shutting > down the TLS connection without shutting down the underlying TCP > connection. I don't know how to write this or what needs to be said, if > anything. As Paul mentioned, this has come up in the process of finishing up the LDAP-over-TLS spec, and has (we think) been resolved. Tim Dierks has suggested the following for the TLS protocol spec: Existing text: Each party is required to send a close_notify alert before closing the write side of the connection. It is required that the other party respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. Text to be added: If the application protocol using TLS provides that any data may be carried over the underlying transport, the TLS implementation must recieve the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation may choose to close the transport without waiting for the responding close_notify. The ldapv3-tls draft spec has the following: 5.1. Graceful Closure Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact. Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3]. After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the reciept of the alert, MAY send and receive LDAP PDUs. The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs. Similar language would presumably work in the IMAP/POP/ACAP draft. > There are other issues concerning restrictions on certificates > and naming in certificates which were raised by others and may also not be > well specified by reference. You may be referring to the issue of whether the TLS client should check the server cert, and just what it should check for. We have also considered this in LDAP-TLS. There is proposed language for this action in draft-ietf-tls-https-01.txt (which is a spec documenting current practice, not proposing new better practice). Debate at the ldapext WG session in LA indicated that there is a diversity of opinion on the topic, from "the client MUST do it or you've thrown security out the window" to "this is a black hole of poorly-defined nasty interminable issues". Some might hold both opinions (8^). One murky issue: PKIX has gone back and forth on whether the "*" wildcard character is allowed in DNS-style subjectAltNames. I think the decision in LA was to put them back in, but it's still up in the air until PKIX part 1 is really finally done. Furthermore, PKIX part 1 doesn't say exactly how the * is used in matching; this is left to apps. The other murky issue: should the client compare against whatever name it used to initiate the connection, or try to come up with the host's canonical name (as Kerberos does)? The former is easier for the client but would presumably require the server to have all of its aliases in its cert. If I were the IESG I'd like to see all TLS-using apps protocols address this server-name-checking issue the same way. But exactly what that way is isn't obvious to me. > I see two choices: > > (1) Delay this indefinitely until a co-author volunteers who is > comfortable writing the necessary text. I don't have time to learn all > about variations in X.509 certs and SSL/TLS APIs which I consider > necessary to write clear text on these topics. > > (2) Do an IETF 4 week last call on the current document, publish as a > proposed standard RFC and if it is necessary to revise it later we can > recycle at proposed status. > > I favor option (2) as I believe it is more important to have a standards > track spec describing how to integrate TLS into these protocols than it is > to have a perfect spec. If I get no complaints, I will ask for a last > call on the current spec in one week. Otherwise I will wait for a > volunteer (anyone who complains will be the obvious choice for > co-author :-). I suggest that dealing with the connection-closing issue is easy, and should just be done. The server-name-checking is not, so the quickest way forward is to leave it out and if it makes it through last call that way, yippee. - RL "Bob" Morgan Stanford From owner-ietf-apps-tls Mon Apr 20 15:45:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA19842 for ietf-apps-tls-bks; Mon, 20 Apr 1998 15:45:35 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA19838 for ; Mon, 20 Apr 1998 15:45:33 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA11238 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Mon, 20 Apr 1998 15:46:02 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA01570 for ; Mon, 20 Apr 1998 15:45:51 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: Re: TLS and ACAP/IMAP/POP Date: Mon, 20 Apr 1998 15:45:50 -0700 Organization: Netscape Communications Corporation Lines: 21 Message-ID: <353BD01E.74F9F6FC@netscape.com> References: NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk RL Bob Morgan wrote: > After the initiator of a close has sent a closure alert, it MUST discard > any TLS messages until it has received an alert from the other party. > It will cease to send TLS Record Protocol PDUs, and following the > reciept of the alert, MAY send and receive LDAP PDUs. I don't see the technical justification for this requirement. In the current close-TCP-connection-after-notify case, there is no corresponding requirement for the sender of a close_notify to discard any received TLS messages. I observe that if there is a cipher suite mismatch, one side will send a handshake_failure alert, closing the underlying TCP connection. Clients which want to fallback from TLS to SASL or simple-bind authentication will still have to be able to reconnect in their fallback code. > Similar language would presumably work in the IMAP/POP/ACAP draft. IMAP/POP/ACAP do not have "unauthenticate but continue connection" operations, so they have no use for a "stop TLS but continue connection" operation. From owner-ietf-apps-tls Mon Apr 20 15:47:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA19854 for ietf-apps-tls-bks; Mon, 20 Apr 1998 15:47:06 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA19850 for ; Mon, 20 Apr 1998 15:47:05 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA11270 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Mon, 20 Apr 1998 15:47:46 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA02213 for ; Mon, 20 Apr 1998 15:47:46 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: Re: TLS and ACAP/IMAP/POP Date: Mon, 20 Apr 1998 15:47:45 -0700 Organization: Netscape Communications Corporation Lines: 21 Message-ID: <353BD091.D7612188@netscape.com> References: NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk RL Bob Morgan wrote: > After the initiator of a close has sent a closure alert, it MUST discard > any TLS messages until it has received an alert from the other party. > It will cease to send TLS Record Protocol PDUs, and following the > reciept of the alert, MAY send and receive LDAP PDUs. I don't see the technical justification for this requirement. In the current close-TCP-connection-after-notify case, there is no corresponding requirement for the sender of a close_notify to discard any received TLS messages. I observe that if there is a cipher suite mismatch, one side will send a handshake_failure alert, closing the underlying TCP connection. Clients which want to fallback from TLS to SASL or simple-bind authentication will still have to be able to reconnect in their fallback code. > Similar language would presumably work in the IMAP/POP/ACAP draft. IMAP/POP/ACAP do not have "unauthenticate but continue connection" operations, so they have no use for a "stop TLS but continue connection" operation. From owner-ietf-apps-tls Mon Apr 20 16:21:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA20285 for ietf-apps-tls-bks; Mon, 20 Apr 1998 16:21:24 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA20281 for ; Mon, 20 Apr 1998 16:21:23 -0700 (PDT) Received: from elwood.innosoft.com ("port 42183"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IW3K7FTMCK984ZQI@INNOSOFT.COM> for ietf-apps-tls@imc.org; Mon, 20 Apr 1998 16:21:31 PDT Date: Mon, 20 Apr 1998 16:23:08 -0700 (PDT) From: Chris Newman Subject: Re: TLS and ACAP/IMAP/POP In-reply-to: To: RL Bob Morgan Cc: Application Use of TLS IETF List , IETF ACAP Mailing List 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 Ok, the text may be simple, but I'm not convinced the issue is simple. The following questions come to mind: (A) Do most or all current SSL/TLS API's support closing TLS without closing the underlying socket? If they don't it adds significant extra complexity to require it. (B) Is it really useful to close TLS and continue the connection with no connection? With LDAPv3 it is likely useful since writes are infrequent and reads of public information are frequent. With IMAP/POP/ACAP I'm far from convinced since there is less public information and mixed read/write access is the norm. Does 3DES by itself result in servers becoming CPU-bound rather than I/O bound? Would it be useful to support use TLS in a mode where the security layer is only active during authentication to make it slightly easier to integrate into an app protocol? I'm inclined to remain silent on this issue until we're confident "yes" is the answer to these questions. Does anyone strongly object to this position? On Sat, 18 Apr 1998, RL Bob Morgan wrote: > The ldapv3-tls draft spec has the following: > > 5.1. Graceful Closure > > Either the client or server MAY terminate the TLS connection on an LDAP > association by sending a TLS closure alert. This will leave the LDAP > association intact. > > Before closing a TLS connection, the client MUST either wait for any > outstanding LDAP operations to complete, or explicitly abandon them > [LDAPv3]. > > After the initiator of a close has sent a closure alert, it MUST discard > any TLS messages until it has received an alert from the other party. > It will cease to send TLS Record Protocol PDUs, and following the > reciept of the alert, MAY send and receive LDAP PDUs. > > The other party, if it receives a closure alert, MUST immediately > transmit a TLS closure alert. It will subequently cease to send TLS > Record Protocol PDUs, and MAY send and receive LDAP PDUs. > > Similar language would presumably work in the IMAP/POP/ACAP draft. > ... > I suggest that dealing with the connection-closing issue is easy, and > should just be done. - Chris From owner-ietf-apps-tls Mon Apr 20 17:30:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA21105 for ietf-apps-tls-bks; Mon, 20 Apr 1998 17:30:20 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA21100; Mon, 20 Apr 1998 17:30:12 -0700 (PDT) Message-Id: <199804210030.RAA21100@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Mon, 20 Apr 1998 17:30:11 -0700 To: Chris Newman , RL Bob Morgan From: Paul Hoffman / IMC Subject: Re: TLS and ACAP/IMAP/POP Cc: Application Use of TLS IETF List , IETF ACAP Mailing List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 04:23 PM 4/20/98 -0700, Chris Newman wrote: >(A) Do most or all current SSL/TLS API's support closing TLS without >closing the underlying socket? If they don't it adds significant extra >complexity to require it. I've been told "yes". >(B) Is it really useful to close TLS and continue the connection with no >connection? In the SMTP/TLS case, I'd say "yes", because there may be transactions you are willing to do without authentication or privacy. > With LDAPv3 it is likely useful since writes are infrequent >and reads of public information are frequent. With IMAP/POP/ACAP I'm far >from convinced since there is less public information and mixed read/write >access is the norm. Agree. > Does 3DES by itself result in servers becoming >CPU-bound rather than I/O bound? Would it be useful to support use TLS in >a mode where the security layer is only active during authentication to >make it slightly easier to integrate into an app protocol? I have no idea. >I'm inclined to remain silent on this issue until we're confident "yes" is >the answer to these questions. Does anyone strongly object to this >position? I don't object, but I think the "yes" answers above make it reasonable to think about dealing with in the current drafts. I actively chose not to, but YMMV. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Mon Apr 20 17:48:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA21249 for ietf-apps-tls-bks; Mon, 20 Apr 1998 17:48:05 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA21245 for ; Mon, 20 Apr 1998 17:48:04 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA20651 for ; Mon, 20 Apr 1998 17:48:46 -0700 (PDT) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA4880; Mon, 20 Apr 1998 17:48:43 -0700 Message-ID: <353BECED.EE950710@netscape.com> Date: Mon, 20 Apr 1998 17:48:45 -0700 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-apps-tls@imc.org, iesg@ietf.org Subject: Serious design flaw in STARTLS documents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk In implementing draft-hoffman-smtp-ssl-05.txt and draft-newman-tls-imappop-03.txt, I have found a security problem and interoperability problem which I believe should be addressed before these documents are published as RFC's. The protocols as specified are likely to lead to client implementations vulnerable to a man-in-the-middle attack directed at capabilities/service-extensions OTHER than the STARTTLS extension itself. This occurs if a client believes extensions it received before starting up TLS. The fix is to require that the client discard all knowledge of capabilities/extensions it received prior to negotiating TLS. After negotiating TLS, the client must re-query for capabilities/extensions. The documents could save a round trip by stating that following a TLS negotiation, the server must immediately send a list of capabilities/extensions to the client. This fix would also address the interoperability problem, which is that the list of available SASL mechanisms is likely to depend on the state of the TLS negotiation. A server does not want to advertise the SASL EXTERNAL mechanism unless it accepts the client's TLS certificate. A server does not want to advertise the SASL PLAIN mechanism unless there is sufficient encryption to protect from passive sniffing any password the client would send in response. Since STARTTLS is an extension which is only enabled by active negotiation of both parties, it is reasonable for it to amend any restrictions in the SMTP or IMAP protocols against the list of capabilities/extensions changing due to session state. From owner-ietf-apps-tls Mon Apr 20 21:43:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA22797 for ietf-apps-tls-bks; Mon, 20 Apr 1998 21:43:53 -0700 (PDT) Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA22793 for ; Mon, 20 Apr 1998 21:43:52 -0700 (PDT) Received: from cisco.com (chacha-async-28.cisco.com [171.69.123.128]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id AAA26442; Tue, 21 Apr 1998 00:44:03 -0400 (EDT) Message-ID: <353C0675.188928A3@cisco.com> Date: Mon, 20 Apr 1998 21:37:41 -0500 From: Michael Boe Organization: Cisco Systems X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: John Myers CC: ietf-apps-tls@imc.org, iesg@ietf.org Subject: Re: Serious design flaw in STARTLS documents References: <353BECED.EE950710@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Correct. I can't remember whether I put such language into the draft-ietf-tn3270e-tls-telnet-00.txt.....but I certainly will ensure that negation of previously-negotiated Telnet options appears in the next draft. Some thought needs to be given to previous negotiations that *are* secure, and whether or not to allow these to continue to be in force. /msb John Myers wrote: > > In implementing draft-hoffman-smtp-ssl-05.txt and > draft-newman-tls-imappop-03.txt, I have found a security problem and > interoperability problem which I believe should be addressed before > these documents are published as RFC's. > > The protocols as specified are likely to lead to client implementations > vulnerable to a man-in-the-middle attack directed at > capabilities/service-extensions OTHER than the STARTTLS extension > itself. This occurs if a client believes extensions it received before > starting up TLS. > > The fix is to require that the client discard all knowledge of > capabilities/extensions it received prior to negotiating TLS. After > negotiating TLS, the client must re-query for capabilities/extensions. > The documents could save a round trip by stating that following a TLS > negotiation, the server must immediately send a list of > capabilities/extensions to the client. > > This fix would also address the interoperability problem, which is that > the list of available SASL mechanisms is likely to depend on the state > of the TLS negotiation. A server does not want to advertise the SASL > EXTERNAL mechanism unless it accepts the client's TLS certificate. A > server does not want to advertise the SASL PLAIN mechanism unless there > is sufficient encryption to protect from passive sniffing any password > the client would send in response. > > Since STARTTLS is an extension which is only enabled by active > negotiation of both parties, it is reasonable for it to amend any > restrictions in the SMTP or IMAP protocols against the list of > capabilities/extensions changing due to session state. From owner-ietf-apps-tls Tue Apr 21 08:12:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA11099 for ietf-apps-tls-bks; Tue, 21 Apr 1998 08:12:46 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id IAA11095 for ; Tue, 21 Apr 1998 08:12:44 -0700 (PDT) Message-Id: <199804211512.IAA11095@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Tue, 21 Apr 1998 08:12:42 -0700 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: Re: Serious design flaw in STARTLS documents In-Reply-To: <353BECED.EE950710@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 05:48 PM 4/20/98 -0700, John Myers wrote: >The protocols as specified are likely to lead to client implementations >vulnerable to a man-in-the-middle attack directed at >capabilities/service-extensions OTHER than the STARTTLS extension >itself. This occurs if a client believes extensions it received before >starting up TLS. To be clear about this: there is no new MITM attack caused by the STARTTLS extension. It is the fact that a lazy client might assume that the pre-TLS extensions were covered by the TLS connection, which is clearly wrong. >The fix is to require that the client discard all knowledge of >capabilities/extensions it received prior to negotiating TLS. I think requiring this is overkill. Discussing it in the drafts and saying that the client MAY ask for the capabilities again is sufficient in my mind. Specifically, if none of the other extensions announced are security-related, forcing a new EHLO is wasteful. Note that SMTP and SMTPbis already explicitly allow sending EHLO again, although some servers do not allow this (ahem). >The documents could save a round trip by stating that following a TLS >negotiation, the server must immediately send a list of >capabilities/extensions to the client. This breaks the client-server model of SMTP, so I don't want to put it in the SMTP/TLS draft. We're not that concerned with one round-trip in SMTP. >This fix would also address the interoperability problem, which is that >the list of available SASL mechanisms is likely to depend on the state >of the TLS negotiation. Quite right, and possibly worth a mention in the SMTP/TLS draft. I believe that SMTP/TLS was meant to have been balloted in the IESG by now. On the other hand, even if it passed, it will be stalled at least a few weeks waiting for PKIX part 1. Is this change (adding a MAY for uncautious implementors) important enough to force another IESG last call? I'm open to input from the list here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue Apr 21 10:07:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12557 for ietf-apps-tls-bks; Tue, 21 Apr 1998 10:07:12 -0700 (PDT) Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA12553 for ; Tue, 21 Apr 1998 10:07:08 -0700 (PDT) Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id TAA26121; Tue, 21 Apr 1998 19:07:20 +0200 Message-Id: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> X-Sender: hta@dokka.kvatro.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 21 Apr 1998 12:30:25 +0200 To: jgmyers@Netscape.COM (John Myers), ietf-apps-tls@imc.org, iesg@ietf.org From: Harald Tveit Alvestrand Subject: Re: Serious design flaw in STARTLS documents In-Reply-To: <353BECED.EE950710@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk John, I believe the flaw you indicate is generic to any protocol that negotiates an integrity or security layer (the same problem arises with negotiating GSSAPI protection using SASL). As such, there are 2 layers of fixes needed: - Document the problem in the SASL specification, and possibly in some document that generically describes "negotiating TLS" - Describe the specific applicability of the problem in SMTP and how to solve it (discard EHLO information after TLS negotiation). I agree that the second thing needs to be done to draft-hoffman-smtp-ssl before it ships. Probably it needs to be even more general; the sequence MAIL FROM:<> STARTTLS ..... RCPT TO: is bogus, but not forbidden by the current document. It probably needs to say that after STARTTLS negotiation, the state is as before EHLO; all state is flushed. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-ietf-apps-tls Tue Apr 21 10:38:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12849 for ietf-apps-tls-bks; Tue, 21 Apr 1998 10:38:40 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA12845 for ; Tue, 21 Apr 1998 10:38:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01150 for ; Tue, 21 Apr 1998 10:39:13 -0700 (PDT) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA6C91; Tue, 21 Apr 1998 10:39:12 -0700 Message-ID: <353CD9C0.8C3155F3@netscape.com> Date: Tue, 21 Apr 1998 10:39:12 -0700 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: ietf-apps-tls@imc.org, iesg@ietf.org Subject: Re: Serious design flaw in STARTLS documents References: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Harald Tveit Alvestrand wrote: > I believe the flaw you indicate is generic to any protocol that > negotiates an integrity or security layer (the same problem arises > with negotiating GSSAPI protection using SASL). > > As such, there are 2 layers of fixes needed: > - Document the problem in the SASL specification, and possibly in > some document that generically describes "negotiating TLS" This is already documented; it is the last paragraph of the "Security Considerations" section of RFC 2222. We may need to make this issue more visible in the IMAP, etc. protocol specifications. From owner-ietf-apps-tls Tue Apr 21 10:40:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12874 for ietf-apps-tls-bks; Tue, 21 Apr 1998 10:40:15 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA12870 for ; Tue, 21 Apr 1998 10:40:14 -0700 (PDT) Received: from elwood.innosoft.com ("port 42230"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IW4MLKUCV6984YUV@INNOSOFT.COM> for ietf-apps-tls@imc.org; Tue, 21 Apr 1998 10:40:57 PDT Date: Tue, 21 Apr 1998 10:42:35 -0700 (PDT) From: Chris Newman Subject: Re: Serious design flaw in STARTLS documents In-reply-to: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> To: Application Use of TLS IETF List 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, 21 Apr 1998, Harald Tveit Alvestrand wrote: > I believe the flaw you indicate is generic to any protocol that > negotiates an integrity or security layer (the same problem arises > with negotiating GSSAPI protection using SASL). > > As such, there are 2 layers of fixes needed: > - Document the problem in the SASL specification, and possibly in > some document that generically describes "negotiating TLS" > ... > It probably needs > to say that after STARTTLS negotiation, the state is as before EHLO; > all state is flushed. I concur with this. I will change draft-newman-tls-imappop appropriately for those protocols. - Chris From owner-ietf-apps-tls Tue Apr 21 10:49:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12965 for ietf-apps-tls-bks; Tue, 21 Apr 1998 10:49:43 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA12961 for ; Tue, 21 Apr 1998 10:49:42 -0700 (PDT) Message-Id: <199804211749.KAA12961@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Tue, 21 Apr 1998 10:49:42 -0700 To: Application Use of TLS IETF List From: Paul Hoffman / IMC Subject: Re: Serious design flaw in STARTLS documents In-Reply-To: References: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Points well taken. I'll revise the SMTP/TLS draft this week to say that SMTP state is cleared after STARTTLS. John: can you provide some wording for what I should say about SASL announcements before and after STARTTLS? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Tue Apr 21 16:50:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA16002 for ietf-apps-tls-bks; Tue, 21 Apr 1998 16:50:56 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA15998 for ; Tue, 21 Apr 1998 16:50:54 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id QAA05206 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Tue, 21 Apr 1998 16:51:40 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA00256 for ; Tue, 21 Apr 1998 16:51:34 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: Re: TLS and ACAP/IMAP/POP Date: Tue, 21 Apr 1998 16:51:34 -0700 Organization: Netscape Communications Corporation Lines: 11 Message-ID: <353D3106.ED7BE65B@netscape.com> References: <199804210030.RAA21100@mail.proper.com> NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > > At 04:23 PM 4/20/98 -0700, Chris Newman wrote: > >(A) Do most or all current SSL/TLS API's support closing TLS without > >closing the underlying socket? If they don't it adds significant extra > >complexity to require it. > > I've been told "yes". Netscape's SSL API currently does not support closing SSL without closing the underlying socket. From owner-ietf-apps-tls Tue Apr 21 16:58:07 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA16064 for ietf-apps-tls-bks; Tue, 21 Apr 1998 16:58:07 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA16060 for ; Tue, 21 Apr 1998 16:58:06 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id QAA05366 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Tue, 21 Apr 1998 16:58:52 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA00241 for ; Tue, 21 Apr 1998 16:58:52 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: Re: Serious design flaw in STARTLS documents Date: Tue, 21 Apr 1998 16:58:51 -0700 Organization: Netscape Communications Corporation Lines: 9 Message-ID: <353D32BB.A6FE0B29@netscape.com> References: <353BECED.EE950710@netscape.com> <199804211512.IAA11095@mail.proper.com> NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > Specifically, if none of the other extensions announced are > security-related, forcing a new EHLO is wasteful. Are you sure client implementors are going to correctly determine which announced extensions are security-critical? For example, PIPELINING is potentially security-critical. If an attacker can convince a client that a server supports PIPELINING, when in fact the server does not, this can cause Bad Things to happen. From owner-ietf-apps-tls Tue Apr 21 17:30:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA16320 for ietf-apps-tls-bks; Tue, 21 Apr 1998 17:30:41 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA16316 for ; Tue, 21 Apr 1998 17:30:40 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id RAA05923 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Tue, 21 Apr 1998 17:31:27 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA00610 for ; Tue, 21 Apr 1998 17:31:26 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: Re: Serious design flaw in STARTLS documents Date: Tue, 21 Apr 1998 17:27:47 -0700 Organization: Netscape Communications Corporation Lines: 29 Message-ID: <353D3983.60A14263@netscape.com> References: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> <199804211749.KAA12961@mail.proper.com> NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > John: can you provide some wording > for what I should say about SASL announcements before and after STARTTLS? Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP Service Extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command next. The list of SMTP Service Extensions returned in response to an EHLO command received after the TLS handshake MAY be different than the list returned before the TLS handshake. For example, a server might not want to advertise support for the SASL EXTERNAL mechanism [SASL] [SMTP-SASL] unless a client has sent an appropriate client certificate during a TLS handshake. A server MUST NOT return the STARTTLS extension in response to an EHLO command received after a TLS handshake has completed. [Add to Security Considerations] Any protocol interactions prior to the TLS handshake are performed in the clear and may be modified by an active attacker. For this reason, section XXX requires that clients and servers discard upon completion of the TLS handshake any knowledge obtained prior to the start of the TLS handshake. From owner-ietf-apps-tls Tue Apr 21 18:25:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA16672 for ietf-apps-tls-bks; Tue, 21 Apr 1998 18:25:29 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA16668 for ; Tue, 21 Apr 1998 18:25:27 -0700 (PDT) Message-Id: <199804220125.SAA16668@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Tue, 21 Apr 1998 18:25:28 -0700 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: Re: Serious design flaw in STARTLS documents In-Reply-To: <353D3983.60A14263@netscape.com> References: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> <199804211749.KAA12961@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk This all seems fine to me, except. >A server MUST NOT return the STARTTLS extension in response >to an EHLO command received after a TLS handshake has completed. (That's the "TLS" extension, by the way...) I would add before that: ===== Both the client and the server must know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active. ===== That is, even if the server doesn't say TLS, the client might issue a STARTTLS command. This covers both sides of the attempt to do TLS over TLS. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Wed Apr 22 12:05:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA07566 for ietf-apps-tls-bks; Wed, 22 Apr 1998 12:05:37 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA07562 for ; Wed, 22 Apr 1998 12:05:36 -0700 (PDT) Received: from elwood.innosoft.com ("port 42543"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IW63UM9HR4984Z0L@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 22 Apr 1998 12:06:11 PDT Date: Wed, 22 Apr 1998 12:07:51 -0700 (PDT) From: Chris Newman Subject: Re: Serious design flaw in STARTLS documents In-reply-to: <353D3983.60A14263@netscape.com> To: John Gardiner Myers 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, 21 Apr 1998, John Gardiner Myers wrote: > ... > > Any protocol interactions prior to the TLS handshake are performed in > the clear and may be modified by an active attacker. For this reason, > section XXX requires that clients and servers discard upon completion of > the TLS handshake any knowledge obtained prior to the start of the TLS > handshake. I'm a bit concerned about this wording. If the user has already authenticated using a SASL mechanism with the SMTP AUTH extension, is that state discarded? I'm also concerned about the implications for starting TLS later on in an IMAP, ACAP or POP session. I see two viable options: (1) STARTTLS is only permitted prior to authentication and always causes new capability negotiations. (2) STARTTLS is permitted at any time and has no effect on authentication state. Clients SHOULD re-issue the command for capabilities. I think (2) is the correct answer. In a situation where active attacks aren't a problem, but privacy is, then it's just a waste to reset protocol state or discard capability information. Comments? - Chris From owner-ietf-apps-tls Wed Apr 22 14:09:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA08711 for ietf-apps-tls-bks; Wed, 22 Apr 1998 14:09:13 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA08707 for ; Wed, 22 Apr 1998 14:09:12 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA25871 for ; Wed, 22 Apr 1998 14:10:00 -0700 (PDT) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA1F99 for ; Wed, 22 Apr 1998 14:10:00 -0700 Message-ID: <353E5CA7.D56E0B64@netscape.com> Date: Wed, 22 Apr 1998 14:10:00 -0700 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-apps-tls@imc.org Subject: Re: Serious design flaw in STARTLS documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Chris Newman wrote: > > On Tue, 21 Apr 1998, John Gardiner Myers wrote: > > ... > > > > Any protocol interactions prior to the TLS handshake are performed in > > the clear and may be modified by an active attacker. For this reason, > > section XXX requires that clients and servers discard upon completion of > > the TLS handshake any knowledge obtained prior to the start of the TLS > > handshake. > > I'm a bit concerned about this wording. > > If the user has already authenticated using a SASL mechanism with the SMTP > AUTH extension, is that state discarded? > > I'm also concerned about the implications for starting TLS later on in an > IMAP, ACAP or POP session. I see two viable options: > > (1) STARTTLS is only permitted prior to authentication and always causes > new capability negotiations. > > (2) STARTTLS is permitted at any time and has no effect on authentication > state. Clients SHOULD re-issue the command for capabilities. > > I think (2) is the correct answer. In a situation where active attacks > aren't a problem, but privacy is, then it's just a waste to reset protocol > state or discard capability information. I think (1) is the correct answer. You want to avoid having to do TLS on top of a SASL security layer, just as you want to avoid having to do TLS on top of TLS. If you authenticate with SASL but do not negotiate a security layer, an active attacker can use your privileges between the SASL authentication and the TLS handshake. If you think you have a situation where active attacks aren't a problem, but privacy is, I think you've mis-identified your threat model. From owner-ietf-apps-tls Wed Apr 22 15:28:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA09295 for ietf-apps-tls-bks; Wed, 22 Apr 1998 15:28:56 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA09291 for ; Wed, 22 Apr 1998 15:28:49 -0700 (PDT) Received: from elwood.innosoft.com ("port 42615"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IW6AYP6OPG9851EX@INNOSOFT.COM> for ietf-apps-tls@imc.org; Wed, 22 Apr 1998 15:29:31 PDT Date: Wed, 22 Apr 1998 15:31:11 -0700 (PDT) From: Chris Newman Subject: Re: Serious design flaw in STARTLS documents In-reply-to: <353E5CA7.D56E0B64@netscape.com> To: Application Use of TLS IETF List 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, 22 Apr 1998, John Myers wrote: > Chris Newman wrote: > > (1) STARTTLS is only permitted prior to authentication and always causes > > new capability negotiations. > > > > (2) STARTTLS is permitted at any time and has no effect on authentication > > state. Clients SHOULD re-issue the command for capabilities. > > I think (1) is the correct answer. You want to avoid having to do TLS > ... > > If you think you have a situation where active attacks aren't a problem, > but privacy is, I think you've mis-identified your threat model. I'm not convinced that such a threat model is non-existant, but I suppose the added complexity of (2) isn't worth the gain in flexibility. However, I'd like to hear from at least one other person before I go ahead and document (1) in the next version of the IMAP/POP/ACAP TLS spec. - Chris From owner-ietf-apps-tls Wed Apr 22 15:57:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA09407 for ietf-apps-tls-bks; Wed, 22 Apr 1998 15:57:22 -0700 (PDT) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA09403 for ; Wed, 22 Apr 1998 15:57:21 -0700 (PDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id RAA01429; Wed, 22 Apr 1998 17:58:06 -0500 (CDT) Received: from dal-tx7-21.ix.netcom.com(207.94.122.149) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma001410; Wed Apr 22 17:57:52 1998 Message-ID: <353E1290.598C17BB@ix.netcom.com> Date: Wed, 22 Apr 1998 16:53:54 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: John Myers CC: ietf-apps-tls@imc.org Subject: Re: Serious design flaw in STARTLS documents References: <353E5CA7.D56E0B64@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk John and all, John Myers wrote: > Chris Newman wrote: > > > > On Tue, 21 Apr 1998, John Gardiner Myers wrote: > > > ... > > > > > > Any protocol interactions prior to the TLS handshake are performed in > > > the clear and may be modified by an active attacker. For this reason, > > > section XXX requires that clients and servers discard upon completion of > > > the TLS handshake any knowledge obtained prior to the start of the TLS > > > handshake. > > > > I'm a bit concerned about this wording. > > > > If the user has already authenticated using a SASL mechanism with the SMTP > > AUTH extension, is that state discarded? > > > > I'm also concerned about the implications for starting TLS later on in an > > IMAP, ACAP or POP session. I see two viable options: > > > > (1) STARTTLS is only permitted prior to authentication and always causes > > new capability negotiations. > > > > (2) STARTTLS is permitted at any time and has no effect on authentication > > state. Clients SHOULD re-issue the command for capabilities. > > > > I think (2) is the correct answer. In a situation where active attacks > > aren't a problem, but privacy is, then it's just a waste to reset protocol > > state or discard capability information. > > I think (1) is the correct answer. You want to avoid having to do TLS > on top of a SASL security layer, just as you want to avoid having to do > TLS on top of TLS. If you authenticate with SASL but do not negotiate a > security layer, an active attacker can use your privileges between the > SASL authentication and the TLS handshake. > > If you think you have a situation where active attacks aren't a problem, > but privacy is, I think you've mis-identified your threat model. I agree with you assessment here John. I have argued with Chris on this matter several times some time ago now. Hence we went ahead and developed our own Interface Facility or MLPI to thwart some of these types of concerns. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Wed Apr 22 17:25:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA10078 for ietf-apps-tls-bks; Wed, 22 Apr 1998 17:25:59 -0700 (PDT) Received: from blinky.ccmail.com (blinky.ccmail.com [192.216.79.99]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA10074 for ; Wed, 22 Apr 1998 17:25:58 -0700 (PDT) Received: from smtpgate.ccmail.com (smtpgate.ccmail.com [192.108.1.202]) by blinky.ccmail.com (8.8.5/8.6.9) with SMTP id RAA25362 for ; Wed, 22 Apr 1998 17:28:56 -0700 (PDT) Received: from ccMail by smtpgate.ccmail.com (ccMail Link to SMTP R8.20.00.15 BETA) id AA893291206; Wed, 22 Apr 1998 17:26:50 -0800 Message-Id: <9804228932.AA893291206@smtpgate.ccmail.com> X-Mailer: ccMail Link to SMTP R8.20.00.15 BETA Date: Wed, 22 Apr 1998 17:25:09 -0800 From: "CJ Lofstedt" To: Subject: Re[2]: Serious design flaw in STARTLS documents MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk I agree with John. I cannot see any advantage with (2), just risks. /C-J ____________________Reply Separator____________________ Subject: Re: Serious design flaw in STARTLS documents Author: Chris Newman Date: 4/22/98 3:31 PM On Wed, 22 Apr 1998, John Myers wrote: > Chris Newman wrote: > > (1) STARTTLS is only permitted prior to authentication and always causes > > new capability negotiations. > > > > (2) STARTTLS is permitted at any time and has no effect on authentication > > state. Clients SHOULD re-issue the command for capabilities. > > I think (1) is the correct answer. You want to avoid having to do TLS > ... > > If you think you have a situation where active attacks aren't a problem, > but privacy is, I think you've mis-identified your threat model. I'm not convinced that such a threat model is non-existant, but I suppose the added complexity of (2) isn't worth the gain in flexibility. However, I'd like to hear from at least one other person before I go ahead and document (1) in the next version of the IMAP/POP/ACAP TLS spec. - Chris From owner-ietf-apps-tls Wed Apr 22 19:29:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA10649 for ietf-apps-tls-bks; Wed, 22 Apr 1998 19:29:57 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA10645 for ; Wed, 22 Apr 1998 19:29:54 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id TAA04777 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Wed, 22 Apr 1998 19:30:29 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA24587 for ; Wed, 22 Apr 1998 19:30:13 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: STARTLS/AUTH interaction Date: Wed, 22 Apr 1998 19:30:12 -0700 Organization: Netscape Communications Corporation Lines: 3 Message-ID: <353EA7B4.B3EAAE3A@netscape.com> References: <9804228932.AA893291206@smtpgate.ccmail.com> NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Should the SMTP AUTH document explicitly forbid STARTLS after an authentication, or is it sufficient for the SMTP TLS document to forbid this? From owner-ietf-apps-tls Wed Apr 22 20:07:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA10848 for ietf-apps-tls-bks; Wed, 22 Apr 1998 20:07:29 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA10843 for ; Wed, 22 Apr 1998 20:07:28 -0700 (PDT) Message-Id: <199804230307.UAA10843@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Wed, 22 Apr 1998 20:07:33 -0700 To: ietf-apps-tls@imc.org From: Paul Hoffman / IMC Subject: Re: STARTLS/AUTH interaction In-Reply-To: <353EA7B4.B3EAAE3A@netscape.com> References: <9804228932.AA893291206@smtpgate.ccmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 07:30 PM 4/22/98 -0700, John Gardiner Myers wrote: >Should the SMTP AUTH document explicitly forbid STARTLS after an >authentication, or is it sufficient for the SMTP TLS document to forbid >this? I think it is sufficient for SMTP/TLS to do so. What if someone comes up with SMTP/SSH? SMTP/FOO? It's the job of those protocols to define what can and can't be done. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Fri Apr 24 13:10:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA25003 for ietf-apps-tls-bks; Fri, 24 Apr 1998 13:10:57 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA24999 for ; Fri, 24 Apr 1998 13:10:56 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id NAA21906 for <@starfish.mcom.com:ietf-apps-tls@imc.org>; Fri, 24 Apr 1998 13:11:45 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA04562 for ; Fri, 24 Apr 1998 13:11:35 -0700 To: ietf-apps-tls@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-apps-tls Subject: TLS vs STARTTLS Date: Fri, 24 Apr 1998 13:11:34 -0700 Organization: Netscape Communications Corporation Lines: 7 Message-ID: <3540F1F6.E686C5D2@netscape.com> References: <3.0.2.32.19980421123025.0097b280@dokka.kvatro.no> <199804211749.KAA12961@mail.proper.com> <199804220125.SAA16668@mail.proper.com> NNTP-Posting-Host: 205.217.229.78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > (That's the "TLS" extension, by the way...) I would add before that: Gaah, hadn't noticed that. Having the extension be "TLS" in SMTP, but be "STARTTLS" in IMAP and ACAP seems like a bad thing to me. Would it be reasonable to change the SMTP extension to "STARTTLS" at this late time? From owner-ietf-apps-tls Fri Apr 24 15:50:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA26251 for ietf-apps-tls-bks; Fri, 24 Apr 1998 15:50:29 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.7.3) with SMTP id PAA26243 for ; Fri, 24 Apr 1998 15:50:28 -0700 (PDT) Received: from CASSATT ([157.59.248.115]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2207.0) id JSJ1KAV0; Fri, 24 Apr 1998 15:51:31 -0700 Message-ID: <001d01bd6fd3$10bb12c0$73f83b9d@cassatt.microsoft.com> From: "Jeff Stephenson" To: Subject: Re: TLS vs STARTTLS Date: Fri, 24 Apr 1998 15:48:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk -----Original Message----- From: John Gardiner Myers Date: Friday, April 24, 1998 1:14 PM >Gaah, hadn't noticed that. Having the extension be "TLS" in SMTP, but >be "STARTTLS" in IMAP and ACAP seems like a bad thing to me. Would it >be reasonable to change the SMTP extension to "STARTTLS" at this late >time? I don't think it would be reasonable, since we're already shipping Exchange 5.5 with TLS advertised in the EHLO response. In general I agree that that it would be nice to (1) have the capability keyword and the protocol command share a name and (2) have similar capabilities across protocols share a name. However, I don't think it's that big a deal if these criteria aren't met. I say keep it advertised as TLS. -- jeff From owner-ietf-apps-tls Fri Apr 24 15:50:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA26250 for ietf-apps-tls-bks; Fri, 24 Apr 1998 15:50:29 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.7.3) with SMTP id PAA26242 for ; Fri, 24 Apr 1998 15:50:28 -0700 (PDT) Received: from CASSATT ([157.59.248.115]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2207.0) id JSJ1KAV8; Fri, 24 Apr 1998 15:51:31 -0700 Message-ID: <001c01bd6fd3$1091b8d0$73f83b9d@cassatt.microsoft.com> From: "Jeff Stephenson" To: Subject: Re: TLS vs STARTTLS Date: Fri, 24 Apr 1998 15:46:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk -----Original Message----- From: John Gardiner Myers Date: Friday, April 24, 1998 1:14 PM >Gaah, hadn't noticed that. Having the extension be "TLS" in SMTP, but >be "STARTTLS" in IMAP and ACAP seems like a bad thing to me. Would it >be reasonable to change the SMTP extension to "STARTTLS" at this late >time? I don't think it would be reasonable, since we're already shipping Exchange 5.5 with TLS advertised in the EHLO response. In general I agree that that it would be nice to (1) have the capability keyword and the protocol command share a name and (2) have similar capabilities across protocols share a name. However, I don't think it's that big a deal if these criteria aren't met. I say keep it advertised as TLS. -- jeff From owner-ietf-apps-tls Fri Apr 24 16:19:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA26396 for ietf-apps-tls-bks; Fri, 24 Apr 1998 16:19:38 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA26392 for ; Fri, 24 Apr 1998 16:19:36 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id SAA28109; Fri, 24 Apr 1998 18:20:34 -0500 (CDT) Received: from dal-tx7-05.ix.netcom.com(207.94.122.133) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma028098; Fri Apr 24 18:20:13 1998 Message-ID: <3540BAC2.D8DEBDA@ix.netcom.com> Date: Fri, 24 Apr 1998 17:16:03 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: Jeff Stephenson CC: ietf-apps-tls@imc.org Subject: Re: TLS vs STARTTLS References: <001c01bd6fd3$1091b8d0$73f83b9d@cassatt.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Jeff and all, Jeff Stephenson wrote: > -----Original Message----- > From: John Gardiner Myers > Date: Friday, April 24, 1998 1:14 PM > > >Gaah, hadn't noticed that. Having the extension be "TLS" in SMTP, but > >be "STARTTLS" in IMAP and ACAP seems like a bad thing to me. Would it > >be reasonable to change the SMTP extension to "STARTTLS" at this late > >time? > > I don't think it would be reasonable, since we're already shipping Exchange > 5.5 with TLS advertised in the EHLO response. In general I agree that that > it would be nice to (1) have the capability keyword and the protocol command > share a name and (2) have similar capabilities across protocols share a > name. However, I don't think it's that big a deal if these criteria aren't > met. I say keep it advertised as TLS. Well first of all it is not necessary to change SMTP to provide for "STARTTLS", but I will leave you all to figure that one out for yourselves. >;) We already provide for your #1 and #2 in our TLS custom extensions in our Interface Facility or MLPI currently. However it would be nice to add this to the spec. Or create a APPS spec for TLS to do this. > > > -- jeff Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com From owner-ietf-apps-tls Wed May 27 14:02:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19455 for ietf-apps-tls-bks; Wed, 27 May 1998 14:02:48 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19442 for ; Wed, 27 May 1998 14:01:26 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA23422 for ; Wed, 27 May 1998 14:05:07 -0700 (PDT) Received: from netscape.com ([208.12.60.63]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA6731; Wed, 27 May 1998 14:05:06 -0700 Message-ID: <356C7FFD.896890E9@netscape.com> Date: Wed, 27 May 1998 14:05:01 -0700 From: jgmyers@Netscape.COM (John Myers) X-Mailer: Mozilla 4.09 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-apps-tls@imc.org, iesg@iesg.org Subject: draft-hoffman-smtp-tls: TLS vs STARTTLS References: <001d01bd6fd3$10bb12c0$73f83b9d@cassatt.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At the last IMC Mailconnect interoperability event, we found that implementations of draft-hoffman-smtp-ssl-06.txt did not interoperate with Exchange 5.5, which conforms to an earlier version of the draft. The changes to the draft were to fix a vulnerability to a man-in-the-middle attack. At the meeting, there was general consensus to fix this problem by changing the name of the EHLO extension from "TLS" to "STARTTLS", so that Exchange 5.5 and implementations of recent revisions of draft-hoffman-smtp-ssl-06 do not try to negotiate TLS. Assuming that consensus holds on the ietf-apps-tls mailing list, I would like to request this change be made before the document is approved as a Proposed Standard. From owner-ietf-apps-tls Wed May 27 14:27:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19628 for ietf-apps-tls-bks; Wed, 27 May 1998 14:27:37 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA19624 for ; Wed, 27 May 1998 14:27:36 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2221.0) id ; Wed, 27 May 1998 14:32:53 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010793E968@DINO> From: "Jeff Stephenson (Exchange)" To: ietf-apps-tls@imc.org, iesg@iesg.org Subject: RE: draft-hoffman-smtp-tls: TLS vs STARTTLS Date: Wed, 27 May 1998 14:32:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2221.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk We at Microsoft definitely support this. It also has the beneficial side-effect of bringing the keyword into line with both the verb and the way in which people refer to the feature. -- jeff -----Original Message----- From: jgmyers@Netscape.COM [mailto:jgmyers@Netscape.COM] Sent: Wednesday, May 27, 1998 2:05 PM At the last IMC Mailconnect interoperability event, we found that implementations of draft-hoffman-smtp-ssl-06.txt did not interoperate with Exchange 5.5, which conforms to an earlier version of the draft. The changes to the draft were to fix a vulnerability to a man-in-the-middle attack. At the meeting, there was general consensus to fix this problem by changing the name of the EHLO extension from "TLS" to "STARTTLS", so that Exchange 5.5 and implementations of recent revisions of draft-hoffman-smtp-ssl-06 do not try to negotiate TLS. Assuming that consensus holds on the ietf-apps-tls mailing list, I would like to request this change be made before the document is approved as a Proposed Standard. From owner-ietf-apps-tls Wed May 27 15:55:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20280 for ietf-apps-tls-bks; Wed, 27 May 1998 15:55:18 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA20276; Wed, 27 May 1998 15:55:17 -0700 (PDT) Message-Id: <199805272255.PAA20276@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 27 May 1998 15:59:30 -0700 To: ietf-apps-tls@imc.org, iesg@iesg.org From: Paul Hoffman / IMC Subject: Re: draft-hoffman-smtp-tls: TLS vs STARTTLS In-Reply-To: <356C7FFD.896890E9@netscape.com> References: <001d01bd6fd3$10bb12c0$73f83b9d@cassatt.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-apps-tls@imc.org Precedence: bulk At 02:05 PM 5/27/98 -0700, John Myers wrote: >Assuming that consensus holds on the ietf-apps-tls mailing list, I would >like to request this change be made before the document is approved as a >Proposed Standard. I support this as well. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-apps-tls Fri Jul 10 22:53:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA12534 for ietf-apps-tls-bks; Fri, 10 Jul 1998 22:53:06 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA12530 for ; Fri, 10 Jul 1998 22:53:04 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id WAA17834 for ; Fri, 10 Jul 1998 22:53:18 -0700 (PDT) Received: from borate.Stanford.EDU (borate.Stanford.EDU [171.64.7.37]) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id HAA10550 for ; Wed, 8 Jul 1998 07:38:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by borate.Stanford.EDU (8.8.8/8.7.3) with ESMTP id HAA16613 for ; Wed, 8 Jul 1998 07:38:00 -0700 (PDT) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id IAA03482 for ietf-123-outbound.06@ietf.org; Wed, 8 Jul 1998 08:55:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA03164; Wed, 8 Jul 1998 08:40:39 -0400 (EDT) Message-Id: <199807081240.IAA03164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@Netscape.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-authmeth-02.txt Date: Wed, 08 Jul 1998 08:40:39 -0400 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Authentication Methods for LDAP Author(s) : H. Alvestrand, M. Wahl Filename : draft-ietf-ldapext-authmeth-02.txt Pages : 15 Date : 07-Jul-98 This document specifies particular combinations of SASL [2] mechanisms and extensions which are required and recommended in LDAP [1] implementations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-authmeth-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-authmeth-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-authmeth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980707123629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-authmeth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-authmeth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980707123629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-apps-tls Fri Jul 10 22:53:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA12545 for ietf-apps-tls-bks; Fri, 10 Jul 1998 22:53:57 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA12541 for ; Fri, 10 Jul 1998 22:53:56 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id WAA16403 for ; Fri, 10 Jul 1998 22:54:10 -0700 (PDT) Received: from borate.Stanford.EDU (borate.Stanford.EDU [171.64.7.37]) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id GAA13714 for ; Thu, 9 Jul 1998 06:40:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by borate.Stanford.EDU (8.8.8/8.7.3) with ESMTP id GAA28318 for ; Thu, 9 Jul 1998 06:40:36 -0700 (PDT) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id IAA02080 for ietf-123-outbound.06@ietf.org; Thu, 9 Jul 1998 08:15:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA01418; Thu, 9 Jul 1998 07:44:51 -0400 (EDT) Message-Id: <199807091144.HAA01418@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@Netscape.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldapv3-tls-01.txt Date: Thu, 09 Jul 1998 07:44:50 -0400 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Author(s) : J. Hodges, B. Morgan, M. Wahl Filename : draft-ietf-ldapext-ldapv3-tls-01.txt Pages : 10 Date : 08-Jul-98 This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-ldapv3-tls-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-tls-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-ldapv3-tls-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980708150306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-tls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-tls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708150306.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-apps-tls Fri Jul 10 23:27:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12644 for ietf-apps-tls-bks; Fri, 10 Jul 1998 23:27:09 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12640 for ; Fri, 10 Jul 1998 23:27:08 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id XAA15683 for ; Fri, 10 Jul 1998 23:27:23 -0700 (PDT) Message-Id: <199807110627.XAA15683@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: draft-ietf-ldapext-ldapv3-tls-01.txt & draft-ietf-ldapext-authmeth-02.txt To: ietf-apps-tls@imc.org From: Jeff.Hodges@stanford.edu Reply-to: ietf-apps-tls@imc.org X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Jul 1998 23:27:23 -0700 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk Re the availability of new versions of.. draft-ietf-ldapext-authmeth-02.txt draft-ietf-ldapext-ldapv3-tls-01.txt ..here's a summary of what's new in these docs since the last versions. ----------------------------------------------------------------------------- Doc changes for draft-ietf-ldapext-authmeth-02.txt from -01 version... - updated section: 3. Introduction with revised threats and security mechanisms enumerations. - updated section: 4. Deployment scenarios with revised scenarios. - added section: 5. Authentication and Authorization: Definitions and Concepts from draft-ietf-ldapext-ldapv3-tls-01.txt - updated section: 6. Required Security Mechanisms - draws distinctions between passive eavesdropping attacks and active intermediary attacks. - revised security conformance requirements. - various detailed refinements to sections: 7. Anonymous authentication 8. Password-based authentication 9. Certificate-based authentication - added section: 11. Authorization Identity - syntax for authorization id included with SASL "EXTERNAL"-flavored Bind - updated section: 12. TLS Ciphersuites - refined and expanded ciphersuite list. Commented on threats different classes of ciphersuites are susceptable to. - Overall subtle-but-important change to doc is to recognize.. - authorization identities are not always represented as DNs ----------------------------------------------------------------------------- Doc changes for draft-ietf-ldapext-ldapv3-tls-01.txt from -00 version... - Removed Section: 6. Authentication and Authorization: Definitions and Concepts ..and moved it to draft-ietf-ldapext-authmeth-02.txt - added Section: 4.3. TLS Version Negotiation - added Section: 4.6. Server Identity Check - refined and expanded: 6. Effects of TLS on a Client's Authorization Identity - changed "invalidAuthorizationId" error to "invalidCredentials" A state diagram corresponding to this draft is available at.. http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.html ----------------------------------------------------------------------------- From owner-ietf-apps-tls Mon Jul 27 12:01:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA05187 for ietf-apps-tls-bks; Mon, 27 Jul 1998 12:01:03 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05183 for ; Mon, 27 Jul 1998 12:01:02 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id MAA22089; Mon, 27 Jul 1998 12:02:27 -0700 (PDT) Message-Id: <199807271902.MAA22089@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt To: Jonathan Trostle , ietf-ldapext@Netscape.COM cc: ietf-apps-tls@imc.org In-reply-to: Your message of Fri, 24 Jul 1998 13:20:24 -0700 Reply-to: Jeff.Hodges@stanford.edu From: Jeff.Hodges@stanford.edu X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jul 1998 12:02:26 -0700 Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > > Helmut.Baumgaertner@mch.sni.de said: > > > Any particular reason for not using authMethodNotSupported as the > > > resultCode in case the LDAP server does not support TLS and cannot > > > return a referral. > > > > Jeff Hodges responded: > > Yes, the reasons we designed it like this are that.. > > > - TLS isn't necessarily an authentication method. It of course ~can~ be, but > > isn't by default. > > > > - the client may be trying to send the operation to an LDAPv2 server, and it > > will hopefully respond with a protocolError -- so we're trying to keep the > > semantics consistent. > > > > Plus, a v3-capable client may ascertain whether the server it is talking with > > supports StartTLS by querying the server's root DSE for the supportedExtension > > attribute and checking to see that StartTLS is listed. > > Jonathan Trostle pointed out: > Presumably the client wants to use TLS because the wire is not > trusted; how is the querying of the server's root DSE for the > supportedExtension attribute and checking for StartTLS protected? Good point, it's not protected if done before integrity and/or confidentiality is ensured on the connection. This topic has been recently discussed in terms of IMAP (see below). It seems to me that we should consider adding another subsection to section 4, along these lines... --------- 4.7 Refresh of Server Capabilities Information The client SHOULD refresh any cached server capabilities information (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session establishment. This is necessary to protect against active-intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment. --------- Although draft-newman-tls-imappop-04.txt doesn't seem to indicate the connotations of the last sentence "The server MAY advertise different capabilities after TLS establishment." It seems that that could be taken to mean that the server legitimately updated its capabilities information once TLS is started for that client, or it could mean that an active attacker mucked with the originally retrieved capabilities info. I suspect that Chris is intending the former connotation, but I'm not sure. Also, we could perhaps update the security considerations section of draft-ietf-ldapext-ldapv3-tls-01.txt to reflect user interface assertions similar to those in draft-newman-tls-imappop-04.txt's security considerations section. Also, the final sec. considerations paragraph says.. "Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality is required." ..and I think we should consider enhancing it like so.. "Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality is required, as well as elect whether and when client authentication via TLS is required." Jeff -------------------------------------------- Date: Wed, 15 Jul 1998 17:39:03 -0700 From: John Gardiner Myers To: imap@u.washington.edu Subject: Re: Unsolicited CAPABILITY response If the client and server negotiate a SASL security layer, it is important for the client to discard its information about server capabilities and re-issue the CAPABILITY command. Otherwise, an active attacker could fool the client by inserting or modifying a CAPABILITY response before authentication completes. For this reason, the STARTTLS extension in draft-newman-tls-imappop-04.txt explicitly modifies the don't-change-CAPABILITIES requirement of the base IMAP specification. -------------------------------------------- Date: Thu, 16 Jul 1998 15:59:18 -0700 (PDT) From: Chris Newman To: imap@u.washington.edu Subject: Re: Unsolicited CAPABILITY response On Wed, 15 Jul 1998, John Gardiner Myers wrote: > If the client and server negotiate a SASL security layer, it is > important for the client to discard its information about server > capabilities and re-issue the CAPABILITY command. Otherwise, an active > attacker could fool the client by inserting or modifying a CAPABILITY > response before authentication completes. For this reason, the STARTTLS > extension in draft-newman-tls-imappop-04.txt explicitly modifies the > don't-change-CAPABILITIES requirement of the base IMAP specification. That draft only waives the requirement after the "STARTTLS" command is issued: Once TLS has been started, the client SHOULD discard cached information about server capabilities and re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. Since the purpose of STARTTLS is to protect against active attacks, it would defeat the purpose if the client trusted information from before the STARTTLS command. The last sentence is added incentive to do the right thing. Incidentally, this language needs to be put in the base spec for the case where a security layer is negotiated by SASL, for the same reason. - Chris -------------------------------------------- From owner-ietf-apps-tls Wed Jul 29 05:17:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14588 for ietf-apps-tls-bks; Wed, 29 Jul 1998 05:17:57 -0700 (PDT) Received: from Qajaq.Stanford.EDU (Qajaq.Stanford.EDU [171.64.20.202]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14584 for ; Wed, 29 Jul 1998 05:17:56 -0700 (PDT) Received: from Perq.Stanford.EDU (csp-co6-15.ix.netcom.com [206.217.108.207]) by Qajaq.Stanford.EDU (8.8.0/8.7.1) with SMTP id FAA09950; Wed, 29 Jul 1998 05:23:07 -0700 (PDT) Date: Wed, 29 Jul 1998 06:19:49 -0600 (MDT) From: RL Bob Morgan X-Sender: morgan@Perq.Stanford.EDU Reply-To: RL Bob Morgan To: "ietf-ldapext@netscape.com LDAPEXT" cc: ietf-apps-tls@imc.org Subject: Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt In-Reply-To: <199807232000.NAA14872@Wind.Stanford.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk On Thu, 23 Jul 1998 Jeff.Hodges@stanford.edu wrote: > ... > > In the absence of a subjectAltName extension of type dNSName in the > > certificate: how should the compare algorithm should look like, as > > the only ldap server name in the cert - the subjectName field - will > > be an X.500 Distinguished Name? Some RDNs may contain rfc822MailBox > > names or something else that allows a mapping onto the servers > > hostname. > > > The cert may also contain subjectAltName extensions distinct from > > dNSName, but nevertheless suitable for identity check, e.g > > rfc822Name, uniformResourceIdentifier or iPAddress. > > Defining this check down to every last possibility is something we've been > hoping to avoid. The check is based on the one in draft-ietf-tls-https-01.txt > and is written as per conversations with Jeff Schiller and Harald Alvestrand. > ... > I'm inclined to leave our text as-is for now, but raise this issue on > ietf-pkix@imc.org (e.g. "hey, we think that end-entity server certs should > have a subjectAltName of type dNSName whether or not they have a subjectName, > because of this client checking the server thing, what do you folks think?") > and see what they have to say. We had a discussion on just this question (whether and how a TLS client should check the server-supplied cert with the server's name and/or address) at the ldapext WG session in LA. One knowledgeable opinionated person said that if this check isn't fully specified and absolutely required we may as well throw all the other security out the window. Another knowledgeable opinionated person said this issue is such a mess and so poorly understood that we would be jumping into a deep black hole if we even mentioned it in the spec. We concluded that consensus is lacking, hence the weasel wording in the spec. I strongly suggest that we don't want this issue to hold up this document. - RL "Bob" From owner-ietf-apps-tls Wed Jul 29 05:16:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14570 for ietf-apps-tls-bks; Wed, 29 Jul 1998 05:16:32 -0700 (PDT) Received: from Qajaq.Stanford.EDU (Qajaq.Stanford.EDU [171.64.20.202]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14566 for ; Wed, 29 Jul 1998 05:16:31 -0700 (PDT) Received: from Perq.Stanford.EDU (csp-co6-15.ix.netcom.com [206.217.108.207]) by Qajaq.Stanford.EDU (8.8.0/8.7.1) with SMTP id FAA09947; Wed, 29 Jul 1998 05:21:36 -0700 (PDT) Date: Wed, 29 Jul 1998 06:18:18 -0600 (MDT) From: RL Bob Morgan X-Sender: morgan@Perq.Stanford.EDU Reply-To: RL Bob Morgan To: Jeff.Hodges@stanford.edu cc: Jonathan Trostle , ietf-ldapext@Netscape.COM, ietf-apps-tls@imc.org Subject: Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt In-Reply-To: <199807271902.MAA22089@Wind.Stanford.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-apps-tls@imc.org Precedence: bulk > --------- > 4.7 Refresh of Server Capabilities Information > > The client SHOULD refresh any cached server capabilities information (e.g. > from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session > establishment. This is necessary to protect against active-intermediary > attacks which may have altered any server capabilities information retr