From vesely@tana.it Sat Aug 1 08:39:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CD33A67E7 for ; Sat, 1 Aug 2009 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6nL7D0KOCEi for ; Sat, 1 Aug 2009 08:39:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 716303A67F4 for ; Sat, 1 Aug 2009 08:39:26 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 01 Aug 2009 17:39:25 +0200 id 00000000005DC030.000000004A7461AD.00007899 Message-ID: <4A7461B8.6020104@tana.it> Date: Sat, 01 Aug 2009 17:39:36 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Q: An API to report network abuse locally Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 15:39:27 -0000 Hi all, I'm wondering whether there is anything better than parsing log files to get specific types of abuse. Dictionary attacks, netbot spam, and similar bad behavior can be diagnosed by the relevant application. It responds a suitable error code, and usually writes a log line. It is CPU intensive to parse the log files in order to extract the relevant IP address and take appropriate action. (The specific action, e.g. block port 25 using iptables for the next 10 minutes, is obviously part of local system/network policies.) Isn't it possible to configure what agent should get what notices without parsing log files? Would that be part of SNMP, GSS, STREAMS or what? Any idea? TIA From julian.reschke@gmx.de Mon Aug 10 05:27:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017983A6C8B for ; Mon, 10 Aug 2009 05:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=-2.874, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouzdh6+8rsmO for ; Mon, 10 Aug 2009 05:27:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F33C03A6BB0 for ; Mon, 10 Aug 2009 05:27:55 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2009 12:21:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 10 Aug 2009 14:21:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+hxFJpNYahjHdBE+9Q4vbxtNSkkEusYLmKAyBQGX h3GzMzxYP/PxsC Message-ID: <4A8010B3.1050100@gmx.de> Date: Mon, 10 Aug 2009 14:21:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Calsify , CardDAV , Apps Discuss Subject: Call for feedback on HTML5 spec on "predefined vocabularies" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 12:27:57 -0000 Hi, (cross-posted to IETF apps-discuss, plus vcarddav and calsify mailing lists) the W3C HTML Working Group is currently preparing a new Working Draft for HTML5. This will be based on the current Editor's Draft at ). A significant change since the last Working Draft is the introduction of "microdata", a way to augment the markup with semantics, similar to and competing with RDFa and microformats in general (see ). As part of introducing microdata, the spec also defines several "predefined vocabularies". Some of them are based on IETF formats (and this is why I'm writing this particular email). One of these vocabularies is "vcard" (see ). As far as I can tell, the HTML spec more or less duplicates information from RFC 2426, and while doing so also introduces specific compliance criteria. It does *not* refer to , so, as far as I can tell, it would hardwire the vocabulary to a soon-to-be-outdated version of the spec, and also removes the inherent extensibility model. Another predefined vocabulary is "vevent" (see ), to which similar observations apply. I have talked to this to many W3C and IETF people, and as far as I can tell, almost all of them consider this to be a Bad Idea. In particular, it seems that the author has not even tried to co-ordinate with the two applicable IETF Working Groups (I just checked the mailing list archives, and couldn't find anything, but maybe I'm missing something). I'm not sure whether the two working groups have considered this issue yet. I encourage to look at the spec now (), or as soon as a new Working Draft is published. In case the Calsify and/or Vcarddav Working Groups want to comment on this, I encourage the chairs to send feedback directly to the W3C HTML WG, so that the feedback gets the proper attention. Best regards, Julian From julian.reschke@gmx.de Tue Aug 11 06:48:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBF13A6ACF for ; Tue, 11 Aug 2009 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.068 X-Spam-Level: X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i39YfgLc3VRx for ; Tue, 11 Aug 2009 06:48:04 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0E99B3A684A for ; Tue, 11 Aug 2009 06:48:03 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2009 13:46:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp066) with SMTP; 11 Aug 2009 15:46:32 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+1DE4nd921IGHaSb9m3+6457nq+oPEokNmGsdPU4 r8Vut4uMmkLoKZ Message-ID: <4A81762B.4040204@gmx.de> Date: Tue, 11 Aug 2009 15:46:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss Subject: ietf-charsets archive gone? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 13:48:05 -0000 Hi, it was just pointed out to me that it's hard (impossible?) to find the archive for the ietf-charsets mailing list. points to , but that 404s (maybe just recently?). mentions the list, but doesn't point to an archive (I did find a copy at lists.w3.org, but it stops in 2004). What's going on here? BR, Julian From aeh@db.org Mon Aug 10 12:41:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C7628C259; Mon, 10 Aug 2009 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.293 X-Spam-Level: X-Spam-Status: No, score=-4.293 tagged_above=-999 required=5 tests=[AWL=2.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvOa7aaoGZRP; Mon, 10 Aug 2009 12:41:08 -0700 (PDT) Received: from submit-tmp.sysedata.no (submit-tmp.sysedata.no [195.159.29.133]) by core3.amsl.com (Postfix) with ESMTP id 25A1E28C26C; Mon, 10 Aug 2009 12:40:50 -0700 (PDT) Received: from [84.215.125.199] (helo=[10.0.0.31]) by submit-tmp.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Maajf-0005yO-RN; Mon, 10 Aug 2009 21:40:47 +0200 Message-ID: <4A8077BE.6080903@db.org> Date: Mon, 10 Aug 2009 21:40:46 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: draft-ietf-behave-turn-uri@tools.ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> In-Reply-To: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Aug 2009 12:55:43 -0700 Cc: apps-discuss@ietf.org, behave@ietf.org, 'Behave Chairs' X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:41:09 -0000 Dan Wing wrote: > BEHAVE is starting a 3 week working group last call (WGLC), ending August 19, > for > > draft-ietf-behave-turn-uri-02 > "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers" > > > *** Review by folks familiar with URIs are encouraged. *** > > > Please send technical comments to the BEHAVE list, and editorial comments to > the authors. > I have done a WGLC review of the document draft-ietf-behave-turn-uri-02. The document looks good, it is quite easy to read, and it should be quite easy to implement from reading the text. I do not have any major comments. /alfred From ravisha22@gmail.com Thu Aug 13 04:02:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3521F3A69C8 for ; Thu, 13 Aug 2009 04:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odC6MVS-1vfF for ; Thu, 13 Aug 2009 04:02:57 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 5F3F33A680D for ; Thu, 13 Aug 2009 04:02:57 -0700 (PDT) Received: by qyk41 with SMTP id 41so558650qyk.29 for ; Thu, 13 Aug 2009 04:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fMc0cJMh3XDC8lIThDCBfqz5qnWCrdIvo/fD2x5lCcU=; b=rrVMxRMoCmxyCkVcNZ2X8599IL/xF+XZmBxHfROXfVSKLKWr6kbzBTBx36lVRQgO1/ ecY7qZNBbSLMiqMUOPcZXjMC8S9k4MmBp/wCgwo4D4jt8Mu6Y12hjt6yQp6s3DSQxDkS GV58PiZuwdIUyN9iRg5S4OQgoL3N4nx1WOcco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QZJBAvR7Bx0e9ui3gxrdLfQrzXnkH06LXMfGcpyym83RcU3zPDIEnOJtgY3es1POvl Ajt++faY+2dWEBSVb55LascSWSECAsUH/lYAZTuPX6rRo2Cf+NIWFcfrIQakang1SPFC 5ADkCXdzthG9I/0VQu3pFs2pi4QKBvm4hBzbI= MIME-Version: 1.0 Received: by 10.224.7.80 with SMTP id c16mr1013814qac.381.1250161004026; Thu, 13 Aug 2009 03:56:44 -0700 (PDT) Date: Thu, 13 Aug 2009 16:26:44 +0530 Message-ID: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> Subject: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001485188e088e9ebe047103caad X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:02:58 -0000 --001485188e088e9ebe047103caad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, Need your valuable inputs on the subject of ability to extend the POP3 and IMAP4 to send mails, in addition to retrieving mails. I'm currently doing a research on this topic and would like to have your valuable feedbacks on the possibility and probably hinderance in terms of any step in the process. Appreciate your help! Regards, Ravi --001485188e088e9ebe047103caad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
Need your valuable inputs on the subject of ability to extend the POP3= and IMAP4 to send mails, in addition to retrieving mails.
=A0
I'm currently doing a research on this topic and would like to hav= e your valuable feedbacks on the possibility and probably hinderance in ter= ms of any step in the process.
=A0
Appreciate your help!
=A0
Regards,
Ravi
=A0
--001485188e088e9ebe047103caad-- From al@akc.com Thu Aug 13 06:03:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7713A6B15 for ; Thu, 13 Aug 2009 06:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqp5dnBLRUW5 for ; Thu, 13 Aug 2009 06:03:50 -0700 (PDT) Received: from imail.akc.com (imail.akc.com [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id 87EFC3A6AD6 for ; Thu, 13 Aug 2009 06:03:50 -0700 (PDT) Received: from upstairs.akc.com [64.253.39.242] by imail.akc.com with SMTP; Thu, 13 Aug 2009 09:02:40 -0400 Message-ID: <006301ca1c1e$afc7bd60$3c01a8c0@upstairs> From: "Al Costanzo" To: "Ravi shankar" , References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Date: Thu, 13 Aug 2009 09:02:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01CA1BF4.C5EDD9F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:03:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0060_01CA1BF4.C5EDD9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ravi, Your email does not give us much to go with to respond. I worked on one = or two RFC in my day. Why would you want to extend protocols that are not intended for this = purpose? Have a look at the RFCs for SMTP and explain why you would want to do = this so the IETP could respond to you. Regards, Al Costanzo ----- Original Message -----=20 From: Ravi shankar=20 To: apps-discuss@ietf.org=20 Sent: Thursday, August 13, 2009 5:56 AM Subject: Feasibility research request: POP3 and IMAP4 extension to = send mail Hi All, Need your valuable inputs on the subject of ability to extend the POP3 = and IMAP4 to send mails, in addition to retrieving mails.=20 I'm currently doing a research on this topic and would like to have = your valuable feedbacks on the possibility and probably hinderance in = terms of any step in the process. Appreciate your help! Regards, Ravi=20 -------------------------------------------------------------------------= ----- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0060_01CA1BF4.C5EDD9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ravi,
 
Your email does not give us much = to go with=20 to respond. I worked on one or two  RFC in my = day.
 
Why would you want to extend = protocols that=20 are not intended for this purpose?
 
Have a look at the RFCs for SMTP = and explain=20 why you would want to do this so the IETP could respond to = you.
 
 
 
Regards,
 
Al Costanzo
----- Original Message -----
From:=20 Ravi=20 shankar
Sent: Thursday, August 13, 2009 = 5:56=20 AM
Subject: Feasibility research = request:=20 POP3 and IMAP4 extension to send mail

Hi All,
 
Need your valuable inputs on the subject of ability to extend the = POP3=20 and IMAP4 to send mails, in addition to retrieving mails.
 
I'm currently doing a research on this topic and would like to = have your=20 valuable feedbacks on the possibility and probably hinderance in terms = of any=20 step in the process.
 
Appreciate your help!
 
Regards,
Ravi
 

_______________________________________________
Apps-Discuss = mailing=20 = list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/ap= ps-discuss
------=_NextPart_000_0060_01CA1BF4.C5EDD9F0-- From tony@att.com Thu Aug 13 06:35:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D873A6ADA for ; Thu, 13 Aug 2009 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qowQMlBZiXbd for ; Thu, 13 Aug 2009 06:35:43 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id AE0E33A68B2 for ; Thu, 13 Aug 2009 06:35:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-8.tower-129.messagelabs.com!1250169975!31790564!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 12774 invoked from network); 13 Aug 2009 13:26:15 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-8.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Aug 2009 13:26:15 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7DDQFad026174 for ; Thu, 13 Aug 2009 08:26:15 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7DDQAqj026031 for ; Thu, 13 Aug 2009 08:26:10 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n7DDQADr022747 for ; Thu, 13 Aug 2009 09:26:10 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n7DDQ5cM022614 for ; Thu, 13 Aug 2009 09:26:05 -0400 Received: from [135.70.223.181] (vpn-135-70-223-181.vpn.east.att.com[135.70.223.181]) by maillennium.att.com (mailgw1) with ESMTP id <20090813132604gw1003ibnue> (Authid: tony); Thu, 13 Aug 2009 13:26:05 +0000 X-Originating-IP: [135.70.223.181] Message-ID: <4A84146C.7040000@att.com> Date: Thu, 13 Aug 2009 09:26:04 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ravi shankar Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> In-Reply-To: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:35:44 -0000 There was a non-standard extension made to POP3 many years ago to do this. It fell on the wayside and no one uses XTND XMIT any more. People are expected to use the Submission protocol these days (RFC 4409). Tony Hansen tony@att.com Ravi shankar wrote: > Need your valuable inputs on the subject of ability to extend the POP3 > and IMAP4 to send mails, in addition to retrieving mails. > > I'm currently doing a research on this topic and would like to have your > valuable feedbacks on the possibility and probably hinderance in terms > of any step in the process. From ravisha22@gmail.com Thu Aug 13 06:50:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1431D3A6B8A for ; Thu, 13 Aug 2009 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEe1-SEEBJaO for ; Thu, 13 Aug 2009 06:50:22 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 033AE3A6B0D for ; Thu, 13 Aug 2009 06:50:21 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so276135qwi.31 for ; Thu, 13 Aug 2009 06:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HA/SZehYccvwz6rzI/kU1fVNeVBiYO2FGwm6VWc+aXU=; b=v6PTmm/B2rcHj9JsslL6v3GqsbyMCFMs0cisQB7nsdv+mCLiaBxUJmWGhw6G1rRyq7 hAiu3mTSfKHz5v7wCaxvy3tsczhPMaD2vZoUFEF4jfrnwIYDBUX7XFYlGgipyhHwNf9Z NKPhnSux1Pp4PDakNF9jRYWhMbnRNxFf6CEtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Nb/7t54kCFKmEaz2wHTwryLRYqE2GVxk2ENjK9zM9Ujh1rSQX7UI95UEZzqE6oh5EY BHEkuybXbmCJe8B7hwTPIIs7u50fW5JMS19Fx+BD7FFEKjlP0dNbi+08xk3PX3Rl6QZK N46lnmFp33Q2uAAitWXH5kJl7c0O9sa+tWb7c= MIME-Version: 1.0 Received: by 10.224.81.206 with SMTP id y14mr1218102qak.248.1250171341913; Thu, 13 Aug 2009 06:49:01 -0700 (PDT) In-Reply-To: <006301ca1c1e$afc7bd60$3c01a8c0@upstairs> References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> <006301ca1c1e$afc7bd60$3c01a8c0@upstairs> Date: Thu, 13 Aug 2009 19:19:01 +0530 Message-ID: <922a897b0908130649v8582e4dr7e8d6f3e3a4c45d4@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: Al Costanzo , apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000feaf1dfdebe43860471063245 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:50:23 -0000 --000feaf1dfdebe43860471063245 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Al, Much appreciate your reply. I have been doing this feasibility study to see how blocking port25 from client computers would affect botnets and their dynamics. Before i jump in to the pool, thought if someone had similar ideas and their thoughts of how practical it is. Regards, Ravi On Thu, Aug 13, 2009 at 7:32 PM, Al Costanzo wrote: > Ravi, > > Your email does not give us much to go with to respond. I worked on one or > two RFC in my day. > > Why would you want to extend protocols that are not intended for this > purpose? > > Have a look at the RFCs for SMTP and explain why you would want to do this > so the IETP could respond to you. > > > > Regards, > > Al Costanzo > > ----- Original Message ----- > *From:* Ravi shankar > *To:* apps-discuss@ietf.org > *Sent:* Thursday, August 13, 2009 5:56 AM > *Subject:* Feasibility research request: POP3 and IMAP4 extension to send > mail > > Hi All, > > Need your valuable inputs on the subject of ability to extend the POP3 and > IMAP4 to send mails, in addition to retrieving mails. > > I'm currently doing a research on this topic and would like to have your > valuable feedbacks on the possibility and probably hinderance in terms of > any step in the process. > > Appreciate your help! > > Regards, > Ravi > > > ------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --000feaf1dfdebe43860471063245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Al,
=A0
Much appreciate your reply. I have been doing this feasibility study t= o see=A0how blocking port25 from client computers would affect botnets and = their dynamics.
=A0
Before i jump in to the pool, thought if someone had similar ideas=A0a= nd their thoughts of how practical it is.
=A0
Regards,
Ravi

On Thu, Aug 13, 2009 at 7:32 PM, Al Costanzo <al@akc.com> = wrote:
Ravi,
=A0
Your email does not give us muc= h to go with to respond. I worked on=A0one or two =A0RFC in my day.<= /div>
=A0
Why would you want to extend pr= otocols that are not intended for this purpose?
=A0
Have a look at the RFCs for SMT= P and explain why you would want to do this so the IETP could respond to yo= u.
=A0
=A0
=A0
Regards,
=A0
Al Costanzo
----- Original Message -----
Sent: Thursday, August 13, 2009 5:56= AM
Subject: Feasibility research reques= t: POP3 and IMAP4 extension to send mail

Hi All,
=A0
Need your valuable inputs on the subject of ability to extend the POP3= and IMAP4 to send mails, in addition to retrieving mails.
=A0
I'm currently doing a research on this topic and would like to hav= e your valuable feedbacks on the possibility and probably hinderance in ter= ms of any step in the process.
=A0
Appreciate your help!
=A0
Regards,
Ravi
=A0

_______________________________________________
Apps-Discuss mail= ing list
Apps= -Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-d= iscuss


--000feaf1dfdebe43860471063245-- From leifj@mnt.se Thu Aug 13 13:43:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539DD3A6939 for ; Thu, 13 Aug 2009 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrVHCXvBKL0T for ; Thu, 13 Aug 2009 13:43:40 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 5C35C3A6899 for ; Thu, 13 Aug 2009 13:43:39 -0700 (PDT) Received: by ewy10 with SMTP id 10so1078233ewy.37 for ; Thu, 13 Aug 2009 13:41:16 -0700 (PDT) Received: by 10.210.34.2 with SMTP id h2mr2168159ebh.79.1250196076560; Thu, 13 Aug 2009 13:41:16 -0700 (PDT) Received: from klapautius.localnet (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) by mx.google.com with ESMTPS id 5sm4174216eyf.48.2009.08.13.13.41.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 13:41:15 -0700 (PDT) To: apps-discuss@ietf.org Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Thu, 13 Aug 2009 22:41:07 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200908132241.07676.leifj@mnt.se> Cc: Ravi shankar X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:43:41 -0000 On Thursday 13 August 2009 15.49.01 Ravi shankar wrote: > Hi Al, > > Much appreciate your reply. I have been doing this feasibility study to > see how blocking port25 from client computers would affect botnets and > their dynamics. > Given that botnets seem to use twitter now the answer is probably "not much". ISPs do block port 25 which is why SMTP submission with SMTP aiuth on port 587 is a good solution which both exists and is widely deployed afaik. Cheers Leif From ravisha22@gmail.com Thu Aug 13 14:31:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DB93A6843 for ; Thu, 13 Aug 2009 14:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX0S0GITtUeh for ; Thu, 13 Aug 2009 14:31:26 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 4C8E03A6810 for ; Thu, 13 Aug 2009 14:31:26 -0700 (PDT) Received: by qyk41 with SMTP id 41so922796qyk.29 for ; Thu, 13 Aug 2009 14:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oThQOF7gk7K7T10CkREt7Rif77RC7j7pqVF1pSD+xPg=; b=Dq85f1JZZRjFIW1VdNZQBVx7LNGFC8cfHqDf2pqS9/fQzXsGeA+9s5pb8GFAyylgEt AI7gMiNlql+Q7fo7YmYCI4R5MXM9LGfs35wD/7hetLs0zKEoFyV8N3uIrvzx2v+FLfuH 06XhlLVIOpTQLKZ9KZ97oHXHOGWnH4tRV0Nms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s66pmJa7+UR+KM2sn+O3SM9ec79pzbvSG3RLye1QR7IUQ/a1QHsSCGvee15mXziuKj LxQ30OsnVM1fP7zeCwZxuVauExHmegqpmRVJx2OtAuhwQnxy+lfGtxuHbHCZMtsCSgmP S2o8fdDkzIRB3WCMTxpnbKtstVwTPYxzFYw8Q= MIME-Version: 1.0 Received: by 10.224.92.143 with SMTP id r15mr1794883qam.105.1250198993963; Thu, 13 Aug 2009 14:29:53 -0700 (PDT) In-Reply-To: <200908132220.22327.leifj@sunet.se> References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> <006301ca1c1e$afc7bd60$3c01a8c0@upstairs> <922a897b0908130649v8582e4dr7e8d6f3e3a4c45d4@mail.gmail.com> <200908132220.22327.leifj@sunet.se> Date: Fri, 14 Aug 2009 02:59:53 +0530 Message-ID: <922a897b0908131429g6305f133p7cf781de9aa197d3@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: Leif Johansson Content-Type: multipart/alternative; boundary=00163613a253ef0dcd04710ca259 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:31:27 -0000 --00163613a253ef0dcd04710ca259 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Leif, Actually botnets spread on the end-user computers and they inturn are used for spreading spam mails. Spammers still use IRC servers as C & C servers and spread the payload or commands to the bot malware. If you can share any documents regarding port 25 blocking by ISPs would be helpful for me in my work. Regards, Ravi On Fri, Aug 14, 2009 at 1:50 AM, Leif Johansson wrote: > On Thursday 13 August 2009 15.49.01 Ravi shankar wrote: > > Hi Al, > > > > Much appreciate your reply. I have been doing this feasibility study to > > see how blocking port25 from client computers would affect botnets and > > their dynamics. > > > > Given that botnets seem to use twitter now the answer is probably "not > much". ISPs do block port 25 which is why SMTP submission with SMTP > aiuth on port 587 is a good solution which both exists and is widely > deployed > afaik. > > Cheers Leif > > > > --00163613a253ef0dcd04710ca259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Leif,
=A0
Actually botnets spread on the end-user computers and they inturn are = used for spreading spam mails.
=A0
Spammers=A0still use IRC servers as C & C servers and spread the p= ayload or commands to the bot malware.
=A0
If you can share any documents regarding port 25 blocking by ISPs woul= d=A0 be helpful for me in my work.
Regards,
Ravi
On Fri, Aug 14, 2009 at 1:50 AM, Leif Johansson = <leifj@sunet.se&= gt; wrote:
On Thursday 13 August 2009 15.49.01 Ravi shankar wrote:> Hi Al,
>
> Much appreciate your reply. I have been doing= this feasibility study to
> see how blocking port25 from client comp= uters would affect botnets and
> their dynamics.
>

Given that botnets seem to use tw= itter now the answer is probably "not
much". ISPs do block por= t 25 which is why SMTP submission with SMTP
aiuth on port 587 is a good = solution which both exists and is widely deployed
afaik.

=A0 =A0 =A0 =A0Cheers Leif



=
--00163613a253ef0dcd04710ca259-- From leifj@sunet.se Fri Aug 14 04:50:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0E63A6828 for ; Fri, 14 Aug 2009 04:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTW-YDVVYPq2 for ; Fri, 14 Aug 2009 04:50:26 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 9D4253A63CB for ; Fri, 14 Aug 2009 04:50:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id A714E3C710; Fri, 14 Aug 2009 13:17:18 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24965-01-93; Fri, 14 Aug 2009 13:17:18 +0200 (CEST) Received: from klapautius.localnet (130-229-10-8-dhcp.wlan.ki.se [130.229.10.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 463EF3C069; Fri, 14 Aug 2009 13:17:18 +0200 (CEST) From: Leif Johansson Organization: SUNET To: apps-discuss@ietf.org Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Date: Fri, 14 Aug 2009 13:17:16 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-14-generic; KDE/4.2.2; i686; ; ) References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> <200908132220.22327.leifj@sunet.se> <922a897b0908131429g6305f133p7cf781de9aa197d3@mail.gmail.com> In-Reply-To: <922a897b0908131429g6305f133p7cf781de9aa197d3@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908141317.16906.leifj@sunet.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Mailman-Approved-At: Fri, 14 Aug 2009 08:19:28 -0700 Cc: Ravi shankar X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 11:50:27 -0000 On Thursday 13 August 2009 23.29.53 Ravi shankar wrote: > Leif, > > Actually botnets spread on the end-user computers and they inturn are used > for spreading spam mails. > > Spammers still use IRC servers as C & C servers and spread the payload or > commands to the bot malware. or twitter as it turns out :) I thought you were talking about mail-based c&c, hence the twitter reference. > > If you can share any documents regarding port 25 blocking by ISPs would be > helpful for me in my work. > Regards, > Ravi Don't have any docs but its a fairly common practice so google should be able to give you something... Cheers Leif From cfinss@dial.pipex.com Fri Aug 14 11:29:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6B33A68A4 for ; Fri, 14 Aug 2009 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kdASwXiXXIQ for ; Fri, 14 Aug 2009 11:29:55 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id A119D3A6817 for ; Fri, 14 Aug 2009 11:29:55 -0700 (PDT) X-Trace: 131349493/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.187/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.187 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAF5JhUo+vGS7/2dsb2JhbACDMEIgjHrCdQmEEAWBTVw X-IronPort-AV: E=Sophos;i="4.43,381,1246834800"; d="scan'208";a="131349493" X-IP-Direction: IN Received: from 1cust187.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.187]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Aug 2009 19:29:57 +0100 Message-ID: <000d01ca1d04$b767fa80$0601a8c0@allison> From: "tom.petch" To: "Ravi shankar" , References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com><006301ca1c1e$afc7bd60$3c01a8c0@upstairs> <922a897b0908130649v8582e4dr7e8d6f3e3a4c45d4@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Date: Fri, 14 Aug 2009 18:44:40 +0200 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:29:56 -0000 You might also want to consider the archives of the asrg list, where botnets, port 25 blocking and means of limiting damage have been a regular occurrence. Tom Petch ----- Original Message ----- From: "Ravi shankar" To: "Al Costanzo" ; Sent: Thursday, August 13, 2009 3:49 PM Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail > Hi Al, > > Much appreciate your reply. I have been doing this feasibility study to > see how blocking port25 from client computers would affect botnets and their > dynamics. > > Before i jump in to the pool, thought if someone had similar ideas and their > thoughts of how practical it is. > > Regards, > Ravi > > On Thu, Aug 13, 2009 at 7:32 PM, Al Costanzo wrote: > > > Ravi, > > > > Your email does not give us much to go with to respond. I worked on one or > > two RFC in my day. > > > > Why would you want to extend protocols that are not intended for this > > purpose? > > > > Have a look at the RFCs for SMTP and explain why you would want to do this > > so the IETP could respond to you. > > > > > > > > Regards, > > > > Al Costanzo > > > > ----- Original Message ----- > > *From:* Ravi shankar > > *To:* apps-discuss@ietf.org > > *Sent:* Thursday, August 13, 2009 5:56 AM > > *Subject:* Feasibility research request: POP3 and IMAP4 extension to send > > mail > > > > Hi All, > > > > Need your valuable inputs on the subject of ability to extend the POP3 and > > IMAP4 to send mails, in addition to retrieving mails. > > > > I'm currently doing a research on this topic and would like to have your > > valuable feedbacks on the possibility and probably hinderance in terms of > > any step in the process. > > > > Appreciate your help! > > > > Regards, > > Ravi > > > > > > ------------------------------ > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -------------------------------------------------------------------------------- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From vesely@tana.it Fri Aug 14 20:37:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCCB3A6845 for ; Fri, 14 Aug 2009 20:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GkH7B+VcZEm for ; Fri, 14 Aug 2009 20:37:15 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A49583A6DC3 for ; Fri, 14 Aug 2009 20:37:15 -0700 (PDT) Received: from [192.168.15.114] (wf-salyut.imt.ru [212.16.1.106]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 15 Aug 2009 05:37:15 +0200 id 00000000005DC02F.000000004A862D6B.000059CE Message-ID: <4A862E30.2050901@tana.it> Date: Sat, 15 Aug 2009 07:40:32 +0400 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> In-Reply-To: <922a897b0908130356n6259f3e8g85d5235ccf47c135@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 03:37:17 -0000 Ravi shankar wrote: > Need your valuable inputs on the subject of ability to extend the POP3 > and IMAP4 to send mails, in addition to retrieving mails. > > I'm currently doing a research on this topic and would like to have your > valuable feedbacks on the possibility and probably hinderance in terms > of any step in the process. The server I'm now using has this possibility configured, as described in http://www.courier-mta.org/install.html#imapsend I found no conceptual nor practical difficulty with it, but use it seldom. From ravisha22@gmail.com Sat Aug 15 12:43:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1045F3A6DDB for ; Sat, 15 Aug 2009 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWSG7mmWcdX7 for ; Sat, 15 Aug 2009 12:43:32 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 7F4383A6C8C for ; Sat, 15 Aug 2009 12:43:32 -0700 (PDT) Received: by qyk41 with SMTP id 41so1757001qyk.29 for ; Sat, 15 Aug 2009 12:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=L3whDp6mtMv/Zg/g2NCfSJK5ISVr06yRm4zAvsnIi78=; b=qTD5incHO3IBRekjGph5TxTNYYqi/YblaEqshH9yLbpSM6U7Q2OQiEaO45VD6/eMAH 14LchO1a4qzosCtq0N6emOLHQz3W0yA7OBtzBU/Oof52/qXHeNK1qlZ6q3KchCJ87kXi ZEHiCtFlqgjTNTq4LHymO/wa0IVDeLzvp475c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BWhF/nmL8F+x3yCXIggGrOwy4AQv31dYHZV3rCdR4rMcnledwyLubsRblk8V0uHq05 gL3Slyb5zuD27qwG1v7xOYiVO6CNxtzOAPLpEAlf8R6f0ISbkaeIRpXExzHr2bADW+nC dOafQDihcpSeJbk378wS16zhvVyrsei5axhA0= MIME-Version: 1.0 Received: by 10.224.57.142 with SMTP id c14mr3234436qah.356.1250365406767; Sat, 15 Aug 2009 12:43:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Aug 2009 01:13:26 +0530 Message-ID: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 From: Ravi shankar To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000feaf06351e8f4cf04713361b1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 19:43:34 -0000 --000feaf06351e8f4cf04713361b1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Okay, that's what i was looking for. Also the idea behind making IMAP/POP3 send mails is that if we can seperate SMTP for purely server level communication, we can completely eliminate it from end -user communication and block the ports completely, be it 25 or 587. Regards, Ravi On Sun, Aug 16, 2009 at 12:30 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/apps-discuss > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Apps-Discuss mailing list submissions to > apps-discuss@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/apps-discuss > or, via email, send a message with subject or body 'help' to > apps-discuss-request@ietf.org > > You can reach the person managing the list at > apps-discuss-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Apps-Discuss digest..." > > > Today's Topics: > > 1. Re: Feasibility research request: POP3 and IMAP4 extension to > send mail (Alessandro Vesely) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 15 Aug 2009 07:40:32 +0400 > From: Alessandro Vesely > Subject: Re: Feasibility research request: POP3 and IMAP4 extension to > send mail > To: apps-discuss@ietf.org > Message-ID: <4A862E30.2050901@tana.it> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Ravi shankar wrote: > > Need your valuable inputs on the subject of ability to extend the POP3 > > and IMAP4 to send mails, in addition to retrieving mails. > > > > I'm currently doing a research on this topic and would like to have your > > valuable feedbacks on the possibility and probably hinderance in terms > > of any step in the process. > > The server I'm now using has this possibility configured, as > described in http://www.courier-mta.org/install.html#imapsend > > I found no conceptual nor practical difficulty with it, but use > it seldom. > > > ------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > End of Apps-Discuss Digest, Vol 19, Issue 6 > ******************************************* > --000feaf06351e8f4cf04713361b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay, that's what i was looking for. Also the idea behind making I= MAP/POP3 send mails is that if we can seperate SMTP for purely server level= communication, we can completely eliminate it from end -user communication= and block the ports completely, be it 25 or 587.
=A0
Regards,
Ravi

On Sun, Aug 16, 2009 at 12:30 AM, <apps-discuss-reque= st@ietf.org> wrote:
If you have received this digest= without all the individual message
attachments you will need to update = your digest options in your list
subscription. =A0To do so, go to

https://www.ietf.org/mailman/= listinfo/apps-discuss

Click the 'Unsubscribe or edit options= ' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
gl= obally for all the list digests you receive at this point.



S= end Apps-Discuss mailing list submissions to
=A0 =A0 =A0 =A0apps-discuss@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 = =A0 =A0https://www.ietf.org/mailman/listinfo/apps-discuss
or, = via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0apps-discus= s-request@ietf.org

You can reach the person managing the list at=
=A0 =A0 =A0 =A0apps-disc= uss-owner@ietf.org

When replying, please edit your Subject line so it is more specific
= than "Re: Contents of Apps-Discuss digest..."


Today= 9;s Topics:

=A0 1. Re: Feasibility research request: POP3 and IMAP4 = extension to
=A0 =A0 =A0send =A0 =A0 =A0mail (Alessandro Vesely)


------------= ----------------------------------------------------------

Message: = 1
Date: Sat, 15 Aug 2009 07:40:32 +0400
From: Alessandro Vesely <<= a href=3D"mailto:vesely@tana.it">vesely@tana.it>
Subject: Re: Feasibility research request: POP3 and IMAP4 extension to
= =A0 =A0 =A0 =A0send =A0 =A0mail
To: apps-discuss@ietf.org
Message-ID: <4A862E30.2050901@tana.it>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Ravi= shankar wrote:
> Need your valuable inputs on the subject of ability= to extend the POP3
> and IMAP4 to send mails, in addition to retriev= ing mails.
>
> I'm currently doing a research on this topic and would lik= e to have your
> valuable feedbacks on the possibility and probably h= inderance in terms
> of any step in the process.

The server I&= #39;m now using has this possibility configured, as
described in http://www.courier-mta.org/install.html#imapsend
I found no conceptual nor practical difficulty with it, but use
it sel= dom.


------------------------------

_____________________________= __________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/ma= ilman/listinfo/apps-discuss


End of Apps-Discuss Digest, Vol 19, Issue 6
********************= ***********************

--000feaf06351e8f4cf04713361b1-- From guenther+ietf@sendmail.com Sat Aug 15 15:20:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3A63A6BB9 for ; Sat, 15 Aug 2009 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnuAWRAuLlj0 for ; Sat, 15 Aug 2009 15:20:08 -0700 (PDT) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by core3.amsl.com (Postfix) with ESMTP id 01B6A3A6B6C for ; Sat, 15 Aug 2009 15:20:07 -0700 (PDT) Received: from [10.210.202.2] ([10.210.202.2]) (authenticated bits=0) by fife.sendmail.com (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7FMK3UQ002298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2009 15:20:08 -0700 X-BATV: Sendmail BATV Filter v0.4.0.dev fife.sendmail.com n7FMK3UQ002298 X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n7FMK3UQ002298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1250374810; bh=cvqCMmvmGmk1A2Ngv+hubb/O1bx2jIabBnB8c RdwonI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=oQJeNwwcCxhQy09z0qrEngRxM1 g3FId55xRHQHczAdSgnGI6q28NoJMvp5Ynr3sBawIeGJhamvkhsDceN+9Lz617INwXf bVC9ca5olEB9+bNAKsa4+E+G5MUtI3kDUiNHf9hR7pMP1U5XBVZ/WZpCoC/BbJsJ8Yt JKjuw810u3g= X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n7FMK3UQ002298 Date: Sat, 15 Aug 2009 15:20:03 -0700 From: Philip Guenther X-X-Sender: guenther@vanye.sendmail.com To: Ravi shankar Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 In-Reply-To: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> Message-ID: References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 22:20:09 -0000 On Sun, 16 Aug 2009, Ravi shankar wrote: > Okay, that's what i was looking for. Also the idea behind making > IMAP/POP3 send mails is that if we can seperate SMTP for purely server > level communication, we can completely eliminate it from end -user > communication and block the ports completely, be it 25 or 587. Why would that (not using SMTP or submission for submission) be a good thing? What problem are you trying to address that exists with a current setup where clients use submission? What would prevent that problem from not immediately reoccuring with the new submission mechanism? (For example, if rogue programs are currently stealing credentials to use authenticated submission to send email, why would they do the exact same thing with submission over IMAP/POP3?) The Lemonade working group went around this topic several years ago and decided against doing submission through IMAP/POP3 after considering a number of deployment scenarios and the security issues around them and instead developed RFCs 4467, 4468, and 4469. The problem being addresses there was that of "forward without download", though firewall traveral was part of the discussion. A key point in the discussion then was that SMTP and submission are extensible and many extensions are in use. Any new submission method would face having to replicate those extensions *and all future ones* or drive people back to SMTP. The obvious solution to that would be to make the "submission via IMAP/POP3" method 'simply' involve tunneling SMTP through the other protocol. That creates myriad security issues and increases the complexity of implementation greatly, as the state diagram for the IMAP/POP3 server suddenly has the SMTP state diagram grafted on to it. Anyway, I urge you review the archives of that discussion to see whether your arguments for putting submission inside IMAP/POP3 were considered then and if so, whether the counter-arguments still apply. An engineering decision was made then based on the discussion; what has changed that would strengthen or weaken the arguments that went into that decision? Philip Guenther -- Chief Architect Sendmail, Inc. From ravisha22@gmail.com Sun Aug 16 02:37:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898F53A6D30 for ; Sun, 16 Aug 2009 02:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGZl1W7EACey for ; Sun, 16 Aug 2009 02:37:09 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 3A10B3A6B64 for ; Sun, 16 Aug 2009 02:37:09 -0700 (PDT) Received: by qyk41 with SMTP id 41so1896783qyk.29 for ; Sun, 16 Aug 2009 02:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uqr8rEQiYAReYH/cw5G0c4PDZXwT990YzukonZ7Fi38=; b=x3uvao8TCTLIPjzFflNIQ/MdQQcrVbiuAPEDbtt2kxlJmVAvO7L6u4vnALJCd8GJpf s+6n2xZWx3/YdAAG/nVyChfXgaLFga0S0PYtuLweq+PfdeJFWlAFPY28skKP+cevyCBn fjxg5/kgi0z/C3UGDlGQz8GDbhFQ3bv03iWLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t46hquXpeyyS38JWs+ff/54lxQCFqs2dPeqOJH3pDa4/A41f6uVJthO8T9j0zyZ/A1 eaNPNb18RmnTNFKkohm+0oTYhNPHNHEHdA9UR/tyY+qu3DGlSFfGMlXSQOOgl1WWGUa6 7hBLw12j1Qa+mfn5savVoEPieTzCW8e90Dc6E= MIME-Version: 1.0 Received: by 10.224.93.130 with SMTP id v2mr3514152qam.119.1250415431785; Sun, 16 Aug 2009 02:37:11 -0700 (PDT) In-Reply-To: References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> Date: Sun, 16 Aug 2009 15:07:11 +0530 Message-ID: <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 From: Ravi shankar To: Philip Guenther Content-Type: multipart/alternative; boundary=000feaf14861a2206f04713f07c6 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 09:37:10 -0000 --000feaf14861a2206f04713f07c6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip, It's not the authentication mechanism that I'm proposing to change, but rather the method in which the mails are transsacted in today's setup. In the present setup, SMTP can be used by any computer connected to Internet to send mails directly to the server, resulting in spam which by normal means in indistinguishable from legitimate mails. What Botnets take advantage of is the fact that a normal Client computer (say, a home PC) can be infected to send spam. Instead if we classify, SMTP as the sole "Server to Server" protocol, it gives us the liberty to block those ports completely in the home/client computers. In order to allow the client computers that use POP3 and IMAP clients to continue transacting mails with SMTP blocked, we can extend them to submit messages as well. While this way is not meant to protect against spam created by user name/password or identity theft, it is specifically aimed at controlling botnet spread spam, which accounts of 100 billion spam emails a day!. Regards, Ravi On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther > wrote: > On Sun, 16 Aug 2009, Ravi shankar wrote: > > Okay, that's what i was looking for. Also the idea behind making > > IMAP/POP3 send mails is that if we can seperate SMTP for purely server > > level communication, we can completely eliminate it from end -user > > communication and block the ports completely, be it 25 or 587. > > > Why would that (not using SMTP or submission for submission) be a good > thing? What problem are you trying to address that exists with a current > setup where clients use submission? What would prevent that problem from > not immediately reoccuring with the new submission mechanism? > > (For example, if rogue programs are currently stealing credentials to use > authenticated submission to send email, why would they do the exact same > thing with submission over IMAP/POP3?) > > > The Lemonade working group went around this topic several years ago and > decided against doing submission through IMAP/POP3 after considering a > number of deployment scenarios and the security issues around them and > instead developed RFCs 4467, 4468, and 4469. The problem being addresses > there was that of "forward without download", though firewall traveral was > part of the discussion. > > A key point in the discussion then was that SMTP and submission are > extensible and many extensions are in use. Any new submission method > would face having to replicate those extensions *and all future ones* or > drive people back to SMTP. The obvious solution to that would be to make > the "submission via IMAP/POP3" method 'simply' involve tunneling SMTP > through the other protocol. That creates myriad security issues and > increases the complexity of implementation greatly, as the state diagram > for the IMAP/POP3 server suddenly has the SMTP state diagram grafted on to > it. Anyway, I urge you review the archives of that discussion to see > whether your arguments for putting submission inside IMAP/POP3 were > considered then and if so, whether the counter-arguments still apply. > > An engineering decision was made then based on the discussion; what has > changed that would strengthen or weaken the arguments that went into that > decision? > > > Philip Guenther > > -- > Chief Architect > Sendmail, Inc. > --000feaf14861a2206f04713f07c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Philip,
=A0
It's not the authentication mechanism that I'm=A0proposing to = change, but rather the method in which the mails are transsacted in today&#= 39;s setup.
=A0
In the present setup, SMTP can be used by any computer connected to In= ternet to send mails directly to the server, resulting in spam which by nor= mal means in indistinguishable from legitimate mails.
=A0
What Botnets take advantage of is the fact that a normal Client comput= er (say, a home PC) can be infected to send spam. Instead if we classify, S= MTP as the sole "Server to Server" protocol, it gives us the libe= rty to block those ports completely in the=A0home/client computers.
=A0
In order=A0to allow=A0the client computers that use POP3 and IMAP clie= nts to continue transacting mails with SMTP blocked, we can extend them=A0 = to submit messages as well.
=A0
While this way is not meant to protect against spam created by user na= me/password or identity theft, it is specifically aimed at controlling botn= et spread spam, which accounts of 100 billion=A0spam emails=A0a day!.
=A0
Regards,
Ravi
On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther= <guen= ther+ietf@sendmail.com> wrote:
On Sun, 16 Aug 2009, Ravi shankar wrote:
> Okay, th= at's what i was looking for. Also the idea behind making
> IMAP/P= OP3 send mails is that if we can seperate SMTP for purely server
> le= vel communication, we can completely eliminate it from end -user
> communication and block the ports completely, be it 25 or 587.

=
Why would that (not using SMTP or submission for submission) be a= good
thing? =A0What problem are you trying to address that exists with = a current
setup where clients use submission? =A0What would prevent that problem from=
not immediately reoccuring with the new submission mechanism?

(F= or example, if rogue programs are currently stealing credentials to use
authenticated submission to send email, why would they do the exact samething with submission over IMAP/POP3?)


The Lemonade working gro= up went around this topic several years ago and
decided against doing su= bmission through IMAP/POP3 after considering a
number of deployment scenarios and the security issues around them and
i= nstead developed RFCs 4467, 4468, and 4469. =A0The problem being addresses<= br>there was that of "forward without download", though firewall = traveral was
part of the discussion.

A key point in the discussion then was that = SMTP and submission are
extensible and many extensions are in use. =A0An= y new submission method
would face having to replicate those extensions = *and all future ones* or
drive people back to SMTP. =A0The obvious solution to that would be to make=
the "submission via IMAP/POP3" method 'simply' involv= e tunneling SMTP
through the other protocol. =A0That creates myriad secu= rity issues and
increases the complexity of implementation greatly, as the state diagramfor the IMAP/POP3 server suddenly has the SMTP state diagram grafted on to=
it. =A0Anyway, I urge you review the archives of that discussion to see=
whether your arguments for putting submission inside IMAP/POP3 were
cons= idered then and if so, whether the counter-arguments still apply.

An= engineering decision was made then based on the discussion; what has
changed that would strengthen or weaken the arguments that went into thatdecision?


Philip Guenther

--Chief Architect
Sendmail, Inc.

--000feaf14861a2206f04713f07c6-- From john-ietf@jck.com Sun Aug 16 10:47:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD8E3A6915 for ; Sun, 16 Aug 2009 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbCXmcfWcacv for ; Sun, 16 Aug 2009 10:47:39 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id BADBC3A68CE for ; Sun, 16 Aug 2009 10:47:38 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1McjpU-000NMW-O1; Sun, 16 Aug 2009 13:47:41 -0400 Date: Sun, 16 Aug 2009 13:47:39 -0400 From: John C Klensin To: Ravi shankar , Philip Guenther Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 Message-ID: In-Reply-To: <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 17:47:39 -0000 --On Sunday, August 16, 2009 15:07 +0530 Ravi shankar wrote: >... > In the present setup, SMTP can be used by any computer > connected to Internet to send mails directly to the server, > resulting in spam which by normal means in indistinguishable > from legitimate mails. > > What Botnets take advantage of is the fact that a normal > Client computer (say, a home PC) can be infected to send spam. > Instead if we classify, SMTP as the sole "Server to Server" > protocol, it gives us the liberty to block those ports > completely in the home/client computers. But that is the exact problem that the use of RFC 4409 Message Submission, including its authentication requirement, is intended to solve. It is already widely deployed, does not require another new protocol, and does not require adding complexity to POP and IMAP (as others have pointed out). > In order to allow the client computers that use POP3 and IMAP > clients to continue transacting mails with SMTP blocked, we > can extend them to submit messages as well. > > While this way is not meant to protect against spam created by > user name/password or identity theft, it is specifically aimed > at controlling botnet spread spam, which accounts of 100 > billion spam emails a day!. I believe that what people are telling you is that we already have a solution to the problem you are proposing to solve. It is a solution that is implemented, deployed, in fairly wide use in some parts of the world. It is also one that requires very little change to deployed clients -- for the typical POP3 or IMAP MUA, all that is needed to support Submit is to change the outgoing port and enable SMTP authentication... and both facilities are present in all modern MUAs. So it seems to me that you need to demonstrate that your suggestion will work better than continued and broaded use of Submit, not merely that it would address part of the botnet problem... more or less the same part that Submit addresses already. It also seems to me that part of your analysis suffers from the same problem as many other analyses of this type and raises another issue you should address. The bad guys running botnets to send spam are ultimately much like the rest of us -- they aren't going to develop and use complex methods to solve problems when simple ones will do. So the botnets use port 25 because it is easy. There is no reason to believe that, if one pushes message posting onto IMAP or POP clients and make successful use of port 25 hard enough and rare enough, that those who are already able to compromise machines to set up those botnets won't figure out how to compromise IMAP or POP clients, password stores, or legitimate posting traffic in order to mimic those things to the degree needed. regards, john From al@akc.com Sun Aug 16 10:47:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F6128C0FD for ; Sun, 16 Aug 2009 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWkcdftPEZuQ for ; Sun, 16 Aug 2009 10:47:41 -0700 (PDT) Received: from imail.akc.com (imail.akc.com [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id 288DC3A68CE for ; Sun, 16 Aug 2009 10:47:40 -0700 (PDT) Received: from upstairs.akc.com [64.253.39.242] by imail.akc.com with SMTP; Sun, 16 Aug 2009 13:47:31 -0400 Message-ID: <003a01ca1ea1$fa484a50$3c01a8c0@upstairs> From: "Al Costanzo" To: "Ravi shankar" , "Philip Guenther" References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 Date: Sun, 16 Aug 2009 13:47:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CA1E78.107F08B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 17:47:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01CA1E78.107F08B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But Ravi, You may be rying to re-invent the wheel. There is already PoP before = Relay as well as other servers that require SMTP authentication = requiring a user name and password to send. These two items already do what you intend, however EVEN if you propose = something else a virus will always cause a problem, no matter what you = do. I know since not only did I work on SMTP mail but also resell = anti-viruii products. I am sorry, I still cannot see the point of what you are trying to do = since on the server side of the house you have SPF. It is up to Mail = Administrators to use these tools to stop spam. If they use them, it = works. If you think they don't work, please explain. Below, is some information for you if you did not read the SPF docs. What is SPF? SPF (defined in RFC 4408) validates the HELO domain and the MAIL FROM = address given as part of the SMTP protocol (RFC 2821 - the "envelope" = layer). The MAIL FROM address is usually displayed as "Return-Path" if = you select the "Show all headers" option in your e-mail client. Domain = owners publish records via DNS that describe their policy for which = machines are authorized to use their domain in the HELO and MAIL FROM = addresses, which are part of the SMTP protocol.=20 What is Sender ID? Sender ID (defined in RFC 4406) is a Microsoft protocol derived from SPF = (hence the identical syntax), which validates one of the message's = address header fields defined by RFC 2822. Which one it validates is = selected according to an algorithm called PRA (Purported Responsible = Address, RFC 4407). The algorithm aims to select the header field with = the e-mail address "responsible" for sending the message.=20 Since it was derived from SPF, Sender ID can also validate the MAIL = FROM. But it defines the new PRA identity to validate, and defines new = sender policy record tags that specify whether a policy covers MAIL FROM = (called MFROM by Sender ID), PRA, or both.=20 Which is better? Neither is better because they address different problems. Comparing = them is comparing apples and oranges. SPF can be compared to other SMTP = layer protocol proposals like CSV/CSA. Sender ID can be compared to = other RFC 2822 layer protocols like DomainKeys IM (DKIM). Nevertheless, = the SPF technical community does have its own opinion on the merits of = Sender ID. Why is there controversy about SPF vs Sender ID? The Sender ID specification contains a recommendation to use SPF's = v=3Dspf1 policies - which are originally defined to apply to MAIL FROM = and HELO identities only - and apply them to the PRA identity as well. = Specifically, it says to consider v=3Dspf1 as equivalent to = spf2.0/mfrom,pra. This is technically wrong, as is explained in detail = below. Sender ID implementors should correct this and treat v=3Dspf1 = records as equivalent to spf2.0/mfrom. Unfortunately this mistake in the = Sender ID specification was not corrected prior to its publication = despite an appeal from the SPF project. This creates a very bad situation in that Sender ID implementations that = follow the recommendation in the Sender ID specification (RFC 4406, = section 3.4) violate the SPF specification (RFC 4408). Since the Sender = ID specification defers to the SPF specification for the definition of = v=3Dspf1, and because SPF has been in existence (prior to the = publication as an IETF RFC) a lot longer than Sender ID, the = recommendation in the Sender ID specification should be ignored by = implementors. Please explain why these dont work and I would be glad to help. Regards, Al Costanzo IETF contributor/RFC Author since 1993 (and I still miss Jon Postel) =20 ----- Original Message -----=20 From: Ravi shankar=20 To: Philip Guenther=20 Cc: apps-discuss@ietf.org=20 Sent: Sunday, August 16, 2009 4:37 AM Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 Philip, It's not the authentication mechanism that I'm proposing to change, = but rather the method in which the mails are transsacted in today's = setup. In the present setup, SMTP can be used by any computer connected to = Internet to send mails directly to the server, resulting in spam which = by normal means in indistinguishable from legitimate mails. What Botnets take advantage of is the fact that a normal Client = computer (say, a home PC) can be infected to send spam. Instead if we = classify, SMTP as the sole "Server to Server" protocol, it gives us the = liberty to block those ports completely in the home/client computers. In order to allow the client computers that use POP3 and IMAP clients = to continue transacting mails with SMTP blocked, we can extend them to = submit messages as well. While this way is not meant to protect against spam created by user = name/password or identity theft, it is specifically aimed at controlling = botnet spread spam, which accounts of 100 billion spam emails a day!. Regards, Ravi On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther = wrote: On Sun, 16 Aug 2009, Ravi shankar wrote: > Okay, that's what i was looking for. Also the idea behind making > IMAP/POP3 send mails is that if we can seperate SMTP for purely = server > level communication, we can completely eliminate it from end -user > communication and block the ports completely, be it 25 or 587. Why would that (not using SMTP or submission for submission) be a = good thing? What problem are you trying to address that exists with a = current setup where clients use submission? What would prevent that problem = from not immediately reoccuring with the new submission mechanism? (For example, if rogue programs are currently stealing credentials = to use authenticated submission to send email, why would they do the exact = same thing with submission over IMAP/POP3?) The Lemonade working group went around this topic several years ago = and decided against doing submission through IMAP/POP3 after considering = a number of deployment scenarios and the security issues around them = and instead developed RFCs 4467, 4468, and 4469. The problem being = addresses there was that of "forward without download", though firewall = traveral was part of the discussion. A key point in the discussion then was that SMTP and submission are extensible and many extensions are in use. Any new submission = method would face having to replicate those extensions *and all future = ones* or drive people back to SMTP. The obvious solution to that would be to = make the "submission via IMAP/POP3" method 'simply' involve tunneling = SMTP through the other protocol. That creates myriad security issues and increases the complexity of implementation greatly, as the state = diagram for the IMAP/POP3 server suddenly has the SMTP state diagram grafted = on to it. Anyway, I urge you review the archives of that discussion to = see whether your arguments for putting submission inside IMAP/POP3 were considered then and if so, whether the counter-arguments still = apply. An engineering decision was made then based on the discussion; what = has changed that would strengthen or weaken the arguments that went into = that decision? Philip Guenther -- Chief Architect Sendmail, Inc. -------------------------------------------------------------------------= ----- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0037_01CA1E78.107F08B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
But Ravi,
 
You may be rying to re-invent = the=20 wheel.  There is already PoP before Relay as well as other servers = that=20 require SMTP authentication requiring a user name and password to=20 send.
 
These two items already do what = you intend,=20 however EVEN if you propose something else a virus will always cause a = problem,=20 no matter what you do.
 
I know since not only did I work = on SMTP=20 mail but also resell anti-viruii products.
 
I am sorry, I still cannot see = the point of=20 what you are trying to do since on the server side of the house you have = SPF.  It is up to Mail Administrators to use these tools to stop=20 spam.  If they use them, it works.  If you think they don't = work,=20 please explain.
 
Below, is some information for = you if you=20 did not read the SPF docs.
 

What is SPF?

SPF (defined in RFC 4408) validates = the=20 HELO domain and the MAIL FROM address given as part of = the=20 SMTP protocol (RFC = 2821 =96 the=20 "envelope" layer). The MAIL FROM address is usually displayed = as=20 "Return-Path" if you select the "Show all headers" option = in your=20 e-mail client. Domain owners publish records via DNS that describe their = policy=20 for which machines are authorized to use their domain in the = HELO and=20 MAIL FROM addresses, which are part of the SMTP protocol.

What is Sender = ID?

Sender ID (defined in RFC 4406) is a Microsoft protocol derived from SPF (hence the=20 identical syntax), which validates one of the message's address header = fields=20 defined by RFC 2822. = Which one=20 it validates is selected according to an algorithm called PRA=20 (Purported Responsible Address, RFC 4407). The algorithm = aims to=20 select the header field with the e-mail address "responsible" for = sending the=20 message.

Since it was derived from SPF, Sender=20 ID can also validate the MAIL FROM. But it defines the new = PRA identity to validate, and defines new sender policy = record=20 tags that specify whether a policy covers MAIL FROM (called=20 MFROM by Sender ID), PRA, or=20 both.

Which is better?

Neither is better because they address different problems. Comparing = them is=20 comparing apples and oranges. SPF can be compared = to other=20 SMTP layer protocol proposals like CSV/CSA= .=20 Sender ID can be compared to other RFC 2822 layer = protocols=20 like DomainKeys=20 IM (DKIM). Nevertheless, the SPF technical = community=20 does have its own = opinion=20 on the merits of Sender ID.

Why is there controversy about SPF vs=20 Sender ID?

The Sender ID specification contains a = recommendation to=20 use SPF's v=3Dspf1 policies =97 which = are originally=20 defined to apply to MAIL FROM and HELO identities only = =97 and=20 apply them to the PRA identity as well. = Specifically, it says=20 to consider v=3Dspf1 as equivalent to = spf2.0/mfrom,pra.=20 This is technically wrong, as is explained in detail below. Sender=20 ID implementors should correct this and treat v=3Dspf1 = records=20 as equivalent to spf2.0/mfrom. Unfortunately this mistake = in the=20 Sender ID specification was not corrected prior to = its=20 publication despite an appeal<= /A> from=20 the SPF project.

This creates a very bad situation in that Sender = ID=20 implementations that follow the recommendation in the Sender=20 ID specification (RFC 4406, section 3.4) violate the SPF=20 specification (RFC 4408). Since the Sender ID = specification=20 defers to the SPF specification for the definition = of=20 v=3Dspf1, and because SPF has been in = existence=20 (prior to the publication as an IETF RFC) a lot longer than Sender=20 ID, the recommendation in the Sender ID = specification=20 should be ignored by implementors.

 

Please explain why these dont work and I would be = glad to=20 help.

 

Regards,

 

Al Costanzo

IETF contributor/RFC Author since 1993 (and I still miss Jon=20 Postel)

 
----- Original Message -----
From:=20 Ravi=20 shankar
Sent: Sunday, August 16, 2009 = 4:37=20 AM
Subject: Re: Apps-Discuss = Digest, Vol 19,=20 Issue 6

Philip,
 
It's not the authentication mechanism that I'm proposing to = change,=20 but rather the method in which the mails are transsacted in today's=20 setup.
 
In the present setup, SMTP can be used by any computer connected = to=20 Internet to send mails directly to the server, resulting in spam which = by=20 normal means in indistinguishable from legitimate mails.
 
What Botnets take advantage of is the fact that a normal Client = computer=20 (say, a home PC) can be infected to send spam. Instead if we classify, = SMTP as=20 the sole "Server to Server" protocol, it gives us the liberty to block = those=20 ports completely in the home/client computers.
 
In order to allow the client computers that use POP3 = and IMAP=20 clients to continue transacting mails with SMTP blocked, we can extend = them  to submit messages as well.
 
While this way is not meant to protect against spam created by = user=20 name/password or identity theft, it is specifically aimed at = controlling=20 botnet spread spam, which accounts of 100 billion spam = emails a=20 day!.
 
Regards,
Ravi
On Sun, Aug 16, 2009 at 3:50 AM, Philip = Guenther <guenther+ietf@sendmail.com>=20 wrote:
On Sun, 16 Aug 2009, Ravi shankar wrote:
> = Okay, that's=20 what i was looking for. Also the idea behind making
> = IMAP/POP3 send=20 mails is that if we can seperate SMTP for purely server
> = level=20 communication, we can completely eliminate it from end -user
> = communication and block the ports completely, be it 25 or=20 587.


Why would that (not using SMTP or submission = for=20 submission) be a good
thing?  What problem are you trying to = address=20 that exists with a current
setup where clients use submission? =  What=20 would prevent that problem from
not immediately reoccuring with = the new=20 submission mechanism?

(For example, if rogue programs are = currently=20 stealing credentials to use
authenticated submission to send = email, why=20 would they do the exact same
thing with submission over=20 IMAP/POP3?)


The Lemonade working group went around this = topic=20 several years ago and
decided against doing submission through = IMAP/POP3=20 after considering a
number of deployment scenarios and the = security=20 issues around them and
instead developed RFCs 4467, 4468, and = 4469.=20  The problem being addresses
there was that of "forward = without=20 download", though firewall traveral was
part of the = discussion.

A=20 key point in the discussion then was that SMTP and submission=20 are
extensible and many extensions are in use.  Any new = submission=20 method
would face having to replicate those extensions *and all = future=20 ones* or
drive people back to SMTP.  The obvious solution to = that=20 would be to make
the "submission via IMAP/POP3" method 'simply' = involve=20 tunneling SMTP
through the other protocol.  That creates = myriad=20 security issues and
increases the complexity of implementation = greatly,=20 as the state diagram
for the IMAP/POP3 server suddenly has the = SMTP state=20 diagram grafted on to
it.  Anyway, I urge you review the = archives of=20 that discussion to see
whether your arguments for putting = submission=20 inside IMAP/POP3 were
considered then and if so, whether the=20 counter-arguments still apply.

An engineering decision was = made then=20 based on the discussion; what has
changed that would strengthen = or weaken=20 the arguments that went into that
decision?


Philip=20 Guenther

--
Chief = Architect
Sendmail,=20 Inc.

_______________________________________________
Apps-Discuss = mailing=20 = list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/ap= ps-discuss
------=_NextPart_000_0037_01CA1E78.107F08B0-- From tony@att.com Sun Aug 16 13:29:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DB13A6AF6 for ; Sun, 16 Aug 2009 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.314 X-Spam-Level: X-Spam-Status: No, score=-106.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+xjswbwK1uu for ; Sun, 16 Aug 2009 13:29:24 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 25C923A6A60 for ; Sun, 16 Aug 2009 13:29:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1250454546!18700110!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 28208 invoked from network); 16 Aug 2009 20:29:07 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-9.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Aug 2009 20:29:07 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7GKT5xm015731 for ; Sun, 16 Aug 2009 15:29:05 -0500 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7GKT1ZW015708 for ; Sun, 16 Aug 2009 15:29:01 -0500 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n7GKT1wt027834 for ; Sun, 16 Aug 2009 15:29:01 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n7GKSvZw027822 for ; Sun, 16 Aug 2009 15:28:57 -0500 Received: from [135.70.9.151] (vpn-135-70-9-151.vpn.west.att.com[135.70.9.151]) by maillennium.att.com (mailgw1) with ESMTP id <20090816202856gw1003ib57e> (Authid: tony); Sun, 16 Aug 2009 20:28:56 +0000 X-Originating-IP: [135.70.9.151] Message-ID: <4A886C07.704@att.com> Date: Sun, 16 Aug 2009 16:28:55 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ravi shankar Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> In-Reply-To: <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 20:29:25 -0000 Ravi, you're under the mistaken assumption that people should be using SMTP to send email. The current recommendations for message submission is to use the Message Submission protocol, which uses port 587 and is described in RFC 4409. While it is *based* on the SMTP protocol, it has various requirements that address all of your concerns. It's been around for about 11 years, but not ISPs have figured out that they should be requiring its use. Tony Hansen tony@att.com Ravi shankar wrote: > Philip, > > It's not the authentication mechanism that I'm proposing to change, but > rather the method in which the mails are transsacted in today's setup. > > In the present setup, SMTP can be used by any computer connected to > Internet to send mails directly to the server, resulting in spam which > by normal means in indistinguishable from legitimate mails. > > What Botnets take advantage of is the fact that a normal Client computer > (say, a home PC) can be infected to send spam. Instead if we classify, > SMTP as the sole "Server to Server" protocol, it gives us the liberty to > block those ports completely in the home/client computers. > > In order to allow the client computers that use POP3 and IMAP clients to > continue transacting mails with SMTP blocked, we can extend them to > submit messages as well. > > While this way is not meant to protect against spam created by user > name/password or identity theft, it is specifically aimed at controlling > botnet spread spam, which accounts of 100 billion spam emails a day!. > > Regards, > Ravi > On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther > > wrote: > > On Sun, 16 Aug 2009, Ravi shankar wrote: > > Okay, that's what i was looking for. Also the idea behind making > > IMAP/POP3 send mails is that if we can seperate SMTP for purely > server > > level communication, we can completely eliminate it from end -user > > communication and block the ports completely, be it 25 or 587. > > > Why would that (not using SMTP or submission for submission) be a good > thing? What problem are you trying to address that exists with a > current > setup where clients use submission? What would prevent that problem > from > not immediately reoccuring with the new submission mechanism? > > (For example, if rogue programs are currently stealing credentials > to use > authenticated submission to send email, why would they do the exact same > thing with submission over IMAP/POP3?) > > > The Lemonade working group went around this topic several years ago and > decided against doing submission through IMAP/POP3 after considering a > number of deployment scenarios and the security issues around them and > instead developed RFCs 4467, 4468, and 4469. The problem being > addresses > there was that of "forward without download", though firewall > traveral was > part of the discussion. > > A key point in the discussion then was that SMTP and submission are > extensible and many extensions are in use. Any new submission method > would face having to replicate those extensions *and all future ones* or > drive people back to SMTP. The obvious solution to that would be to > make > the "submission via IMAP/POP3" method 'simply' involve tunneling SMTP > through the other protocol. That creates myriad security issues and > increases the complexity of implementation greatly, as the state diagram > for the IMAP/POP3 server suddenly has the SMTP state diagram grafted > on to > it. Anyway, I urge you review the archives of that discussion to see > whether your arguments for putting submission inside IMAP/POP3 were > considered then and if so, whether the counter-arguments still apply. > > An engineering decision was made then based on the discussion; what has > changed that would strengthen or weaken the arguments that went into > that > decision? > > > Philip Guenther > > -- > Chief Architect > Sendmail, Inc. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From al@akc.com Sun Aug 16 15:39:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398FA28C148 for ; Sun, 16 Aug 2009 15:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBqhY3sLENCu for ; Sun, 16 Aug 2009 15:39:46 -0700 (PDT) Received: from imail.akc.com (imail.akc.com [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id D5DB73A6AA5 for ; Sun, 16 Aug 2009 15:39:45 -0700 (PDT) Received: from upstairs.akc.com [64.253.39.242] by imail.akc.com with SMTP; Sun, 16 Aug 2009 18:39:33 -0400 Message-ID: <005701ca1eca$c5c79960$3c01a8c0@upstairs> From: "Al Costanzo" To: "Tony Hansen" , , References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> <4A886C07.704@att.com> Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 Date: Sun, 16 Aug 2009 18:39:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 22:39:47 -0000 Tony, I disagree. RFC 4409 does not alter the use of port 25 in any way. Some ISPs block port 25 and then use the ALT port 587 and use SMTP Auth. But this is a waste of time with what this person wants to do. All the ISP needs to do is turn on SMTP [SMTP-AUTH] on port 25 and the problem is solved. it is also mentioned in the doc in section 3.3 (below so you dont have to grab a copy. If you just turn on this feature, the problem is solved. Most ISPs use this, my company does. Regards, -Al ----- Doc Inclusion ----- 3.3. Authorized Submission Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication. Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols. IP address restrictions are very widely implemented, but do not allow for travelers and similar situations, and can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy. ----- Original Message ----- From: "Tony Hansen" To: "Ravi shankar" Cc: Sent: Sunday, August 16, 2009 3:28 PM Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 > Ravi, you're under the mistaken assumption that people should be using > SMTP to send email. The current recommendations for message submission is > to use the Message Submission protocol, which uses port 587 and is > described in RFC 4409. While it is *based* on the SMTP protocol, it has > various requirements that address all of your concerns. It's been around > for about 11 years, but not ISPs have figured out that they should be > requiring its use. > > Tony Hansen > tony@att.com > > Ravi shankar wrote: >> Philip, >> It's not the authentication mechanism that I'm proposing to change, but >> rather the method in which the mails are transsacted in today's setup. >> In the present setup, SMTP can be used by any computer connected to >> Internet to send mails directly to the server, resulting in spam which by >> normal means in indistinguishable from legitimate mails. >> What Botnets take advantage of is the fact that a normal Client computer >> (say, a home PC) can be infected to send spam. Instead if we classify, >> SMTP as the sole "Server to Server" protocol, it gives us the liberty to >> block those ports completely in the home/client computers. >> In order to allow the client computers that use POP3 and IMAP clients to >> continue transacting mails with SMTP blocked, we can extend them to >> submit messages as well. >> While this way is not meant to protect against spam created by user >> name/password or identity theft, it is specifically aimed at controlling >> botnet spread spam, which accounts of 100 billion spam emails a day!. >> Regards, >> Ravi >> On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther >> > wrote: >> >> On Sun, 16 Aug 2009, Ravi shankar wrote: >> > Okay, that's what i was looking for. Also the idea behind making >> > IMAP/POP3 send mails is that if we can seperate SMTP for purely >> server >> > level communication, we can completely eliminate it from end -user >> > communication and block the ports completely, be it 25 or 587. >> >> >> Why would that (not using SMTP or submission for submission) be a >> good >> thing? What problem are you trying to address that exists with a >> current >> setup where clients use submission? What would prevent that problem >> from >> not immediately reoccuring with the new submission mechanism? >> >> (For example, if rogue programs are currently stealing credentials >> to use >> authenticated submission to send email, why would they do the exact >> same >> thing with submission over IMAP/POP3?) >> >> >> The Lemonade working group went around this topic several years ago >> and >> decided against doing submission through IMAP/POP3 after considering >> a >> number of deployment scenarios and the security issues around them >> and >> instead developed RFCs 4467, 4468, and 4469. The problem being >> addresses >> there was that of "forward without download", though firewall >> traveral was >> part of the discussion. >> >> A key point in the discussion then was that SMTP and submission are >> extensible and many extensions are in use. Any new submission method >> would face having to replicate those extensions *and all future ones* >> or >> drive people back to SMTP. The obvious solution to that would be to >> make >> the "submission via IMAP/POP3" method 'simply' involve tunneling SMTP >> through the other protocol. That creates myriad security issues and >> increases the complexity of implementation greatly, as the state >> diagram >> for the IMAP/POP3 server suddenly has the SMTP state diagram grafted >> on to >> it. Anyway, I urge you review the archives of that discussion to see >> whether your arguments for putting submission inside IMAP/POP3 were >> considered then and if so, whether the counter-arguments still apply. >> >> An engineering decision was made then based on the discussion; what >> has >> changed that would strengthen or weaken the arguments that went into >> that >> decision? >> >> >> Philip Guenther >> >> -- >> Chief Architect >> Sendmail, Inc. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From vesely@tana.it Sun Aug 16 22:21:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2C83A6B4D for ; Sun, 16 Aug 2009 22:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qBPjlUAzk1r for ; Sun, 16 Aug 2009 22:21:35 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id ED9AF3A6A9F for ; Sun, 16 Aug 2009 22:21:34 -0700 (PDT) Received: from [192.168.15.114] (wf-salyut.imt.ru [212.16.1.106]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 17 Aug 2009 07:21:35 +0200 id 00000000005DC02F.000000004A88E8DF.0000553D Message-ID: <4A88E9A8.3010501@tana.it> Date: Mon, 17 Aug 2009 09:24:56 +0400 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ravi shankar Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6 References: <922a897b0908151243p4bc8b083u3b5b85efd16671d0@mail.gmail.com> <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> In-Reply-To: <922a897b0908160237y170dcb3me31759c8cc52b86a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 05:21:36 -0000 Ravi shankar wrote: > What Botnets take advantage of is the fact that a normal Client computer > (say, a home PC) can be infected to send spam. Instead if we classify, > SMTP as the sole "Server to Server" protocol, it gives us the liberty to > block those ports completely in the home/client computers. Not straightforwardly. We'd need a way to distinguish a server from a client, for blocking client access. From ravisha22@gmail.com Mon Aug 17 03:45:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0386428C12E for ; Mon, 17 Aug 2009 03:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftL0lKOeEcl1 for ; Mon, 17 Aug 2009 03:45:30 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 02C6D3A6DA0 for ; Mon, 17 Aug 2009 03:45:29 -0700 (PDT) Received: by qyk41 with SMTP id 41so2211425qyk.29 for ; Mon, 17 Aug 2009 03:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XoiFSJ9EuJ0fLMtWYK/4dfogZWaIrWDN27yazS7JC/M=; b=k9AAum4iFylw6/WW/rXxpaSLZoTVQ2hEx2tIM5hDEW7ESr9KMPjVl+ChmvqrkcmCvI ejpwJnsqeSV35KaR3XLZ+jTLW8R7eijtgKElQYntZwmuO3mlw9e1u96GsMyeMb4SinMk V7aMAIN4nnR34scDDCBd/kZp69sERNft7MBbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nt9nwtEbqAxqjrATh2Nh/xs4qt0xZRiL3wcPKh82PQaSRPQrhB0E/m9sL1LN2TIcwF oahGVUWhXicgUamucpEl5dJuKHiW2HFpfNfskcL2ebQjtnkQmb4zo5W39NlDlLmaUeEX 3XAYgPyWcmtVoAo8e5nkghM3l9s9k8uWE+2Q0= MIME-Version: 1.0 Received: by 10.224.98.149 with SMTP id q21mr4060846qan.229.1250505932518; Mon, 17 Aug 2009 03:45:32 -0700 (PDT) Date: Mon, 17 Aug 2009 16:15:32 +0530 Message-ID: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> Subject: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: apps-discuss@ietf.org, Al Costanzo Content-Type: multipart/alternative; boundary=001636137aa0e5b75004715419bd X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 10:45:31 -0000 --001636137aa0e5b75004715419bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Okay Al, Let me try to explain the concept, and see if i can do it better this time. My proposal has 2 parts: 1. Designating protocols for "Client to server" and "Server to server" communication 2. Blocking port 25. (this is being adopted by ISP, but apparently not all as evident from the spam figures gotten from botnets) Now the first point. Designating protocol as Client to server and Server to server (atleast in email realm), gives greater control in implementing changes to it (making changes to MUAs is much easier compared to MTAs.) Also allows to vigourously control the ports used by home PCs (which accounts for roughly70% of botnet spam) The second point. This method is "fairly" in use, but may be ISPs are waiting for this to be made as a industry standard to implement it throughtout the world. Problem part: -------------------- Now the classification i proposed in point 1 requires a protocol to submit messages, in addition to POP3/IMAP4, whcih can retrieve message. Considering SMTP is very rich in feature and extensions, if we designate it as "Server to server" protocol, POP3 and IMAP4, can be extended to submit messages by themselves by using the same ports 110/143. This can work securely on top of SSL, which most companies have implemented for POP3 and IMAP usage. Depending on the architecture of the POP3/IMAP in a messaging server, the difficulty level will vary, but this will give greater control over the protocols for future changes and certainly bring down the botnet spam. Regards, Ravi Again I'm not trying to propose this as a solution against account theft and it is out of scope of this work as well. --001636137aa0e5b75004715419bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay Al,
=A0
Let me try to explain the concept, and see if i can do it better this = time.
=A0
My proposal has 2 parts:
=A0
1. Designating protocols for "Client to server" and "Se= rver to server" communication
2. Blocking port 25. (this is being adopted by ISP, but apparently not= all as evident=A0from the spam figures gotten from botnets)
=A0
Now the first point.
=A0
Designating protocol as Client to server and Server to server (atleast= in email realm), gives greater control in implementing changes to it (maki= ng changes to MUAs is much easier compared to MTAs.)
Also allows to vigourously control the ports used by home=A0PCs (which= accounts for roughly70% of botnet spam)
=A0
The second point.
=A0
This=A0method is "fairly" in use, but may be ISPs are waitin= g for this to be made as a industry standard to implement it throughtout th= e world.
=A0
=A0
Problem part:
--------------------
=A0
Now the classification i proposed in point 1 requires a protocol to su= bmit messages, in addition to POP3/IMAP4, whcih can retrieve message. Consi= dering SMTP is very rich in feature and extensions,
if we designate it as "Server to server" protocol,=A0 POP3 a= nd IMAP4, can be extended to submit messages by themselves by using the sam= e ports 110/143. This can work securely on top of SSL,
which most companies=A0have implemented for POP3 and IMAP usage.
=A0
Depending on the architecture of the POP3/IMAP in a messaging server, = the difficulty level will vary, but this will give greater control over the= protocols for future changes and certainly bring down the botnet spam.
=A0
Regards,
Ravi
=A0
Again I'm not trying to propose this as a solution against account= theft and it is out of scope of this work=A0as well.
--001636137aa0e5b75004715419bd-- From dave@cridland.net Mon Aug 17 04:06:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9924728C264 for ; Mon, 17 Aug 2009 04:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Aaf9eeDZJl for ; Mon, 17 Aug 2009 04:06:51 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 427AF28C2A7 for ; Mon, 17 Aug 2009 04:06:51 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 17 Aug 2009 12:06:53 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> In-Reply-To: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> MIME-Version: 1.0 Message-Id: <28382.1250507211.886761@puncture> Date: Mon, 17 Aug 2009 12:06:51 +0100 From: Dave Cridland To: Ravi shankar , General discussion of application-layer protocols , Al Costanzo Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:06:52 -0000 On Mon Aug 17 11:45:32 2009, Ravi shankar wrote: > Let me try to explain the concept, and see if i can do it better > this time. > > Let me try to explain the response again, and see if I can do it better this time. > My proposal has 2 parts: > > 1. Designating protocols for "Client to server" and "Server to > server" > communication This is already the case. SMTP and Submission are two closely related protocols, but they are different, and run on different ports. Submission *cannot* be used for botnet "shotgun" spam, since it requires authentication, even for local deliveries. > 2. Blocking port 25. (this is being adopted by ISP, but apparently > not all > as evident from the spam figures gotten from botnets) Which is entirely possible already. It should be noted that blocking port 25 prevents people from running their own mailserver locally, which is a problem for many (including myself) who might wish to do so for security reasons, amongst others. Still, however, this leaves port 587 open, allowing the client-to-server protocol - Submission - to operate unhindered. > Designating protocol as Client to server and Server to server > (atleast in > email realm), gives greater control in implementing changes to it > (making > changes to MUAs is much easier compared to MTAs.) Yes, but given that all existing MUAs already support SMTP, making them support Submission can be as simple as allowing them to have the port number changed. So if you're arguing on the basis of ease of implementation, I think you're arguing against yourself. > The second point. > > This method is "fairly" in use, but may be ISPs are waiting for > this to be > made as a industry standard to implement it throughtout the world. I'm sure there's many ISPs who'd be happy to make email suddenly entirely within their control. > Now the classification i proposed in point 1 requires a protocol to > submit > messages, in addition to POP3/IMAP4, whcih can retrieve message. Like Submission. > Considering > SMTP is very rich in feature and extensions, > if we designate it as "Server to server" protocol, POP3 and IMAP4, > can be > extended to submit messages by themselves by using the same ports > 110/143. The two halves of your argument here are not simply orthogonal, but actually your premise argues against your conclusion, and in many cases continues to do so throughout this section. Perhaps you meant: Considering SMTP is very rich in feature and extensions, we could reuse the protocol on a distinct port, and repurpose it specifically as a client-to-server protocol only - indeed, we already have, and called it "Submission". > This can work securely on top of SSL, > which most companies have implemented for POP3 and IMAP usage. This can work securely on top of TLS, which most companies have implemented for SMTP usage. > Depending on the architecture of the POP3/IMAP in a messaging > server, the > difficulty level will vary, but this will give greater control over > the > protocols for future changes and certainly bring down the botnet > spam. Independent of the architecture of the POP3/IMAP in a messaging server, the difficulty level will be low, immediately leveraging current and future changes, and should certainly bring down the botnet spam. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ravisha22@gmail.com Mon Aug 17 04:30:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6273A28C2C3 for ; Mon, 17 Aug 2009 04:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+AZ1mbqLsWs for ; Mon, 17 Aug 2009 04:30:50 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 92F1728C2B6 for ; Mon, 17 Aug 2009 04:30:49 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so960242qwi.31 for ; Mon, 17 Aug 2009 04:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xxiGWCU92Ge+iEeH+QwrQGpM9DqEnPv7jHWAwXXigS4=; b=ts7KYG6v4C+Mbe/bBH9YfB+EkBHCYlr3FhugvAQbbnBNhgwMpjrY89w3yZVvtcXflH 4s5HPCSKU4udirP9VnZNsmjg9tXrGFCuauBicUE2+nGsTEht5nre6GCcMOGgY2JrsEH4 mHoPSPQz94zMOQxEGITSc+QrCZiZVBjotPg4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x0l+pAINiNaVJRJpuP54nfv6mdE+9uZuC7diBlFpDpW/iHDo5XrkVUoCt90h8x3hph r7EhihVL28WoJIscxwTGn5UyNYCeeGAOGDet4yGGAExYtvffM8n95b1q6tq3GwlEsfLh nRUu7r9kA1XNYHQQ9NXW4Gacf44lCyiJrVvrE= MIME-Version: 1.0 Received: by 10.224.117.8 with SMTP id o8mr4092110qaq.227.1250508651602; Mon, 17 Aug 2009 04:30:51 -0700 (PDT) In-Reply-To: <28382.1250507211.886761@puncture> References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> Date: Mon, 17 Aug 2009 17:00:51 +0530 Message-ID: <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: Dave Cridland Content-Type: multipart/alternative; boundary=000feaeec653f7a577047154bbe5 Cc: General discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:30:51 -0000 --000feaeec653f7a577047154bbe5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The whole point of my discussion is to seperate SMTP from normal client computers, so that botnets wont use SMTP to disguise a homepc as a registered server and send spam impersonating some domain. Ravi On Mon, Aug 17, 2009 at 4:36 PM, Dave Cridland wrote: > On Mon Aug 17 11:45:32 2009, Ravi shankar wrote: > >> Let me try to explain the concept, and see if i can do it better this >> time. >> >> >> Let me try to explain the response again, and see if I can do it better > this time. > > My proposal has 2 parts: >> >> 1. Designating protocols for "Client to server" and "Server to server" >> communication >> > > This is already the case. > > SMTP and Submission are two closely related protocols, but they are > different, and run on different ports. Submission *cannot* be used for > botnet "shotgun" spam, since it requires authentication, even for local > deliveries. > > > 2. Blocking port 25. (this is being adopted by ISP, but apparently not all >> as evident from the spam figures gotten from botnets) >> > > Which is entirely possible already. > > It should be noted that blocking port 25 prevents people from running their > own mailserver locally, which is a problem for many (including myself) who > might wish to do so for security reasons, amongst others. > > Still, however, this leaves port 587 open, allowing the client-to-server > protocol - Submission - to operate unhindered. > > Designating protocol as Client to server and Server to server (atleast in >> email realm), gives greater control in implementing changes to it (making >> changes to MUAs is much easier compared to MTAs.) >> > > Yes, but given that all existing MUAs already support SMTP, making them > support Submission can be as simple as allowing them to have the port number > changed. So if you're arguing on the basis of ease of implementation, I > think you're arguing against yourself. > > The second point. >> >> This method is "fairly" in use, but may be ISPs are waiting for this to be >> made as a industry standard to implement it throughtout the world. >> > > I'm sure there's many ISPs who'd be happy to make email suddenly entirely > within their control. > > Now the classification i proposed in point 1 requires a protocol to submit >> messages, in addition to POP3/IMAP4, whcih can retrieve message. >> > > Like Submission. > > Considering >> SMTP is very rich in feature and extensions, >> if we designate it as "Server to server" protocol, POP3 and IMAP4, can be >> extended to submit messages by themselves by using the same ports 110/143. >> > > The two halves of your argument here are not simply orthogonal, but > actually your premise argues against your conclusion, and in many cases > continues to do so throughout this section. > > Perhaps you meant: > > Considering SMTP is very rich in feature and extensions, we could reuse the > protocol on a distinct port, and repurpose it specifically as a > client-to-server protocol only - indeed, we already have, and called it > "Submission". > > This can work securely on top of SSL, >> which most companies have implemented for POP3 and IMAP usage. >> > > This can work securely on top of TLS, which most companies have implemented > for SMTP usage. > > Depending on the architecture of the POP3/IMAP in a messaging server, the >> difficulty level will vary, but this will give greater control over the >> protocols for future changes and certainly bring down the botnet spam. >> > > Independent of the architecture of the POP3/IMAP in a messaging server, the > difficulty level will be low, immediately leveraging current and future > changes, and should certainly bring down the botnet spam. > > Dave. > -- > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > --000feaeec653f7a577047154bbe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The whole point of my discussion is to seperate SMTP from normal clien= t computers, so that botnets wont use SMTP to disguise a homepc as a regist= ered server and send spam impersonating some domain.
=A0
Ravi

On Mon, Aug 17, 2009 at 4:36 PM, Dave Cridland <= span dir=3D"ltr"><dave@cridland.net= > wrote:
On Mon Aug 17 11:45:32 2009, Ravi shankar wrote:
Let me try to explain the concep= t, and see if i can do it better this time.


Let me try to explain the response again, and see if I can do it better thi= s time.=20


My proposal has 2 parts:

= 1. Designating protocols for "Client to server" and "Server = to server"
communication

This is already the case.

SM= TP and Submission are two closely related protocols, but they are different= , and run on different ports. Submission *cannot* be used for botnet "= shotgun" spam, since it requires authentication, even for local delive= ries.=20



2. Blocking port 25. (this is be= ing adopted by ISP, but apparently not all
as evident from the spam figu= res gotten from botnets)

Which is entirely possible already.

It should= be noted that blocking port 25 prevents people from running their own mail= server locally, which is a problem for many (including myself) who might wi= sh to do so for security reasons, amongst others.

Still, however, this leaves port 587 open, allowing the client-to-serve= r protocol - Submission - to operate unhindered.=20


Designating protocol as Client t= o server and Server to server (atleast in
email realm), gives greater co= ntrol in implementing changes to it (making
changes to MUAs is much easier compared to MTAs.)

Yes, but given that all existing MUAs already support SMTP, making them su= pport Submission can be as simple as allowing them to have the port number = changed. So if you're arguing on the basis of ease of implementation, I= think you're arguing against yourself.=20


The second point.

This me= thod is "fairly" in use, but may be ISPs are waiting for this to = be
made as a industry standard to implement it throughtout the world.

I'm sure there's many ISPs who'd be happy to = make email suddenly entirely within their control.=20


Now the classification i propose= d in point 1 requires a protocol to submit
messages, in addition to POP3= /IMAP4, whcih can retrieve message.

Like Submission.=20


=A0Considering
SMTP is very r= ich in feature and extensions,
if we designate it as "Server to ser= ver" protocol, =A0POP3 and IMAP4, can be
extended to submit messages by themselves by using the same ports 110/143.<= br>

The two halves of your argument here are not simp= ly orthogonal, but actually your premise argues against your conclusion, an= d in many cases continues to do so throughout this section.

Perhaps you meant:

Considering SMTP is very rich in feature and = extensions, we could reuse the protocol on a distinct port, and repurpose i= t specifically as a client-to-server protocol only - indeed, we already hav= e, and called it "Submission".=20


This can work securely on top of= SSL,
which most companies have implemented for POP3 and IMAP usage.

This can work securely on top of TLS, which most com= panies have implemented for SMTP usage.=20


Depending on the architecture of= the POP3/IMAP in a messaging server, the
difficulty level will vary, bu= t this will give greater control over the
protocols for future changes and certainly bring down the botnet spam.
<= /blockquote>
Independent of the architecture of the POP3/IMAP in a= messaging server, the difficulty level will be low, immediately leveraging= current and future changes, and should certainly bring down the botnet spa= m.

Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dav= e.cridland.net
=A0- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/=
=A0- http:/= /dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
=

--000feaeec653f7a577047154bbe5-- From dave@cridland.net Mon Aug 17 04:33:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C26328C2C4 for ; Mon, 17 Aug 2009 04:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP6iW0NvO+dm for ; Mon, 17 Aug 2009 04:33:04 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 0391828C2C3 for ; Mon, 17 Aug 2009 04:33:04 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 17 Aug 2009 12:33:06 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> In-Reply-To: <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> MIME-Version: 1.0 Message-Id: <28382.1250508786.610976@puncture> Date: Mon, 17 Aug 2009 12:33:06 +0100 From: Dave Cridland To: Ravi shankar , General discussion of application-layer protocols , Al Costanzo Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:33:05 -0000 On Mon Aug 17 12:30:51 2009, Ravi shankar wrote: > The whole point of my discussion is to seperate SMTP from normal > client > computers, so that botnets wont use SMTP to disguise a homepc as a > registered server and send spam impersonating some domain. And the whole point of my response is that this is already the case, and is better achieved with Submission, not an entirely new protocol. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From tony@att.com Mon Aug 17 04:39:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1AF28C283 for ; Mon, 17 Aug 2009 04:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.342 X-Spam-Level: X-Spam-Status: No, score=-106.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCjg4rgb5PEe for ; Mon, 17 Aug 2009 04:39:24 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id A856328C2B0 for ; Mon, 17 Aug 2009 04:38:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1250509139!30287540!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 27142 invoked from network); 17 Aug 2009 11:39:00 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-13.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Aug 2009 11:39:00 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7HBcxt9026016 for ; Mon, 17 Aug 2009 06:38:59 -0500 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7HBculo025976 for ; Mon, 17 Aug 2009 06:38:56 -0500 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n7HBcuKf012744 for ; Mon, 17 Aug 2009 06:38:56 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n7HBcqVZ012718 for ; Mon, 17 Aug 2009 06:38:53 -0500 Received: from [135.70.9.151] (vpn-135-70-9-151.vpn.west.att.com[135.70.9.151]) by maillennium.att.com (mailgw1) with ESMTP id <20090817113852gw1003ib5pe> (Authid: tony); Mon, 17 Aug 2009 11:38:52 +0000 X-Originating-IP: [135.70.9.151] Message-ID: <4A89414A.90604@att.com> Date: Mon, 17 Aug 2009 07:38:50 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: General discussion of application-layer protocols Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> In-Reply-To: <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:39:25 -0000 Submission already *is* a separate protocol from SMTP, running on a separate port. Tony Hansen tony@att.com Ravi shankar wrote: > The whole point of my discussion is to seperate SMTP from normal client > computers, so that botnets wont use SMTP to disguise a homepc as a > registered server and send spam impersonating some domain. > > Ravi > > On Mon, Aug 17, 2009 at 4:36 PM, Dave Cridland > wrote: > > On Mon Aug 17 11:45:32 2009, Ravi shankar wrote: > > Let me try to explain the concept, and see if i can do it better > this time. > > > Let me try to explain the response again, and see if I can do it > better this time. > > > My proposal has 2 parts: > > 1. Designating protocols for "Client to server" and "Server to > server" > communication > > > This is already the case. > > SMTP and Submission are two closely related protocols, but they are > different, and run on different ports. Submission *cannot* be used > for botnet "shotgun" spam, since it requires authentication, even > for local deliveries. > > > > 2. Blocking port 25. (this is being adopted by ISP, but > apparently not all > as evident from the spam figures gotten from botnets) > > > Which is entirely possible already. > > It should be noted that blocking port 25 prevents people from > running their own mailserver locally, which is a problem for many > (including myself) who might wish to do so for security reasons, > amongst others. > > Still, however, this leaves port 587 open, allowing the > client-to-server protocol - Submission - to operate unhindered. > > > Designating protocol as Client to server and Server to server > (atleast in > email realm), gives greater control in implementing changes to > it (making > changes to MUAs is much easier compared to MTAs.) > > > Yes, but given that all existing MUAs already support SMTP, making > them support Submission can be as simple as allowing them to have > the port number changed. So if you're arguing on the basis of ease > of implementation, I think you're arguing against yourself. > > > The second point. > > This method is "fairly" in use, but may be ISPs are waiting for > this to be > made as a industry standard to implement it throughtout the world. > > > I'm sure there's many ISPs who'd be happy to make email suddenly > entirely within their control. > > > Now the classification i proposed in point 1 requires a protocol > to submit > messages, in addition to POP3/IMAP4, whcih can retrieve message. > > > Like Submission. > > > Considering > SMTP is very rich in feature and extensions, > if we designate it as "Server to server" protocol, POP3 and > IMAP4, can be > extended to submit messages by themselves by using the same > ports 110/143. > > > The two halves of your argument here are not simply orthogonal, but > actually your premise argues against your conclusion, and in many > cases continues to do so throughout this section. > > Perhaps you meant: > > Considering SMTP is very rich in feature and extensions, we could > reuse the protocol on a distinct port, and repurpose it specifically > as a client-to-server protocol only - indeed, we already have, and > called it "Submission". > > > This can work securely on top of SSL, > which most companies have implemented for POP3 and IMAP usage. > > > This can work securely on top of TLS, which most companies have > implemented for SMTP usage. > > > Depending on the architecture of the POP3/IMAP in a messaging > server, the > difficulty level will vary, but this will give greater control > over the > protocols for future changes and certainly bring down the botnet > spam. > > > Independent of the architecture of the POP3/IMAP in a messaging > server, the difficulty level will be low, immediately leveraging > current and future changes, and should certainly bring down the > botnet spam. > > Dave. > -- > Dave Cridland - mailto:dave@cridland.net > - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ravisha22@gmail.com Mon Aug 17 04:49:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0906E3A68A8 for ; Mon, 17 Aug 2009 04:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfA9iArUsd8U for ; Mon, 17 Aug 2009 04:49:49 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id D0ACE28C2C0 for ; Mon, 17 Aug 2009 04:49:10 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so962171qwi.31 for ; Mon, 17 Aug 2009 04:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hC1kzZBYAyO3L+2rIMfhLT1OzJpjrlfc4eN74FQmRT0=; b=Kx5OJoT/OAOA9g3Hyl7oIi1KnqbBqnqnxjl9qxyt9vHwo2oI8Zz65EIwVsaBksStn0 aLMN2Ae3Z1V+WnTFyCKw7tzgQd1c/QS5REdEQiBdkWZfC05THdHi85zVK6V1/uPC6wVD FzGAGQ8FM+c/o0OgwtubdVtxKkAnw18YxcOWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gx0i3SNtR1L2wkFxBBfIBMwiDneTKqTb4DmxWE46its6Rp/OQ/QdWCNWsAbX60WA42 1xQ9Rl+ez+WuA6Lbm2TT9VB3ZQSJcdHSiOJNgCcWpzue+B/FGtcFCwrh8Hu6Zd3y9PG2 tQfeDYxmJc/e3s98/JEkKz9e2G+AmHS3TIV/g= MIME-Version: 1.0 Received: by 10.224.116.212 with SMTP id n20mr4095521qaq.172.1250509753963; Mon, 17 Aug 2009 04:49:13 -0700 (PDT) In-Reply-To: <28382.1250508786.610976@puncture> References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> Date: Mon, 17 Aug 2009 17:19:13 +0530 Message-ID: <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: Dave Cridland Content-Type: multipart/alternative; boundary=00c09f972008ac55f6047154fdf3 Cc: General discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:49:50 -0000 --00c09f972008ac55f6047154fdf3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave, I dont think this is turning out to be a healthy discussion, as your responses, instead of re-inforcing your point, is like mocking me. If you read my original post, I'm not proposing a new protocol altogather but a extension to the already existing ones to give greater control over how they are used. And i do know the fact that botnets do not send spam using submission protocol, as it requires authentication. Regards, Ravi On Mon, Aug 17, 2009 at 5:03 PM, Dave Cridland wrote: > On Mon Aug 17 12:30:51 2009, Ravi shankar wrote: > >> The whole point of my discussion is to seperate SMTP from normal client >> computers, so that botnets wont use SMTP to disguise a homepc as a >> registered server and send spam impersonating some domain. >> > > And the whole point of my response is that this is already the case, and is > better achieved with Submission, not an entirely new protocol. > > > Dave. > -- > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > --00c09f972008ac55f6047154fdf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dave,
=A0
I dont think this is turning out to be a healthy discussion, as your r= esponses, instead of re-inforcing=A0your point, is like=A0mocking me.
If you read my original post, I'm not proposing a new protocol alt= ogather but a extension to the already existing ones to give greater contro= l over how they are used.
=A0
And=A0 i do know the fact that botnets do not send spam using submissi= on protocol, as it requires authentication.
Regards,
Ravi
On Mon, Aug 17, 2009 at 5:03 PM, Dave Cridland <= span dir=3D"ltr"><dave@cridland.net= > wrote:
On Mon Aug 17 12:30:51 2009, Ravi shankar wrote:
The whole point of my discussion= is to seperate SMTP from normal client
computers, so that botnets wont = use SMTP to disguise a homepc as a
registered server and send spam impersonating some domain.
=
And the whole point of my response is that this is already the ca= se, and is better achieved with Submission, not an entirely new protocol.= =20


Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.c= ridland.net
=A0- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/=
=A0- http:/= /dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

--00c09f972008ac55f6047154fdf3-- From dave@cridland.net Mon Aug 17 04:57:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F5E3A6C6D for ; Mon, 17 Aug 2009 04:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-U4wFttUrJY for ; Mon, 17 Aug 2009 04:57:04 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 052943A68A8 for ; Mon, 17 Aug 2009 04:57:03 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 17 Aug 2009 12:57:06 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> In-Reply-To: <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> MIME-Version: 1.0 Message-Id: <28382.1250510226.785110@puncture> Date: Mon, 17 Aug 2009 12:57:06 +0100 From: Dave Cridland To: Ravi shankar , General discussion of application-layer protocols , Al Costanzo Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:57:05 -0000 On Mon Aug 17 12:49:13 2009, Ravi shankar wrote: > I dont think this is turning out to be a healthy discussion, as your > responses, instead of re-inforcing your point, is like mocking me. Then please read the responses you're getting, because this is the first indication I've seen that you're reading any of them. > If you read my original post, I'm not proposing a new protocol > altogather > but a extension to the already existing ones to give greater > control over > how they are used. I see that, but what nearly everyone is suggesting is that instead of doing anything new, simply using what we have already achieves your stated goals. If your goal is actually that you don't think that the functions of mailstore and submission should use distinct protocols, then this is an entirely different argument - I'd note that whilst X.400 combines these two functions, internet mail has historically not done so, and the changes required both to client and server would be impressively large - much larger than simply using port 587, which is largely all that's required for typical simple cases of using Submission. > And i do know the fact that botnets do not send spam using > submission > protocol, as it requires authentication. So let me turn the question around. In what way are the problems you're trying to solve not solved by use of Submission? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ravisha22@gmail.com Mon Aug 17 11:13:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9886128C2DF for ; Mon, 17 Aug 2009 11:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfY31WVCHV2C for ; Mon, 17 Aug 2009 11:13:08 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 020753A6F05 for ; Mon, 17 Aug 2009 11:13:07 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1042221qwi.31 for ; Mon, 17 Aug 2009 11:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AZmfgh0TV3+Eam9aUKIe5PR6/fg/gpj6ZYiR+UGxnD8=; b=mi40wmLJ4XE2Czm7lhZrrhE9421JOjKuYxYlCsvUFSpkDUnCp/+I7mwWbCh+aDh19y bAK2C0JyEBXYoYvt2XAwdm9webF3xCDwfv7OZMOOrEdr3/OYKn98wpc2KhYySHBHqG6v ymJpBaaEbffE9C8wb+qaH7Dj1cCHGfV6UhnTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VxGGW3tazdpOTo2T0Qfs2d/ty3HQzqakrLEQimC9KENXiUipuE5fzx6II//s/EAlsx aAaQ1STmIn5eZWFeV5gbhKVfQgRr+iNJiP6s4M7890ppAfXfmEWW3YlfYaNES2fwYOOj WVskWOn1AQHsy0jI8HdoYF0gp5YBmlG76bv7Y= MIME-Version: 1.0 Received: by 10.224.79.22 with SMTP id n22mr4532384qak.230.1250532790618; Mon, 17 Aug 2009 11:13:10 -0700 (PDT) In-Reply-To: <20090817161942.GQ1043@Sun.COM> References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> <20090817161942.GQ1043@Sun.COM> Date: Mon, 17 Aug 2009 23:43:10 +0530 Message-ID: <922a897b0908171113s24607cc5rab1142536a60430d@mail.gmail.com> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail From: Ravi shankar To: Nicolas Williams , Al Costanzo , General discussion of application-layer protocols Content-Type: multipart/alternative; boundary=00c09f8a4ce4c3e12004715a5a65 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:13:09 -0000 --00c09f8a4ce4c3e12004715a5a65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you all for replying to assist me. I much appreciate it. It would be interesting to see, how much submission is used for this purpose in commercial mailing servers. Regards, Ravi On Mon, Aug 17, 2009 at 9:49 PM, Nicolas Williams wrote: > On Mon, Aug 17, 2009 at 05:19:13PM +0530, Ravi shankar wrote: > > I dont think this is turning out to be a healthy discussion, as your > > responses, instead of re-inforcing your point, is like mocking me. > > Losing an argument may well not feel like having a healthy discussion, > but if so that's because your expectations were wrong (i.e., you > expected that people would agree with the particulars of your idea). > > A healthy discussion includes the possibility of losing an argument. > Someone who rejects that possibility cannot engage in a healthy > discussion whenever they are on the losing end. > > > If you read my original post, I'm not proposing a new protocol altogather > > but a extension to the already existing ones to give greater control over > > how they are used. > > It's still something new, and since there's already something that > accomplishes what you propose (Submission), you've lost the argument. > > > And i do know the fact that botnets do not send spam using submission > > protocol, as it requires authentication. > > Then that's all we need: Submission. You yourself admit it. But you > *really* want an IMAP4 and a POP3 extension, and you're not explaining > why, and even if you did, it's not likely that you'd win the argument. > > But I'll do you a favor and produce an argument for an IMAP4/POP3 > extension for e-mail submission: IMAP4/POP3 connections tend to stay > alive for long periods of time[*], whereas SUBMIT connections tend to > stay alive just long enough to empty an Outgoing folder, so you could > reduce the number of TLS connections needed if you just extend > IMAP4/POP3. But I don't think that argument is very strong: TLS > overhead is not a problem here. > > [*] At least when I use mutt. > > Nico > -- > --00c09f8a4ce4c3e12004715a5a65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you all for replying to assist me. I much appreciate it.
=A0
It would be interesting to see, how much submission is used for this p= urpose in commercial mailing servers.
=A0
Regards,
Ravi
On Mon, Aug 17, 2009 at 9:49 PM, Nicolas William= s <Nicolas= .Williams@sun.com> wrote:
On Mon, Aug 17, 2009 at 05:19:13PM +0530, Ravi shankar wr= ote:
> I dont think this is turning out to be a healthy discussion, a= s your
> responses, instead of re-inforcing your point, is like mocki= ng me.

Losing an argument may well not feel like having a healthy discus= sion,
but if so that's because your expectations were wrong (i.e., y= ou
expected that people would agree with the particulars of your idea).<= br>
A healthy discussion includes the possibility of losing an argument.Someone who rejects that possibility cannot engage in a healthy
discuss= ion whenever they are on the losing end.

> If you read my original post, I'm not propos= ing a new protocol altogather
> but a extension to the already existi= ng ones to give greater control over
> how they are used.

It's still something new, and since there's already something that<= br>accomplishes what you propose (Submission), you've lost the argument= .

> And =A0i do know the fact that botnets do not se= nd spam using submission
> protocol, as it requires authentication.
Then that's all we need: Submission. =A0You yourself admit = it. =A0But you
*really* want an IMAP4 and a POP3 extension, and you're not explaining<= br>why, and even if you did, it's not likely that you'd win the arg= ument.

But I'll do you a favor and produce an argument for an IM= AP4/POP3
extension for e-mail submission: IMAP4/POP3 connections tend to stay
ali= ve for long periods of time[*], whereas SUBMIT connections tend to
stay = alive just long enough to empty an Outgoing folder, so you could
reduce = the number of TLS connections needed if you just extend
IMAP4/POP3. =A0But I don't think that argument is very strong: TLS
o= verhead is not a problem here.

[*] At least when I use mutt.

= Nico
--

--00c09f8a4ce4c3e12004715a5a65-- From tony@att.com Mon Aug 17 11:43:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8033A6F7E for ; Mon, 17 Aug 2009 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9W58Ku41-wY for ; Mon, 17 Aug 2009 11:43:40 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id B05503A6F8A for ; Mon, 17 Aug 2009 11:43:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1250534623!38113075!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 27697 invoked from network); 17 Aug 2009 18:43:44 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Aug 2009 18:43:44 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7HIhhxS024557 for ; Mon, 17 Aug 2009 13:43:43 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n7HIhcrH024442 for ; Mon, 17 Aug 2009 13:43:39 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n7HIhc20009274 for ; Mon, 17 Aug 2009 14:43:38 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n7HIhZrk009208 for ; Mon, 17 Aug 2009 14:43:35 -0400 Received: from [135.25.188.131] (unknown[135.25.188.131]) by maillennium.att.com (mailgw1) with ESMTP id <20090817184335gw1003ic4ce> (Authid: tony); Mon, 17 Aug 2009 18:43:35 +0000 X-Originating-IP: [135.25.188.131] Message-ID: <4A89A4D6.5070602@att.com> Date: Mon, 17 Aug 2009 14:43:34 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: General discussion of application-layer protocols Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> In-Reply-To: <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:43:41 -0000 Ravi shankar wrote: > ... > If you read my original post, I'm not proposing a new protocol > altogather but a extension to the already existing ones to give > greater control over how they are used. > > And i do know the fact that botnets do not send spam using submission > protocol, as it requires authentication. > Regards, > Ravi > > Dave Cridland > On Mon Aug 17 12:30:51 2009, Ravi shankar wrote: > > The whole point of my discussion is to seperate SMTP from > normal client computers, so that botnets wont use SMTP to > disguise a homepc as a registered server and send spam > impersonating some domain. > > And the whole point of my response is that this is already the > case, and is better achieved with Submission, not an entirely new > protocol. Ravi, what you're asking to be done was already done over a decade ago, but the protocol that was modified/extended was SMTP itself. Out of SMTP came the Submission protocol. The Submission protocol is NOT SMTP, but looks a LOT like SMTP, normally runs on port 587, and does things like requiring the AUTH command to be used, as well as some other client-only types of actions. In one of your email messages, you stated a false premise: In the present setup, SMTP can be used by any computer connected to Internet to send mails directly to the server, resulting in spam which by normal means in indistinguishable from legitimate mails. Many ISPs turned off port 25 years ago and require their email user clients to use the Submission protocol to send email. They reserve SMTP for purely server level communication, and totally eliminate it from end-user communication. I would like to know what it is you're expecting to gain from teaching IMAP or POP to do email submission that is not already achieved by the ISPs blocking user-level SMTP and requiring the Submission protocol to be used? For your research, you should also read some of the white papers that the folks at MAAWG have written on the topic, including how and why port 25 should be blocked and how use of the Submission protocol is to be used in its place. A different question that I think WOULD make an interesting research topic is how much harm is happening due to the few ISPs out there that don't *yet* require the Submission protocol to be used? Tony Hansen tony@att.com From alexey.melnikov@isode.com Mon Aug 17 13:46:21 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B5C3A6783 for ; Mon, 17 Aug 2009 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvUmyW5Zp0U4 for ; Mon, 17 Aug 2009 13:46:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2D8D43A6D24 for ; Mon, 17 Aug 2009 13:46:21 -0700 (PDT) Received: from [92.40.185.38] (92.40.185.38.sub.mbb.three.co.uk [92.40.185.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 17 Aug 2009 21:46:25 +0100 Message-ID: <4A89C193.5050102@isode.com> Date: Mon, 17 Aug 2009 21:46:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Earlier deadline for BOFs in Hiroshima MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 20:46:22 -0000 Based on discussions between IESG and AMS about improving BOF/WG scheduling, there would be an earlier deadline for BOF requests: * September 7, Monday - Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PT (21:00 UTC/GMT). To request a BOF, please see instructions on Requesting a BOF. [9 weeks prior] * September 14, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 PT (21:00 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool [8 weeks prior] So please let Lisa and myself know if you want to have a BOF in Hiroshima as soon as possible. From eran@hueniverse.com Wed Aug 19 11:31:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB603A68DA for ; Wed, 19 Aug 2009 11:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbtp221y-RUD for ; Wed, 19 Aug 2009 11:31:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 731883A69C5 for ; Wed, 19 Aug 2009 11:31:56 -0700 (PDT) Received: (qmail 3162 invoked from network); 19 Aug 2009 18:31:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Aug 2009 18:31:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Aug 2009 11:31:54 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" , URI Date: Wed, 19 Aug 2009 11:31:57 -0700 Subject: Registration timing of new URI schemes Thread-Topic: Registration timing of new URI schemes Thread-Index: Acog+1WKMVhfFQZ/SLOF/Z/NaVQ++w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 18:31:57 -0000 While working on a new protocol we (might have) identified a need for a new= URI scheme. The problem is that the protocol and use cases are still in th= eir early stage, and will require multiple iterations and experimentation t= o figure out. At the same time, this effort has failed over the past two ye= ars because of attempts to find the 'ideal' solution prior to real work exp= erimentations. We are trying something different now by building a couple o= f live services offered by some large web players. The proposed new URI scheme is not yet well defined. We only have small bit= s of information about how it should work, whether it could/should be resol= vable, and if it should be bound to a specific protocol. But we are only go= ing to figure it out by experimentation. The question is, at what point should we request a provisional registration= of the new URI scheme? How much running code and actual deployment is appr= opriate? We might end up using an existing scheme instead or decide that th= e new scheme is indeed required. I am asking this because I have no desire to spend time and energy discussi= ng a new URI scheme (and provisional at that) when we clearly don't have al= l the answers. But at the same time, I don't want to cause problems by usin= g a new scheme that is not at all registered. Any guidelines? BCP 35 does not provide guidelines as to *when* should a ne= w URI scheme be registered and how much experimentation is allowed. EHL From timbray@gmail.com Wed Aug 19 11:36:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A633A6C4C for ; Wed, 19 Aug 2009 11:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0s1r+IiUZUE for ; Wed, 19 Aug 2009 11:36:17 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 5FBB23A6BE5 for ; Wed, 19 Aug 2009 11:36:17 -0700 (PDT) Received: by ewy2 with SMTP id 2so1350176ewy.43 for ; Wed, 19 Aug 2009 11:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=euKnbM0WrNf+W9Zf2gD2YQVkQQdHjR/u097e9KDo2vg=; b=YT422m3f95ew7BiKtarV0A5eXva4+/nfnbjmpS9xzFm2+vyr1cmHNW7zQd7bozY1dI i56fbNrmj6qTU0QGJckyk+e8oV1+Dbfnp0aFVh7G7Vad/2DuM1HYY7PMaVGHFp2Kor7l s+HYlGcm8Sep2Y346GMCR5bmIjVAALdvmw8Pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=i2D3sufdbdl3d2ShHmQcgt9X+8zfplPrdKtA6e2mXf9J/BnJ1ToLlwBeUuUs3TpTn1 9oqpDih5um9Ge+sw/IeeyT1oBgu7zjPAHOZP1w61YDs2QaGqeFwZbE2C4QIOWFA9z/4N sMirpUHzsUrkrnHpKMGLDbNxV+ZeCFB1eS1w4= MIME-Version: 1.0 Sender: timbray@gmail.com Received: by 10.211.168.8 with SMTP id v8mr6071611ebo.19.1250706978048; Wed, 19 Aug 2009 11:36:18 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Aug 2009 11:36:18 -0700 X-Google-Sender-Auth: 1b0693b3f698a6b0 Message-ID: <517bf110908191136v2b645051oba52db3c6a9dfbcb@mail.gmail.com> Subject: Re: Registration timing of new URI schemes From: Tim Bray To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 18:36:18 -0000 On Wed, Aug 19, 2009 at 11:31 AM, Eran Hammer-Lahav wr= ote: > While working on a new protocol we (might have) identified a need for a n= ew URI scheme. The problem is that the protocol and use cases are still in = their early stage, and will require multiple iterations and experimentation= to figure out. At the same time, this effort has failed over the past two = years because of attempts to find the 'ideal' solution prior to real work e= xperimentations. We are trying something different now by building a couple= of live services offered by some large web players. > Well, one thing that has historically happened is that when you put in the new-scheme request, a bunch of grumpy old Web-heads want to have an argument as to whether you really need a new one, when there are lots of other perfectly good ones out there and quite a bit of benefit from re-use. You might save some time and irritation by having that argument first, and it might help you progress your thinking about the problem in general. -Tim From mark@coactus.com Wed Aug 19 13:19:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6933A6C2F for ; Wed, 19 Aug 2009 13:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY7wZGPTfbAo for ; Wed, 19 Aug 2009 13:19:39 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 14C063A6CC4 for ; Wed, 19 Aug 2009 13:19:38 -0700 (PDT) Received: by gxk17 with SMTP id 17so6145690gxk.19 for ; Wed, 19 Aug 2009 13:19:40 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.150.115.12 with SMTP id n12mr11120084ybc.145.1250713180748; Wed, 19 Aug 2009 13:19:40 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Aug 2009 16:19:40 -0400 X-Google-Sender-Auth: 601839365bf4ab1a Message-ID: Subject: Re: Registration timing of new URI schemes From: Mark Baker To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 20:19:39 -0000 On Wed, Aug 19, 2009 at 2:31 PM, Eran Hammer-Lahav wrote: > Any guidelines? BCP 35 does not provide guidelines as to *when* should a new URI scheme be registered and how much experimentation is allowed. I think the "when" is "when you meet the requirements of section 3", and I doubt you'd have any trouble meeting them, even if the referenced specification was a work in progress. The provisional registry exists in large part for situations like the one you describe. Mark. From eran@hueniverse.com Wed Aug 19 22:48:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3703A6850 for ; Wed, 19 Aug 2009 22:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssFGKRpeHIRS for ; Wed, 19 Aug 2009 22:48:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 54BCC3A69E6 for ; Wed, 19 Aug 2009 22:48:30 -0700 (PDT) Received: (qmail 30170 invoked from network); 20 Aug 2009 05:48:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Aug 2009 05:48:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Aug 2009 22:48:19 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" , URI Date: Wed, 19 Aug 2009 22:48:22 -0700 Subject: Guidelines on usage of // in new URI schemes Thread-Topic: Guidelines on usage of // in new URI schemes Thread-Index: AcohWdP8KIVqS5Q8QEeN+nYAszT5Mw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 05:48:31 -0000 I am in the process of proposing a new URI scheme to identify user accounts= [1]. This is part of the WebFinger protocol [2] effort. This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shor= tly but I would like to present a proposal before we have a public debate a= bout it here. The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local id= entifier). When looking at the URI specification (RFC 3986) and at the new = URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes. In this case, we have a requirement to keep the URI (the part after the sch= eme:) looking as close to an RFC-822 identifier (username@host) and that me= ans two options: acct:username@host acct://username@host The 'username@host' part seems to fit perfectly into the URI authority as d= efined by RFC 3986. However, since the URI does not have a path, it does no= t really contain a hierarchical structure (just the top level host). The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which onl= y allows the userinfo and host subcomponents of the authority component, an= d no other URI components. Since the new scheme will be often used with URI= templates and other facilities often used with http: URIs, it is very conv= enient to have a common structure (even if it is only a subset). I don't se= e any down side to using // other than defying expectations established by = the mailto: URI scheme. The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it require= s spelling out how to break the URI path into sub components specific to th= is scheme. So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reus= e as much as possible and therefore include the //. Any suggestions? EHL [1] http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-= acct-uri-scheme-for-accounts.html [2] http://code.google.com/p/webfinger From timur.shemsedinov@gmail.com Wed Aug 19 23:18:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEC93A69C0 for ; Wed, 19 Aug 2009 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H+fi3zijLM3 for ; Wed, 19 Aug 2009 23:18:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id E8E183A6850 for ; Wed, 19 Aug 2009 23:18:37 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1129847fgg.18 for ; Wed, 19 Aug 2009 23:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CHTrjInY/4GALHt8H+8dj6Sx1lxNmk5KAd3ZDppOcaU=; b=aqUq7YytInmK+sjspoWYhmOnY+9/GVd8e2gjA1rGmYSsLnK8/JZ3xlkt09umM9UmL/ VqcXntP4v9AUaO05+3msqyzQZLV5FT62dNx/QUbM9HQrRxqDpGqnW/QO7kBUwjHZHcCw Bdp+0KYXoS7XHi9gTrxxFhP8y7Yiaw10XrLU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VnPwvxaCJz71x+Q7G0MKVcd+XSfHwLux9YW/65LPmeztfxknen6ETxpVSZEQ/max3B VAXBDwBMTbKK5VOoqARfh811eVW5xXGpjyr4Ne9KFQ8LUOPUaohXBU440T8dY1SthhAH eWcda5Na7OsVuZf4a++5PlQROMhVWBos/W+/4= MIME-Version: 1.0 Received: by 10.86.222.15 with SMTP id u15mr4826713fgg.33.1250749102046; Wed, 19 Aug 2009 23:18:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 20 Aug 2009 09:18:22 +0300 Message-ID: <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> Subject: Re: Guidelines on usage of // in new URI schemes From: Timur Shemsedinov To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001485eb93b5ee5bf604718cb7e7 Cc: URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 06:18:39 -0000 --001485eb93b5ee5bf604718cb7e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *Hello* See RFC 2718 - Guidelines for new URL Schemes http://www.ietf.org/rfc/rfc2718.txt 2.1.2 Improper use of "//" following ":" Contrary to some examples set in past years, the use of double slashes as the first component of the of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their should not use double slashes following the ":" string. On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav wrote: > I am in the process of proposing a new URI scheme to identify user accounts > [1]. This is part of the WebFinger protocol [2] effort. > > This email is *not* an invitation to debate the merits of this new URI > scheme (just yet). I am sure we will have many lively discussions about it > shortly but I would like to present a proposal before we have a public > debate about it here. > > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and authenticate the > local identifier). When looking at the URI specification (RFC 3986) and at > the new URI guidelines (BCP 35), it is hard to figure out what is an > appropriate use of // in new schemes. > > In this case, we have a requirement to keep the URI (the part after the > scheme:) looking as close to an RFC-822 identifier (username@host) and > that means two options: > > acct:username@host > acct://username@host > > The 'username@host' part seems to fit perfectly into the URI authority as > defined by RFC 3986. However, since the URI does not have a path, it does > not really contain a hierarchical structure (just the top level host). > > The benefit of using // in this case is that existing URI parsing code can > be used unmodified to process the new URI. It is a simple profile which only > allows the userinfo and host subcomponents of the authority component, and > no other URI components. Since the new scheme will be often used with URI > templates and other facilities often used with http: URIs, it is very > convenient to have a common structure (even if it is only a subset). I don't > see any down side to using // other than defying expectations established by > the mailto: URI scheme. > > The benefit of not using // is that it makes the URI follow the well > establish pattern in mailto: and save two bytes. The down side is that it > requires spelling out how to break the URI path into sub components specific > to this scheme. > > So far the feedback I received is focus on style which is perfectly valid, > but I want to make sure I am not missing anything. My preference is to reuse > as much as possible and therefore include the //. > > Any suggestions? > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme-for-accounts.html > [2] http://code.google.com/p/webfinger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001485eb93b5ee5bf604718cb7e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello

See RFC 2718 - Guidelines for new URL Schemes
http://www.ietf.org/rfc/rfc2718.t= xt

2.1.2 Improper use of "//" following "<sche= me>:"

Contrary to some examples set in past years, the use of double
= slashes as the first component of the <scheme-specific-part> of a UR= L
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme= -
specific-part> contains a hierarchical structure as described in= RFC
2396. In URLs from such schemes, the use of double slashes indi= cates
that what follows is the top hierarchical element for a naming
aut= hority. (See section 3 of RFC 2396 for more details.) URL
schemes w= hich do not contain a conformant hierarchical structure in
their <= scheme-specific-part> should not use double slashes following
the "<scheme>:" string.


On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote:
I am in the proce= ss of proposing a new URI scheme to identify user accounts [1]. This is par= t of the WebFinger protocol [2] effort.

This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shor= tly but I would like to present a proposal before we have a public debate a= bout it here.

The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local id= entifier). When looking at the URI specification (RFC 3986) and at the new = URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the sch= eme:) looking as close to an RFC-822 identifier (username@host) and that me= ans two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI author= ity as defined by RFC 3986. However, since the URI does not have a path, it= does not really contain a hierarchical structure (just the top level host)= .

The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which onl= y allows the userinfo and host subcomponents of the authority component, an= d no other URI components. Since the new scheme will be often used with URI= templates and other facilities often used with http: URIs, it is very conv= enient to have a common structure (even if it is only a subset). I don'= t see any down side to using // other than defying expectations established= by the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it require= s spelling out how to break the URI path into sub components specific to th= is scheme.

So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reus= e as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.= hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme= -for-accounts.html
[2] http:/= /code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001485eb93b5ee5bf604718cb7e7-- From McQuilWP@pobox.com Wed Aug 19 23:20:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291F83A6BBA for ; Wed, 19 Aug 2009 23:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB7JKHpzkWG7 for ; Wed, 19 Aug 2009 23:20:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 3464D3A6956 for ; Wed, 19 Aug 2009 23:20:32 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8DF2511198; Thu, 20 Aug 2009 02:20:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=KusdaKCkjADi 7JZWYp0Ov95Alds=; b=rTnINjJ7b90G4hd2jElxwGmOGUA370b68IP5TLMLe0py TnO5GZ7U9lzZvcKSDAI0VGux6mDDcDq1zB7H82SnRpyN9DXV2pUfd0HTDW4gVXbm n4tIHpTG7YHi1DgizAA+mm0Dyp9NKidmWr1eX8p0c8NhEK30wAmBJZtHbpOEqKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=GzqEFL QCM8LifpBN9ZgiJZjO0kuB6/+w9j3s2kWltCswOaX0lRJCqEf8XyxAPQ4cDjvIhS PP6IE7+G1plg1jNViBp01y44ppT5bGv87snKPWhr9WMP2pI21Pze5MzrUpEITN3+ IP3tf3yMLRIdqsNs6KzQaETpV02bX0rUSO1xg= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7088711197; Thu, 20 Aug 2009 02:20:20 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.60.165]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id CD57B11196; Thu, 20 Aug 2009 02:20:18 -0400 (EDT) Date: Wed, 19 Aug 2009 23:20:17 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <14913655.20090819232017@pobox.com> To: Apps-Discusssion Subject: Re: Guidelines on usage of // in new URI schemes In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 895B21E0-8D51-11DE-9EA8-CA0F1FFB4A78-02871704!a-pb-sasl-quonix.pobox.com X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 06:20:34 -0000 On Wed, 2009-08-19, Eran Hammer-Lahav wrote: > I am in the process of proposing a new URI scheme to identify user > accounts [1]. This is part of the WebFinger protocol [2] effort. > This email is *not* an invitation to debate the merits of this new URI > scheme (just yet). I am sure we will have many lively discussions about > it shortly but I would like to present a proposal before we have a public > debate about it here. > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and authenticate > the local identifier). When looking at the URI specification (RFC 3986) > and at the new URI guidelines (BCP 35), it is hard to figure out what is > an appropriate use of // in new schemes. > In this case, we have a requirement to keep the URI (the part after > the scheme:) looking as close to an RFC-822 identifier (username@host) > and that means two options: > acct:username@host > acct://username@host > The 'username@host' part seems to fit perfectly into the URI authority > as defined by RFC 3986. However, since the URI does not have a path, it > does not really contain a hierarchical structure (just the top level > host). > The benefit of using // in this case is that existing URI parsing code > can be used unmodified to process the new URI. It is a simple profile > which only allows the userinfo and host subcomponents of the authority > component, and no other URI components. Since the new scheme will be > often used with URI templates and other facilities often used with http: > URIs, it is very convenient to have a common structure (even if it is > only a subset). I don't see any down side to using // other than defying > expectations established by the mailto: URI scheme. > The benefit of not using // is that it makes the URI follow the well > establish pattern in mailto: and save two bytes. The down side is that it > requires spelling out how to break the URI path into sub components > specific to this scheme. > So far the feedback I received is focus on style which is perfectly > valid, but I want to make sure I am not missing anything. My preference > is to reuse as much as possible and therefore include the //. > Any suggestions? It seems to me that the purpose of the // in a net-path is to allow the case where the // is NOT there (e.g., a relative path). Assuming that you were to adopt the //, what would be the meaning of such a URI without the // ? If there is no reasonable distinction, I think the // would be superfluous. -- Bill McQuillan From alexey.melnikov@isode.com Thu Aug 20 03:43:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D9B28C407 for ; Thu, 20 Aug 2009 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWAMhgiJR4g0 for ; Thu, 20 Aug 2009 03:42:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1111F28C3C0 for ; Thu, 20 Aug 2009 03:42:54 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Aug 2009 11:42:58 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A8D28AA.4060906@isode.com> Date: Thu, 20 Aug 2009 11:42:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Additional reviews of draft-daboo-srv-email-02.txt needed MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 10:43:07 -0000 Hi, I've just initiated IETF LC for this document. The document describes how DNS SRV records can be used for email client autodiscovery of IMAP/POP servers. I would like to solicit additional reviews of the document. Thanks, Alexey From timur.shemsedinov@gmail.com Thu Aug 20 04:49:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B8928C0E9 for ; Thu, 20 Aug 2009 04:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVw-MBvj9m8n for ; Thu, 20 Aug 2009 04:49:35 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id C61243A6EE9 for ; Thu, 20 Aug 2009 04:49:32 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1484523fga.16 for ; Thu, 20 Aug 2009 04:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=1F0p6otnpoUDl2f1RMsvKRw4b/K1Vw9IURI7+oLXzco=; b=NCIYTJ2wbdR5KlEAfiXCrY72u6vMNi39Sasm84i7U3DHAEIH+bw6t1Jqi5KUSysIbd ZmElWqiTjsMVsaubr5kzz/O5+Md/08lSavUVLav5XbfXpTI8nkIfh/GJrS8D1pqhZ/W+ t8HdFoMAiw929yf5ETljJ90VCjbFkCeEcs7t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=my9u7TvkdR39hRaVoReBpTLwXqUhF5Ts7Tph6MWBQTBoEG7vqD3qIqlawMx/XOqgqN HdLiv0rj/70sHHZuvsoX793vjWYKx1WRC4YBLh48kdd4XH2d00/rX+W4dXqqFFzRagwJ OQe92z7wHugyfCifjXQ2HzrfouOVeaet6aNqY= MIME-Version: 1.0 Received: by 10.87.31.38 with SMTP id i38mr5043415fgj.36.1250768975573; Thu, 20 Aug 2009 04:49:35 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606CBE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343783606CBE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 20 Aug 2009 14:49:35 +0300 Message-ID: <248bcd790908200449g332af1c5v3b5890ade44ffc5f@mail.gmail.com> Subject: Re: Guidelines on usage of // in new URI schemes From: Timur Shemsedinov To: Eran Hammer-Lahav , Apps Discuss Content-Type: multipart/alternative; boundary=000d615091547c336b0471915889 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 11:49:36 -0000 --000d615091547c336b0471915889 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If acct scheme allows "path" you should use //, for example: acct://username@host/hierarchical/path/to/specific/resource or like ftp://user@host/folder otherwise (if acct only purpose is to identify user like this acct:username@host) you can't use // For example: tel:, mailto:, telnet: etc... there are no path, so // is not acceptable, BCP 35: *URL schemes which do not contain a conformant hierarchical structure in their should not use double slashes* On Thu, Aug 20, 2009 at 9:30 AM, Eran Hammer-Lahav wro= te: > Yeah, that=92s BCP 35 and it doesn=92t answer my question. > > > > EHL > > > > *From:* Timur Shemsedinov [mailto:timur.shemsedinov@gmail.com] > *Sent:* Wednesday, August 19, 2009 11:18 PM > *To:* Eran Hammer-Lahav > *Cc:* apps-discuss@ietf.org; URI > *Subject:* Re: Guidelines on usage of // in new URI schemes > > > > *Hello* > > See RFC 2718 - Guidelines for new URL Schemes > http://www.ietf.org/rfc/rfc2718.txt > > 2.1.2 Improper use of "//" following ":" > > Contrary to some examples set in past years, the use of double > slashes as the first component of the of a URL > is not simply an artistic indicator that what follows is a URL: > Double slashes are used ONLY when the syntax of the URL's specific-part> contains a hierarchical structure as described in RFC > 2396. In URLs from such schemes, the use of double slashes indicates > that what follows is the top hierarchical element for a naming > authority. (See section 3 of RFC 2396 for more details.) URL > schemes which do not contain a conformant hierarchical structure in > their should not use double slashes following > the ":" string. > > On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav > wrote: > > I am in the process of proposing a new URI scheme to identify user accoun= ts > [1]. This is part of the WebFinger protocol [2] effort. > > This email is *not* an invitation to debate the merits of this new URI > scheme (just yet). I am sure we will have many lively discussions about i= t > shortly but I would like to present a proposal before we have a public > debate about it here. > > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and authenticate = the > local identifier). When looking at the URI specification (RFC 3986) and a= t > the new URI guidelines (BCP 35), it is hard to figure out what is an > appropriate use of // in new schemes. > > In this case, we have a requirement to keep the URI (the part after the > scheme:) looking as close to an RFC-822 identifier (username@host) and > that means two options: > > acct:username@host > acct://username@host > > The 'username@host' part seems to fit perfectly into the URI authority as > defined by RFC 3986. However, since the URI does not have a path, it does > not really contain a hierarchical structure (just the top level host). > > The benefit of using // in this case is that existing URI parsing code ca= n > be used unmodified to process the new URI. It is a simple profile which o= nly > allows the userinfo and host subcomponents of the authority component, an= d > no other URI components. Since the new scheme will be often used with URI > templates and other facilities often used with http: URIs, it is very > convenient to have a common structure (even if it is only a subset). I do= n't > see any down side to using // other than defying expectations established= by > the mailto: URI scheme. > > The benefit of not using // is that it makes the URI follow the well > establish pattern in mailto: and save two bytes. The down side is that it > requires spelling out how to break the URI path into sub components speci= fic > to this scheme. > > So far the feedback I received is focus on style which is perfectly valid= , > but I want to make sure I am not missing anything. My preference is to re= use > as much as possible and therefore include the //. > > Any suggestions? > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-ac= ct-uri-scheme-for-accounts.html > [2] http://code.google.com/p/webfinger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --000d615091547c336b0471915889 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If acct scheme allows "path" you should use //, for example: acct= ://username@host/hierarchical/path/to/specific/resource or like ftp://user@host/folder
otherwise (if acct only purpose i= s to identify user like this acct:username@host) you can't use //
For example: tel:, mailto:, telnet: etc... there are no path, so // is not = acceptable,

BCP 35: URL schemes which do not contain a conformant= hierarchical structure in their <scheme-specific-part> should not us= e double slashes


On Thu, Aug 20, 2009 at 9:30 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Yeah, that=92s= BCP 35 and it doesn=92t answer my question.

=A0

EHL

=A0

From: Timur Shemsedinov [mailto:ti= mur.shemsedinov@gmail.com]
Sent: Wednesday, August 19, 2009 11:18 PM
To: Eran Hammer-Lahav
Cc: apps-= discuss@ietf.org; URI
Subject: Re: Guidelines on usage of // in new URI schemes

=A0

Hello

See RFC 2718 - Guidelines for new URL Schemes
http://ww= w.ietf.org/rfc/rfc2718.txt

2.1.2 Improper use of "//" following "<scheme>:"<= br>
Contrary to some examples set in past years, the use of double
slashes as the first component of the <scheme-specific-part> of a URL=
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme- specific-part> contains a hierarchical structure as described in RFC
2396. In URLs from such schemes, the use of double slashes indicates
that what follows is the top hierarchical element for a naming
authority. (See section 3 of RFC 2396 for more details.) URL
schemes which do not contain a conformant hierarchical structure in
their <scheme-specific-part> should not use double slashes following<= br> the "<scheme>:" string.

On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I am in the process of proposing a new URI scheme to identify user accounts [1]. This is part of the WebFinger protocol [2] effo= rt.

This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shortly= but I would like to present a proposal before we have a public debate about it here.

The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local identifier). When looking at the URI specification (RFC 3986) and at the ne= w URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the scheme:) looking as close to an RFC-822 identifier (username@host) and that means two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI author= ity as defined by RFC 3986. However, since the URI does not have a path, it does n= ot really contain a hierarchical structure (just the top level host).

The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which only allows the userinfo and host subcomponents of the authority component, and = no other URI components. Since the new scheme will be often used with URI templates and other facilities often used with http: URIs, it is very convenient to have a common structure (even if it is only a subset). I don&= #39;t see any down side to using // other than defying expectations established b= y the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it requires spelling out how to break the URI path into sub components specific to this scheme.

So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reuse as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.= hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme= -for-accounts.html
[2] http:/= /code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

=A0


--000d615091547c336b0471915889-- From samj@samj.net Thu Aug 20 05:00:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D723A6E68 for ; Thu, 20 Aug 2009 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.976 X-Spam-Level: X-Spam-Status: No, score=-6.976 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcRCmKqw8oLZ for ; Thu, 20 Aug 2009 05:00:45 -0700 (PDT) Received: from eu1sys200aog108.obsmtp.com (eu1sys200aog108.obsmtp.com [207.126.144.125]) by core3.amsl.com (Postfix) with SMTP id 6536E3A6D30 for ; Thu, 20 Aug 2009 05:00:44 -0700 (PDT) Received: from source ([72.14.220.157]) by eu1sys200aob108.postini.com ([207.126.147.11]) with SMTP ID DSNKSo068RyyGdDtcy4swGD4oFD+LVKORAwj@postini.com; Thu, 20 Aug 2009 12:00:50 UTC Received: by fg-out-1718.google.com with SMTP id l27so990560fgb.5 for ; Thu, 20 Aug 2009 05:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.251.40 with SMTP id y40mr5001403fgh.57.1250769646201; Thu, 20 Aug 2009 05:00:46 -0700 (PDT) In-Reply-To: <248bcd790908200449g332af1c5v3b5890ade44ffc5f@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343783606CBE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908200449g332af1c5v3b5890ade44ffc5f@mail.gmail.com> Date: Thu, 20 Aug 2009 14:00:46 +0200 Message-ID: <21606dcf0908200500i267ac4a6r133ad7099c6233be@mail.gmail.com> Subject: Re: Guidelines on usage of // in new URI schemes From: Sam Johnston To: Timur Shemsedinov Content-Type: multipart/alternative; boundary=001485e995bb752cb904719180b0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 12:00:46 -0000 --001485e995bb752cb904719180b0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2009 at 1:49 PM, Timur Shemsedinov < timur.shemsedinov@gmail.com> wrote: > If acct scheme allows "path" you should use //, for example: > acct://username@host/hierarchical/path/to/specific/resource or like > ftp://user@host/folder > otherwise (if acct only purpose is to identify user like this > acct:username@host) you can't use // > For example: tel:, mailto:, telnet: etc... there are no path, so // is no= t > acceptable, > > BCP 35: *URL schemes which do not contain a conformant hierarchical > structure in their should not use double slashes* > Agreed. Sam > On Thu, Aug 20, 2009 at 9:30 AM, Eran Hammer-Lahav w= rote: > >> Yeah, that=92s BCP 35 and it doesn=92t answer my question. >> >> >> >> EHL >> >> >> >> *From:* Timur Shemsedinov [mailto:timur.shemsedinov@gmail.com] >> *Sent:* Wednesday, August 19, 2009 11:18 PM >> *To:* Eran Hammer-Lahav >> *Cc:* apps-discuss@ietf.org; URI >> *Subject:* Re: Guidelines on usage of // in new URI schemes >> >> >> >> *Hello* >> >> See RFC 2718 - Guidelines for new URL Schemes >> http://www.ietf.org/rfc/rfc2718.txt >> >> 2.1.2 Improper use of "//" following ":" >> >> Contrary to some examples set in past years, the use of double >> slashes as the first component of the of a URL >> is not simply an artistic indicator that what follows is a URL: >> Double slashes are used ONLY when the syntax of the URL's > specific-part> contains a hierarchical structure as described in RFC >> 2396. In URLs from such schemes, the use of double slashes indicates >> that what follows is the top hierarchical element for a naming >> authority. (See section 3 of RFC 2396 for more details.) URL >> schemes which do not contain a conformant hierarchical structure in >> their should not use double slashes following >> the ":" string. >> >> On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav >> wrote: >> >> I am in the process of proposing a new URI scheme to identify user >> accounts [1]. This is part of the WebFinger protocol [2] effort. >> >> This email is *not* an invitation to debate the merits of this new URI >> scheme (just yet). I am sure we will have many lively discussions about = it >> shortly but I would like to present a proposal before we have a public >> debate about it here. >> >> The new scheme has two components, a local identifier (username, >> screenname, handle, etc.) and a host (which can resolve and authenticate= the >> local identifier). When looking at the URI specification (RFC 3986) and = at >> the new URI guidelines (BCP 35), it is hard to figure out what is an >> appropriate use of // in new schemes. >> >> In this case, we have a requirement to keep the URI (the part after the >> scheme:) looking as close to an RFC-822 identifier (username@host) and >> that means two options: >> >> acct:username@host >> acct://username@host >> >> The 'username@host' part seems to fit perfectly into the URI authority a= s >> defined by RFC 3986. However, since the URI does not have a path, it doe= s >> not really contain a hierarchical structure (just the top level host). >> >> The benefit of using // in this case is that existing URI parsing code c= an >> be used unmodified to process the new URI. It is a simple profile which = only >> allows the userinfo and host subcomponents of the authority component, a= nd >> no other URI components. Since the new scheme will be often used with UR= I >> templates and other facilities often used with http: URIs, it is very >> convenient to have a common structure (even if it is only a subset). I d= on't >> see any down side to using // other than defying expectations establishe= d by >> the mailto: URI scheme. >> >> The benefit of not using // is that it makes the URI follow the well >> establish pattern in mailto: and save two bytes. The down side is that i= t >> requires spelling out how to break the URI path into sub components spec= ific >> to this scheme. >> >> So far the feedback I received is focus on style which is perfectly vali= d, >> but I want to make sure I am not missing anything. My preference is to r= euse >> as much as possible and therefore include the //. >> >> Any suggestions? >> >> EHL >> >> [1] >> http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-a= cct-uri-scheme-for-accounts.html >> [2] http://code.google.com/p/webfinger >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001485e995bb752cb904719180b0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2009 at 1:49 PM, Timur Shemsedinov <timur.shemsedinov@gmail.com> wrote:
If acct scheme allows "path" you should use //, for example: acct= ://username@host/hierarchical/path/to/specific/resource or like ftp://user@host/folder
otherwise (if a= cct only purpose is to identify user like this acct:username@host) you can&= #39;t use //
For example: tel:, mailto:, telnet: etc... there are no path, so // is not = acceptable,

BCP 35: URL schemes which do not contain a conformant= hierarchical structure in their <scheme-specific-part> should not us= e double slashes

Agreed.

Sam
=A0
On Thu, Aug 20, 2009 at 9:30 AM, Eran H= ammer-Lahav <eran@hueniverse.com> wrote:

Yeah, that=92s= BCP 35 and it doesn=92t answer my question.

=A0

EHL

=A0

From: Timur Shemsedinov [mailto:ti= mur.shemsedinov@gmail.com]
Sent: Wednesday, August 19, 2009 11:18 PM
To: Eran Hammer-Lahav
Cc: apps-= discuss@ietf.org; URI
Subject: Re: Guidelines on usage of // in new URI schemes

=A0

Hello

See RFC 2718 - Guidelines for new URL Schemes
http://ww= w.ietf.org/rfc/rfc2718.txt

2.1.2 Improper use of "//" following "<scheme>:"<= br>
Contrary to some examples set in past years, the use of double
slashes as the first component of the <scheme-specific-part> of a URL=
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme- specific-part> contains a hierarchical structure as described in RFC
2396. In URLs from such schemes, the use of double slashes indicates
that what follows is the top hierarchical element for a naming
authority. (See section 3 of RFC 2396 for more details.) URL
schemes which do not contain a conformant hierarchical structure in
their <scheme-specific-part> should not use double slashes following<= br> the "<scheme>:" string.

On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I am in the process of proposing a new URI scheme to identify user accounts [1]. This is part of the WebFinger protocol [2] effo= rt.

This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shortly= but I would like to present a proposal before we have a public debate about it here.

The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local identifier). When looking at the URI specification (RFC 3986) and at the ne= w URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the scheme:) looking as close to an RFC-822 identifier (username@host) and that means two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI author= ity as defined by RFC 3986. However, since the URI does not have a path, it does n= ot really contain a hierarchical structure (just the top level host).

The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which only allows the userinfo and host subcomponents of the authority component, and = no other URI components. Since the new scheme will be often used with URI templates and other facilities often used with http: URIs, it is very convenient to have a common structure (even if it is only a subset). I don&= #39;t see any down side to using // other than defying expectations established b= y the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it requires spelling out how to break the URI path into sub components specific to this scheme.

So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reuse as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.= hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme= -for-accounts.html
[2] http:/= /code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

=A0



_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--001485e995bb752cb904719180b0-- From plh@w3.org Thu Aug 20 07:43:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1EE3A689B for ; Thu, 20 Aug 2009 07:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxjle5i258Nb for ; Thu, 20 Aug 2009 07:43:34 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) by core3.amsl.com (Postfix) with ESMTP id 59B9F3A67B6 for ; Thu, 20 Aug 2009 07:43:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Me8rb-0000bt-8C; Thu, 20 Aug 2009 10:43:39 -0400 Received: from maggie.w3.org ([193.51.208.68]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Me0zS-0004Ne-0B for plehegar@jay.w3.org; Thu, 20 Aug 2009 02:19:14 -0400 Received: from frink.w3.org ([128.30.52.56]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Me0zG-00089Y-Dx for plh+uri@w3.org; Thu, 20 Aug 2009 06:19:02 +0000 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Me0zF-0001PG-Nh for plh+uri@w3.org; Thu, 20 Aug 2009 06:19:01 +0000 X-From_: timur.shemsedinov@gmail.com Thu Aug 20 06:19:01 2009 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Me0zE-0001OY-PO for uri@listhub.w3.org; Thu, 20 Aug 2009 06:19:01 +0000 Received: from fg-out-1718.google.com ([72.14.220.155]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Me0z3-000882-IT for uri@w3.org; Thu, 20 Aug 2009 06:19:00 +0000 Received: by fg-out-1718.google.com with SMTP id e21so1210373fga.21 for ; Wed, 19 Aug 2009 23:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CHTrjInY/4GALHt8H+8dj6Sx1lxNmk5KAd3ZDppOcaU=; b=aqUq7YytInmK+sjspoWYhmOnY+9/GVd8e2gjA1rGmYSsLnK8/JZ3xlkt09umM9UmL/ VqcXntP4v9AUaO05+3msqyzQZLV5FT62dNx/QUbM9HQrRxqDpGqnW/QO7kBUwjHZHcCw Bdp+0KYXoS7XHi9gTrxxFhP8y7Yiaw10XrLU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VnPwvxaCJz71x+Q7G0MKVcd+XSfHwLux9YW/65LPmeztfxknen6ETxpVSZEQ/max3B VAXBDwBMTbKK5VOoqARfh811eVW5xXGpjyr4Ne9KFQ8LUOPUaohXBU440T8dY1SthhAH eWcda5Na7OsVuZf4a++5PlQROMhVWBos/W+/4= MIME-Version: 1.0 Received: by 10.86.222.15 with SMTP id u15mr4826713fgg.33.1250749102046; Wed, 19 Aug 2009 23:18:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Old-Date: Thu, 20 Aug 2009 09:18:22 +0300 Message-ID: <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> From: Timur Shemsedinov To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001485eb93b5ee5bf604718cb7e7 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1Me0z3-000882-IT 0cfc420a00d5cab3ca7bc406c25e3838 X-Original-To: uri@w3.org X-Diagnostic: Not on the accept list X-Envelope-To: uri Subject: [Moderator Action] Re: Guidelines on usage of // in new URI schemes Resent-From: Philippe Le Hegaret Resent-To: public-iri Resent-Cc: "apps-discuss@ietf.org" , URI Organization: World Wide Web Consortium Date: Thu, 20 Aug 2009 10:43:38 -0400 X-Mailer: Evolution 2.26.1 Resent-Message-Id: Resent-Date: Thu, 20 Aug 2009 10:43:39 -0400 Cc: URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 14:43:36 -0000 --001485eb93b5ee5bf604718cb7e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *Hello* See RFC 2718 - Guidelines for new URL Schemes http://www.ietf.org/rfc/rfc2718.txt 2.1.2 Improper use of "//" following ":" Contrary to some examples set in past years, the use of double slashes as the first component of the of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their should not use double slashes following the ":" string. On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav wrote: > I am in the process of proposing a new URI scheme to identify user accounts > [1]. This is part of the WebFinger protocol [2] effort. > > This email is *not* an invitation to debate the merits of this new URI > scheme (just yet). I am sure we will have many lively discussions about it > shortly but I would like to present a proposal before we have a public > debate about it here. > > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and authenticate the > local identifier). When looking at the URI specification (RFC 3986) and at > the new URI guidelines (BCP 35), it is hard to figure out what is an > appropriate use of // in new schemes. > > In this case, we have a requirement to keep the URI (the part after the > scheme:) looking as close to an RFC-822 identifier (username@host) and > that means two options: > > acct:username@host > acct://username@host > > The 'username@host' part seems to fit perfectly into the URI authority as > defined by RFC 3986. However, since the URI does not have a path, it does > not really contain a hierarchical structure (just the top level host). > > The benefit of using // in this case is that existing URI parsing code can > be used unmodified to process the new URI. It is a simple profile which only > allows the userinfo and host subcomponents of the authority component, and > no other URI components. Since the new scheme will be often used with URI > templates and other facilities often used with http: URIs, it is very > convenient to have a common structure (even if it is only a subset). I don't > see any down side to using // other than defying expectations established by > the mailto: URI scheme. > > The benefit of not using // is that it makes the URI follow the well > establish pattern in mailto: and save two bytes. The down side is that it > requires spelling out how to break the URI path into sub components specific > to this scheme. > > So far the feedback I received is focus on style which is perfectly valid, > but I want to make sure I am not missing anything. My preference is to reuse > as much as possible and therefore include the //. > > Any suggestions? > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme-for-accounts.html > [2] http://code.google.com/p/webfinger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001485eb93b5ee5bf604718cb7e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello

See RFC 2718 - Guidelines for new URL Schemes
http://www.ietf.org/rfc/rfc2718.txt

2.1.2 Improper use of "//" following "<scheme>:"

Contrary to some examples set in past years, the use of double
slashes as the first component of the <scheme-specific-part> of a URL
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme-
specific-part> contains a hierarchical structure as described in RFC
2396. In URLs from such schemes, the use of double slashes indicates
that what follows is the top hierarchical element for a naming
authority. (See section 3 of RFC 2396 for more details.) URL
schemes which do not contain a conformant hierarchical structure in
their <scheme-specific-part> should not use double slashes following
the "<scheme>:" string.


On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I am in the process of proposing a new URI scheme to identify user accounts [1]. This is part of the WebFinger protocol [2] effort.

This email is *not* an invitation to debate the merits of this new URI scheme (just yet). I am sure we will have many lively discussions about it shortly but I would like to present a proposal before we have a public debate about it here.

The new scheme has two components, a local identifier (username, screenname, handle, etc.) and a host (which can resolve and authenticate the local identifier). When looking at the URI specification (RFC 3986) and at the new URI guidelines (BCP 35), it is hard to figure out what is an appropriate use of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the scheme:) looking as close to an RFC-822 identifier (username@host) and that means two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI authority as defined by RFC 3986. However, since the URI does not have a path, it does not really contain a hierarchical structure (just the top level host).

The benefit of using // in this case is that existing URI parsing code can be used unmodified to process the new URI. It is a simple profile which only allows the userinfo and host subcomponents of the authority component, and no other URI components. Since the new scheme will be often used with URI templates and other facilities often used with http: URIs, it is very convenient to have a common structure (even if it is only a subset). I don't see any down side to using // other than defying expectations established by the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establish pattern in mailto: and save two bytes. The down side is that it requires spelling out how to break the URI path into sub components specific to this scheme.

So far the feedback I received is focus on style which is perfectly valid, but I want to make sure I am not missing anything. My preference is to reuse as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme-for-accounts.html
[2] http://code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001485eb93b5ee5bf604718cb7e7-- From derhoermi@gmx.net Wed Aug 19 12:33:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC713A6F79 for ; Wed, 19 Aug 2009 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ7ivSH-t1hz for ; Wed, 19 Aug 2009 12:33:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B297E3A6EB7 for ; Wed, 19 Aug 2009 12:33:42 -0700 (PDT) Received: (qmail invoked by alias); 19 Aug 2009 19:33:46 -0000 Received: from dslb-094-223-200-041.pools.arcor-ip.net (EHLO hive) [94.223.200.41] by mail.gmx.net (mp036) with SMTP; 19 Aug 2009 21:33:46 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/Sp0QlwVvSO3++ULfzdBlMLMMLXnpyuy89m+JJt0 V7r0RNWN+Mc73K From: Bjoern Hoehrmann To: Eran Hammer-Lahav Subject: Re: Registration timing of new URI schemes Date: Wed, 19 Aug 2009 21:33:45 +0200 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783606BD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-Mailman-Approved-At: Thu, 20 Aug 2009 08:23:59 -0700 Cc: URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:33:44 -0000 * Eran Hammer-Lahav wrote: >I am asking this because I have no desire to spend time and energy >discussing a new URI scheme (and provisional at that) when we clearly >don't have all the answers. But at the same time, I don't want to cause >problems by using a new scheme that is not at all registered. When people come up with new schemes, the main problem I'd have is that they are usually not properly documented with little evidence of intent to do that and properly register them. Those concerns would be addressed if you e.g. keep your thoughts on them in an Internet Draft and keeping it from expiring, while you would not be dragged into arguments over it prematurely. Picking a reasonably verbose and specific name for it would also mitigate concerns over interference with other efforts. As for timing, if you have multiple independent implementations that are likely to be maintained for the next few years, that would be too late; you would need to start discussion when there is still an opportunity to make possibly substantive changes to those implementations in response to feedback. In doubt name it "for-experimental-use-only-:"; your desire to put it up for discussion should increase alongside your desire to simply name it "schemename" instead. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From vesely@tana.it Thu Aug 20 22:29:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986263A6DF1 for ; Thu, 20 Aug 2009 22:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO89n3mckVGz for ; Thu, 20 Aug 2009 22:29:28 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id CCA673A6DE0 for ; Thu, 20 Aug 2009 22:29:13 -0700 (PDT) Received: from [192.168.15.176] (wf-salyut.imt.ru [212.16.1.106]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 21 Aug 2009 07:29:13 +0200 id 00000000005DC030.000000004A8E30A9.00007D8A Message-ID: <4A8E30A8.9050307@tana.it> Date: Fri, 21 Aug 2009 09:29:12 +0400 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> In-Reply-To: <4A8D28AA.4060906@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 05:29:29 -0000 Alexey Melnikov wrote: > Hi, > I've just initiated IETF LC for this document. The document describes > how DNS SRV records can be used for email client autodiscovery of > IMAP/POP servers. > I would like to solicit additional reviews of the document. Just one point: The document assumes that the server for user@example.com is somehost.example.com. This can be deduced from the Security Considerations and from TLS certificate requirements, but is not stated clearly and openly. I'd object this very restriction, as I cannot see how it is justified. No similar requirements exist for SMTP servers or MX records. Of course, I would welcome a statement about accountability requirements for email domains as a means to increase security (I'll look for adoption of an SMTP extension on that topic) but not a sneaking introduction of such concept. From alexey.melnikov@isode.com Fri Aug 21 05:57:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA843A6A10 for ; Fri, 21 Aug 2009 05:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BaXt--Kksu3 for ; Fri, 21 Aug 2009 05:57:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 79EC73A6835 for ; Fri, 21 Aug 2009 05:57:44 -0700 (PDT) Received: from [172.16.2.196] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 Aug 2009 13:57:45 +0100 Message-ID: <4A8E99B2.1060002@isode.com> Date: Fri, 21 Aug 2009 13:57:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Alessandro Vesely Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> In-Reply-To: <4A8E30A8.9050307@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:57:45 -0000 Hi Alessandro, Alessandro Vesely wrote: > Alexey Melnikov wrote: > >> Hi, >> I've just initiated IETF LC for this document. The document describes >> how DNS SRV records can be used for email client autodiscovery of >> IMAP/POP servers. >> I would like to solicit additional reviews of the document. > > Just one point: The document assumes that the server for > user@example.com is somehost.example.com. This can be deduced from the > Security Considerations and from TLS certificate requirements, but is > not stated clearly and openly. You are quite wrong about that. There is no such requirement. However, if TLS is used, there is a requirement that the server advertised in the DNS SRV record shows that it supports the domain part (example.com above). This is needed to protect from attacks on insecure DNS. > I'd object this very restriction, as I cannot see how it is justified. > No similar requirements exist for SMTP servers or MX records. Of > course, I would welcome a statement about accountability requirements > for email domains as a means to increase security (I'll look for > adoption of an SMTP extension on that topic) but not a sneaking > introduction of such concept. From vkg@alcatel-lucent.com Fri Aug 21 07:05:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A0E28C14D for ; Fri, 21 Aug 2009 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPax-fyLde0K for ; Fri, 21 Aug 2009 07:05:37 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id EFF1E3A698B for ; Fri, 21 Aug 2009 07:05:36 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7LE5bcU020663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 09:05:37 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7LE5blM017367; Fri, 21 Aug 2009 09:05:37 -0500 (CDT) Message-ID: <4A8EA9B1.2050203@alcatel-lucent.com> Date: Fri, 21 Aug 2009 09:05:37 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> In-Reply-To: <4A8E99B2.1060002@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:05:38 -0000 Alexey Melnikov wrote: >> Just one point: The document assumes that the server for >> user@example.com is somehost.example.com. This can be deduced from the >> Security Considerations and from TLS certificate requirements, but is >> not stated clearly and openly. > > You are quite wrong about that. There is no such requirement. > However, if TLS is used, there is a requirement that the server > advertised in the DNS SRV record shows that it supports the domain part > (example.com above). Alexey: I don't think that is quite the case. Based on the work we did in SIP for TLS, I believe that the pkix WG view is that if the input to SRV process is the domain name "example.com", then the certificate received better contain "example.com" and not "somehost.example.com". Of course, the certificate can contain multiple entries in the SAN and the client can match the specific one it used as input to SRV. Some browsers today, most notably Firefox v3.0.11, issues a warning if the URL is http://example.com but the certificate received contains the name "www.example.com". Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From alexey.melnikov@isode.com Fri Aug 21 07:12:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1841F28C160 for ; Fri, 21 Aug 2009 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbdYGy+Ys5Bm for ; Fri, 21 Aug 2009 07:12:18 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C85E13A6909 for ; Fri, 21 Aug 2009 07:12:17 -0700 (PDT) Received: from [172.16.2.196] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 Aug 2009 15:12:22 +0100 Message-ID: <4A8EAB2D.6010308@isode.com> Date: Fri, 21 Aug 2009 15:11:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Vijay K. Gurbani" Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> In-Reply-To: <4A8EA9B1.2050203@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:12:19 -0000 Hi Vijay, Vijay K. Gurbani wrote: > Alexey Melnikov wrote: > >>> Just one point: The document assumes that the server for >>> user@example.com is somehost.example.com. This can be deduced from >>> the Security Considerations and from TLS certificate requirements, >>> but is not stated clearly and openly. >> >> You are quite wrong about that. There is no such requirement. >> However, if TLS is used, there is a requirement that the server >> advertised in the DNS SRV record shows that it supports the domain >> part (example.com above). > > Alexey: I don't think that is quite the case. Based on the work > we did in SIP for TLS, I believe that the pkix WG view is that > if the input to SRV process is the domain name "example.com", > then the certificate received better contain "example.com" and > not "somehost.example.com". This is what I said above ("the domain part" is "example.com", not "somehost.example.com"). Unless I am confused, I think you are actually agreeing with what I said. > Of course, the certificate can > contain multiple entries in the SAN and the client can match > the specific one it used as input to SRV. Yes. > Some browsers today, most notably Firefox v3.0.11, issues a > warning if the URL is http://example.com but the certificate > received contains the name "www.example.com". And rightly so. From vkg@alcatel-lucent.com Fri Aug 21 07:18:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFE53A6909 for ; Fri, 21 Aug 2009 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM2YP7R7KEl0 for ; Fri, 21 Aug 2009 07:18:34 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 531A13A68B4 for ; Fri, 21 Aug 2009 07:18:33 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7LEIcZg004142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 09:18:38 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7LEIcNk028347; Fri, 21 Aug 2009 09:18:38 -0500 (CDT) Message-ID: <4A8EACBE.1040804@alcatel-lucent.com> Date: Fri, 21 Aug 2009 09:18:38 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> In-Reply-To: <4A8EAB2D.6010308@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:18:35 -0000 Alexey Melnikov wrote: > This is what I said above ("the domain part" is "example.com", not > "somehost.example.com"). Unless I am confused, I think you are actually > agreeing with what I said. OK, then we are in agreement. Apparently I mis-understood your original response; I assumed you meant that the client should be okay if it used "example.com" as input to SRV but received a certificate attesting only "somehost.example.com". Clearly that is not the case, and the client should expect "example.com" as an identity in the certificate. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From cyrus@daboo.name Fri Aug 21 07:33:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C531E28C18D for ; Fri, 21 Aug 2009 07:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-FFwDzHIird for ; Fri, 21 Aug 2009 07:33:27 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id C4F3028C18B for ; Fri, 21 Aug 2009 07:33:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5211E183D2E4; Fri, 21 Aug 2009 10:33:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP5JMtk8wpRr; Fri, 21 Aug 2009 10:33:32 -0400 (EDT) Received: from [10.0.1.6] (unknown [17.101.35.28]) by daboo.name (Postfix) with ESMTP id 13857183D2DA; Fri, 21 Aug 2009 10:33:29 -0400 (EDT) Date: Fri, 21 Aug 2009 10:33:27 -0400 From: Cyrus Daboo To: "Vijay K. Gurbani" , Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: In-Reply-To: <4A8EACBE.1040804@alcatel-lucent.com> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1367 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:33:27 -0000 Hi Vijay, --On August 21, 2009 9:18:38 AM -0500 "Vijay K. Gurbani" wrote: >> This is what I said above ("the domain part" is "example.com", not >> "somehost.example.com"). Unless I am confused, I think you are actually >> agreeing with what I said. > > OK, then we are in agreement. Apparently I mis-understood > your original response; I assumed you meant that the client > should be okay if it used "example.com" as input to SRV but > received a certificate attesting only "somehost.example.com". > > Clearly that is not the case, and the client should expect > "example.com" as an identity in the certificate. The last paragraph of the security considerations makes these statements: 1) When no secure DNS is in place clients SHOULD check the hostname returned from the SRV lookup and match that to the domain used for the SRV lookup. If those do not match, then additional user verification is required. 2) If TLS is available for the host, then clients MUST use the domain used in the SRV lookup "for certificate verification purposes". Now that last statement is a little bit vague. Is it saying that the SRV domain must be attested to in the TSL certificate, or could it imply that a sub-domain of the SRV domain be attested to. I would like to hear from security folks on this as I am not at all sure. -- Cyrus Daboo From vkg@alcatel-lucent.com Fri Aug 21 07:41:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9E828C1AF for ; Fri, 21 Aug 2009 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AybnA+B5cu7Q for ; Fri, 21 Aug 2009 07:41:34 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 97CE928C19D for ; Fri, 21 Aug 2009 07:41:30 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n7LEfRM7028454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 09:41:28 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7LEfRAG016743; Fri, 21 Aug 2009 09:41:27 -0500 (CDT) Message-ID: <4A8EB217.6070205@alcatel-lucent.com> Date: Fri, 21 Aug 2009 09:41:27 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:41:35 -0000 Cyrus Daboo wrote: > 2) If TLS is available for the host, then clients MUST use the domain > used in the SRV lookup "for certificate verification purposes". > > Now that last statement is a little bit vague. Is it saying that the SRV > domain must be attested to in the TSL certificate, or could it imply > that a sub-domain of the SRV domain be attested to. I would like to hear > from security folks on this as I am not at all sure. Hello Cyrus: My understanding is that you should stay away from domain delegation, sub domains or wildcards in certificates. That is, you want to be as explicit as possible -- if the input to DNS is "foo.com", then the returned certificate better contain exactly "foo.com" in the Subject, or better yet, as an identity in the SAN. Subdomains and wildcards can be be used to circumvent security. When we did the work for SIP certificates, we explicitly stayed away from these. You may also want to run this by pkix WG and the security directorate. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From alexey.melnikov@isode.com Fri Aug 21 07:50:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4308328C1DA for ; Fri, 21 Aug 2009 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB-SeGKWo65X for ; Fri, 21 Aug 2009 07:50:22 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3C2733A6DBB for ; Fri, 21 Aug 2009 07:48:55 -0700 (PDT) Received: from [172.16.2.196] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 Aug 2009 15:49:00 +0100 Message-ID: <4A8EB3C9.1010105@isode.com> Date: Fri, 21 Aug 2009 15:48:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> In-Reply-To: <4A8EB217.6070205@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:50:23 -0000 Vijay K. Gurbani wrote: > Cyrus Daboo wrote: > >> 2) If TLS is available for the host, then clients MUST use the domain >> used in the SRV lookup "for certificate verification purposes". >> >> Now that last statement is a little bit vague. Is it saying that the >> SRV domain must be attested to in the TSL certificate, or could it >> imply that a sub-domain of the SRV domain be attested to. I would >> like to hear from security folks on this as I am not at all sure. > > Hello Cyrus: > > My understanding is that you should stay away from domain > delegation, sub domains or wildcards in certificates. That is, > you want to be as explicit as possible -- if the input to DNS is > "foo.com", then the returned certificate better contain exactly > "foo.com" in the Subject, or better yet, as an identity in the SAN. > > Subdomains and wildcards can be be used to circumvent > security. When we did the work for SIP certificates, we > explicitly stayed away from these. I agree about subdomains, as they are under different administrative control. I haven't heard about problems with wildcards (in the leftmost host part only). Russ Housley and Tim Polk were certainly Ok with this kind of wildcards when discussing another document during IESG review. I think the current text as written is quite clear that the domain itself should be used for TLS server identity verification, which I think is the correct way. > You may also want to run this by pkix WG and the security > directorate. That would be fine too, if you want additional opinions. From cyrus@daboo.name Fri Aug 21 08:09:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E9328C1A9 for ; Fri, 21 Aug 2009 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te3P-kCnay3f for ; Fri, 21 Aug 2009 08:09:41 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 398E83A686E for ; Fri, 21 Aug 2009 08:08:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E9654183D603; Fri, 21 Aug 2009 11:09:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UudL6Q258X0m; Fri, 21 Aug 2009 11:09:03 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 37AF1183D5FC; Fri, 21 Aug 2009 11:09:01 -0400 (EDT) Date: Fri, 21 Aug 2009 11:08:59 -0400 From: Cyrus Daboo To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: In-Reply-To: <4A8EB3C9.1010105@isode.com> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> <4A8EB3C9.1010105@isode.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1650 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:09:42 -0000 Hi Alexey, --On August 21, 2009 3:48:41 PM +0100 Alexey Melnikov wrote: >> Subdomains and wildcards can be be used to circumvent >> security. When we did the work for SIP certificates, we >> explicitly stayed away from these. > > I agree about subdomains, as they are under different administrative > control. I haven't heard about problems with wildcards (in the leftmost > host part only). Russ Housley and Tim Polk were certainly Ok with this > kind of wildcards when discussing another document during IESG review. > > I think the current text as written is quite clear that the domain itself > should be used for TLS server identity verification, which I think is the > correct way. The problem is you probably don't want to have "example.com" in the subject of the certificate for the server "imap.example.com" because clients that are directly configured with "imap.example.com" as the server host name will expect "imap.example.com" in the subject. i.e. the SRV lookup process should not "break" existing client behavior wrt verifying certificates. Perhaps the requirement on the certificate could be: 1) Subject MUST match the server host name (does not break existing clients) 2) Subject Alternative Name (SAN) should include the SRV query name, i.e. _imap._tcp.example.com. i.e, rather than making it the domain itself ("example.com") we explicitly indicate that the server is valid when found through the SRV lookup process. Clients would then be required to verify the SAN against the SRV query they did. Is this reasonable? Is there any precedent for an approach like this? -- Cyrus Daboo From vkg@alcatel-lucent.com Fri Aug 21 09:08:03 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB37E3A6E87 for ; Fri, 21 Aug 2009 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WbAubVVw-MT for ; Fri, 21 Aug 2009 09:08:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B77A93A6E6D for ; Fri, 21 Aug 2009 09:08:02 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7LG7vSF010916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 11:07:57 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7LG7uk8027571; Fri, 21 Aug 2009 11:07:57 -0500 (CDT) Message-ID: <4A8EC65C.2040107@alcatel-lucent.com> Date: Fri, 21 Aug 2009 11:07:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> <4A8EB3C9.1010105@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:08:04 -0000 Cyrus Daboo wrote: > The problem is you probably don't want to have "example.com" in the > subject of the certificate for the server "imap.example.com" because > clients that are directly configured with "imap.example.com" as the > server host name will expect "imap.example.com" in the subject. i.e. the > SRV lookup process should not "break" existing client behavior wrt > verifying certificates. > > Perhaps the requirement on the certificate could be: > > 1) Subject MUST match the server host name (does not break existing > clients) > > 2) Subject Alternative Name (SAN) should include the SRV query name, > i.e. _imap._tcp.example.com. i.e, rather than making it the domain > itself ("example.com") we explicitly indicate that the server is valid > when found through the SRV lookup process. Clients would then be > required to verify the SAN against the SRV query they did. > > Is this reasonable? Is there any precedent for an approach like this? Cyrus: Isn't it easier for an additional identity of "imap.example.com" to be present in the SAN instead of an intermediary SRV query name like "_imap._tcp.example.com"? This covers the case of clients who are configured with "imap.example.com" to work just as seamlessly as clients who start with "example.com" as their SRV query. Plus we don't have to ask CAs to put in an DNS intermediary identifier like "_imap._tcp.example.com", which AFAIK does not have any precedence. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From fanf2@hermes.cam.ac.uk Sat Aug 22 16:58:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384EB3A6AE6 for ; Sat, 22 Aug 2009 16:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZnPCnynE3BK for ; Sat, 22 Aug 2009 16:58:25 -0700 (PDT) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by core3.amsl.com (Postfix) with ESMTP id C969E3A6AD9 for ; Sat, 22 Aug 2009 16:58:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37299) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1Mf0Tb-0003YN-JA (Exim 4.70) (return-path ); Sun, 23 Aug 2009 00:58:27 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Mf0Tb-0001rb-Tf (Exim 4.67) (return-path ); Sun, 23 Aug 2009 00:58:27 +0100 Date: Sun, 23 Aug 2009 00:58:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ravi shankar , General discussion of application-layer protocols Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail In-Reply-To: <4A89A4D6.5070602@att.com> Message-ID: References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> <4A89A4D6.5070602@att.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 23:58:26 -0000 On Mon, 17 Aug 2009, Tony Hansen wrote: > > Ravi, what you're asking to be done was already done over a decade ago, but > the protocol that was modified/extended was SMTP itself. Out of SMTP came the > Submission protocol. The Submission protocol is NOT SMTP, but looks a LOT like > SMTP, normally runs on port 587, and does things like requiring the AUTH > command to be used, as well as some other client-only types of actions. I should add that there's an architectural reason for submission to be an SMTP variant rather than an extension to a mail store access protocol. Any message submission mechanism needs a way for the MUA to specify the SMTP envelope, that is the MAIL and RCPT commands *including* any extension keywords. Any mail transmission feature that must work between separate sites must be specified as an SMTP extension, because that's the inter-domain mail protocol. In many cases (e.g. DSN/NOTARY) the submitting MUA needs to invoke the feature (or parts of it). So if the submission protocol is not an SMTP variant then new mail transmission features will have to be specified twice. There aren't many difficulties caused by loose coupling between message submission and mail store access. Saving a copy of sent mail is not very efficient, nor is forwarding mail, but BURL can improve this. The latency of sending mail is higher that it could be, but this need not slow down the user if the MUA sends asynchronously in the background. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From vesely@tana.it Sat Aug 22 23:24:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D923A680B for ; Sat, 22 Aug 2009 23:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.077 X-Spam-Level: X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBrbO-nPe1mm for ; Sat, 22 Aug 2009 23:24:34 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 7AEBA3A68F1 for ; Sat, 22 Aug 2009 23:24:34 -0700 (PDT) Received: from [192.168.15.125] (wf-salyut.imt.ru [212.16.1.106]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sun, 23 Aug 2009 08:24:35 +0200 id 00000000005DC02F.000000004A90E0A4.0000626C Message-ID: <4A90E09E.5010006@tana.it> Date: Sun, 23 Aug 2009 10:24:30 +0400 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> <4A8EB3C9.1010105@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 06:24:35 -0000 Cyrus Daboo wrote: > --On August 21, 2009 3:48:41 PM +0100 Alexey Melnikov > wrote: >> I think the current text as written is quite clear that the domain itself >> should be used for TLS server identity verification, which I think is the >> correct way. Since the same protocol can serve both TLS and cleartext connections, the requirement that the server name somehow matches a given domain cannot be restricted to TLS. That restriction implies that a compliant server should avoid to set up TLS and SRV at the same time: If SRV records with a different domain are allowed, they prevent using secure connections, vice-versa if TLS with certificate from a different domain is in use, it cannot be advertised in an SRV record. IOW, SRV and TLS are not fully compatible by design. In addition, as matching the domain is a precise requirement, speaking about "a secure DNS option" should have the same precision, i.e. explicitly mention DNSSEC (or would DNS over SCTP suffice?) BTW, it seems to me that if attackers are able to poison the DNS so as to place the wrong name in an SRV record, they could as well place the wrong IP for the correct name instead. How effective is that restriction for preventing users' passwords from being phished? > The problem is you probably don't want to have "example.com" in the > subject of the certificate for the server "imap.example.com" because > clients that are directly configured with "imap.example.com" as the > server host name will expect "imap.example.com" in the subject. i.e. the > SRV lookup process should not "break" existing client behavior wrt > verifying certificates. That's correct. There are countless discussions about how to deduce the domain name from the HELO identity in an SMTP dialog, and all of them conclude that there's no way to do it. Therefore, your proposed Subject/SAN alternative may make sense. > Perhaps the requirement on the certificate could be: > > 1) Subject MUST match the server host name (does not break existing > clients) > > 2) Subject Alternative Name (SAN) should include the SRV query name, > i.e. _imap._tcp.example.com. i.e, rather than making it the domain > itself ("example.com") we explicitly indicate that the server is valid > when found through the SRV lookup process. Clients would then be > required to verify the SAN against the SRV query they did. > > Is this reasonable? Is there any precedent for an approach like this? SAN is not always used, some CA (e.g. CAcert.org) don't sign it, and it is not clear how they could verify it. I would propose a domain compatibility relationship as follows: if two domains share at least one primary MX server, then they are compatible. I'd expect it to be nearly an equivalence relationship, albeit not necessarily. This concept is as new as your requirement that a server has the same domain. Is it good? Useful? At any rate, statistics about certificate settings for mail show there's a lot of "wrong" certificates. If srv.example.com serves a number of virtual domains, e.g. example.org and example.net, *how* should they set up DNS and certificates? It is new ground: a full example would be appreciated. I don't know how many servers will not be compliant with SRV, but SNI is relatively new, so any providers who designed their set up before 2006 will presumably delay adoption of SRV records until most clients support SNI. From simon@josefsson.org Sun Aug 23 14:41:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6F33A6D3A for ; Sun, 23 Aug 2009 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQKbETZZDVDT for ; Sun, 23 Aug 2009 14:41:56 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2BA133A6BD1 for ; Sun, 23 Aug 2009 14:41:55 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7NLfrla016329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 23 Aug 2009 23:41:55 +0200 From: Simon Josefsson To: Alessandro Vesely Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> <4A8EB3C9.1010105@isode.com> <4A90E09E.5010006@tana.it> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090823:cyrus@daboo.name::k/VqtUF8IuGTFVnV:3XsN X-Hashcash: 1:22:090823:vesely@tana.it::pL9tdzPEEVEDL0ZZ:5CpZ X-Hashcash: 1:22:090823:apps-discuss@ietf.org::UUZvKnLTQKaIEAjb:O9I+ Date: Sun, 23 Aug 2009 23:41:53 +0200 In-Reply-To: <4A90E09E.5010006@tana.it> (Alessandro Vesely's message of "Sun, 23 Aug 2009 10:24:30 +0400") Message-ID: <87ab1qnr6m.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 21:41:57 -0000 Alessandro Vesely writes: >> Perhaps the requirement on the certificate could be: >> >> 1) Subject MUST match the server host name (does not break existing >> clients) >> >> 2) Subject Alternative Name (SAN) should include the SRV query name, >> i.e. _imap._tcp.example.com. i.e, rather than making it the domain >> itself ("example.com") we explicitly indicate that the server is >> valid when found through the SRV lookup process. Clients would then >> be required to verify the SAN against the SRV query they did. >> >> Is this reasonable? Is there any precedent for an approach like this? > > SAN is not always used, some CA (e.g. CAcert.org) don't sign it, and > it is not clear how they could verify it. That is wrong, CAcert.org definitely supports SANs. All certs I've acquired through cacert.org have had SANs in them for quite some time. /Simon From Nicolas.Williams@sun.com Sun Aug 23 23:50:38 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DF03A6B62 for ; Sun, 23 Aug 2009 23:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7PW68GPSQxi for ; Sun, 23 Aug 2009 23:50:37 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 895F23A6970 for ; Sun, 23 Aug 2009 23:50:37 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7O6ogau021091 for ; Mon, 24 Aug 2009 06:50:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7O6ogBe025928 for ; Mon, 24 Aug 2009 00:50:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7O5srAR007518; Mon, 24 Aug 2009 00:54:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7O5srjS007517; Mon, 24 Aug 2009 00:54:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 24 Aug 2009 00:54:53 -0500 From: Nicolas Williams To: Tony Finch Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Message-ID: <20090824055452.GG1043@Sun.COM> References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> <4A89A4D6.5070602@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: General discussion of application-layer protocols , Ravi shankar X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 06:50:38 -0000 On Sun, Aug 23, 2009 at 12:58:27AM +0100, Tony Finch wrote: > I should add that there's an architectural reason for submission to be an > SMTP variant rather than an extension to a mail store access protocol. Any > message submission mechanism needs a way for the MUA to specify the SMTP > envelope, that is the MAIL and RCPT commands *including* any extension > keywords. Why would you assume that an extension to IMAP for this wouldn't provide for dealing with the envelope? Heck, one could tunnel SUBMIT over IMAP. There is a good architectural reason for wanting a separate mail submission protocol: not everyone uses IMAP or POP3. Think of mailbox over NFS, for example. Also, one might want to reply to an e-mail forwarded from a different account than the one where one is reading the e-mail, and that might not work so well if one must use the mailstore access protocol for submission. There's also a good reason for wanting to have the mail submission to happen over IMAP: to defeat traffic analysis. I don't think that's important enough to warrant such an extension. Nico -- From eburger@standardstrack.com Mon Aug 24 04:36:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182673A6B42 for ; Mon, 24 Aug 2009 04:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7dS03pzsxsP for ; Mon, 24 Aug 2009 04:36:24 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 668FA3A6783 for ; Mon, 24 Aug 2009 04:36:24 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MfXqe-0005mF-Nb; Mon, 24 Aug 2009 04:36:29 -0700 Message-Id: <5EBDABB8-2CD2-4A2C-8C8C-1FAD117765EC@standardstrack.com> From: Eric Burger To: Nicolas Williams In-Reply-To: <20090824055452.GG1043@Sun.COM> Content-Type: multipart/signed; boundary=Apple-Mail-39-76162998; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Date: Mon, 24 Aug 2009 07:36:26 -0400 References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> <4A89A4D6.5070602@att.com> <20090824055452.GG1043@Sun.COM> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: General discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:36:25 -0000 --Apple-Mail-39-76162998 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All this does is drive deep packet inspection, so you do not even get to avoid traffic analysis. We are in agreement: there is absolutely no value to tunneling SUBMIT over IMAP or POP: you get less security with less functionality, neither of which is a desirable result. On Aug 24, 2009, at 1:54 AM, Nicolas Williams wrote: > There's also a good reason for wanting to have the mail submission to > happen over IMAP: to defeat traffic analysis. I don't think that's > important enough to warrant such an extension. --Apple-Mail-39-76162998 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4MjQxMTM2MjZaMCMGCSqGSIb3 DQEJBDEWBBT2PuTrDDcIKp+KUAHCkIkYcH6ocjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQA+mXdOYVfWMNX79yZxHfttJWixGdPdeJ/GC8igh+2QZC3g LFOVj19uV6iL4G9PPl8AvzXVplmx/V+epIFBfIN3UFFk3stmL2EBTpdaIfFiIMsHZt96SZzbX7ws ZIMvbjPvarp8qkGl72j/XDAGV6UV/iUQCMWa5wOIPvNrLQviNHqN+ZqeijvqVqvHVMdPOrBak43H qbd62z2u+bKHhT2J53FRhGFcqTTZq/HMnTgr8q4dUBcR6xBF2T/uOtTfcA97/ZWvRKVDqGc86gAT MldhsfzzdIpXG9xxsJOyJYQ8JgITK3Vuy/0q/ynjpmtEm2t0UHswiIogZa4GWKtIo95TAAAAAAAA --Apple-Mail-39-76162998-- From Nicolas.Williams@sun.com Mon Aug 24 05:18:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAE53A69E5 for ; Mon, 24 Aug 2009 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJPHNcySL+bE for ; Mon, 24 Aug 2009 05:18:03 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 9416728B23E for ; Mon, 24 Aug 2009 05:18:03 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7OCI6nT002102 for ; Mon, 24 Aug 2009 12:18:06 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7OCI5du047820 for ; Mon, 24 Aug 2009 06:18:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7OC7HTE007841; Mon, 24 Aug 2009 07:07:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7OC7Hmi007840; Mon, 24 Aug 2009 07:07:17 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 24 Aug 2009 07:07:17 -0500 From: Nicolas Williams To: Eric Burger Subject: Re: Feasibility research request: POP3 and IMAP4 extension to send mail Message-ID: <20090824120717.GI1043@Sun.COM> References: <922a897b0908170345q1eb9b0efi5a8b7c334438fcc6@mail.gmail.com> <28382.1250507211.886761@puncture> <922a897b0908170430t6a982e32s707e42718e033e16@mail.gmail.com> <28382.1250508786.610976@puncture> <922a897b0908170449q751c7ec9ocd6e31e1cf1916dd@mail.gmail.com> <4A89A4D6.5070602@att.com> <20090824055452.GG1043@Sun.COM> <5EBDABB8-2CD2-4A2C-8C8C-1FAD117765EC@standardstrack.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EBDABB8-2CD2-4A2C-8C8C-1FAD117765EC@standardstrack.com> User-Agent: Mutt/1.5.7i Cc: General discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 12:18:04 -0000 On Mon, Aug 24, 2009 at 07:36:26AM -0400, Eric Burger wrote: > All this does is drive deep packet inspection, so you do not even get > to avoid traffic analysis. Well, presumably you'd be using TLS. > We are in agreement: there is absolutely no value to tunneling SUBMIT > over IMAP or POP: ... Yes. From vesely@tana.it Mon Aug 24 09:37:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F033A69AF for ; Mon, 24 Aug 2009 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.012 X-Spam-Level: X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8fGiGtfN9dd for ; Mon, 24 Aug 2009 09:37:48 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 8035128C20E for ; Mon, 24 Aug 2009 09:37:46 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 24 Aug 2009 18:37:51 +0200 id 00000000005DC030.000000004A92C1DF.000013EC Message-ID: <4A92C21B.3010208@tana.it> Date: Mon, 24 Aug 2009 18:38:51 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Simon Josefsson Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <4A8EA9B1.2050203@alcatel-lucent.com> <4A8EAB2D.6010308@isode.com> <4A8EACBE.1040804@alcatel-lucent.com> <4A8EB217.6070205@alcatel-lucent.com> <4A8EB3C9.1010105@isode.com> <4A90E09E.5010006@tana.it> <87ab1qnr6m.fsf@mocca.josefsson.org> In-Reply-To: <87ab1qnr6m.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:37:49 -0000 Simon Josefsson wrote: >>> Perhaps the requirement on the certificate could be: >>> >>> 1) Subject MUST match the server host name (does not break existing >>> clients) >>> >>> 2) Subject Alternative Name (SAN) should include the SRV query name, >>> i.e. _imap._tcp.example.com. i.e, rather than making it the domain >>> itself ("example.com") we explicitly indicate that the server is >>> valid when found through the SRV lookup process. Clients would then >>> be required to verify the SAN against the SRV query they did. >>> >>> Is this reasonable? Is there any precedent for an approach like this? >> SAN is not always used, some CA (e.g. CAcert.org) don't sign it, and >> it is not clear how they could verify it. > > That is wrong, CAcert.org definitely supports SANs. All certs I've > acquired through cacert.org have had SANs in them for quite some time. Oops, I apologize for my mistake. In their words nothing else except for commonNames and subjectAltNames will appear on your certificate, the other fields are removed According to http://blog.cacert.org/2005/05/37.html they take SANs since 2005. An interesting discussion on using them appears in http://wiki.cacert.org/wiki/VhostTaskForce. However, it's centered on web usage, not mail. After examining a number of combinations, they apparently suggest "1 CN + multiple SAN" setups. Using multiple SANs, an ESP hosting a reasonable number of domains could provide an acceptable certificate without resorting to SNI. As an alternative to the SRV label mentioned in (2) above, the mail domain name could be indicated by a reserved mailbox, e.g. postmaster@example.com. The latter may be less confusing for casual examiners of that certificate. From shuque@isc.upenn.edu Mon Aug 24 11:04:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC56728C259 for ; Mon, 24 Aug 2009 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCU5Xm48ofQz for ; Mon, 24 Aug 2009 11:04:43 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 937813A6C24 for ; Mon, 24 Aug 2009 11:04:28 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 8DC4028F6; Mon, 24 Aug 2009 14:04:34 -0400 (EDT) Date: Mon, 24 Aug 2009 14:04:34 -0400 From: Shumon Huque To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090824180434.GA16812@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8E99B2.1060002@isode.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:04:43 -0000 On Fri, Aug 21, 2009 at 01:57:22PM +0100, Alexey Melnikov wrote: > Hi Alessandro, > > Alessandro Vesely wrote: > > >Alexey Melnikov wrote: > > > >>Hi, > >>I've just initiated IETF LC for this document. The document describes > >>how DNS SRV records can be used for email client autodiscovery of > >>IMAP/POP servers. > >>I would like to solicit additional reviews of the document. > > > >Just one point: The document assumes that the server for > >user@example.com is somehost.example.com. This can be deduced from the > >Security Considerations and from TLS certificate requirements, but is > >not stated clearly and openly. > > You are quite wrong about that. There is no such requirement. > However, if TLS is used, there is a requirement that the server > advertised in the DNS SRV record shows that it supports the domain part > (example.com above). This is needed to protect from attacks on insecure DNS. Quite true, although an important question is how the domain part is advertised in the certificate. Most likely it will be put in the the common name or the subjectaltname's DNSname field. But in many cases that poses a security problem, if other services unrelated to IMAP (or POP3 and submission) are also hosted at the domain part. If we issue an "example.com" certificate to the IMAP service, it could use that to impersonate any TLS service at that domain unrelated to IMAP (eg. jabber, https, etc). I'm not sure we have a good practical solution to this problem. today. RFC 4985 (SRVName SAN) could be used in theory to compartmentalize certificates to specific services at a domain name. But I'm not sure any commercial CAs today will issue certs with such extensions. --Shumon. From vkg@alcatel-lucent.com Mon Aug 24 11:33:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CD83A68A7 for ; Mon, 24 Aug 2009 11:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKP4RrNBpLPo for ; Mon, 24 Aug 2009 11:33:05 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AE85E3A6E7D for ; Mon, 24 Aug 2009 11:33:05 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7OIX8qO008581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 13:33:09 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7OIX79N016926; Mon, 24 Aug 2009 13:33:07 -0500 (CDT) Message-ID: <4A92DCE3.5080300@alcatel-lucent.com> Date: Mon, 24 Aug 2009 13:33:07 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shumon Huque Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> In-Reply-To: <20090824180434.GA16812@isc.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:33:06 -0000 Shumon Huque wrote: > Quite true, although an important question is how the domain part > is advertised in the certificate. Most likely it will be put in > the the common name or the subjectaltname's DNSname field. But > in many cases that poses a security problem, if other services > unrelated to IMAP (or POP3 and submission) are also hosted at > the domain part. If we issue an "example.com" certificate to the > IMAP service, it could use that to impersonate any TLS service at > that domain unrelated to IMAP (eg. jabber, https, etc). That is quite true (though I am not sure whether it is "impersonation", per se; after all, it is a signed and issued certificate.) > I'm not sure we have a good practical solution to this problem. The notion of tying an identity in the certificate to a specific use is reasonable, I think. The way we did this in our SIP work was to have a SIP-specific extended key usage (EKU) -- see http://tools.ietf.org/html/draft-ietf-sip-eku-05. However, EKUs have their own set of emotional baggage, including the fact that existing certificates will not have the specific extension specified. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From shuque@isc.upenn.edu Mon Aug 24 12:02:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0BC3A6E86 for ; Mon, 24 Aug 2009 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+RraW86XY54 for ; Mon, 24 Aug 2009 12:02:50 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 48B3E3A6E88 for ; Mon, 24 Aug 2009 12:02:50 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 6AA9F28D3; Mon, 24 Aug 2009 15:02:56 -0400 (EDT) Date: Mon, 24 Aug 2009 15:02:56 -0400 From: Shumon Huque To: "Vijay K. Gurbani" Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090824190256.GA19213@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <4A92DCE3.5080300@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A92DCE3.5080300@alcatel-lucent.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 19:02:51 -0000 On Mon, Aug 24, 2009 at 01:33:07PM -0500, Vijay K. Gurbani wrote: > Shumon Huque wrote: > >Quite true, although an important question is how the domain part > >is advertised in the certificate. Most likely it will be put in > >the the common name or the subjectaltname's DNSname field. But > >in many cases that poses a security problem, if other services > >unrelated to IMAP (or POP3 and submission) are also hosted at > >the domain part. If we issue an "example.com" certificate to the > >IMAP service, it could use that to impersonate any TLS service at > >that domain unrelated to IMAP (eg. jabber, https, etc). > > That is quite true (though I am not sure whether it is > "impersonation", per se; after all, it is a signed and issued > certificate.) Well, it may have been signed and issued correctly. But since the embedded identity wasn't specified with sufficient granularity, it could be used for purposes other than intended. And this leads to the impersonation threat. In a large enough organization, different services at the same domain name may be operated by different folks, on different systems, with different security requirements. You normally don't want the operator of one of those services being able to impersonate the identity of another. Either deliberately, or because it got compromised by an attacker. > >I'm not sure we have a good practical solution to this problem. > > The notion of tying an identity in the certificate to a specific > use is reasonable, I think. The way we did this in our SIP > work was to have a SIP-specific extended key usage (EKU) -- see > http://tools.ietf.org/html/draft-ietf-sip-eku-05. > > However, EKUs have their own set of emotional baggage, > including the fact that existing certificates will not have > the specific extension specified. Yeah, that's an interesting way to address this. But I think it has an even bigger deployment problem than RFC 4985. You'd need to define a new EKU for each new service. With RFC 4985, one general purpose spec could potentially be used for all services that use DNS SRV records. --Shumon. From cyrus@daboo.name Mon Aug 24 12:19:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263043A6D2D for ; Mon, 24 Aug 2009 12:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+Idcg4MnV7h for ; Mon, 24 Aug 2009 12:19:25 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 564AE3A6E9E for ; Mon, 24 Aug 2009 12:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id ECB1C1855E82; Mon, 24 Aug 2009 15:19:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfSJe9747A1H; Mon, 24 Aug 2009 15:19:04 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 019F41855E78; Mon, 24 Aug 2009 15:19:02 -0400 (EDT) Date: Mon, 24 Aug 2009 15:18:55 -0400 From: Cyrus Daboo To: Shumon Huque , Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> In-Reply-To: <20090824180434.GA16812@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1513 Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 19:19:26 -0000 Hi Shumon, --On August 24, 2009 2:04:34 PM -0400 Shumon Huque wrote: >> You are quite wrong about that. There is no such requirement. >> However, if TLS is used, there is a requirement that the server >> advertised in the DNS SRV record shows that it supports the domain part >> (example.com above). This is needed to protect from attacks on insecure >> DNS. > > Quite true, although an important question is how the domain part > is advertised in the certificate. Most likely it will be put in > the the common name or the subjectaltname's DNSname field. But > in many cases that poses a security problem, if other services > unrelated to IMAP (or POP3 and submission) are also hosted at > the domain part. If we issue an "example.com" certificate to the > IMAP service, it could use that to impersonate any TLS service at > that domain unrelated to IMAP (eg. jabber, https, etc). > > I'm not sure we have a good practical solution to this problem. > today. RFC 4985 (SRVName SAN) could be used in theory to compartmentalize > certificates to specific services at a domain name. But I'm not > sure any commercial CAs today will issue certs with such extensions. Right. This was why I suggested using the SRV query string in the subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that gets to that cert via an SRV lookup can verify that it is valid, whilst other clients will effectively ignore that, and the cert can't "impersonate" another service. -- Cyrus Daboo From alexey.melnikov@isode.com Mon Aug 24 13:41:20 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A301D28C32C for ; Mon, 24 Aug 2009 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccv43zgwNyPf for ; Mon, 24 Aug 2009 13:41:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 55DD33A6EB0 for ; Mon, 24 Aug 2009 13:41:13 -0700 (PDT) Received: from [92.40.15.178] (92.40.15.178.sub.mbb.three.co.uk [92.40.15.178]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 24 Aug 2009 21:41:18 +0100 Message-ID: <4A92FADB.1030406@isode.com> Date: Mon, 24 Aug 2009 21:40:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> In-Reply-To: <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 20:41:20 -0000 Cyrus Daboo wrote: > Hi Shumon, > > --On August 24, 2009 2:04:34 PM -0400 Shumon Huque > wrote: > >>> You are quite wrong about that. There is no such requirement. >>> However, if TLS is used, there is a requirement that the server >>> advertised in the DNS SRV record shows that it supports the domain part >>> (example.com above). This is needed to protect from attacks on insecure >>> DNS. >> >> Quite true, although an important question is how the domain part >> is advertised in the certificate. Most likely it will be put in >> the the common name or the subjectaltname's DNSname field. But >> in many cases that poses a security problem, if other services >> unrelated to IMAP (or POP3 and submission) are also hosted at >> the domain part. If we issue an "example.com" certificate to the >> IMAP service, it could use that to impersonate any TLS service at >> that domain unrelated to IMAP (eg. jabber, https, etc). >> >> I'm not sure we have a good practical solution to this problem. >> today. RFC 4985 (SRVName SAN) could be used in theory to >> compartmentalize >> certificates to specific services at a domain name. But I'm not >> sure any commercial CAs today will issue certs with such extensions. > > Right. This was why I suggested using the SRV query string in the > subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that > gets to that cert via an SRV lookup can verify that it is valid, > whilst other clients will effectively ignore that, and the cert can't > "impersonate" another service. If you are going to do that, you need to update IMAP and POP3 specs properly, i.e. to define TLS server identity verification procedure for these protocols that requires that clients check srvName. From shuque@isc.upenn.edu Mon Aug 24 15:00:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3DF3A6B0E for ; Mon, 24 Aug 2009 15:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olx8ocrBazDX for ; Mon, 24 Aug 2009 15:00:24 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 8D08F28C1BB for ; Mon, 24 Aug 2009 15:00:24 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id A535C28D3; Mon, 24 Aug 2009 18:00:30 -0400 (EDT) Date: Mon, 24 Aug 2009 18:00:30 -0400 From: Shumon Huque To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090824220030.GA24271@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A92FADB.1030406@isode.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:00:25 -0000 On Mon, Aug 24, 2009 at 09:40:59PM +0100, Alexey Melnikov wrote: > Cyrus Daboo wrote: > >Right. This was why I suggested using the SRV query string in the > >subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that > >gets to that cert via an SRV lookup can verify that it is valid, > >whilst other clients will effectively ignore that, and the cert can't > >"impersonate" another service. > > If you are going to do that, you need to update IMAP and POP3 specs > properly, i.e. to define TLS server identity verification procedure for > these protocols that requires that clients check srvName. Putting the SRV query name in dNSName is a somewhat novel use. And reusing an existing widely used SAN field is probably more deployable than a new barely used SAN field. Would you have to update the IMAP and POP3 documents though? Wouldn't this I-D just update them. To support older software as well, the server owner would just obtain a cert with 2 dnsnames, the SRV name and the server hostname. --Shumon. From stpeter@stpeter.im Mon Aug 24 15:03:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F293A6978 for ; Mon, 24 Aug 2009 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyDsg6Wx+32K for ; Mon, 24 Aug 2009 15:03:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E4DEF3A6D2F for ; Mon, 24 Aug 2009 15:03:36 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC9334007B; Mon, 24 Aug 2009 16:03:42 -0600 (MDT) Message-ID: <4A930E3D.1080707@stpeter.im> Date: Mon, 24 Aug 2009 16:03:41 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Shumon Huque Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <20090824220030.GA24271@isc.upenn.edu> In-Reply-To: <20090824220030.GA24271@isc.upenn.edu> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:03:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/24/09 4:00 PM, Shumon Huque wrote: > On Mon, Aug 24, 2009 at 09:40:59PM +0100, Alexey Melnikov wrote: >> Cyrus Daboo wrote: >>> Right. This was why I suggested using the SRV query string in the >>> subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that >>> gets to that cert via an SRV lookup can verify that it is valid, >>> whilst other clients will effectively ignore that, and the cert can't >>> "impersonate" another service. >> If you are going to do that, you need to update IMAP and POP3 specs >> properly, i.e. to define TLS server identity verification procedure for >> these protocols that requires that clients check srvName. > > Putting the SRV query name in dNSName is a somewhat novel > use. And reusing an existing widely used SAN field is probably > more deployable than a new barely used SAN field. Perhaps I missed something, but don't we have RFC 4985 for SRVName? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqTDj0ACgkQNL8k5A2w/vy4RACg6VPhFPXUViw6JIgUryP2Lpsi cFMAoJu5bV+OvsGe0ovqAqhs8RcybVoJ =+usG -----END PGP SIGNATURE----- From shuque@isc.upenn.edu Mon Aug 24 15:12:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702E33A6831 for ; Mon, 24 Aug 2009 15:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7WdkpaV25Qz for ; Mon, 24 Aug 2009 15:12:44 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 70B053A6D3D for ; Mon, 24 Aug 2009 15:12:44 -0700 (PDT) Received: from NOSFERATU.net.isc.upenn.edu (NOSFERATU.net.isc.upenn.edu [128.91.197.55]) by talkeetna.isc-net.upenn.edu (Postfix) with ESMTP id 9367228D2; Mon, 24 Aug 2009 18:12:50 -0400 (EDT) Message-ID: <4A931062.1050205@isc.upenn.edu> Date: Mon, 24 Aug 2009 18:12:50 -0400 From: Shumon Huque User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <20090824220030.GA24271@isc.upenn.edu> <4A930E3D.1080707@stpeter.im> In-Reply-To: <4A930E3D.1080707@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:12:45 -0000 Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/24/09 4:00 PM, Shumon Huque wrote: >> On Mon, Aug 24, 2009 at 09:40:59PM +0100, Alexey Melnikov wrote: >>> Cyrus Daboo wrote: >>>> Right. This was why I suggested using the SRV query string in the >>>> subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that >>>> gets to that cert via an SRV lookup can verify that it is valid, >>>> whilst other clients will effectively ignore that, and the cert can't >>>> "impersonate" another service. >>> If you are going to do that, you need to update IMAP and POP3 specs >>> properly, i.e. to define TLS server identity verification procedure for >>> these protocols that requires that clients check srvName. >> Putting the SRV query name in dNSName is a somewhat novel >> use. And reusing an existing widely used SAN field is probably >> more deployable than a new barely used SAN field. > > Perhaps I missed something, but don't we have RFC 4985 for SRVName? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ Yes Peter, we do. And the XMPP updates even use it, as you know :) The main impediment is that we can't get any commercial CAs to issue certs with SRVName yet .. Perhaps, this doc should recommend RFC 4985, but also allow putting the SRV query name into dnsname. --Shumon. (Really, I wish we could get the "global" commercial CAs to certify enterprise CAs with appropriate name constraint extensions, so that we could all issue our own certs, with whatever capabilities we needed. But that's a topic of another diatribe ..) From duerst@it.aoyama.ac.jp Tue Aug 25 00:25:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BF93A688F for ; Tue, 25 Aug 2009 00:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.813 X-Spam-Level: * X-Spam-Status: No, score=1.813 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emDT5txPIee6 for ; Tue, 25 Aug 2009 00:25:57 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id D8FBC3A6874 for ; Tue, 25 Aug 2009 00:25:56 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n7P7PnlG030371 for ; Tue, 25 Aug 2009 16:25:49 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 743a_83463e52_9148_11de_a764_001d096c566a; Tue, 25 Aug 2009 16:25:49 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48497) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Aug 2009 16:22:52 +0900 Message-ID: <4A9391EC.7070103@it.aoyama.ac.jp> Date: Tue, 25 Aug 2009 16:25:32 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Olson Timezones Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 07:25:58 -0000 The following link: http://article.gmane.org/gmane.comp.time.tz/2822 may be of interest in the context of work on timezone identification contemplated earlier on this list. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From lear@cisco.com Tue Aug 25 00:40:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B833A6B9E for ; Tue, 25 Aug 2009 00:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKGc+hmMpnN3 for ; Tue, 25 Aug 2009 00:40:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AD4AC3A6E69 for ; Tue, 25 Aug 2009 00:40:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAP0xk0qQ/uCLe2dsb2JhbACBU5k0AQEWJAaiQ4g3jzoFhBqKSA X-IronPort-AV: E=Sophos;i="4.44,271,1249257600"; d="scan'208";a="47808244" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2009 07:40:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7P7esxY005713; Tue, 25 Aug 2009 09:40:54 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp5582.cisco.com [10.61.85.205]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7P7esgk015379; Tue, 25 Aug 2009 07:40:54 GMT Message-ID: <4A939586.8030000@cisco.com> Date: Tue, 25 Aug 2009 09:40:54 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Subject: Re: Olson Timezones References: <4A9391EC.7070103@it.aoyama.ac.jp> In-Reply-To: <4A9391EC.7070103@it.aoyama.ac.jp> X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=343; t=1251186054; x=1252050054; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Olson=20Timezones |Sender:=20; bh=BU1mZZqVk1mf2fri9AUjhfqdn5XJgTxtMnPtiQA/v18=; b=WPocifhTaS7VymvOfiQKc9Mksww7VjebpdgHCJVGvdMCgIZQxNZg5yLW5j sqQ8u1sFYbSAA5yuaVl8hNw/7HjgCmeIexXXv40mrSrmpKEcPfnIrAZMVx6/ r0Lbi2kzJj; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 07:40:54 -0000 Martin, I responded to that note, but have not heard back from Mr. Olson. Eliot On 8/25/09 9:25 AM, "Martin J. Dürst" wrote: > The following link: http://article.gmane.org/gmane.comp.time.tz/2822 > may be of interest in the context of work on timezone identification > contemplated earlier on this list. > > Regards, Martin. From vesely@tana.it Tue Aug 25 04:16:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E86F3A6BC3 for ; Tue, 25 Aug 2009 04:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_EMAIL=2.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItIMl9m4VumJ for ; Tue, 25 Aug 2009 04:16:24 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 42BE53A686D for ; Tue, 25 Aug 2009 04:16:24 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 25 Aug 2009 13:16:06 +0200 id 00000000005DC02F.000000004A93C7F6.000061E2 Message-ID: <4A93C7F5.5020108@tana.it> Date: Tue, 25 Aug 2009 13:16:05 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> In-Reply-To: <4A92FADB.1030406@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 11:16:25 -0000 Alexey Melnikov wrote: > Cyrus Daboo wrote: >>> I'm not sure we have a good practical solution to this problem. >>> today. RFC 4985 (SRVName SAN) could be used in theory to compartmentalize >>> certificates to specific services at a domain name. But I'm not >>> sure any commercial CAs today will issue certs with such extensions. >> >> Right. This was why I suggested using the SRV query string in the >> subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that >> gets to that cert via an SRV lookup can verify that it is valid, >> whilst other clients will effectively ignore that, and the cert can't >> "impersonate" another service. > > If you are going to do that, you need to update IMAP and POP3 specs > properly, i.e. to define TLS server identity verification procedure for > these protocols that requires that clients check srvName. Will the spec be flexible about that? I mean, checking them only if they are present? To recap, say mail.example.com hosts mail services for example.org and example.net. Assume its certificate may have SAN fields for any of the following: * otherName dNSName mail.example.com * iPAddress 192.0.2.3 * otherName srvName _imap.example.org * otherName srvName _imap.example.net * rfc822Name postmaster@example.org * rfc822Name postmaster@example.net The question is whether a suitable tradeoff among interoperability, compartmentalization, and other security issues may be obtained by tailoring those SAN fields, even without Server Name Indication. To complete the example, also assume the following RRs are set, and obtainable by regular DNS over UDP queries. mail.example.com IN A 192.0.2.3 mail.example.net IN A 192.0.2.3 3.2.0.192.in-addr.arpa IN CNAME 3.0-24.2.0.192.in-addr.arpa 0-24.2.0.192.in-addr.arpa IN NS ns.example.com 3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.com 3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.net _imap._tcp.example.org IN SRV 0 0 143 mail.example.com _imap._tcp.example.net IN SRV 0 0 143 mail.example.net example.com IN MX 0 mail.example.com example.org IN MX 0 mail.example.com example.net IN MX 0 mail.example.com Note that example.org is served by an host in a different domain zone. However, as far as DNS queries can be trusted, the client can check that example.com is compatible with example.org (because they share a primary MX.) If postmaster@example.org is included in the certificate, the client may trust that the signing CA had verified who got mail for it, and consider that as corroborating the value of the SRV RR. Am I missing something? IMHO, any MUST/MUST NOT in the spec should only prevent cases where phishing can actually be operated, so as not to standardize ill defined practices. I would suggest that the spec exemplifies, in an appendix, various cases of DNS and certificate settings, telling in what cases the client should trust the info, ask confirmation, or strongly discourage the user. The spec may also suggest that (in some cases) challenge/response authentication takes place even if the channel is crypted, to avoid phishing. From cyrus@daboo.name Tue Aug 25 06:32:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D463A6D1E for ; Tue, 25 Aug 2009 06:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD5XpvoYMM64 for ; Tue, 25 Aug 2009 06:32:52 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 780AB3A694D for ; Tue, 25 Aug 2009 06:32:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DF894185B54D; Tue, 25 Aug 2009 09:32:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Itx-Im7-S8R; Tue, 25 Aug 2009 09:32:57 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 9209E185B546; Tue, 25 Aug 2009 09:32:56 -0400 (EDT) Date: Tue, 25 Aug 2009 09:32:53 -0400 From: Cyrus Daboo To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , apps-discuss@ietf.org Subject: Re: Olson Timezones Message-ID: In-Reply-To: <4A9391EC.7070103@it.aoyama.ac.jp> References: <4A9391EC.7070103@it.aoyama.ac.jp> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=474 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 13:32:53 -0000 Hi "Martin, --On August 25, 2009 4:25:32 PM +0900 "\"Martin J. D=C3=BCrst\""=20 wrote: > The following link: http://article.gmane.org/gmane.comp.time.tz/2822 may > be of interest in the context of work on timezone identification > contemplated earlier on this list. Right. I am hoping to get a BOF in place for more formal discussion of this = at the next meeting. Hopefully there will be supporting documents available = for that soon. --=20 Cyrus Daboo From shuque@isc.upenn.edu Tue Aug 25 06:59:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778973A6AC0 for ; Tue, 25 Aug 2009 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIT6qC6zeywz for ; Tue, 25 Aug 2009 06:59:25 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 0F7CC3A680E for ; Tue, 25 Aug 2009 06:58:53 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 3A24C2908; Tue, 25 Aug 2009 09:59:00 -0400 (EDT) Date: Tue, 25 Aug 2009 09:59:00 -0400 From: Shumon Huque To: Alessandro Vesely Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090825135900.GA12182@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A93C7F5.5020108@tana.it> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 13:59:26 -0000 On Tue, Aug 25, 2009 at 01:16:05PM +0200, Alessandro Vesely wrote: > > Will the spec be flexible about that? I mean, checking them only if > they are present? Sure, why not? > To recap, say mail.example.com hosts mail services for example.org and > example.net. Assume its certificate may have SAN fields for any of the > following: > > * otherName dNSName mail.example.com > * iPAddress 192.0.2.3 > * otherName srvName _imap.example.org > * otherName srvName _imap.example.net > * rfc822Name postmaster@example.org > * rfc822Name postmaster@example.net For the purposes of this draft, I think you just need: dNSName mail.example.com otherName SRVName _imap.example.org otherName SRVName _imap.example.net and to include Cyrus's proposal of SRV query names in dNSName: dNSName mail.example.com dNSName _imap._tcp.example.org dNSName _imap._tcp.example.net otherName SRVName _imap.example.org otherName SRVName _imap.example.net Clients that don't understand this draft would presumably be hardcoded with the server name (mail.example.com) and would look for that identity in dNSName (or perhaps common name). Clients that understand this draft would look for the otherName/SRVName corresponding to the service they are using (example.org or example.net) and failing that, look for the full SRV query name string in dNSName. There should probably be a separate draft about the non-submission SMTP mail delivery and MX records cases. This draft only addresses submission which doesn't use MX records as far as I know. --Shumon. From alexey.melnikov@isode.com Tue Aug 25 07:20:02 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310433A6F7D for ; Tue, 25 Aug 2009 07:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikN-OSqmGcwN for ; Tue, 25 Aug 2009 07:20:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9954728C481 for ; Tue, 25 Aug 2009 07:19:44 -0700 (PDT) Received: from [172.16.2.153] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Aug 2009 15:19:49 +0100 Message-ID: <4A93F2FA.2050705@isode.com> Date: Tue, 25 Aug 2009 15:19:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shumon Huque Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> In-Reply-To: <20090825135900.GA12182@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:20:02 -0000 Shumon Huque wrote: >There should probably be a separate draft about the non-submission >SMTP mail delivery and MX records cases. This draft only addresses >submission which doesn't use MX records as far as I know. > > Can you elaborate on why you think this separate draft is needed? From vesely@tana.it Tue Aug 25 07:42:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1963A6DDE for ; Tue, 25 Aug 2009 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jl8RamXJuuY for ; Tue, 25 Aug 2009 07:42:25 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1DA5B3A6D95 for ; Tue, 25 Aug 2009 07:42:24 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 25 Aug 2009 16:42:30 +0200 id 00000000005DC030.000000004A93F856.000026DD Message-ID: <4A93F856.2030906@tana.it> Date: Tue, 25 Aug 2009 16:42:30 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> <4A93F2FA.2050705@isode.com> In-Reply-To: <4A93F2FA.2050705@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:42:26 -0000 Alexey, Alexey Melnikov wrote: > Shumon Huque wrote: > >> There should probably be a separate draft about the non-submission >> SMTP mail delivery and MX records cases. This draft only addresses >> submission which doesn't use MX records as far as I know. >> > Can you elaborate on why you think this separate draft is needed? I understood Shumon's wording as a kind way to tell me that the MX records and related considerations that I wrote upthread have nothing to do with the draft at hand. I haven't object, because the view he has portrayed doesn't comprehend matching the host name returned in the SRV record and the original service domain that was queried. I have introduced MX considerations in an attempt to establish an alternative requirement than mandating obscure matching of domain names in the absence of DNSSEC. Shumon will contradict me if I misunderstood him. From shuque@isc.upenn.edu Tue Aug 25 07:45:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4953A6F53 for ; Tue, 25 Aug 2009 07:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTPN2BPvNewo for ; Tue, 25 Aug 2009 07:45:44 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 589AA3A6906 for ; Tue, 25 Aug 2009 07:45:43 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id D27132907; Tue, 25 Aug 2009 10:45:49 -0400 (EDT) Date: Tue, 25 Aug 2009 10:45:49 -0400 From: Shumon Huque To: Alexey Melnikov Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090825144549.GA13539@isc.upenn.edu> References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> <4A93F2FA.2050705@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A93F2FA.2050705@isode.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:45:45 -0000 On Tue, Aug 25, 2009 at 03:19:38PM +0100, Alexey Melnikov wrote: > Shumon Huque wrote: > > >There should probably be a separate draft about the non-submission > >SMTP mail delivery and MX records cases. This draft only addresses > >submission which doesn't use MX records as far as I know. > > > > > Can you elaborate on why you think this separate draft is needed? Actually I think Alessandro brought up MX records in the tail end of his message, but I might have misunderstood what he was saying .. At any rate, I think there is a problem that needs to be addressed. Say an MTA is delivering mail to user@example.com using STARTTLS, and the relevant MX record is: example.com IN MX 0 mail.example.com Which identity should it expect to see in the presented certificate? RFC 3207 says only: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. If that means the hostname of the server (eg. mail.example.com) then it's the same problem: you are susceptible to a DNS spoofing attack. And I think the majority of SMTP servers that support STARTTLS are configured today with certs corresponding to their hostnames. --Shumon. From alexey.melnikov@isode.com Tue Aug 25 13:59:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6683A6A25 for ; Tue, 25 Aug 2009 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBeDxpgKTGs6 for ; Tue, 25 Aug 2009 13:59:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D804B3A67E1 for ; Tue, 25 Aug 2009 13:58:59 -0700 (PDT) Received: from [172.16.2.153] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Aug 2009 21:59:05 +0100 Message-ID: <4A945076.4040904@isode.com> Date: Tue, 25 Aug 2009 21:58:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shumon Huque Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> In-Reply-To: <20090825135900.GA12182@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 20:59:01 -0000 Shumon Huque wrote: >On Tue, Aug 25, 2009 at 01:16:05PM +0200, Alessandro Vesely wrote: > > >>Will the spec be flexible about that? I mean, checking them only if >>they are present? >> >> >Sure, why not? > > >>To recap, say mail.example.com hosts mail services for example.org and >>example.net. Assume its certificate may have SAN fields for any of the >>following: >> >>* otherName dNSName mail.example.com >>* iPAddress 192.0.2.3 >>* otherName srvName _imap.example.org >>* otherName srvName _imap.example.net >>* rfc822Name postmaster@example.org >>* rfc822Name postmaster@example.net >> >> >For the purposes of this draft, I think you just need: > > dNSName mail.example.com > otherName SRVName _imap.example.org > otherName SRVName _imap.example.net > Agreed. >and to include Cyrus's proposal of SRV query names in dNSName: > > dNSName mail.example.com > dNSName _imap._tcp.example.org > dNSName _imap._tcp.example.net > otherName SRVName _imap.example.org > otherName SRVName _imap.example.net > >Clients that don't understand this draft would presumably be >hardcoded with the server name (mail.example.com) and would look >for that identity in dNSName (or perhaps common name). Clients >that understand this draft would look for the otherName/SRVName >corresponding to the service they are using (example.org or >example.net) and failing that, look for the full SRV query name >string in dNSName. > dNSName _imap._tcp.example.org/_imap._tcp.example.net looks like a misuse of dNSName. I would ask the Security Area Directors about whether this is Ok. From fanf2@hermes.cam.ac.uk Wed Aug 26 06:30:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBF428C139 for ; Wed, 26 Aug 2009 06:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTG4D8vc+gDr for ; Wed, 26 Aug 2009 06:30:44 -0700 (PDT) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 465FC3A67B1 for ; Wed, 26 Aug 2009 06:30:41 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56645) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1MgIYT-0002oW-22 (Exim 4.70) (return-path ); Wed, 26 Aug 2009 14:28:49 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1MgIYT-0008RW-Jt (Exim 4.67) (return-path ); Wed, 26 Aug 2009 14:28:49 +0100 Date: Wed, 26 Aug 2009 14:28:49 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Shumon Huque Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed In-Reply-To: <20090825144549.GA13539@isc.upenn.edu> Message-ID: References: <4A8D28AA.4060906@isode.com> <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> <4A93F2FA.2050705@isode.com> <20090825144549.GA13539@isc.upenn.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:30:45 -0000 On Tue, 25 Aug 2009, Shumon Huque wrote: > > And I think the majority of SMTP servers that support STARTTLS are > configured today with certs corresponding to their hostnames. That's true for submission servers, but less than 10% of MXs that support STARTTLS have valid certificates. A very large proportion of them have the wrong subject name. http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Note there are at least four names that are configured separately and which are relevant to MX server authentication: the mail domain; the target name of the MX record; the server's canonical name (e.g. as in reverse DNS); and the MTA's configured host name. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From shuque@isc.upenn.edu Wed Aug 26 17:51:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8FE3A6BBD for ; Wed, 26 Aug 2009 17:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOjar8rjUbud for ; Wed, 26 Aug 2009 17:51:06 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 881F93A6A6B for ; Wed, 26 Aug 2009 17:51:06 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id BBCA628F8; Wed, 26 Aug 2009 20:51:12 -0400 (EDT) Date: Wed, 26 Aug 2009 20:51:12 -0400 From: Shumon Huque To: Tony Finch Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed Message-ID: <20090827005112.GA908@isc.upenn.edu> References: <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> <4A93F2FA.2050705@isode.com> <20090825144549.GA13539@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 00:51:07 -0000 On Wed, Aug 26, 2009 at 02:28:49PM +0100, Tony Finch wrote: > On Tue, 25 Aug 2009, Shumon Huque wrote: > > > > And I think the majority of SMTP servers that support STARTTLS are > > configured today with certs corresponding to their hostnames. > > That's true for submission servers, but less than 10% of MXs that support > STARTTLS have valid certificates. A very large proportion of them have the > wrong subject name. > > http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Interesting data. It appears that most people are using this effectively as an anonymous encryption channel. > Note there are at least four names that are configured separately and > which are relevant to MX server authentication: the mail domain; the > target name of the MX record; the server's canonical name (e.g. as in > reverse DNS); and the MTA's configured host name. > > Tony. So, which should be used as the certificate identity? I don't think either the MX target or the mail domain in dNSName or common name is good enough, for reasons already outlined in this thread. I'd like to see the IETF specify the use of application or service-specific identities in all protocols. I also think a point needs to be made about DNSSEC. Many specs are saying that a resolved DNS name is not an acceptably secure identity because of insecure DNS. The implication to be drawn is that the deployment of DNSSEC will take care of this problem and allow such identities to be used. But how does an application know that DNSSEC is being used? It would probably need to be using a DNSSEC aware name resolution API that indicated that the queried data was successfully authenticated with DNSSEC. Those things don't really exist yet (although there are some early drafts on the topic), despite some early deployment of DNSSEC. --Shumon. From vesely@tana.it Thu Aug 27 01:13:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E9B3A689A for ; Thu, 27 Aug 2009 01:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYhng9tZbsDK for ; Thu, 27 Aug 2009 01:13:33 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 32F4C3A6A0B for ; Thu, 27 Aug 2009 01:13:31 -0700 (PDT) Received: from [217.203.154.28] ([217.203.154.28]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 27 Aug 2009 10:13:33 +0200 id 00000000005DC034.000000004A96402E.00000411 Message-ID: <4A96402D.2090508@tana.it> Date: Thu, 27 Aug 2009 12:13:33 +0400 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Additional reviews of draft-daboo-srv-email-02.txt needed References: <4A8E30A8.9050307@tana.it> <4A8E99B2.1060002@isode.com> <20090824180434.GA16812@isc.upenn.edu> <80915C5A84C4DABC6AC2B749@caldav.corp.apple.com> <4A92FADB.1030406@isode.com> <4A93C7F5.5020108@tana.it> <20090825135900.GA12182@isc.upenn.edu> <4A93F2FA.2050705@isode.com> <20090825144549.GA13539@isc.upenn.edu> <20090827005112.GA908@isc.upenn.edu> In-Reply-To: <20090827005112.GA908@isc.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 08:13:34 -0000 Shumon Huque wrote: > On Wed, Aug 26, 2009 at 02:28:49PM +0100, Tony Finch wrote: >> Note there are at least four names that are configured separately and >> which are relevant to MX server authentication: the mail domain; the >> target name of the MX record; the server's canonical name (e.g. as in >> reverse DNS); and the MTA's configured host name. > > So, which should be used as the certificate identity? I don't > think either the MX target or the mail domain in dNSName or > common name is good enough, for reasons already outlined in this > thread. I'd like to see the IETF specify the use of application > or service-specific identities in all protocols. +1. I'd state the objective as follows: Certificates should carry enough information to 1. confirm the identity of the host and/or accountable domain, thereby clearing any mistrust about DNS, and 2. confirm the service(s) that the certificate is meant to be valid for. That way compartmentalization is a decision made by the certificate requester, and applications may act appropriately. In order to avoid creating an ad-hoc OID, SRVNames could be used to indicate the service, regardless of whether they correspond to actual RRs. No SRVName would imply any service; otherwise, only services explicitly mentioned in the certificate. Some of these names, including _imap, _pop3, _submit, are specified in the draft. What about the other ones? What difference makes the FQDN of a service, e.g. _mail vs _mail.example.com (claim of RR existence?) I guess many of the misconfiguration issues that Tony referred stem from lack of simple but detailed instructions and examples. From stpeter@stpeter.im Thu Aug 27 16:56:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C4B28C36F for ; Thu, 27 Aug 2009 16:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx10V-XczH-r for ; Thu, 27 Aug 2009 16:56:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C07F83A6E79 for ; Thu, 27 Aug 2009 16:56:22 -0700 (PDT) Received: from squire.local (dsl-175-240.dynamic-dsl.frii.net [216.17.175.240]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F16D84007B; Thu, 27 Aug 2009 17:56:18 -0600 (MDT) Message-ID: <4A97183A.9090800@stpeter.im> Date: Thu, 27 Aug 2009 17:35:22 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 23:56:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry about the very delayed reply. I'm finally revising the I-D so I might be posting additional messages in some old threads... On 6/6/09 8:51 AM, Paul Hoffman wrote: > At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote: >> Hi Paul, >> >> Paul Hoffman wrote: >> >>> Greetings again. I would like to argue that, from a security >>> perspective, we should not allow looking up DNS names in the >>> subjectName in PKIX certificates in this document. Section 3.1 >>> says: The server's identity may also be verified by comparing the >>> reference identity to the Common Name (CN) [LDAP-SCHEMA] value in >>> the leaf Relative Distinguished Name (RDN) of the subjectName >>> field of the server's certificate. This comparison is performed >>> using the rules for comparison of DNS names in Section 3.1.3.1, >>> below, with the exception that no wildcard matching is allowed. >>> Although the use of the Common Name value is existing practice, >>> it is deprecated, and Certification Authorities are encouraged to >>> provide subjectAltName values instead. Note that the TLS >>> implementation may represent DNs in certificates according to >>> X.500 or other conventions. For example, some X.500 >>> implementations order the RDNs in a DN using a left-to-right >>> (most significant to least significant) convention instead of >>> LDAP's right-to-left convention. >>> >>> That ambiguity leads to a fairly trivial identity attack. >>> >> Can you elaborate on this? (A pointer to discussion elsewhere would >> be fine as well.) > > If there is a TLD that has the same name as the SLD that you want to > attack, you can get a certificate that uses the CNs. For example, if > you want to attack ar.com, you could register com.ar, get a > certificate for it, and use it to fool systems that follow the rule > in the last sentence above. This attack will get easier as more TLDs > with names that exist as current SLDs are created in the coming > years. > >>> There is no good reason for a CA to issue certificates with >>> domain names in the subjectName, and lots of reasons for it not >>> to. >>> >> I think the current reality is that many of CAs still do that >> without supporting DNS name in the subjectAltName. > > Probably. Are you saying that the fact that they are doing this > knowingly insecurely should stop us from prohibiting it in this > profile? This profile is supposed to be a way to codify secure > authentication practice. Saying "but there are CAs who do it wrong > and you should validate their certificates anyway" seems > counterproductive. Paul, I agree that this document needs to codify secure authentication practices. However, that raises a more general issue: shall this document specify rules only for certificate validation or also for certificate generation? My understanding of the scope that Kurt and I inherited from JeffH and RL Bob is that the document specifies rules only for validation, and even there only for a particular subset of validation, namely matching of the server's presented identities against the client's expected "reference identity" (e.g., not necessarily mentioning anything about the fact that the certificate needs to be certified by a chain of certificates terminating in a trust anchor). Personally I think that it would be helpful to specify rules about both generation and validation (and about how the client should proceed if validation in the broadest sense fails), but before expanding the scope of the document I'd like to make sure that people here are comfortable with doing so. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXGDoACgkQNL8k5A2w/vx/EQCg3+Ev4lVWqfNLPwoHPf8uOGFa +bEAnApfXipZ9f+pYNFYKx/orJM8Vn+f =ArGv -----END PGP SIGNATURE----- From phoffman@imc.org Thu Aug 27 17:34:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8E83A6822 for ; Thu, 27 Aug 2009 17:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgjN7bniG7Xe for ; Thu, 27 Aug 2009 17:34:41 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 966093A688D for ; Thu, 27 Aug 2009 17:34:41 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7S0Yk11016695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 17:34:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A97183A.9090800@stpeter.im> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> Date: Thu, 27 Aug 2009 17:34:45 -0700 To: Peter Saint-Andre From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 00:34:42 -0000 At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: >Paul, I agree that this document needs to codify secure authentication >practices. However, that raises a more general issue: shall this >document specify rules only for certificate validation or also for >certificate generation? Validation only. >My understanding of the scope that Kurt and I >inherited from JeffH and RL Bob is that the document specifies rules >only for validation, and even there only for a particular subset of >validation, namely matching of the server's presented identities against >the client's expected "reference identity" (e.g., not necessarily >mentioning anything about the fact that the certificate needs to be >certified by a chain of certificates terminating in a trust anchor). Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details are in 5280", but I don't think you even need that. >Personally I think that it would be helpful to specify rules about both >generation and validation (and about how the client should proceed if >validation in the broadest sense fails), but before expanding the scope >of the document I'd like to make sure that people here are comfortable >with doing so. It would be useful to say what to do when validation fails; you simply don't have to list all the PKIXy ways it can fail. From stpeter@stpeter.im Thu Aug 27 19:21:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0213A6B94 for ; Thu, 27 Aug 2009 19:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnqAlFpRCYzT for ; Thu, 27 Aug 2009 19:21:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 95FFC3A6A21 for ; Thu, 27 Aug 2009 19:21:42 -0700 (PDT) Received: from squire.local (dsl-175-240.dynamic-dsl.frii.net [216.17.175.240]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B3DF4007B for ; Thu, 27 Aug 2009 20:21:49 -0600 (MDT) Message-ID: <4A973F3C.1000907@stpeter.im> Date: Thu, 27 Aug 2009 20:21:48 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: [Fwd: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check] X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:21:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops, mistakenly sent to Paul only... - -------- Original Message -------- Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Date: Thu, 27 Aug 2009 20:20:54 -0600 From: Peter Saint-Andre To: Paul Hoffman References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> On 8/27/09 6:34 PM, Paul Hoffman wrote: > At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: >> Paul, I agree that this document needs to codify secure >> authentication practices. However, that raises a more general >> issue: shall this document specify rules only for certificate >> validation or also for certificate generation? > > Validation only. Works for me. >> My understanding of the scope that Kurt and I inherited from JeffH >> and RL Bob is that the document specifies rules only for >> validation, and even there only for a particular subset of >> validation, namely matching of the server's presented identities >> against the client's expected "reference identity" (e.g., not >> necessarily mentioning anything about the fact that the certificate >> needs to be certified by a chain of certificates terminating in a >> trust anchor). > > Correct. You might toss in a paragraph saying "of course, you need to > do full PKIX checking as well, details are in 5280", but I don't > think you even need that. Sure thing. >> Personally I think that it would be helpful to specify rules about >> both generation and validation (and about how the client should >> proceed if validation in the broadest sense fails), but before >> expanding the scope of the document I'd like to make sure that >> people here are comfortable with doing so. > > It would be useful to say what to do when validation fails; you > simply don't have to list all the PKIXy ways it can fail. Shamelessly borrowing from draft-ietf-xmpp-3920bis, the text describing "what to do when validation fails" might be as detailed as this... *** The outcome of the checking procedure is one of the following: Case #1: The client finds at least one presented identity that matches the reference identity; the entity MUST use this as the validated identity of the server. Case #2: The client finds no subjectAltName that matches the reference identity but a human user has permanently accepted the certificate during a previous connection attempt; the client MUST verify that the cached certificate was presented and MUST notify the user if the certificate has changed since the last time that a secure connection was successfully negotiated. Case #3: The client finds no subjectAltName that matches the reference identity and a human user has not permanently accepted the certificate during a previous connection attempt; the client MUST NOT use the presented identity (if any) as the validated identity of the server and instead MUST proceed as described in the next section. Instead, if the client is a user-oriented application, then it MUST either (1) automatically terminate the connection with a bad certificate error or (2) show the certificate (including the entire certificate chain) to the user and give the user the choice of terminating the connecting or accepting the certificate temporarily (i.e., for this connection attempt only) or permanently (i.e., for all future connection attempts) and then continuing with the connection; if a user permanently accepts a certificate in this way, the client MUST cache the certificate (or some non-forgeable representation such as a hash value) and in future connection attempts behave as in Case #2. (It is the resposibility of the human user to verify the hash value or fingerprint of the certificate with the peer over a trusted communication layer.) If the client is an automated application, then it SHOULD terminate the connection with a bad certificate error and log the error to an appropriate audit log; an automated application MAY provide a configuration setting that disables this check, but MUST provide a setting that enables the check. *** However, it's not clear to me if we really need to go into that level of detail. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXPzwACgkQNL8k5A2w/vy5kACg8BhWMB6KLUsQ7I2S1htazixZ jrMAoOljceiV0nuAOS3t6FNh9zsh4i1G =Yote -----END PGP SIGNATURE----- From phoffman@imc.org Thu Aug 27 19:29:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9B43A6963 for ; Thu, 27 Aug 2009 19:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.443 X-Spam-Level: X-Spam-Status: No, score=-5.443 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffLp0H8D+F6p for ; Thu, 27 Aug 2009 19:29:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C0EEA3A6858 for ; Thu, 27 Aug 2009 19:29:53 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7S2TwLm022437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 19:30:00 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A973F3C.1000907@stpeter.im> References: <4A973F3C.1000907@stpeter.im> Date: Thu, 27 Aug 2009 19:29:57 -0700 To: Peter Saint-Andre , "apps-discuss@ietf.org" From: Paul Hoffman Subject: Re: [Fwd: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check] Content-Type: text/plain; charset="us-ascii" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:29:54 -0000 At 8:21 PM -0600 8/27/09, Peter Saint-Andre wrote: >However, it's not clear to me if we really need to go into that level of >detail. We don't really need to go to that level, but I think it is quite appropriate, given that the desired result is guidance for developers who often get it wrong. From stpeter@stpeter.im Thu Aug 27 19:31:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD5A3A6858 for ; Thu, 27 Aug 2009 19:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG38-TrUn43j for ; Thu, 27 Aug 2009 19:31:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 311BF3A6963 for ; Thu, 27 Aug 2009 19:31:04 -0700 (PDT) Received: from squire.local (dsl-175-240.dynamic-dsl.frii.net [216.17.175.240]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EF4084007B; Thu, 27 Aug 2009 20:31:10 -0600 (MDT) Message-ID: <4A97416D.9000905@stpeter.im> Date: Thu, 27 Aug 2009 20:31:09 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Fwd: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check] References: <4A973F3C.1000907@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:31:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/27/09 8:29 PM, Paul Hoffman wrote: > At 8:21 PM -0600 8/27/09, Peter Saint-Andre wrote: >> However, it's not clear to me if we really need to go into that >> level of detail. > > We don't really need to go to that level, but I think it is quite > appropriate, given that the desired result is guidance for developers > who often get it wrong. That's my feeling. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXQW0ACgkQNL8k5A2w/vxIWACfV7MJ1wKo0OI4wYDZP1vVMK8n 6VMAn29Pom5LfZ/Yf9lTsug7MemOIsaD =Zuyh -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Aug 28 08:48:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470A728C3E4 for ; Fri, 28 Aug 2009 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Jai0WVvMAxo for ; Fri, 28 Aug 2009 08:48:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E23A528C406 for ; Fri, 28 Aug 2009 08:48:28 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4341F4007B; Fri, 28 Aug 2009 09:48:33 -0600 (MDT) Message-ID: <4A97FC50.2030007@stpeter.im> Date: Fri, 28 Aug 2009 09:48:32 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simon Josefsson Subject: Re: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt] References: <4A26FA6A.2060902@stpeter.im> <87ljo8s8pu.fsf@mocca.josefsson.org> In-Reply-To: <87ljo8s8pu.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:48:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Again, sorry about the delayed reply. On 6/4/09 2:29 AM, Simon Josefsson wrote: > Peter Saint-Andre writes: > >> FYI. All I did was update the references, change the title slightly, and >> update the authors. Feedback is welcome before we publish a version with >> more significant modifications. > > Generally, I agree a document like this is needed. Some suggestions: > > 1) Define all terminology in section 2. The term "reference identity" > is defined in section 3 but used in other sections too. Done in my working copy. > 2) Re 3.1, should the reference identity be considered a stored string > wrt IDNA? As I understand what reference identity refers to, it seems > like a query string to me. Could you perhaps elaborate your reasons for thinking so? JeffH and RL Bob wrote that text, so they can explain their reasoning better than I can. However, I note the following text from RFC 3454 regarding the distinction between stored strings and queries: In general, "stored strings" are strings that are used in protocol identifiers and named entities, such as names in digital certificates and DNS domain name parts. "Queries" are strings that are used to match against strings that are stored identifiers, such as user-entered names for digital certificate authorities and DNS lookups. .... The goal of the requirements in this section is to prevent comparisons between two strings that were both permitted to contain unassigned code points. When two strings X and Y are compared and string Y was prepared in a way that permits unassigned code points, a negative result to the comparison is not definitive; it's possible that the strings don't match even though they would match if a more recent version of the profile were used for Y. However, if both X and Y were prepared in a way that permits unassigned code points, something worse can happen: even a positive result for the comparison is not definitive. It is possible that the strings do match even though they would not match if a more recent version of the profile were used (one that prohibits a code point appearing in both X and Y). Due to the way that versioning is handled in this section, stored strings that are embedded in structures that cannot be changed (such as the signed parts of digital certificates) MUST NOT contain any unassigned code points. Given that (1) what I am now calling presented identities (i.e., the identities presented by the server in its X.509 certificate) are "embedded in structures that cannot be changed" and (2) RFC 3454 seems to be saying that a comparison must be made either between two stored strings or between two queries (not between a stored string and a query), I think the current text makes sense because we want to compare the reference identity to each presented identity and the latter will be stored strings, not queries. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqX/FAACgkQNL8k5A2w/vyYYwCgv3e/kycgZpN9INUu1q2MpQjz jzsAoIAZx1ZaaGhBUgIzvw1xUunplfFT =evup -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Aug 28 09:28:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCBD3A711A for ; Fri, 28 Aug 2009 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV1St-Akt0m4 for ; Fri, 28 Aug 2009 09:28:44 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 14DDC3A7122 for ; Fri, 28 Aug 2009 09:28:37 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA27A4007B; Fri, 28 Aug 2009 10:28:38 -0600 (MDT) Message-ID: <4A9805B5.7070505@stpeter.im> Date: Fri, 28 Aug 2009 10:28:37 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <20090608173324.GL1049@Sun.COM> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:28:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/8/09 11:59 AM, Paul Hoffman wrote: > At 12:33 PM -0500 6/8/09, Nicolas Williams wrote: >> A phase-out of certs with domain names in subjectName seems in >> order. > > Not at all. It is fine to have a certificate with a subject with a CN > of "www.example.com". That value follows the semantics for "common > name". Right, in this document we are not legislating what can go in a CN. However, my understanding is that we are saying that a client would not compare its reference identity against the string "www.example.com" as found in the CN. Correct? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqYBbUACgkQNL8k5A2w/vxpkwCfXoleWTQ7x8BFx9sf1RbISrH1 qEYAnjSJqYrnq7Bb6YVK79DLyt5IT4zo =pTxy -----END PGP SIGNATURE----- From phoffman@imc.org Fri Aug 28 09:39:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D8D3A6BB2 for ; Fri, 28 Aug 2009 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOEAgAccwxbO for ; Fri, 28 Aug 2009 09:39:34 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E69953A684B for ; Fri, 28 Aug 2009 09:39:33 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7SGddXX073952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 09:39:40 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A9805B5.7070505@stpeter.im> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <20090608173324.GL1049@Sun.COM> <4A9805B5.7070505@stpeter.im> Date: Fri, 28 Aug 2009 09:39:38 -0700 To: Peter Saint-Andre From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:39:34 -0000 At 10:28 AM -0600 8/28/09, Peter Saint-Andre wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 6/8/09 11:59 AM, Paul Hoffman wrote: >> At 12:33 PM -0500 6/8/09, Nicolas Williams wrote: >>> A phase-out of certs with domain names in subjectName seems in >>> order. >> >> Not at all. It is fine to have a certificate with a subject with a CN >> of "www.example.com". That value follows the semantics for "common >> name". > >Right, in this document we are not legislating what can go in a CN. >However, my understanding is that we are saying that a client would not >compare its reference identity against the string "www.example.com" as >found in the CN. Correct? Correct. The document is about how to find the identifier in an interoperable fashion, not what CAs need to do. From stpeter@stpeter.im Fri Aug 28 13:41:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45983A6B3A for ; Fri, 28 Aug 2009 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJfGk87kVOUM for ; Fri, 28 Aug 2009 13:41:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7F3CC3A6A78 for ; Fri, 28 Aug 2009 13:41:00 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E53AD4007B; Fri, 28 Aug 2009 14:40:52 -0600 (MDT) Message-ID: <4A9840D3.9030302@stpeter.im> Date: Fri, 28 Aug 2009 14:40:51 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> In-Reply-To: <4A2C1577.6060802@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "Kurt D. Zeilenga" , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:41:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/7/09 1:31 PM, Alexey Melnikov wrote: > Paul Hoffman wrote: > >> At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote: >> >> >>> Hi Paul, >>> >>> Paul Hoffman wrote: >>> >>>> Greetings again. I would like to argue that, from a security >>>> perspective, we should not allow looking up DNS names in the >>>> subjectName in PKIX certificates in this document. Section 3.1 says: >>>> The server's identity may also be verified by comparing the reference >>>> identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf >>>> Relative Distinguished Name (RDN) of the subjectName field of the >>>> server's certificate. This comparison is performed using the rules >>>> for comparison of DNS names in Section 3.1.3.1, below, with the >>>> exception that no wildcard matching is allowed. Although the use of >>>> the Common Name value is existing practice, it is deprecated, and >>>> Certification Authorities are encouraged to provide subjectAltName >>>> values instead. Note that the TLS implementation may represent DNs >>>> in certificates according to X.500 or other conventions. For >>>> example, some X.500 implementations order the RDNs in a DN using a >>>> left-to-right (most significant to least significant) convention >>>> instead of LDAP's right-to-left convention. >>>> >>>> That ambiguity leads to a fairly trivial identity attack >>>> >>> Can you elaborate on this? (A pointer to discussion elsewhere would >>> be fine as well.) >>> >> If there is a TLD that has the same name as the SLD that you want to >> attack, you can get a certificate that uses the CNs. For example, if >> you want to attack ar.com, you could register com.ar, get a >> certificate for it, and use it to fool systems that follow the rule in >> the last sentence above. This attack will get easier as more TLDs with >> names that exist as current SLDs are created in the coming years. >> > Paul, I missed your point entirely. Yes, this is indeed a concern. > > However I believe the text is talking about something else entirely. It > is talking about order of Relative DNs (RDNs). For example, a > subjectName for a domain might look like: > > cn=www.example.com, ou=Web Services, c=GB > > Here c=GB is the most significant RDN. What the text is saying is that > some X.500 implementations would represent it as > > c=GB, ou=Web Services, cn=www.example.com > > or something like this. Kurt can probably explain this better than I can. After puzzling over the text for a while, I agree that this is what it is trying to say (perhaps not very well). But as far as I can see, in the second example the client would not check the CN because it is not the leaf RDN. Or is the text saying that sometimes the leaf RDN might actually be right-most instead of left-most? > So there is no reordering of domains inside the CN value. Agreed. > [As a side note, if the document were allowing use of DC (domain > components) in subjectName, the problem you've identifier would have > been relevant: > dc=com, dc=ar, ou=Web Services, c=GB > versa > dc=ar, dc=com, ou=Web Services, c=GB > ] Yes, let's make it clear that DCs will not be checked. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqYQNMACgkQNL8k5A2w/vxfGgCgsMqN9acIc05zXoRt/+Pul7m7 E/UAoNkIJo3zicafd75CcecPK9iQUBLY =nHAw -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Fri Aug 28 13:56:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C753A6F4B for ; Fri, 28 Aug 2009 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fli+yfjM3mDz for ; Fri, 28 Aug 2009 13:56:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A29473A6D27 for ; Fri, 28 Aug 2009 13:56:18 -0700 (PDT) Received: from [92.40.87.106] (92.40.87.106.sub.mbb.three.co.uk [92.40.87.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 28 Aug 2009 21:56:24 +0100 Message-ID: <4A98445D.2060406@isode.com> Date: Fri, 28 Aug 2009 21:55:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:56:19 -0000 Paul Hoffman wrote: >At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: > > >>Paul, I agree that this document needs to codify secure authentication >>practices. However, that raises a more general issue: shall this >>document specify rules only for certificate validation or also for >>certificate generation? >> > >Validation only. > > I tend to agree. But generation has to match validation, so I don't see much practical difference. Unless I am missing some subtle point... >>My understanding of the scope that Kurt and I >>inherited from JeffH and RL Bob is that the document specifies rules >>only for validation, and even there only for a particular subset of >>validation, namely matching of the server's presented identities against >>the client's expected "reference identity" (e.g., not necessarily >>mentioning anything about the fact that the certificate needs to be >>certified by a chain of certificates terminating in a trust anchor). >> > >Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details are in 5280", > Agreed. >but I don't think you even need that. > > I think the reference to RFC 5280 needs to be normative for this document. >>Personally I think that it would be helpful to specify rules about both >>generation and validation (and about how the client should proceed if >>validation in the broadest sense fails), but before expanding the scope >>of the document I'd like to make sure that people here are comfortable >>with doing so. >> > >It would be useful to say what to do when validation fails; you simply don't have to list all the PKIXy ways it can fail. > > Agreed. From stpeter@stpeter.im Fri Aug 28 14:00:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1565628C330 for ; Fri, 28 Aug 2009 14:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8r7CxUbR-S9 for ; Fri, 28 Aug 2009 14:00:57 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2D4E228C2F8 for ; Fri, 28 Aug 2009 14:00:57 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F38CD4007B; Fri, 28 Aug 2009 15:01:03 -0600 (MDT) Message-ID: <4A98458E.207@stpeter.im> Date: Fri, 28 Aug 2009 15:01:02 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> <4A98445D.2060406@isode.com> In-Reply-To: <4A98445D.2060406@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:00:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/09 2:55 PM, Alexey Melnikov wrote: > Paul Hoffman wrote: > >> At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: >> >> >>> Paul, I agree that this document needs to codify secure authentication >>> practices. However, that raises a more general issue: shall this >>> document specify rules only for certificate validation or also for >>> certificate generation? >>> >> >> Validation only. >> >> > I tend to agree. But generation has to match validation, so I don't see > much practical difference. Unless I am missing some subtle point... This specification is not legislating how CAs MUST or MUST NOT generate certificates, only how clients MUST or MUST NOT check the identities that they find. The difference between encoding and decoding, I suppose. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqYRY4ACgkQNL8k5A2w/vz+FwCcCw6715HAnvJrGXgDLmTdFqIV m74AoNEiFFkNlXFdqcbDxDG3J2LB50m+ =ZcLL -----END PGP SIGNATURE----- From phoffman@imc.org Fri Aug 28 14:10:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31773A6C37 for ; Fri, 28 Aug 2009 14:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPuLpvb-JqFs for ; Fri, 28 Aug 2009 14:10:51 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AA2263A69DF for ; Fri, 28 Aug 2009 14:10:51 -0700 (PDT) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7SLAu2w091005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 14:10:58 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A98445D.2060406@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> <4A98445D.2060406@isode.com> Date: Fri, 28 Aug 2009 14:10:55 -0700 To: Alexey Melnikov From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:10:53 -0000 At 9:55 PM +0100 8/28/09, Alexey Melnikov wrote: >Paul Hoffman wrote: > >>At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: >> >> >>>Paul, I agree that this document needs to codify secure authentication >>>practices. However, that raises a more general issue: shall this >>>document specify rules only for certificate validation or also for >>>certificate generation? >>> >> >>Validation only. >> >> >I tend to agree. But generation has to match validation, so I don't see much practical difference. Unless I am missing some subtle point... Not subtle at all. Telling CAs what they should and should not put in certificates has been a complete failure in the past. Telling CAs what conformant implementations will do with their certificates should be / could be more effective. It also puts the onus on relying parties to actually read the certs in order to comply with the RFC, not to assume that the CA did anything special. From stpeter@stpeter.im Fri Aug 28 14:19:12 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FDB3A68F6 for ; Fri, 28 Aug 2009 14:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wi-lQmyghA4 for ; Fri, 28 Aug 2009 14:19:11 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D51443A6C3D for ; Fri, 28 Aug 2009 14:18:50 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 83AD94007B; Fri, 28 Aug 2009 15:18:55 -0600 (MDT) Message-ID: <4A9849BE.4050302@stpeter.im> Date: Fri, 28 Aug 2009 15:18:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A97183A.9090800@stpeter.im> <4A98445D.2060406@isode.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:19:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/09 3:10 PM, Paul Hoffman wrote: > At 9:55 PM +0100 8/28/09, Alexey Melnikov wrote: >> Paul Hoffman wrote: >> >>> At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote: >>> >>> >>>> Paul, I agree that this document needs to codify secure >>>> authentication practices. However, that raises a more general >>>> issue: shall this document specify rules only for certificate >>>> validation or also for certificate generation? >>>> >>> Validation only. >>> >>> >> I tend to agree. But generation has to match validation, so I don't >> see much practical difference. Unless I am missing some subtle >> point... > > Not subtle at all. Telling CAs what they should and should not put in > certificates has been a complete failure in the past. Telling CAs > what conformant implementations will do with their certificates > should be / could be more effective. It also puts the onus on relying > parties to actually read the certs in order to comply with the RFC, > not to assume that the CA did anything special. Yes, exactly. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqYSb4ACgkQNL8k5A2w/vxlAwCfXTd1BNgHpsAmNPOnPTZdn6My O0cAn37beriI83wEXyKVXCMs0PdA4feY =RXXk -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Fri Aug 28 14:29:03 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C783A6A9B for ; Fri, 28 Aug 2009 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyygTWBsbYJq for ; Fri, 28 Aug 2009 14:29:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D98F63A6DB4 for ; Fri, 28 Aug 2009 14:28:58 -0700 (PDT) Received: from [92.40.87.106] (92.40.87.106.sub.mbb.three.co.uk [92.40.87.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 28 Aug 2009 22:29:04 +0100 Message-ID: <4A984C01.2070400@isode.com> Date: Fri, 28 Aug 2009 22:28:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A9840D3.9030302@stpeter.im> In-Reply-To: <4A9840D3.9030302@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "Kurt D. Zeilenga" , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:29:03 -0000 Peter Saint-Andre wrote: >On 6/7/09 1:31 PM, Alexey Melnikov wrote: > > [...] >>However I believe the text is talking about something else entirely. It >>is talking about order of Relative DNs (RDNs). For example, a >>subjectName for a domain might look like: >> >> cn=www.example.com, ou=Web Services, c=GB >> >>Here c=GB is the most significant RDN. What the text is saying is that >>some X.500 implementations would represent it as >> >> c=GB, ou=Web Services, cn=www.example.com >> >>or something like this. Kurt can probably explain this better than I can. >> > >After puzzling over the text for a while, I agree that this is what it >is trying to say (perhaps not very well). But as far as I can see, in >the second example the client would not check the CN because it is not >the leaf RDN. Or is the text saying that sometimes the leaf RDN might >actually be right-most instead of left-most? > I think it is. >>So there is no reordering of domains inside the CN value. >> > >Agreed. > > > >>[As a side note, if the document were allowing use of DC (domain >>components) in subjectName, the problem you've identifier would have >>been relevant: >>dc=com, dc=ar, ou=Web Services, c=GB >>versa >>dc=ar, dc=com, ou=Web Services, c=GB >>] >> > >Yes, let's make it clear that DCs will not be checked. > Good. From ietf-discuss-apps@ninebynine.org Sat Aug 29 16:04:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69B23A6B11 for ; Sat, 29 Aug 2009 16:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVN9jp1T+HJm for ; Sat, 29 Aug 2009 16:04:18 -0700 (PDT) Received: from sbh14.songbird.com (sbh14.songbird.com [72.52.113.14]) by core3.amsl.com (Postfix) with ESMTP id ADCC23A6A00 for ; Sat, 29 Aug 2009 16:04:18 -0700 (PDT) Received: from tinos.zoo.ox.ac.uk (localhost.localdomain [127.0.0.1]) by sbh14.songbird.com (8.13.8/8.13.8) with ESMTP id n7Q8a69b001521 for ; Wed, 26 Aug 2009 01:36:11 -0700 Message-ID: <4A94415B.3060609@ninebynine.org> Date: Tue, 25 Aug 2009 20:54:03 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Apps Discuss Subject: Comments on draft-hixie-thewebsocketprotocol-35 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh14.songbird.com [127.0.0.1]); Wed, 26 Aug 2009 01:36:11 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 23:04:19 -0000 [I've tried sending this twice to the HYBI list, but for some reason it's not getting through (this doesn't augur well for traditional IETF values of openness). So I'm sending it here in the expectation that someone will be able to relay it to the proper forum. #g.] Dear all, re: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-35 [Summary: in its present form, a thumbs down.] I was prompted to review this spec by this comment posted to the W3C technical architecture group (TAG) mailing list: [[ What's the point of this new protocol? To bum a small constant in network performance? Seems shortsighted given the enormous amount of effort it takes to tool up for and specify a new protocol. Not to mention one that looks to essentially end a platform on which to build a further babel of ad hoc protocols. And considering Moores law. Definitely worth a review, if you ask me. URN versus URI seems the least issue here. ]] I thought this comment missed what I thought was the point, and that maybe it needed to be corrected. But on reading the spec in its current form, I can see why someone would say this. ... So, what's the problem, in two parts: (a) what problem is being solved? (b) what is the problem with the spec? My understanding of the problem to be solved, based on what I understand about the goals of HYBI, is that in its present form the Web has no common way to "push" information to a browser application. There are a number of solutions/workarounds based on HTTP long-polling or variants, but these have variousbproblems with proxies, etc., and there is as yet no single accepted solution. My expectation is that the websockets protocol proposes to be such a solution. I think the specification, in its current form, completely fails to present itself as such a solution. To me, it reads less like an open protocol specification, and rather more like a programming team internal design memo. From reading it, I can't tell if it addresses the problem I expected it to address. It seems to me that you need to understand websockets in some detail in order to understand this spec with a reasonable amount of effort - I want to be able to pick out the "high points" on a single read though, but instead I find myself plunged into a level of detail that I can't relate to. For example, take the very first sentence of the Introduction (sic): "The Web Socket protocol is designed on the principle that there should be minimal framing (the only framing that exists is to make the protocol frame-based instead of stream-based, and to support a distinction between Unicode text and binary frames)" - this very first sentence introduces a number of lower-level techncial issues (framing, frame-based, stream-based, unicode text, binary frames) without providing any context. Even the abstract isn't very helpful here (the second sentence, starting with "It is intended to fail ..." doesn't exactly engender confidence). None of this means that I think this is a bad protocol: the truth is, I can't tell if it is or not. So, yes, my comments could be construed as being about style rather than substance, but if we're in the business of forging consensus I think some consideration needs to be given to the readers of a specification in order to get meaningful review. I'll try and make a few suggestions, which I don't claim are best or complete: 1. Provide some context and motivation. Start the introduction by stating the problem that is being solved, and why it is not solved by existing standard protocols. Also, alomng the way, it might be worth mentioning efforts like cometd/bayeux and BOSH and saying how this proposal is similar and/or different. 2. Indicate some specific types of applications for which the problem exists (my favourites include: real-time web page updates, synchronization of displays between multiple web pages, on-the-fly persisting of user interactions, ...). 3. [nit] Abstract: talk about "graceful fallback" instead of "intended to fail" 4. Introduce key concepts before delving into details about them: I don't mean in textboook fashion, but indicating how they relate to the problem at hand (e.g. why is framing an issue, how does it relate to Unicode bvs binary data?). 5. Move most of the current "introduction" text into a high-level protocol description section. 6. Provide a protocol state diagram or similar overview. 7. Section 3: why is this based on [WEBADDRESSES] rather than [RFC3986]? I can't offhand tell if [WEBADDRESSES] is acceptable as a normative reference. I have not read sections 4 and 5 in detail, as they seem to be concerned entirely with very low-level and rather wordy protocol processing descriptions, but I find myself asking: why not just specify a hand-off extension to HTTP that allows bidirectional communication to proceed using a protocol such as BEEP? I fear there's a certain amount of reinvention going on here. But I could be wrong. I wish I could be more constructive, but in its present form I can't see anything that helps me in this current specification. Maybe this can be improved, as I think the goals of HYBI are important. #g From stpeter@stpeter.im Mon Aug 31 15:06:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0A728C52D for ; Mon, 31 Aug 2009 15:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un3yH9hGAFgz for ; Mon, 31 Aug 2009 15:06:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 070F128C258 for ; Mon, 31 Aug 2009 15:06:24 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99C254007B for ; Mon, 31 Aug 2009 16:06:34 -0600 (MDT) Message-ID: <4A9C4969.2020200@stpeter.im> Date: Mon, 31 Aug 2009 16:06:33 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: new version of server identity draft X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:06:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new version of draft-saintandre-tls-server-id is now available: http://www.ietf.org/id/draft-saintandre-tls-server-id-check-01.txt I've attempted to incorporate all feedback provided on this list, but I have not yet had a chance to look at all of the existing work in this area so I am sure that further edits will be forthcoming. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqcSWkACgkQNL8k5A2w/vysLwCgt6ZG1zmYO/usOoc7wvCLcSH7 ot0An3+I+jIg9CVVNcpvRTP/j3heBebu =Gub0 -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Mon Aug 31 15:44:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3943A6B1E for ; Mon, 31 Aug 2009 15:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTyYwfRj8Ry2 for ; Mon, 31 Aug 2009 15:44:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1E5673A68E5 for ; Mon, 31 Aug 2009 15:42:20 -0700 (PDT) Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 31 Aug 2009 23:42:30 +0100 Message-ID: <4A9C51CF.4050009@isode.com> Date: Mon, 31 Aug 2009 23:42:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss , alexey-melnikov-chairs@tools.ietf.org Subject: Alexey's Apps Area Activity Report for July-August 2009 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:44:22 -0000 Please let me know if you think the information below is not accurate. ============================================== Document Status and Progress: Active documents, my action: - draft-ietf-webdav-bind (Experimental) - need to address 2 DISCUSSes (Cullen, Robert), in particular about the document "updating the base WebDAV spec". - draft-reschke-rfc2731bis (None) - need to decide what to do with this document, in particular I am missing information about why RFC 2731 was published as Informational and who was the responsible AD. - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - deciding if I will sponsor this document. Need to tell authors results of an informal review. Active documents in IETF LC or IESG review: - draft-daboo-srv-email (Proposed Standard) - in IETF LC - draft-ietf-eai-imap-utf8 (Experimental) - IETF LC ended, hopefully will be reviewed by IESG on September 10th. In RFC Editor's queue: - draft-ietf-vcarddav-webdav-mkcol (Proposed Standard) - draft-hollenbeck-rfc493*bis (Full Standard) - in AUTH48 - draft-ietf-lemonade-streaming (Informational) - in AUTH48 - draft-ietf-ltru-4645bis (Informational) - in AUTH48 - draft-ietf-ltru-4646bis (BCP) - in AUTH48 Published as RFCs: - draft-ietf-lemonade-notifications (Informational) - RFC 5551 - draft-crocker-email-arch (Informational) - RFC 5598 Active documents, waiting on others: - draft-dusseault-http-patch (Unknown) - waiting for shepherding write-up before requesting IETF LC - draft-duerst-mailto-bis - performed AD-style review, waiting for revised document before deciding how to progress it - draft-ietf-eai-pop (Experimental) - new revision needed to address AD review - draft-ietf-eai-downgraded-display (Experimental) - new revision needed to address AD review and comments from Harald Alvestrand - draft-ietf-vcarddav-carddav (Proposed Standard) - waiting for the author to respond to my AD review before deciding if the document should be revised or sent to IETF LC - draft-klensin-ftp-registry (Proposed Standard) - waiting for new revision after my AD review. - draft-cridland-acap-vendor-registry (Proposed Standard) - presented the draft during the Apps Area meeting in Stockholm. New revision needed. - draft-ietf-sieve-mime-loop (Proposed Standard) [as document shepherd] - waiting for the Sieve WG to come to consensus on the last remaining change to address Tim Polk's DISCUSS. List of DISCUSSes I am currently holding: Really Old (over 2 months): draft-ietf-bfd-base-09.txt draft-ietf-ipfix-file-03.txt draft-ietf-ipfix-exporting-type-04.txt draft-ietf-ntp-ntpv4-proto-11.txt draft-mraihi-inch-thraud-08.txt draft-ietf-mmusic-sdp-capability-negotiation-10.txt draft-ietf-avt-rtcpssm-18.txt Old (3 weeks - 2 months): draft-ietf-nea-pb-tnc-04.txt - talked to NEA WG chairs in Stockholm about resolution. A way forward was agreed. New or recently updated (last 3 weeks week): draft-ietf-netconf-partial-lock-09.txt draft-ietf-dime-diameter-qos-11.txt draft-ietf-ipfix-export-per-sctp-stream-03.txt draft-housley-tls-authz-extns-07.txt draft-ietf-ntp-dhcpv6-ntp-opt-04.txt draft-ietf-ospf-hmac-sha-06.txt draft-ietf-ospf-manet-or-02.txt draft-ietf-ltans-dssc-09.txt [updated] draft-wilde-sms-uri-19.txt [updated] draft-ietf-geopriv-http-location-delivery-16.txt [updated] draft-ietf-nea-pa-tnc-05.txt [updated] draft-rosenberg-sip-app-media-tag-03.txt [for next week] Other activities/actions: Done: - draft-ietf-sasl-scram (my own document) is finally in Publication Requested state (Pasi is the responsible AD) - draft-ietf-sieve-external-lists (my own document) - posted 2 revisions (1 before Stockholm, 1 after) - Reviewed and approved some of errata for documents in scope for the YAM WG - initiated call for nominations for 4646bis IANA Expert Reviewer Ongoing: - Request to review 1 new MIME type registration (some activity on the first 2): - Request for registration for 3gpp-ims+xml: discussion with 3GPP people about the best way to address IESG concern on stability of references - OGPX chartering discussion - Discussing possible BOFs for Hiroshima (HTTP State management, StringPrep, Generic Referral Objects (GROBJ), timezone registry) My action: - Need to finish IMAP Keyword registry document (Lisa agreed to sponsor the document) - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG Status: 1) EAI - active discussion about how to move Experimental documents to Standard Track (timeline, criteria) and on whether the downgrade document needs to be a part of the set moved to Standard Track. Some discussion about EAI IMAP, POP and downgraded display documents going to IETF LC/IESG review. 2) Lemonade [In shutting down state] - 1 remaining document is in AUTH48 3) LTRU - the 2 remaining documents are in AUTH48 4) MORG - some discussions with chairs about getting SORTDISPLAY and STATUS-in-LIST published 5) VCARDDAV - draft-ietf-vcarddav-webdav-mkcol-06.txt approved for publication. AD review of vCardDAV. Discussion about mapping of vCard to XML. 6) YAM - discussion about IESG review template for 8BITMIME document