From pgut001@cs.auckland.ac.nz Sat May 2 02:39:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54B43A68E2 for ; Sat, 2 May 2009 02:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_50=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubxaqfXoaNY3 for ; Sat, 2 May 2009 02:39:23 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id E667E3A68EC for ; Sat, 2 May 2009 02:39:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 94A249EBFF; Sat, 2 May 2009 21:40:41 +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 s84cLQeiQO0f; Sat, 2 May 2009 21:40:41 +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 1763A9F21A; Sat, 2 May 2009 21:40:40 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 593461DE4001; Sat, 2 May 2009 21:40:40 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1M0Bi4-0006y0-6o; Sat, 02 May 2009 21:40:40 +1200 From: Peter Gutmann To: frantz@pwpconsult.com, tls@ietf.org In-Reply-To: Message-Id: Sender: pgut001 Date: Sat, 02 May 2009 21:40:40 +1200 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 02 May 2009 09:39:23 -0000 Bill Frantz writes: >When I think of the reasons that NSA/DOD could have for requiring AES-128 for >secret and AES-192 for top secret, I think they may be looking at the whole >cryptographic system. They're also looking at the whole political system. During a discussion among crypto geeks some years ago someone from some branch of the USG involved with crypto said that they were under a lot of pressure from govt-agency consumers of crypto who were used to commercial products with keys that went up to 10, 11, and 12. Having a single key size of (say) 128 bits would look bad when those same govt-agency consumers could go out and buy commercial products that were obviously stronger than the proposed government standard because they had larger numbers behind the algorithm name. So although there wasn't any immediate technical reason to use larger keys, if there wasn't a capability in AES for keys to go to 11 or 12 then it would look bad compared to non-govt- approved crypto. I don't know how much influence that had on the final decision, but given the choice between having to explain for the rest of my life to one govt.agency after another that 128 bits is good enough, and simply letting them choose keys that go to 11 if it makes them feel better, I know which one I'd choose. Peter. From uri@ll.mit.edu Sun May 3 08:42:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C743A6989 for ; Sun, 3 May 2009 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8o6iErV6oy4 for ; Sun, 3 May 2009 08:42:16 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id C005D3A6B2A for ; Sun, 3 May 2009 08:42:16 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n43FhQ37012486 for ; Sun, 3 May 2009 11:43:26 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA7Ra4py; Sun May 3 11:42:51 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sun, 3 May 2009 11:42:51 -0400 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Sun, 3 May 2009 11:42:49 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnLCjRusRp8GW8nS3uxlnpkePF4OQA+5teS Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C62333B944AAurillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 03 May 2009 15:42:24 -0000 --_000_C62333B944AAurillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While this certainly makes a nice tea-table story, I question the "historic= al truthfulness" of it. YOU may need to explain things to YOUR customers (and make them understand)= , lest they feel mistreated and go to another vendor. I don't think USG age= ncies have the same luxury of choosing their own crypto policy provider and= product approver! The pressure usually is applied the other way (the "othe= r" agency says "we want/need this", and the "crypto" branch responds "nonet= heless you shall use that, and we cannot reveal to you why"). P.S. AES competition had entries with variable key sizes, I think up to 512= bits. Did it look bad - selecting an algorithm with lower maximum key leng= th? No agency complained loud enough for us to hear, I guess? P.P.S. If you choose so, you can define AES with independent subkeys, using= PRNG to generate keys for each round from a given seed of any length you s= elect (say 302 bits?). :-) P.P.P.S. KGB's encryption standard - "GOST" - was released in 1981 or 1983 = (internally!) for "sensitive but unclassified" data and had 256-bit key. De= sign allowed independent subkeys of 512 bits (if memory serves me). And tha= t's on a 64-bit block cipher... On 5/2/09 05:40 , "Peter Gutmann" wrote: Bill Frantz writes: >When I think of the reasons that NSA/DOD could have for requiring AES-128 = for >secret and AES-192 for top secret, I think they may be looking at the whol= e >cryptographic system. They're also looking at the whole political system. During a discussion am= ong crypto geeks some years ago someone from some branch of the USG involved wi= th crypto said that they were under a lot of pressure from govt-agency consume= rs of crypto who were used to commercial products with keys that went up to 10= , 11, and 12. Having a single key size of (say) 128 bits would look bad when those same govt-agency consumers could go out and buy commercial products t= hat were obviously stronger than the proposed government standard because they = had larger numbers behind the algorithm name. So although there wasn't any immediate technical reason to use larger keys, if there wasn't a capability= in AES for keys to go to 11 or 12 then it would look bad compared to non-govt- approved crypto. I don't know how much influence that had on the final decision, but given t= he choice between having to explain for the rest of my life to one govt.agency after another that 128 bits is good enough, and simply letting them choose keys that go to 11 if it makes them feel better, I know which one I'd choos= e. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Regards, Uri --_000_C62333B944AAurillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Comparative cipher suite strengths While this certainly makes a nice tea-table story, I question the = 220;historical truthfulness” of it.

YOU may need to explain things to YOUR customers (and make them understand)= , lest they feel mistreated and go to another vendor. I don’t think U= SG agencies have the same luxury of choosing their own crypto policy provid= er and product approver! The pressure usually is applied the other way (the= “other” agency says “we want/need this”, and the &= #8220;crypto” branch responds “nonetheless you shall use that, = and we cannot reveal to you why”).

P.S. AES competition had entries with variable key sizes, I think up to 512= bits. Did it look bad – selecting an algorithm with lower maximum ke= y length? No agency complained loud enough for us to hear, I guess?

P.P.S. If you choose so, you can define AES with independent subkeys, using= PRNG to generate keys for each round from a given seed of any length you s= elect (say 302 bits?).  :-)

P.P.P.S. KGB’s encryption standard – “GOST” –= was released in 1981 or 1983 (internally!) for “sensitive but unclas= sified” data and had 256-bit key. Design allowed independent subkeys = of 512 bits (if memory serves me). And that’s on a 64-bit block ciphe= r...


On 5/2/09  05:40 , "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:

Bill Frantz <frantz@pwpconsult.com> writes:

>When I think of the reasons that NSA/DOD could have for requiring AES-1= 28 for
>secret and AES-192 for top secret, I think they may be looking at the w= hole
>cryptographic system.

They're also looking at the whole political system.  During a discussi= on among
crypto geeks some years ago someone from some branch of the USG involved wi= th
crypto said that they were under a lot of pressure from govt-agency consume= rs
of crypto who were used to commercial products with keys that went up to 10= ,
11, and 12.  Having a single key size of (say) 128 bits would look bad= when
those same govt-agency consumers could go out and buy commercial products t= hat
were obviously stronger than the proposed government standard because they = had
larger numbers behind the algorithm name.  So although there wasn't an= y
immediate technical reason to use larger keys, if there wasn't a capability= in
AES for keys to go to 11 or 12 then it would look bad compared to non-govt-=
approved crypto.

I don't know how much influence that had on the final decision, but given t= he
choice between having to explain for the rest of my life to one govt.agency=
after another that 128 bits is good enough, and simply letting them choose<= BR> keys that go to 11 if it makes them feel better, I know which one I'd choos= e.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 16:24:48 -0000 Hello and sorry for the very late reply, I have some questions and comments made by me to make sure I understand well (inline). Correct me if anything is not ok. > As an authentication mechanism, the main goal of FOAF+SSL is to bind the > client to the URI (of a foaf:Agent), in the same way as the client would = be > bound to a Subject DN in a PKI. > In short, FOAF+SSL certificates are X.509 certificates that contain a pub= lic > key and foaf:Agent URI in its subject alternative name extension; more or > less all the rest is ignored. (For people not familiar with FOAF, > foaf:Person is a subclass of foaf:Agent that models a person, for example= .) By ignoring the rest I suppose that you don't sign the certificate, and it is used merely as a container for the URI? > To compare FOAF+SSL and PKI: what binds the client to a Subject DN is bot= h > (a) the TLS handshake (which links the client the holder of the private k= ey > matching the public key in the client cert) and (b) the verification of t= he > actual certificate (certification path to trust anchor, etc.) So this part was for X.509 PKI that the client certificate is signed and verified... > FOAF+SSL also uses the fact that the client presents both an identity cla= im > (its foaf:Agent URI in the client certificate instead of an X.500 Subject > DN) and the public key (which matches the private key the client actually > has). Only the evaluation of trust in the client-certificate changes. At > this stage, whether the client certificate is self-signed or signed by > another party isn't particularly important, since it's not what's used to > verify its content. So as far as I understand the certificate is just an identity claim. What is the reason for this to be sent using a TLS client certificate? Couldn't be just a cookie (if talking about http). > There are two ways of verifying the certificate in FOAF+SSL, and the > security offerings are significantly different: dereferencing and > cryptographic web-of-trust. So this is verification on whether the one sending the foaf url is the one who claims to be? > A. Dereferencing > > Dereferencing is the main method explained on Henry's blog [1][2]. (I sho= uld > point out that Henry's use of "web of trust" is more about how individual= s > link to each other in a social network and doesn't necessarily involve > signing those assertions, as in OpenPGP, which makes it somewhat differen= t > from a "cryptographic" web of trust). > > It works as follows: > =A01. The client presents a certificate (self-signed or not) that contain= s a > URI (such as , a foaf:Agent), and a public key= . > =A02. The server dereferences this URI (i.e. does an HTTP GET) and proces= ses > the content of the document, which will contain a public key associated t= o > this URI. > =A03. If the public key in the dereferenced document for this URI and the > public key in the client certificate match, then the verification is > successful. > The security of this verification model depends on how much the > authenticating server can trust the authenticity of document that was > obtained by dereferencing the URI. In particular, it must trust the serve= r > certificate of 'romeo.example' and the fact that no one tampered with the > file on that server. Ok, thus the whole security lies on the URI dereference by the server. It's like having some central authorities to verify identities. > This level of security is suitable for some applications, but probably no= t > all. What do you mean by level? Do you mean that this is of lower security level= ? > B. Cryptographic web of trust > > I've talked a bit more about this on my own blog [3]. It's possible to si= gn > sub-graphs asserting the links between an ID (the URI) and a public key. > This way, one could have a set of trust anchors under the form of a > local/trusted FOAF file (or something else) against which to evaluate a > certificate (=E0 la OpenPGP). Similarly, a hierarchical model could be bu= ilt. > The level of assurance here depends on how much you trust the trust ancho= rs > and potential introducers; it's likely to be greater than with the > dereferencing method. This really reminds me of openpgp. Why not use openpgp certificates instead? As I see below that reason was to able to work on current infrastructure? > The security levels are quite flexible, and systems using FOAF+SSL for > authentication and authorisation ought to be configured according to the > requirements of the application (like any system, I suppose). When we say > that FOAF+SSL is a secure protocol, we really ought to qualify that > assertion. So I suppose that the security levels you are referring are the openpgp web of trust verification parameters? > The advantage of the FOAF+SSL approach (putting the information in an X.5= 09 > certificate as opposed to creating another type of certificate) is that t= his > works without modifying the implementation of SSL/TLS stacks. The only > changes required are in the customisation of the evaluation of trust in a > client certificate. > This requires some specific configuration in the application, but no chan= ges > of the SSL-related libraries themselves if they have such hooks (JSSE and > OpenSSL work, at least). In fact, for development purposes, we've accept = any > certificate during the handshake and do the verification at the applicati= on > level. Clear. > The original questions that Henry sent were related to the way the browse= r > chooses a certificate (or asks the user to choose). Because the FOAF+SSL > certificate is self-signed, the server has to be configured with an empty > list of CAs in the CertificateRequest. This is the same problem as the on= e > addressed in Section 3.4 of RFC 5081 [4]. I cannot help on that it is too browser specific and I don't think there is a uniform way not even across different release versions of the some client. > To make the choice of certificate easier in the browser, we had thought o= f > having an "open CA", for which we would distribute the private key openly= , > just for the sake of making the servers add that CA in the > CertificateRequest list. I've since realised that we don't really need th= at, > since only the name matters: we could just make the server ask for a > conventional name and the self-signed client certificate would have that > issuer name [5]. Of course, this wouldn't be compliant with RFC 5280 [6]. Why? Where does it contradict? I suppose that you mean to send a common dummy CA DN name and all foaf certificates would be signed using that DN. Sounds legal, since you are not deploying CA compliant with PKIX. > We would be interested in feedback regarding this approach, in particular > whether this would break with further versions of TLS. It is a hack, but since it plays with the rules it works and should work in the future (TLS doesn't really care about the contents of the certificates or how verification is being done). regards, Nikos From n.mavrogiannopoulos@gmail.com Sun May 3 09:26:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256F73A6FAE for ; Sun, 3 May 2009 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UKPYbVmwLpM for ; Sun, 3 May 2009 09:26:40 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 934583A70D0 for ; Sun, 3 May 2009 09:26:38 -0700 (PDT) Received: by bwz7 with SMTP id 7so3211813bwz.37 for ; Sun, 03 May 2009 09:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pIpMjaPWVsveWE1KZyTvwujFEQOriq2xuHqNi+1vehQ=; b=FHZsJ59ALMBoddHiNrGJVzUwZ9OmaoO/SDdLHdE7Nfgv/G/3FfAW9w5JGUtTAS1JX0 Qjts8CHWUzVlGZOC61d3eZesqHCl4IKptuQVWC5KIKyA4La7yEtZuJcNgF5uVEhEYx8j hCv5VIh4OC5PEQ4+hoB0pZ1XDGx71574ptzaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LfhvF7Lp8yhOyeFEu24eydJi4VSw2dn9D7RNDSNJh4nswepBYIRi+fje96RXiKKeka EShKLwlngDvZm/r3PThcPECLS6WJ1coF8EPQ6+lZuWoeAIzuM50WT88czCjFBHdFtzr+ VhJ1xhNW0dOR9DZf2zvbt5GBjLKRTuQLrbyuk= MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.204.77.67 with SMTP id f3mr4780698bkk.75.1241368080939; Sun, 03 May 2009 09:28:00 -0700 (PDT) In-Reply-To: References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org> <49F1C9B7.9060504@manchester.ac.uk> Date: Sun, 3 May 2009 19:28:00 +0300 X-Google-Sender-Auth: de7dcfca7671d9c2 Message-ID: From: Nikos Mavrogiannopoulos To: Bruno Harbulot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 03 May 2009 16:26:41 -0000 > So as far as I understand the certificate is just an identity claim. > What is the reason for this to be sent using a TLS client certificate? > Couldn't be just a cookie (if talking about http). Please ignore this question. It is made clear by the text below that you use the public key parameters. I just forgot to delete this part. regards, Nikos From Henry.Story@Sun.COM Sun May 3 09:58:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B014F3A70FF for ; Sun, 3 May 2009 09:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.517 X-Spam-Level: X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_20=-0.74, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dka5aVRFiBH8 for ; Sun, 3 May 2009 09:58:01 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 0F3FB3A7111 for ; Sun, 3 May 2009 09:57:51 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n43Gx9Em019687 for ; Sun, 3 May 2009 16:59:13 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ200G00UY9KL00@fe-emea-10.sun.com> for tls@ietf.org; Sun, 03 May 2009 17:59:09 +0100 (BST) Received: from [192.168.0.2] ([unknown] [88.163.1.232]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ2008AOV6FFN40@fe-emea-10.sun.com>; Sun, 03 May 2009 17:59:09 +0100 (BST) Date: Sun, 03 May 2009 18:58:52 +0200 From: Henry Story In-reply-to: Sender: Henry.Story@Sun.COM To: Nikos Mavrogiannopoulos Message-id: X-Mailer: Apple Mail (2.930.3) References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org> <49F1C9B7.9060504@manchester.ac.uk> Cc: tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] [foaf-protocols] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 03 May 2009 16:58:02 -0000 Hi Nikos, the paper has now been finalised and should be available http://spot2009.semanticweb.org/papers soon. In the mean time I have made it available here: http://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf On 3 May 2009, at 18:26, Nikos Mavrogiannopoulos wrote: > Hello and sorry for the very late reply, > I have some questions and comments made by me to make sure I > understand well (inline). Correct me if anything is not ok. >> As an authentication mechanism, the main goal of FOAF+SSL is to >> bind the >> client to the URI (of a foaf:Agent), in the same way as the client >> would be >> bound to a Subject DN in a PKI. >> In short, FOAF+SSL certificates are X.509 certificates that contain >> a public >> key and foaf:Agent URI in its subject alternative name extension; >> more or >> less all the rest is ignored. (For people not familiar with FOAF, >> foaf:Person is a subclass of foaf:Agent that models a person, for >> example.) > > By ignoring the rest I suppose that you don't sign the certificate, > and it is used merely as a container for the URI? I am not sure if it is possible in TLS have non signed certificates... What is sure is that the User's public key published in the certificate has to be able to verify the TLS communication sent by the user when he signs stuff with his private key. This is what ties the user to the public key. >> To compare FOAF+SSL and PKI: what binds the client to a Subject DN >> is both >> (a) the TLS handshake (which links the client the holder of the >> private key >> matching the public key in the client cert) and (b) the >> verification of the >> actual certificate (certification path to trust anchor, etc.) > > So this part was for X.509 PKI that the client certificate is signed > and verified... > >> FOAF+SSL also uses the fact that the client presents both an >> identity claim >> (its foaf:Agent URI in the client certificate instead of an X.500 >> Subject >> DN) and the public key (which matches the private key the client >> actually >> has). Only the evaluation of trust in the client-certificate >> changes. At >> this stage, whether the client certificate is self-signed or signed >> by >> another party isn't particularly important, since it's not what's >> used to >> verify its content. > > So as far as I understand the certificate is just an identity claim. > What is the reason for this to be sent using a TLS client certificate? > Couldn't be just a cookie (if talking about http). Well it is an identity claim, that comes with both an Identity, and a statement of a public key. The two together do the work of identifying the end user. The paper goes into the reasoning a server will follow in order to come to accept the identity claim. Henry From jwkckid1@ix.netcom.com Sun May 3 18:49:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AB43A6B4D for ; Sun, 3 May 2009 18:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=1.573, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgIivzcoZ-lW for ; Sun, 3 May 2009 18:49:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id E9A783A6B24 for ; Sun, 3 May 2009 18:49:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ldLsl8jWwvbNXgw7AeEcaTs9ynXvrFRLJe5YeKvyYmimjSY1r78gMFBspuDQlLxo; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.100.18] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M0nKb-00012y-0R; Sun, 03 May 2009 21:50:58 -0400 Message-ID: <49FE49F2.F8CA49A3@ix.netcom.com> Date: Sun, 03 May 2009 18:50:42 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Blumenthal, Uri" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688bab1744b36d25b2cd4f6e2bbdb1d125d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.100.18 Cc: "tls@ietf.org" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 04 May 2009 01:49:39 -0000 Uri and all, FWIW, I believe you have captured the situation spot on, unfortunately. "One size fits all" seems to be USG's approach to nearly every situation when it comes to security along with other areas of consideration or interest. "Blumenthal, Uri" wrote: > While this certainly makes a nice tea-table story, I question the > “historical truthfulness” of it. > > YOU may need to explain things to YOUR customers (and make them > understand), lest they feel mistreated and go to another vendor. I > don’t think USG agencies have the same luxury of choosing their own > crypto policy provider and product approver! The pressure usually is > applied the other way (the “other” agency says “we want/need this”, > and the “crypto” branch responds “nonetheless you shall use that, and > we cannot reveal to you why”). > > P.S. AES competition had entries with variable key sizes, I think up > to 512 bits. Did it look bad – selecting an algorithm with lower > maximum key length? No agency complained loud enough for us to hear, I > guess? > > P.P.S. If you choose so, you can define AES with independent subkeys, > using PRNG to generate keys for each round from a given seed of any > length you select (say 302 bits?). :-) > > P.P.P.S. KGB’s encryption standard – “GOST” – was released in 1981 or > 1983 (internally!) for “sensitive but unclassified” data and had > 256-bit key. Design allowed independent subkeys of 512 bits (if memory > serves me). And that’s on a 64-bit block cipher... > > > On 5/2/09 05:40 , "Peter Gutmann" wrote: > > Bill Frantz writes: > > >When I think of the reasons that NSA/DOD could have for > requiring AES-128 for > >secret and AES-192 for top secret, I think they may be > looking at the whole > >cryptographic system. > > They're also looking at the whole political system. During > a discussion among > crypto geeks some years ago someone from some branch of the > USG involved with > crypto said that they were under a lot of pressure from > govt-agency consumers > of crypto who were used to commercial products with keys > that went up to 10, > 11, and 12. Having a single key size of (say) 128 bits > would look bad when > those same govt-agency consumers could go out and buy > commercial products that > were obviously stronger than the proposed government > standard because they had > larger numbers behind the algorithm name. So although there > wasn't any > immediate technical reason to use larger keys, if there > wasn't a capability in > AES for keys to go to 11 or 12 then it would look bad > compared to non-govt- > approved crypto. > > I don't know how much influence that had on the final > decision, but given the > choice between having to explain for the rest of my life to > one govt.agency > after another that 128 bits is good enough, and simply > letting them choose > keys that go to 11 if it makes them feel better, I know > which one I'd choose. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Uri > > > ---------------------------------------------------------------- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 From stefan@aaa-sec.com Mon May 4 03:26:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C96B3A67FC for ; Mon, 4 May 2009 03:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxbDYj6tER8n for ; Mon, 4 May 2009 03:26:44 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 2ADB33A6B66 for ; Mon, 4 May 2009 03:26:38 -0700 (PDT) Received: (qmail 37786 invoked from network); 4 May 2009 10:28:05 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 May 2009 10:28:05 -0000 Received: (qmail 83816 invoked from network); 4 May 2009 10:28:01 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 May 2009 10:28:01 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 04 May 2009 12:27:59 +0200 From: Stefan Santesson To: , Nagendra Modadugu Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcnMov7lHNmUHX9kz0SXz1LF6sshaw== In-Reply-To: <200904290114.n3T1EI4h003479@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: stefans@exmsft.com, TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 04 May 2009 10:26:45 -0000 Generally I would like to avoid things that prevents this from being as simple as possible. Reading Martin's reply I don't feel this would be a suitable amendment. /Stefan On 09-04-29 3:14 AM, "Martin Rex" wrote: > Nagendra Modadugu wrote: >> >> I'm joining the discussion a little bit late. Is there still time to >> consider 1-RTT version of the full-handshake described in "Fast-Track" >> paper? (i.e. client sends the ClientKeyExchange message speculatively before >> receiving the ServerHello). > > To me, this looks more like a flawed assumption rather than a > "speculative action", because it is impossible to recover. > > The idea behind the short cuts is that the server can continue > with the full handshake if the shortcut is not available for > whatever reason. Sending a ClientKeyExchange based on > assumptions what the contents of the ServerHello will be > precludes the Server from making decisions to which it is > entiteled in the original TLS protocol, and the result can > easily be a fatal error, which means that the network communication > channel must be closed and reopened -- a recovery at the > TLS protocol level is impossible. > > > Having the Client send (protected) application data optimistically > following the Client Finished message without waiting for the > Server Finished seems like an acceptable optimization > if you badly need to cut down the number of round trips. > > Such an optimization, however, may have a significant impact > on the semantics of SSL_connect for APIs like that of OpenSSL. > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Martin.Rex@sap.com Mon May 4 07:48:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5A23A6B18 for ; Mon, 4 May 2009 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IIlZu5oMxl8 for ; Mon, 4 May 2009 07:48:21 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 94C3E3A6A59 for ; Mon, 4 May 2009 07:48:21 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n44EnisH023023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 16:49:44 +0200 (MEST) From: Martin Rex Message-Id: <200905041449.n44Eni9x021957@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 4 May 2009 16:49:43 +0200 (MEST) In-Reply-To: <20090501055009.3857D19668A@kilo.networkresonance.com> from "Eric Rescorla" at Apr 30, 9 10:50:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 04 May 2009 14:48:22 -0000 Eric Rescorla wrote: > > At Thu, 30 Apr 2009 18:56:35 -0700, > Bill Frantz wrote: > > > > Nicolas.Williams@sun.com (Nicolas Williams) on Thursday, April 23, 2009 wrote: > > > > >The more likely explanation is that *some* imaginable > > >cryptanalytic advances could reduce the effective strength of AES in > > >such a way that longer keys remain more secure than shorter keys. > > > > When I think of the reasons that NSA/DOD could have for requiring AES-128 > > for secret and AES-192 for top secret, I think they may be looking at the > > whole cryptographic system. While symmetric cyphers have some solid math > > behind them, other parts of the system, such as generating random numbers > > for the keys are frequently more akin to black magic. > > > > If my random numbers were only 75% random against some attack, with AES-192 > > I would still have 128 bits of strength against a brute force attack. With > > AES-128, I'd only have 96 bits, and I would be quite concerned when > > protecting top secret data. > > I don't think this lines up particularly well with how CSPRNGs > work. You start with some random seed information S which you > use to seed the CSPRNG. That seed has some number of bits of > entropy. Call it E. You then generate your cryptographic key. > No matter how long that key is, the total strength of the system > is the cost of brute-forcing S, i.e., 2^E operations. This is true > whether the symmetric cipher is 128 bits or 256 bits. It is not universally true that the "seed" of a CSPRNG is smaller than its random output. There are implementations of CSPRNGs (cryptographic strength pseudo random number generators) that use a large internal state (or "entropy pool", much larger than the randoms that are returned on each invocation. It is usually possible to "seed" that pool with large entropy (i.e. > 128 bit) as well. Gathering sufficient seed entropy is usually not a problem (100 bits/second is simple), but compressing that entropy into a fixed size "entropy pool" / CSPRNG internal state ist probably something that cryptographers should look at. -Martin From ekr@networkresonance.com Mon May 4 08:21:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEEC3A6CEC for ; Mon, 4 May 2009 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSrQ7SeWyYcu for ; Mon, 4 May 2009 08:21:11 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D78AE28C128 for ; Mon, 4 May 2009 08:20:51 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CE75550822; Mon, 4 May 2009 08:25:26 -0700 (PDT) Date: Mon, 04 May 2009 08:25:26 -0700 From: Eric Rescorla To: martin.rex@sap.com In-Reply-To: <200905041449.n44Eni9x021957@fs4113.wdf.sap.corp> References: <20090501055009.3857D19668A@kilo.networkresonance.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: <20090504152526.CE75550822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 04 May 2009 15:21:12 -0000 At Mon, 4 May 2009 16:49:43 +0200 (MEST), Martin Rex wrote: > > Eric Rescorla wrote: > > > > At Thu, 30 Apr 2009 18:56:35 -0700, > > Bill Frantz wrote: > > > > > > Nicolas.Williams@sun.com (Nicolas Williams) on Thursday, April 23, 2009 wrote: > > > > > > >The more likely explanation is that *some* imaginable > > > >cryptanalytic advances could reduce the effective strength of AES in > > > >such a way that longer keys remain more secure than shorter keys. > > > > > > When I think of the reasons that NSA/DOD could have for requiring AES-128 > > > for secret and AES-192 for top secret, I think they may be looking at the > > > whole cryptographic system. While symmetric cyphers have some solid math > > > behind them, other parts of the system, such as generating random numbers > > > for the keys are frequently more akin to black magic. > > > > > > If my random numbers were only 75% random against some attack, with AES-192 > > > I would still have 128 bits of strength against a brute force attack. With > > > AES-128, I'd only have 96 bits, and I would be quite concerned when > > > protecting top secret data. > > > > I don't think this lines up particularly well with how CSPRNGs > > work. You start with some random seed information S which you > > use to seed the CSPRNG. That seed has some number of bits of > > entropy. Call it E. You then generate your cryptographic key. > > No matter how long that key is, the total strength of the system > > is the cost of brute-forcing S, i.e., 2^E operations. This is true > > whether the symmetric cipher is 128 bits or 256 bits. > > It is not universally true that the "seed" of a CSPRNG is smaller > than its random output. Yes, that's true, but in that case Bill's analysis isn't relevant. -Ekr From pgut001@cs.auckland.ac.nz Mon May 4 20:26:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108EB3A69FC for ; Mon, 4 May 2009 20:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-2.403, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtGG5XN2AgzW for ; Mon, 4 May 2009 20:26:09 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id EB6EF3A6E3D for ; Mon, 4 May 2009 20:25:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8FC579FACD; Tue, 5 May 2009 15:26:57 +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 Dzt4x7eMkx7E; Tue, 5 May 2009 15:26:57 +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 7DD139FA12; Tue, 5 May 2009 15:26:56 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id F35E4E0808A; Tue, 5 May 2009 15:26:54 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1M1BJ0-0003em-Rp; Tue, 05 May 2009 15:26:54 +1200 From: Peter Gutmann To: tls@ietf.org, uri@ll.mit.edu In-Reply-To: Message-Id: Sender: pgut001 Date: Tue, 05 May 2009 15:26:54 +1200 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 05 May 2009 03:26:10 -0000 "Blumenthal, Uri" writes: >While this certainly makes a nice tea-table story, I question the "historical >truthfulness" of it. As I said, it was told to me by someone involved at the time, but it was some years ago and unfortunately I didn't think to take names and numbers. >YOU may need to explain things to YOUR customers (and make them understand), >lest they feel mistreated and go to another vendor. I don't think USG >agencies have the same luxury of choosing their own crypto policy provider >and product approver! You're assuming that the people in these organisations work like Turing machines, and automatically follow all directives from a central authority. Here's an instance of this kind of thing that happened to a large supplier to the USG. Some snake-oiler (it was either the JAWS L5 people or Meganet) were trying to get their software adopted by this organisation. They got a list of contact details for people all over the organisation and called anyone they thought would have any influence, all over the company (the person who had to deal with some of the fallout described it as a kind of mongolian-hordes attack, as soon as they'd stamped it out in one location it started up again somewhere else), explaining that their algorithms were more secure because they had bigger numbers behind the algorithm name. This carried on for quite some time, it was the same battle over and over again, and from the bits I heard often came down to the security people having to say "drop this, or else" because the target within the company didn't understand why they should use prescribed algorithms when the snake oil was obviously better (it's quite likely that some parts of the company, who were never discovered by the security people, did end up using the snake oil). You can see this (for different organisations than the one above) with the occasional JAWS/Meganet press release that some big customer (including USG users) have adopted their stuff, try enough people in enough organisations and eventually they'll fall for it, no matter how the Turing-machine model says they should react. Meganet have even specifically targetted USG users via an active penetration attack on FIPS 140, see their web site, complete with convenient GSA and CCR links, for details. Peter. From uri@ll.mit.edu Tue May 5 04:31:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32B228C106 for ; Tue, 5 May 2009 04:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsncEOUSoida for ; Tue, 5 May 2009 04:31:09 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 54A2D3A682B for ; Tue, 5 May 2009 04:30:45 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n45BVmAn026324; Tue, 5 May 2009 07:31:48 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA1Oa4AY; Tue May 5 07:31:11 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Tue, 5 May 2009 07:31:11 -0400 From: "Blumenthal, Uri" To: Peter Gutmann , "tls@ietf.org" Date: Tue, 5 May 2009 07:31:10 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnNMXCdX5C2DhbZQfa8SSn1LjKbXgAQ4xOa Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6259BBE44E0urillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 05 May 2009 11:31:14 -0000 --_000_C6259BBE44E0urillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>While this certainly makes a nice tea-table story, I question the "histor= ical >>truthfulness" of it. > >As I said, it was told to me by someone involved at the time, but it was s= ome >years ago and unfortunately I didn't think to take names and numbers. Understand. >>YOU may need to explain things to YOUR customers (and make them understan= d), >>lest they feel mistreated and go to another vendor. I don't think USG >>agencies have the same luxury of choosing their own crypto policy provide= r >>and product approver! > >You're assuming that the people in these organisations work like Turing >machines, and automatically follow all directives from a central authority= . No, I'm assuming different branches of USG with different rules. Like those= who design or build something, and need approval of somebody like NSA for = building what they design and deploying what they build. An agency that can= pretty much go outside, buy whatever - and use it internally without askin= g anybody's permission, nor having to pass some validation by a 3rd party -= is outside of my scope of expertise (though I can assume they exist :-). >Here's an instance of this kind of thing that happened to a large supplier= to >the USG........ All I can say is "Wow!!" Un-frigging-believable! -- Regards, Uri uri@ll.mit.edu --_000_C6259BBE44E0urillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Comparative cipher suite strengths
>>While this certainly makes a nice tea-table sto= ry, I question the "historical
>>truthfulness" of it.
>
>As I said, it was told to me by someone involved at the time, but it wa= s some
>years ago and unfortunately I didn't think to take names and numbers.


>>YOU may need to explain things to YOUR customers (and make them und= erstand),
>>lest they feel mistreated and go to another vendor. I don't think U= SG
>>agencies have the same luxury of choosing their own crypto policy p= rovider
>>and product approver!
>
>You're assuming that the people in these organisations work like Turing=
>machines, and automatically follow all directives from a central author= ity.


>Here's an instance of this kind of thing that happened to a large suppl= ier to
>the USG........

uri@ll.mit.edu
 --_000_C6259BBE44E0urillmitedu_-- From dean@av8.com Tue May 5 12:39:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155583A6B70 for ; Tue, 5 May 2009 12:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_05=-1.11, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQkVFCh3U-94 for ; Tue, 5 May 2009 12:39:47 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id E4FAF3A67EA for ; Tue, 5 May 2009 12:39:46 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n45Jf62a002137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 May 2009 15:41:07 -0400 Date: Tue, 5 May 2009 15:41:05 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Peter Gutmann In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 05 May 2009 19:39:48 -0000 On Tue, 5 May 2009, Peter Gutmann wrote: > "Blumenthal, Uri" writes: > > >While this certainly makes a nice tea-table story, I question the "historical > >truthfulness" of it. > > As I said, it was told to me by someone involved at the time, but it was some > years ago and unfortunately I didn't think to take names and numbers. Well, if Peter's recollection is not historically correct, and many such stories get things wrong (me included---I once thought I knew the story (from a third-hand source) about an event between RMS and ATT that occurred before GNU was formed. I thought to check the facts with RMS, and RMS told me I had it wrong--I heard it verbally, and didn't remember the precise source, so I don't know if I misremembered it or my source had it wrong. The point is: We all fail sometimes. If Peter has the history wrong, please state the correct history with your sources of fact. Just saying Peter has it wrong is no help. > You're assuming that the people in these organisations work like > Turing machines [...] > because the target within the company didn't understand why they should > use prescribed algorithms when the snake oil was obviously better [...] > try enough people in enough organisations and eventually they'll fall > for it, no matter how the Turing-machine model says they should react. Yep, that about covers it. I think we all probably have to deal with snake-oilers at some time or other. And my experience is about the same: its tedious. It seems to be a colossal waste of time. Fortunately or unfortunately, the snake-oiler's I'm currently fighting keep sending me a reminder once or twice a month to do a little more work... ;-) But snake-oil has to be discredited on its de-merits, not by altering specifications to encompass both snake-oil and non-snake-oil. The best thing you can do is put up a web page discrediting the snake-oilers to help others do the same. And promote the non-snake-oil on its comparative merits until people catch on. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean@av8.com Tue May 5 13:22:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BEB3A69BB for ; Tue, 5 May 2009 13:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-1.244, BAYES_20=-0.74, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7eAq-sqAfSo for ; Tue, 5 May 2009 13:22:31 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 3F5A13A682E for ; Tue, 5 May 2009 13:22:31 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n45KNmLQ002315 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 May 2009 16:23:49 -0400 Date: Tue, 5 May 2009 16:23:48 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Peter Gutmann In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 05 May 2009 20:22:32 -0000 I think this Schnier "Cryptogram" is particularly insightful on the subject of Snake oil, and even mentions the issue of AES key lengths. I found it by googling for "JAWS L5 Meganet". :-) http://www.ussrback.com/crypto/misc/cryptogram-021599.txt --Dean On Tue, 5 May 2009, Dean Anderson wrote: > On Tue, 5 May 2009, Peter Gutmann wrote: > > > "Blumenthal, Uri" writes: > > > > >While this certainly makes a nice tea-table story, I question the "historical > > >truthfulness" of it. > > > > As I said, it was told to me by someone involved at the time, but it was some > > years ago and unfortunately I didn't think to take names and numbers. > > Well, if Peter's recollection is not historically correct, and many such > stories get things wrong (me included---I once thought I knew the story > (from a third-hand source) about an event between RMS and ATT that > occurred before GNU was formed. I thought to check the facts with RMS, > and RMS told me I had it wrong--I heard it verbally, and didn't remember > the precise source, so I don't know if I misremembered it or my source > had it wrong. The point is: We all fail sometimes. If Peter has the > history wrong, please state the correct history with your sources of > fact. Just saying Peter has it wrong is no help. > > > > You're assuming that the people in these organisations work like > > Turing machines > [...] > > because the target within the company didn't understand why they should > > use prescribed algorithms when the snake oil was obviously better > [...] > > try enough people in enough organisations and eventually they'll fall > > for it, no matter how the Turing-machine model says they should react. > > > Yep, that about covers it. I think we all probably have to deal with > snake-oilers at some time or other. And my experience is about the same: > its tedious. It seems to be a colossal waste of time. Fortunately or > unfortunately, the snake-oiler's I'm currently fighting keep sending me > a reminder once or twice a month to do a little more work... ;-) > > But snake-oil has to be discredited on its de-merits, not by altering > specifications to encompass both snake-oil and non-snake-oil. The best > thing you can do is put up a web page discrediting the snake-oilers to > help others do the same. And promote the non-snake-oil on its > comparative merits until people catch on. > > --Dean > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From smb@cs.columbia.edu Wed May 6 19:26:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D853B3A6C79 for ; Wed, 6 May 2009 19:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VYeeEqf89hg for ; Wed, 6 May 2009 19:26:38 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id DC8A03A6E09 for ; Wed, 6 May 2009 19:25:46 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 5FCEB328DAD; Thu, 7 May 2009 02:27:12 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0B7E0328DA7; Thu, 7 May 2009 02:27:11 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id D54F92988C3; Wed, 6 May 2009 22:27:07 -0400 (EDT) Date: Wed, 6 May 2009 22:27:07 -0400 From: "Steven M. Bellovin" To: Bill Frantz Message-ID: <20090506222707.0f7e3ffd@cs.columbia.edu> In-Reply-To: References: <20090423185550.GW1500@Sun.COM> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 07 May 2009 02:26:40 -0000 On Thu, 30 Apr 2009 18:56:35 -0700 Bill Frantz wrote: > When I think of the reasons that NSA/DOD could have for requiring > AES-128 for secret and AES-192 for top secret, I think they may be > looking at the whole cryptographic system. While symmetric cyphers > have some solid math behind them, other parts of the system, such as > generating random numbers for the keys are frequently more akin to > black magic. >=20 =46rom http://catless.ncl.ac.uk/Risks/15.48.html#subj1 The unit key is generated via Skipjack itself, from random seeds provided by the two escrow agencies (approximately monthly, though that isn't certain yet). They say they prefer a software generation process because its correct behavior is auditable. In other words, the NSA understands that keys should not be generated by a random process. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jsalowey@cisco.com Sun May 10 17:18:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A903A68E5 for ; Sun, 10 May 2009 17:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.303 X-Spam-Level: X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0iVBox4y9xx for ; Sun, 10 May 2009 17:18:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3E71D3A6358 for ; Sun, 10 May 2009 17:18:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,325,1238976000"; d="scan'208";a="301935483" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 May 2009 00:19:35 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4B0JZiq031740 for ; Sun, 10 May 2009 17:19:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4B0JZXu023651 for ; Mon, 11 May 2009 00:19:35 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 May 2009 17:19:35 -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 Date: Sun, 10 May 2009 17:19:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Disclosure from Certicom Thread-Index: AcnRzimeHuqCIh8AT+eFryhifDfLbQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 11 May 2009 00:19:35.0739 (UTC) FILETIME=[2A2648B0:01C9D1CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=264; t=1242001175; x=1242865175; c=relaxed/simple; s=sjdkim2002; 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:=20IPR=20Disclosure=20from=20Certicom |Sender:=20; bh=fsBY5/YCAILQzYUtGPii2BwzzQCgfdHWzQQSAmTlL4I=; b=HCn7X8CEas6MamZ2XWbvjln+R+BBZzrdXuqj7i4aM/27qN6+bqmBDdLha6 zLZ7XDJFwW2rO5DNax8K3mehTfFGbML+3AbYTicp8OgutT29OLraod0TlRiM izxMzn+PkC; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [TLS] IPR Disclosure from Certicom X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 11 May 2009 00:18:06 -0000 I don't think the IP disclosure from Certicom (referenced in http://www.ietf.org/mail-archive/web/tls/current/msg02770.html) was ever posted to the list. It can be found on the IETF web site at https://datatracker.ietf.org/ipr/1004/. =20 Cheers,=20 Joe From simon@josefsson.org Mon May 11 11:17:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AEF28C164 for ; Mon, 11 May 2009 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=-3.043, BAYES_00=-2.599, FRT_FOLLOW1=1.332, MANGLED_EXTNSN=2.3, MANGLED_LICNSD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooialJa5UrlN for ; Mon, 11 May 2009 11:17:24 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A89A328C17D for ; Mon, 11 May 2009 11:16:32 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M3a4N-0004ex-WB; Mon, 11 May 2009 20:17:51 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090511:jsalowey@cisco.com::4p1pa20b2Dtiw1qG:1+bU X-Hashcash: 1:22:090511:tls@ietf.org::VAccCKxRK7on39+M:TNgE Date: Mon, 11 May 2009 20:17:37 +0200 In-Reply-To: (Joseph Salowey's message of "Sun, 10 May 2009 17:19:34 -0700") Message-ID: <874ovrbj26.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] IPR Disclosure from Certicom X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 11 May 2009 18:17:25 -0000 "Joseph Salowey (jsalowey)" writes: > I don't think the IP disclosure from Certicom (referenced in > http://www.ietf.org/mail-archive/web/tls/current/msg02770.html) was ever > posted to the list. It can be found on the IETF web site at > https://datatracker.ietf.org/ipr/1004/. That link doesn't contain any details of the patent disclosure. Instead it links to an externally hosted PDF on certicom.com. The PDF I downloaded had SHA-1 9219120d99c5bdee93059ae39f93978db1a8c833. I'm included below the output from pdftohml plus lynx --dump in case the PDF link is modified/removed by Certicom, or if the IPR disclosure on the IETF web site is removed. I haven't read the text. /Simon Certicom IPR contribution for RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc4347-bis-00, draft-rescorla-tls-suiteb-07, draft-ietf-tls-extractor-02, draft-green-secsh-ecc-03, draft-ietf-avt-d tls-srtp-05, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3851bis-08, draft-ietf-smime-3850bis-08, draft-ietf-smime-multisig-05, draft-ietf-smime-sha2-09, and draft-ietf-smime-3278bis-02 13 October 2008 It is Certicom's desire to facilitate the wide-scale adoption and proli feration of Elliptic Curve Cryptography (ECC) technology in the marketplace to replace today's agi ng public key systems. At this time, Certicom believes its patents and patent applications lis ted in Schedule A contain claims which may be necessary and essential to implementations of the f ollowing protocols: IETF TLS: "[1]The Transport Layer Security (TLS) Protocol -- Version 1.1," RFC 43 46 or [2]"The Transport Layer Security (TLS) Protocol - Version 1.2," RFC 5246, or[3] "Datagram Trans port Layer Security (DTLS) - Version 1.2," draft-ietf-tls-rfc4347-bis-00.txt, or[4] "Transport Layer Security (TLS) Extensions", RFC 4366, or[5] "Datagram Transport Layer Security (DTLS) - Version 1. 0", RFC 4347, or [6]"Datagram Transport Layer Security (DTLS) Extension to Establish Key s for Secure Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-05.txt or [7]"Keyi ng Material Extractors for Transport Layer Security (TLS)", draft-ietf-tls-extractor-02.txt when used with either: A. "[8]Elliptic Curve Cryptography (ECC) Cipher Suites for Transport L ayer [9]Security(TLS)" RFC 4492, May 2006; or, B. [10]"TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galo is Counter [11]Mode," RFC 5289, or C. [12]"Suite B Cipher Suites for TLS," draft-rescorla-tls-suiteb-07.t xt; IETF IKE for IPSec: IPsec IKE and IKEv2 Protocols: [13]"The Internet Key Exchange (IKE)," RFC 2409; or [14]"Internet Key E xchange (IKEv2) Protocol," RFC 4306 when used with either: A. [15]"IKE and IKEv2 Authentication Using ECDSA," RFC 4754; or B. [16]" ECP Groups for IKE and IKEv2," RFC 4753; or C. [17]"Suite B Cryptographic Suites for IPsec." RFC 4869; or D. [18]"Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4 109 __________________________________________________________________ SSH: [19]"The Secure Shell (SSH) Transport Layer Protocol," RFC 4253 or [20] "The Secure Shell (SSH) Authentication Protocol", RFC 4252 when used with: A. [21]"Elliptic-Curve Algorithm Integration in the Secure Shell Trans port Layer," [22]draft-green-secsh-ecc-03; or B. [23]"Suite B Cryptographic Suites for Secure Shell", draft-igoe-sec sh-suiteb-00.txt. CMS in S/MIME: [24]"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.0 Message Specification," RFC 2633 or[25] "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, RFC 3851, or[26] "Secure/Multipurpose Internet Mail Exte nsions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, or [27]"Secure/Multipurpose Intern et Mail Extensions (S/MIME) Version 3.2 Certificate Handling", draft-ietf-smime-3850bis-08 .txt, or [28]"Secure/Multipurpose Internet Mail Extensions Specification", draft -ietf-smime-3851bis-08.txt or[29] "Multiple Signatures in S/MIME", draft-ietf-smime-multisig-05.tx t, when used with digital certificates and: A. [30]"Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptog raphic Message [31]Syntax (CMS)," RFC 3278; or B. [32]"Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptog raphic Message [33]Syntax (CMS)," draft-ietf-smime-3278bis-02.txt; or C. [34]"Using SHA2 Algorithms with Cryptographic Message Syntax", draf t-ietf-smime- [35]sha2-09.txt; or D. [36]"Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIM E)", RFC 5008. Certicom will, upon request, provide a nonexclusive, royalty free paten t license, to manufacturers to permit end users (including both client and server sid es), to use the patents in schedule A when implementing any of these protocols, including those re quiring third party certificates provided the certificate is obtained from a licensed Certi ficate Authority (CA). This license does not cover the issuing of certificates by a Certification A uthority (CA). The reasonable terms and conditions of this license are contained in th e license document that Certicom intends to make available on its web site. This royalty free license is restricted to the use of the protocols lis ted above utilizing the ECC options in the specified drafts and restricted to NIST curves P256, P38 4, and P521 only. The IKE and IKEv2 protocols must be used in combination with IPSec in this lice nse grant; and CMS must be used in combination with S/MIME in this grant. Certicom will grant licenses on reasonable and non-discriminatory terms for implementations of these protocols ove r other named curves or explicitly defined curves. The above list of protocols will be amen ded from time to time in order to keep the documents current. __________________________________________________________________ The license granted does not extend, either explicitly or implicitly, t o other IETF protocols. Any party wishing to request a license should contact: Tony Rosati VP of Intellectual Property Licensing Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON L4W 5L1 [37]Tel:(613)254-9265 email: [38]trosati@certicom.com Any party wishing to request additional information may contact: Matthew Campagna Director of Research Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON L4W 5L1 [39]Tel:(203)897-9777 email: [40]mcampagna@certicom.com __________________________________________________________________ Schedule A (1) U.S. Pat. No. 5,761,305 entitled "Key Agreement and Transport Proto col with Implicit Signatures" issued on June 2, 1998; (2) Can. Pat, Appl. Ser. No. 2,176,972 entitled "Key Agreement and Tran sport Protocol with Implicit Signature and Reduced Bandwidth" filed on May 16, 1996; (3) U.S. Pat. No. 5,889,865 entitled "Key Agreement and Transport Proto col with Implicit Signatures" issued on March 30, 1999; (4) U.S. Pat. No. 5,896,455 entitled "'Key Agreement and Transport Prot ocol with Implicit Signatures" issued on April 20, 1999; (5) U.S. Pat. No. 5,933,504 entitled "Strengthened Public Key Protocol" issued on August 3, 1999; (6) U.K Pat. No. 9510035 entitled "Strengthened Public Key Protocol" fi led on May 18, 1995 (superseded by 8 below); (7) Can. Pat. Appl. Ser. No. 2,176,866 entitled "Strengthened Public Ke y Protocol" filed on May 17, 1996; (8) E.P. Pat. Publ. Appl. Ser. No. 0743774 entitled "Strengthened Publi c Key Protocol" filed on May 17, 1996 ; (9) U.S. Pat. No. 5,999,626 entitled "Digital Signatures on a Smartcard " issued on December 7, 1999; (10) Can. Pat No. 2202566 entitled "Digital Signatures on a Smartcard" issued on December 12, 2006; (11) E.P. Pat. Appl. No. 97106114.8 entitled "Digital Signatures on a S martcard" filed on April 15, 1997; (12) U.S Pat. No. 6,122,736 entitled "Key Agreement and Transport Proto col with Implicit Signatures" issued on September 19, 2000; (13) Can. Pat. No. 2,174,261 entitled "Key Agreement and Transport Pro tocol with Implicit Signatures" issued on June 12, 2007; (14) E.P. Pat. No. 0739105 entitled "Key Agreement and Transport Protoc ol with Implicit Signatures" issued on October 13, 2004, registered in DE, FR, UK; (15) U.S. Pat. No. 6,141,420 entitled "Elliptic Curve Encryption System s" issued on October 31, 2000; __________________________________________________________________ (16) Can. Pat Appl. Ser. No.2155038 entitled "Elliptic Curve Encryption Systems" filed on July 31, 1995; (17) E.P. Pat. No. 0804758 entitled "Elliptic Curve Encryption System" issued on November 19, 2005, registered in CH, DE, FR, UK; (18) U.S. Pat. No. 6,336,188 entitled "Authenticated Key Agreement" iss ued on January 1, 2002; (19) U.S. Pat. No. 6,487,661 entitled "Key Agreement and Transport Prot ocol" issued on November 26, 2002; (20) Can. Pat. No. 2174260 entitled "Key Agreement Transport Protocol" issued on June 19, 2007; (21) E. P. Pat. No. 0739106 entitled "Key Agreement and Transport Proto col" issued on October 15, 2003, registered in DE, FR, UK; (22) U.S. Pat. No. 6,563,928 entitled "Strengthened Public Key Protocol " issued on May 13, 2003; (23) U.S. Pat. No. 6,618,483 entitled "Elliptic Curve Encryption System s issued September 9, 2003; (24) U.S. Pat. No. 6,925,564 entitled "Digital Signatures on a Smartca rd" issued on August 02, 2005; (25) U.S. Pat. No. 6,785,813 entitled "Key Agreement and Transport Prot ocol with Implicit Signatures" issued on August 31, 2004; (26) U.S. Pat. No. 6,704,870 entitled "Digital Signatures on a Smartcar d" issued on March 9, 2004; and (27) U.S. Pat. Appl. Ser. No. 10/185,735 entitled "Strengthened Public Key Protocol" filed on July 1, 2000. __________________________________________________________________ Document Outline * * * __________________________________________________________________ References 1. http://www.ietf.org/rfc/rfc4346.txt 2. http://tools.ietf.org/html/rfc5246 3. http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-00.txt 4. http://www.ietf.org/rfc/rfc4366.txt 5. http://tools.ietf.org/html/rfc4347 6. ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-dtls-srtp-05.txt 7. http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-02.txt 8. http://www.ietf.org/rfc/rfc4492.txt 9. http://www.ietf.org/rfc/rfc4492.txt 10. http://tools.ietf.org/html/rfc5289 11. http://tools.ietf.org/html/rfc5289 12. ftp://ftp.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-07.txt 13. http://www.vpnc.org/rfc2409 14. http://www.vpnc.org/rfc4309 15. http://www.vpnc.org/rfc4754 16. http://www.vpnc.org/rfc4753 17. http://www.vpnc.org/rfc4869 18. http://www.rfc-editor.org/rfc/rfc4109.txt 19. http://www.ietf.org/rfc/rfc4253.txt 20. http://www.ietf.org/rfc/rfc4252.txt 21. http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-03.txt 22. http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-03.txt 23. ftp://ftp.ietf.org/internet-drafts/draft-igoe-secsh-suiteb-00.txt 24. http://www.ietf.org/rfc/rfc2633.txt 25. http://www.ietf.org/rfc/rfc3851.txt 26. http://www.ietf.org/rfc/rfc3850.txt 27. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-3850bis-08.txt 28. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-3851bis-08.txt 29. http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt 30. http://www.ietf.org/rfc/rfc3278.txt 31. http://www.ietf.org/rfc/rfc3278.txt 32. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-3278bis-02.txt 33. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-3278bis-02.txt 34. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-sha2-09.txt 35. ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-sha2-09.txt 36. ftp://ftp.rfc-editor.org/in-notes/rfc5008.txt 37. file://localhost/home/jas/cmc/certicom%20-ipr-contribution-to-ietfsept08.html 38. mailto:trosati@certicom.com 39. file://localhost/home/jas/cmc/certicom%20-ipr-contribution-to-ietfsept08.html 40. mailto:mcampagna@certicom.com From frantz@pwpconsult.com Mon May 11 21:33:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F0B3A6A2D for ; Mon, 11 May 2009 21:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcwl5h37XMSO for ; Mon, 11 May 2009 21:33:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 863FE3A67FE for ; Mon, 11 May 2009 21:33:43 -0700 (PDT) Received: from [173.75.83.140] (helo=[192.168.1.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M3jhy-00066O-BY for TLS@ietf.org; Tue, 12 May 2009 00:35:14 -0400 Date: Mon, 11 May 2009 21:36:39 -0700 From: Bill Frantz To: TLS@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796c84556d3440d7c34ce712674dcf9100350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.140 Subject: Re: [TLS] IPR Disclosure from Certicom X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 04:33:44 -0000 simon@josefsson.org (Simon Josefsson) on Monday, May 11, 2009 wrote: > Certicom will, upon request, provide a nonexclusive, royalty free paten > t license, to > manufacturers to permit end users (including both client and server sid > es), to use the patents in > schedule A when implementing any of these protocols, including those re > quiring third party > certificates provided the certificate is obtained from a licensed Certi > ficate Authority (CA). This > license does not cover the issuing of certificates by a Certification A > uthority (CA). I read this as saying you should not use any elliptic curve cryptography that depends on Certicom's patents if you are using self-signed certificates or acting as your own CA (unless you have a license from Certicom). The easiest way to avoid Certicom's patents is to avoid elliptic curve cryptography. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security?" -- Bruce Schneier From jsalowey@cisco.com Mon May 11 22:57:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30933A6A5E for ; Mon, 11 May 2009 22:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeyW+7opQmWy for ; Mon, 11 May 2009 22:57:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5694F3A69D8 for ; Mon, 11 May 2009 22:57:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,180,1241395200"; d="scan'208";a="302731126" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 May 2009 05:58:41 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4C5wfG5020023 for ; Mon, 11 May 2009 22:58:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n4C5wfYJ009380 for ; Tue, 12 May 2009 05:58:41 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 22:58:41 -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 Date: Mon, 11 May 2009 22:58:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proto write-up for TLS exporter Thread-Index: AcnSxrLKjYHnkM7BS66nSZO1Y7I5wQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 12 May 2009 05:58:41.0638 (UTC) FILETIME=[B3A9D860:01C9D2C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6988; t=1242107921; x=1242971921; 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:=20Proto=20write-up=20for=20TLS=20exporter |Sender:=20; bh=Xo5hbsHU4T++1UJw76bE0hXifwanmY09LyaSUE/rUHI=; b=cbukSJnGIHN84Mz7DD30L9PV+PsAAQH2uAtLQEoGWIW5YNFl5+0gIBUs4q ZksL51EId0ytogjbqyZQSSpbtpC8paKH9r/4peBkVjhJ3s92N6a4bL3MaUTt kMkpQbGFOA; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 05:57:11 -0000 (1.a) Who is the Document Shepherd for this document? Has the=20 Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 I, Joe Salowey, co-chair of the TLS working group, am the Document shepherd for this document. I have reviewed the document and I believe it is ready for forwarding to the IESG for publication. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed?=20 The document has been reviewed by key working group members that understand TLS. The document has also been reviewed by members of the cryptographic community that are experts in key derivation. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 The document deals with cryptography and has had cryptographic review. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 The document shepherd has no concerns with the document. There is an IPR disclosure that lists this document: https://datatracker.ietf.org/ipr/1004/. The contents of this disclosure where originally posted to the list on June 30, 2008 (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html). The IETF IPR disclosure reference was recently posted to the TLS list as well. There has been little discussion on this in the working group. The general sentiment is that the IPR is applicable to cases where ECC certificates are used.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it?=20 The consensus behind this document is strong with decent support and participation from the working group.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No.=20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See=20 http://www.ietf.org/ID-Checklist.html and=20 http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 There are a few nits with respect to references in the document. There is also one instance of "MUST not" that should be replaced by "MUST NOT". =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The Document has split references. In the current version some of the references are out of date or missing. A informative reference to RFC 5216 should be added in place of 2716. The reference to RFC 5281 should be informative. The reference to the DTLS-SRTP draft should be rectified in the text. =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 Yes (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 Yes (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. Working Group Summary=20 There was significant consensus in the working group supporting this document. The largest controversy was over the name. =20 Document Quality=20 The approach is planned for use in several protocols. The document has been reviewed by cryptographers who are experts in the area of key derivation. From simon@josefsson.org Tue May 12 08:57:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6474C3A6C83 for ; Tue, 12 May 2009 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptyeT0Q+aS8G for ; Tue, 12 May 2009 08:57:44 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 64F253A6C1B for ; Tue, 12 May 2009 08:57:43 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M3uNq-00077K-OY; Tue, 12 May 2009 17:59:12 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090512:tls@ietf.org::Ufl6Wcl9WfAqer7A:0h2z X-Hashcash: 1:22:090512:jsalowey@cisco.com::Tz2HwM6JwTGitogB:cVic Date: Tue, 12 May 2009 17:59:09 +0200 In-Reply-To: (Joseph Salowey's message of "Mon, 11 May 2009 22:58:40 -0700") Message-ID: <87preeqpma.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 15:57:45 -0000 "Joseph Salowey (jsalowey)" writes: > 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. > > The document shepherd has no concerns with the document. There is an > IPR disclosure that lists this document: > https://datatracker.ietf.org/ipr/1004/. The contents of this disclosure > where originally posted to the list on June 30, 2008 > (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html). That post does not relate to the #1004 patent disclosure. The post refers to the January 2006 license, which did not reference TLS exporter. The #1004 patent disclosure refers to the October 2008 license. > The IETF IPR disclosure reference was recently posted to the TLS list > as well. There has been little discussion on this in the working > group. Possibly because it was posted yesterday. > The general sentiment is that the IPR is applicable to cases where ECC > certificates are used. Can you provide a reference for this? Who has made that interpretation? /Simon From paul.hoffman@vpnc.org Tue May 12 09:36:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F13F3A6C43 for ; Tue, 12 May 2009 09:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD4zNFz8xqIk for ; Tue, 12 May 2009 09:36:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DA2E93A6E77 for ; Tue, 12 May 2009 09:35:59 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4CGbRRY065370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 09:37:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87preeqpma.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> Date: Tue, 12 May 2009 09:37:25 -0700 To: Simon Josefsson , "Joseph Salowey \(jsalowey\)" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 16:36:15 -0000 First off, the write-up doesn't say which document it is for. I assume that it is for draft-ietf-tls-extractor-05.txt. At 5:59 PM +0200 5/12/09, Simon Josefsson wrote: >"Joseph Salowey (jsalowey)" writes: > >> 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. >> >> The document shepherd has no concerns with the document. There is an >> IPR disclosure that lists this document: > > https://datatracker.ietf.org/ipr/1004/. The contents of this disclosure >> where originally posted to the list on June 30, 2008 > > (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html). > >That post does not relate to the #1004 patent disclosure. The post >refers to the January 2006 license, which did not reference TLS >exporter. Simon is correct. >The #1004 patent disclosure refers to the October 2008 >license. Yep. > > The general sentiment is that the IPR is applicable to cases where ECC >> certificates are used. > >Can you provide a reference for this? Who has made that interpretation? Yes, please. I am not aware of any even vague consensus on what IPR #1004 means or applies to. --Paul Hoffman, Director --VPN Consortium From jsalowey@cisco.com Tue May 12 10:27:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B6E3A6EE8 for ; Tue, 12 May 2009 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EETc1HSAFXR for ; Tue, 12 May 2009 10:27:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC4F83A6E9D for ; Tue, 12 May 2009 10:27:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,183,1241395200"; d="scan'208";a="184397828" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 May 2009 17:28:41 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4CHSf9t029415; Tue, 12 May 2009 10:28:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n4CHSft8025940; Tue, 12 May 2009 17:28:41 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 10:28:41 -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 Date: Tue, 12 May 2009 10:28:40 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnTH/JO/hZelCShRJ6pm5E2PooQKwABC1bQ References: <87preeqpma.fsf@mocca.josefsson.org> From: "Joseph Salowey (jsalowey)" To: "Paul Hoffman" , "Simon Josefsson" X-OriginalArrivalTime: 12 May 2009 17:28:41.0147 (UTC) FILETIME=[17B198B0:01C9D327] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3679; t=1242149321; x=1243013321; c=relaxed/simple; s=sjdkim2002; 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]=20Proto=20write-up=20for=20TLS=20 exporter |Sender:=20; bh=FqGerr/6O2i3lczH4V8iKP/g+XFERZqMCy1dPpnT3wU=; b=rhrUtDzWePnEvO8TaK0Rn6Vfq0SgS8ef7FGidD9lxONxC4oNF6YQPvgrMI yI9Yw4x3U++4wpDKLQC1GRV/7EYwacb8+5NBlruZQD1WT9TYS7mhqyZ2gLFZ AcxfFg3EnC; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 17:27:15 -0000 You're both absolutely right, when I looked at the PDF file on the website I didn't connect that it was from October (I wonder if there was another one previous that was supplanted by the October one). Also, the sentiment I related was from offline discussions and does not represent working group consensus. I'll update the write-up to include the document title and the revised IPR discussion section below. I'll also hold off on forwarding to the IESG for a few days in case discussion develops. =20 Thanks for reading the PROTO write-up, its better to catch this now: (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 The document shepherd has no concerns with the document. There is an IPR disclosure that lists this document: https://datatracker.ietf.org/ipr/1004/. Although the IETF IPR disclosure was posted in October, a reference was only recently posted to the TLS list. So far, there has been little discussion on this in the working group. Discussions outside the working group between the chairs and others seem to indicate that the IPR is applicable to cases where ECC certificates are used.=20 Thanks, Joe > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 > Sent: Tuesday, May 12, 2009 9:37 AM > To: Simon Josefsson; Joseph Salowey (jsalowey) > Cc: TLS@ietf.org > Subject: Re: [TLS] Proto write-up for TLS exporter >=20 > First off, the write-up doesn't say which document it is for.=20 > I assume that it is for draft-ietf-tls-extractor-05.txt. >=20 >=20 > At 5:59 PM +0200 5/12/09, Simon Josefsson wrote: > >"Joseph Salowey (jsalowey)" writes: > > > >> concerns here. Has an IPR disclosure related to=20 > this document > >> been filed? If so, please include a reference to the > >> disclosure and summarize the WG discussion and=20 > conclusion on > >> this issue. > >> > >> The document shepherd has no concerns with the document. =20 > There is an=20 > >> IPR disclosure that lists this document: > > > https://datatracker.ietf.org/ipr/1004/. The contents of this=20 > > > disclosure > >> where originally posted to the list on June 30, 2008 > > > (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html). > > > >That post does not relate to the #1004 patent disclosure. The post=20 > >refers to the January 2006 license, which did not reference TLS=20 > >exporter. >=20 > Simon is correct. >=20 > >The #1004 patent disclosure refers to the October 2008 license. >=20 > Yep. >=20 > > > The general sentiment is that the IPR is applicable to=20 > cases where=20 > > > ECC > >> certificates are used. > > > >Can you provide a reference for this? Who has made that=20 > interpretation? >=20 > Yes, please. I am not aware of any even vague consensus on=20 > what IPR #1004 means or applies to. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 From Martin.Rex@sap.com Tue May 12 10:47:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BDA3A6C31 for ; Tue, 12 May 2009 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCO6szazZwHW for ; Tue, 12 May 2009 10:47:04 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 603F33A6CBF for ; Tue, 12 May 2009 10:47:04 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n4CHmCVZ024869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 19:48:12 +0200 (MEST) From: Martin Rex Message-Id: <200905121748.n4CHmBFK016142@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 12 May 2009 19:48:11 +0200 (MEST) In-Reply-To: <87preeqpma.fsf@mocca.josefsson.org> from "Simon Josefsson" at May 12, 9 05:59:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 12 May 2009 17:47:05 -0000 Simon Josefsson wrote: > > That post does not relate to the #1004 patent disclosure. The post > refers to the January 2006 license, which did not reference TLS > exporter. The #1004 patent disclosure refers to the October 2008 > license. I'm confused. TLS exporters has nothing to do with ECC crypto or X.509 certificates. It is about a PRF and a shared secret and random challenges between the TLS communication peers. -Martin From simon@josefsson.org Wed May 13 04:32:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1D03A6D89 for ; Wed, 13 May 2009 04:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdv89EtMX3iG for ; Wed, 13 May 2009 04:32:37 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7D48A3A6998 for ; Wed, 13 May 2009 04:32:36 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M4Cip-00015G-M7; Wed, 13 May 2009 13:34:04 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87preeqpma.fsf@mocca.josefsson.org> <200905121748.n4CHmBFK016142@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090513:tls@ietf.org::0X3f4r4Mx8o+OaRw:1ax X-Hashcash: 1:22:090513:martin.rex@sap.com::srEWzqZAQ+g72E7d:Cku2 Date: Wed, 13 May 2009 13:34:02 +0200 In-Reply-To: <200905121748.n4CHmBFK016142@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 12 May 2009 19:48:11 +0200 (MEST)") Message-ID: <87octxnsnp.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 11:32:38 -0000 Martin Rex writes: > Simon Josefsson wrote: >> >> That post does not relate to the #1004 patent disclosure. The post >> refers to the January 2006 license, which did not reference TLS >> exporter. The #1004 patent disclosure refers to the October 2008 >> license. > > I'm confused. TLS exporters has nothing to do with ECC crypto > or X.509 certificates. It is about a PRF and a shared secret > and random challenges between the TLS communication peers. That is right, but the #1004 patent disclosure claims to cover tls-extractor. /Simon From simon@josefsson.org Wed May 13 04:57:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16B73A6D04 for ; Wed, 13 May 2009 04:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6RLuycIWluo for ; Wed, 13 May 2009 04:57:27 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id BD98E3A6782 for ; Wed, 13 May 2009 04:57:27 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M4D6u-00015V-AO; Wed, 13 May 2009 13:58:57 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: <87preeqpma.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090513:paul.hoffman@vpnc.org::7kmOQ8XK3VMR1VF5:4Fh1 X-Hashcash: 1:22:090513:tls@ietf.org::epBivgwYk0I29Tkx:9QYG X-Hashcash: 1:22:090513:jsalowey@cisco.com::YUYVydGfM8MgjcrO:o7gH Date: Wed, 13 May 2009 13:58:54 +0200 In-Reply-To: (Joseph Salowey's message of "Tue, 12 May 2009 10:28:40 -0700") Message-ID: <87eiutnri9.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 11:57:28 -0000 I don't support publishing tls-extractor on the standards track as long as there are unclear patent threat against it and no acceptable free software compatible patent license is available. I haven't seen anyone offer a credible analysis that the patent claims would not taint an implementation of the document. If someone presents analysis, that would influence my opinion. Putting this document on the standards track suggests that other IETF documents should reference it on extracting keying material from TLS. That seems like a poor recommendation to make broadly, because every protocol that would make use of tls-extractor would then have the uncertainty of being tainted by the Certicom patent claims. I believe the wider Internet community will be better off by not publishing the document as an RFC at all if the patent situation does not improve. We should not encourage patented technology for running the global Internet. The patent disclosure was posted to this list only a few days ago. It has not been mentioned in earlier discussions of the draft or during WGLC's as far as I recall. I believe a few days is a too short time to be able to establish consensus. Referring to external discussions in the proto-writeup is not acceptable, it explicitly requests reference to WG discussions about the patent disclaimer. /Simon From uri@ll.mit.edu Wed May 13 05:22:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9FA28C1B4 for ; Wed, 13 May 2009 05:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s02ZMdiDMa97 for ; Wed, 13 May 2009 05:22:28 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 88D4028C1B1 for ; Wed, 13 May 2009 05:22:27 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n4DCNssm004062 for ; Wed, 13 May 2009 08:23:54 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAUOaWYU; Wed May 13 08:13:39 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 13 May 2009 08:13:38 -0400 From: "Blumenthal, Uri" To: "'tls@ietf.org'" Date: Wed, 13 May 2009 08:13:37 -0400 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnTwlLbxQG85SLZQoqf4vlsq/H14QAI4VJC Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A631F21D8@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 12:22:28 -0000 SSBzdXBwb3J0IFNpbW9uJ3MgcmVhc29uaW5nIGFuZCBjb25jbHVzaW9ucy4NCg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJv dW5jZXNAaWV0Zi5vcmc+DQpUbzogSm9zZXBoIFNhbG93ZXkgKGpzYWxvd2V5KSA8anNhbG93ZXlA Y2lzY28uY29tPg0KQ2M6IFRMU0BpZXRmLm9yZyA8VExTQGlldGYub3JnPg0KU2VudDogV2VkIE1h eSAxMyAwNzo1ODo1NCAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBQcm90byB3cml0ZS11cCBmb3Ig VExTIGV4cG9ydGVyDQoNCkkgZG9uJ3Qgc3VwcG9ydCBwdWJsaXNoaW5nIHRscy1leHRyYWN0b3Ig b24gdGhlIHN0YW5kYXJkcyB0cmFjayBhcyBsb25nDQphcyB0aGVyZSBhcmUgdW5jbGVhciBwYXRl bnQgdGhyZWF0IGFnYWluc3QgaXQgYW5kIG5vIGFjY2VwdGFibGUgZnJlZQ0Kc29mdHdhcmUgY29t cGF0aWJsZSBwYXRlbnQgbGljZW5zZSBpcyBhdmFpbGFibGUuDQoNCkkgaGF2ZW4ndCBzZWVuIGFu eW9uZSBvZmZlciBhIGNyZWRpYmxlIGFuYWx5c2lzIHRoYXQgdGhlIHBhdGVudCBjbGFpbXMNCndv dWxkIG5vdCB0YWludCBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZG9jdW1lbnQuICBJZiBzb21l b25lIHByZXNlbnRzDQphbmFseXNpcywgdGhhdCB3b3VsZCBpbmZsdWVuY2UgbXkgb3Bpbmlvbi4N Cg0KUHV0dGluZyB0aGlzIGRvY3VtZW50IG9uIHRoZSBzdGFuZGFyZHMgdHJhY2sgc3VnZ2VzdHMg dGhhdCBvdGhlciBJRVRGDQpkb2N1bWVudHMgc2hvdWxkIHJlZmVyZW5jZSBpdCBvbiBleHRyYWN0 aW5nIGtleWluZyBtYXRlcmlhbCBmcm9tIFRMUy4NClRoYXQgc2VlbXMgbGlrZSBhIHBvb3IgcmVj b21tZW5kYXRpb24gdG8gbWFrZSBicm9hZGx5LCBiZWNhdXNlIGV2ZXJ5DQpwcm90b2NvbCB0aGF0 IHdvdWxkIG1ha2UgdXNlIG9mIHRscy1leHRyYWN0b3Igd291bGQgdGhlbiBoYXZlIHRoZQ0KdW5j ZXJ0YWludHkgb2YgYmVpbmcgdGFpbnRlZCBieSB0aGUgQ2VydGljb20gcGF0ZW50IGNsYWltcy4N Cg0KSSBiZWxpZXZlIHRoZSB3aWRlciBJbnRlcm5ldCBjb21tdW5pdHkgd2lsbCBiZSBiZXR0ZXIg b2ZmIGJ5IG5vdA0KcHVibGlzaGluZyB0aGUgZG9jdW1lbnQgYXMgYW4gUkZDIGF0IGFsbCBpZiB0 aGUgcGF0ZW50IHNpdHVhdGlvbiBkb2VzDQpub3QgaW1wcm92ZS4gIFdlIHNob3VsZCBub3QgZW5j b3VyYWdlIHBhdGVudGVkIHRlY2hub2xvZ3kgZm9yIHJ1bm5pbmcNCnRoZSBnbG9iYWwgSW50ZXJu ZXQuDQoNClRoZSBwYXRlbnQgZGlzY2xvc3VyZSB3YXMgcG9zdGVkIHRvIHRoaXMgbGlzdCBvbmx5 IGEgZmV3IGRheXMgYWdvLiAgSXQNCmhhcyBub3QgYmVlbiBtZW50aW9uZWQgaW4gZWFybGllciBk aXNjdXNzaW9ucyBvZiB0aGUgZHJhZnQgb3IgZHVyaW5nDQpXR0xDJ3MgYXMgZmFyIGFzIEkgcmVj YWxsLiAgSSBiZWxpZXZlIGEgZmV3IGRheXMgaXMgYSB0b28gc2hvcnQgdGltZSB0bw0KYmUgYWJs ZSB0byBlc3RhYmxpc2ggY29uc2Vuc3VzLiAgUmVmZXJyaW5nIHRvIGV4dGVybmFsIGRpc2N1c3Np b25zIGluDQp0aGUgcHJvdG8td3JpdGV1cCBpcyBub3QgYWNjZXB0YWJsZSwgaXQgZXhwbGljaXRs eSByZXF1ZXN0cyByZWZlcmVuY2UgdG8NCldHIGRpc2N1c3Npb25zIGFib3V0IHRoZSBwYXRlbnQg ZGlzY2xhaW1lci4NCg0KL1NpbW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From uri@ll.mit.edu Wed May 13 05:24:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BB228C1C6 for ; Wed, 13 May 2009 05:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3Ptvgop8gEc for ; Wed, 13 May 2009 05:24:33 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 0CEAB3A6C6A for ; Wed, 13 May 2009 05:24:32 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n4DCQ2H0006255 for ; Wed, 13 May 2009 08:26:02 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAUOaWYU; Wed May 13 08:13:39 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 13 May 2009 08:13:38 -0400 From: "Blumenthal, Uri" To: "'tls@ietf.org'" Date: Wed, 13 May 2009 08:13:37 -0400 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnTwlLbxQG85SLZQoqf4vlsq/H14QAI4VJC Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A631F21D8@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 12:24:33 -0000 SSBzdXBwb3J0IFNpbW9uJ3MgcmVhc29uaW5nIGFuZCBjb25jbHVzaW9ucy4NCg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJv dW5jZXNAaWV0Zi5vcmc+DQpUbzogSm9zZXBoIFNhbG93ZXkgKGpzYWxvd2V5KSA8anNhbG93ZXlA Y2lzY28uY29tPg0KQ2M6IFRMU0BpZXRmLm9yZyA8VExTQGlldGYub3JnPg0KU2VudDogV2VkIE1h eSAxMyAwNzo1ODo1NCAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBQcm90byB3cml0ZS11cCBmb3Ig VExTIGV4cG9ydGVyDQoNCkkgZG9uJ3Qgc3VwcG9ydCBwdWJsaXNoaW5nIHRscy1leHRyYWN0b3Ig b24gdGhlIHN0YW5kYXJkcyB0cmFjayBhcyBsb25nDQphcyB0aGVyZSBhcmUgdW5jbGVhciBwYXRl bnQgdGhyZWF0IGFnYWluc3QgaXQgYW5kIG5vIGFjY2VwdGFibGUgZnJlZQ0Kc29mdHdhcmUgY29t cGF0aWJsZSBwYXRlbnQgbGljZW5zZSBpcyBhdmFpbGFibGUuDQoNCkkgaGF2ZW4ndCBzZWVuIGFu eW9uZSBvZmZlciBhIGNyZWRpYmxlIGFuYWx5c2lzIHRoYXQgdGhlIHBhdGVudCBjbGFpbXMNCndv dWxkIG5vdCB0YWludCBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZG9jdW1lbnQuICBJZiBzb21l b25lIHByZXNlbnRzDQphbmFseXNpcywgdGhhdCB3b3VsZCBpbmZsdWVuY2UgbXkgb3Bpbmlvbi4N Cg0KUHV0dGluZyB0aGlzIGRvY3VtZW50IG9uIHRoZSBzdGFuZGFyZHMgdHJhY2sgc3VnZ2VzdHMg dGhhdCBvdGhlciBJRVRGDQpkb2N1bWVudHMgc2hvdWxkIHJlZmVyZW5jZSBpdCBvbiBleHRyYWN0 aW5nIGtleWluZyBtYXRlcmlhbCBmcm9tIFRMUy4NClRoYXQgc2VlbXMgbGlrZSBhIHBvb3IgcmVj b21tZW5kYXRpb24gdG8gbWFrZSBicm9hZGx5LCBiZWNhdXNlIGV2ZXJ5DQpwcm90b2NvbCB0aGF0 IHdvdWxkIG1ha2UgdXNlIG9mIHRscy1leHRyYWN0b3Igd291bGQgdGhlbiBoYXZlIHRoZQ0KdW5j ZXJ0YWludHkgb2YgYmVpbmcgdGFpbnRlZCBieSB0aGUgQ2VydGljb20gcGF0ZW50IGNsYWltcy4N Cg0KSSBiZWxpZXZlIHRoZSB3aWRlciBJbnRlcm5ldCBjb21tdW5pdHkgd2lsbCBiZSBiZXR0ZXIg b2ZmIGJ5IG5vdA0KcHVibGlzaGluZyB0aGUgZG9jdW1lbnQgYXMgYW4gUkZDIGF0IGFsbCBpZiB0 aGUgcGF0ZW50IHNpdHVhdGlvbiBkb2VzDQpub3QgaW1wcm92ZS4gIFdlIHNob3VsZCBub3QgZW5j b3VyYWdlIHBhdGVudGVkIHRlY2hub2xvZ3kgZm9yIHJ1bm5pbmcNCnRoZSBnbG9iYWwgSW50ZXJu ZXQuDQoNClRoZSBwYXRlbnQgZGlzY2xvc3VyZSB3YXMgcG9zdGVkIHRvIHRoaXMgbGlzdCBvbmx5 IGEgZmV3IGRheXMgYWdvLiAgSXQNCmhhcyBub3QgYmVlbiBtZW50aW9uZWQgaW4gZWFybGllciBk aXNjdXNzaW9ucyBvZiB0aGUgZHJhZnQgb3IgZHVyaW5nDQpXR0xDJ3MgYXMgZmFyIGFzIEkgcmVj YWxsLiAgSSBiZWxpZXZlIGEgZmV3IGRheXMgaXMgYSB0b28gc2hvcnQgdGltZSB0bw0KYmUgYWJs ZSB0byBlc3RhYmxpc2ggY29uc2Vuc3VzLiAgUmVmZXJyaW5nIHRvIGV4dGVybmFsIGRpc2N1c3Np b25zIGluDQp0aGUgcHJvdG8td3JpdGV1cCBpcyBub3QgYWNjZXB0YWJsZSwgaXQgZXhwbGljaXRs eSByZXF1ZXN0cyByZWZlcmVuY2UgdG8NCldHIGRpc2N1c3Npb25zIGFib3V0IHRoZSBwYXRlbnQg ZGlzY2xhaW1lci4NCg0KL1NpbW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From ekr@networkresonance.com Wed May 13 08:08:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D643A67B5 for ; Wed, 13 May 2009 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4rtpYb-bYD2 for ; Wed, 13 May 2009 08:07:59 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5B3BF3A68F0 for ; Wed, 13 May 2009 08:07:59 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2668950822; Wed, 13 May 2009 08:12:44 -0700 (PDT) Date: Wed, 13 May 2009 08:12:44 -0700 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87preeqpma.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.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: <20090513151244.2668950822@romeo.rtfm.com> Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 15:08:00 -0000 At Tue, 12 May 2009 17:59:09 +0200, Simon Josefsson wrote: >=20 > "Joseph Salowey (jsalowey)" writes: >=20 > > concerns here. Has an IPR disclosure related to this document= =20 > > been filed? If so, please include a reference to the=20 > > disclosure and summarize the WG discussion and conclusion on = > > this issue.=20 > > > > The document shepherd has no concerns with the document. There is an > > IPR disclosure that lists this document: > > https://datatracker.ietf.org/ipr/1004/. The contents of this disclosure > > where originally posted to the list on June 30, 2008 > > (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html). >=20 > That post does not relate to the #1004 patent disclosure. The post > refers to the January 2006 license, which did not reference TLS > exporter. The #1004 patent disclosure refers to the October 2008 > license. >=20 > > The IETF IPR disclosure reference was recently posted to the TLS list > > as well. There has been little discussion on this in the working > > group. >=20 > Possibly because it was posted yesterday. >=20 > > The general sentiment is that the IPR is applicable to cases where ECC > > certificates are used. >=20 > Can you provide a reference for this? Who has made that interpretation? I don't know about consensus, but that's my interpretation. I made it based on the PDF file linked from the #1004 disclosure which seems to me to pretty clearly state that extractor (and pretty much every other TLS document) apply when used with ECC: IETF TLS:=20 "The Transport Layer Security (TLS) Protocol Version 1.1," RFC 4346 or "Th= e Transport Layer=20 Security (TLS) Protocol =AD Version 1.2," RFC 5246, or "Datagram Transport = Layer Security (DTLS) =AD=20 Version 1.2," draftietftlsrfc4347bis00.txt, or "Transport Layer Security (T= LS) Extensions",=20 RFC 4366, or "Datagram Transport Layer Security (DTLS) =AD Version 1.0", R= FC 4347, or =20 "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for S= ecure Realtime=20 Transport Protocol (SRTP)", draftietfavtdtlssrtp05.txt or "Keying Material = Extractors for=20 Transport Layer Security (TLS)", draftietftlsextractor02.txt when used wit= h either:=20 =20 A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transpo= rt Layer=20 Security(TLS)" RFC 4492, May 2006; or,=20 B. "TLS Elliptic Curve Cipher Suites with SHA256/384 and AES Ga= lois Counter=20 Mode," RFC 5289, or=20 C. "Suite B Cipher Suites for TLS," draftrescorlatlssuiteb07.tx= t;=20 Do you have some reason to believe that extractors itself is encumbered abs= ent use of ECC? -Ekr From paul.hoffman@vpnc.org Wed May 13 08:20:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF5E3A6CC5 for ; Wed, 13 May 2009 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1MMLpRUYP6O for ; Wed, 13 May 2009 08:20:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8A83B3A6EF3 for ; Wed, 13 May 2009 08:20:34 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DFLwdh055044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 08:21:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87eiutnri9.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> Date: Wed, 13 May 2009 08:21:59 -0700 To: Simon Josefsson , "Joseph Salowey \(jsalowey\)" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 15:20:35 -0000 At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: >I don't support publishing tls-extractor on the standards track as long >as there are unclear patent threat against it and no acceptable free >software compatible patent license is available. This is absurd and obstructionist. You are saying that if anyone publishes an IPR statement about a work in progress, they can stop that document from becoming a standard. --Paul Hoffman, Director --VPN Consortium From Martin.Rex@sap.com Wed May 13 09:47:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E7F3A6947 for ; Wed, 13 May 2009 09:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HjLsPzabOma for ; Wed, 13 May 2009 09:47:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9E54B3A68C8 for ; Wed, 13 May 2009 09:47:31 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n4DGn2tw026149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 18:49:02 +0200 (MEST) From: Martin Rex Message-Id: <200905131649.n4DGn1T2009974@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Wed, 13 May 2009 18:49:01 +0200 (MEST) In-Reply-To: <87octxnsnp.fsf@mocca.josefsson.org> from "Simon Josefsson" at May 13, 9 01:34:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 16:47:32 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > Simon Josefsson wrote: > >> > >> That post does not relate to the #1004 patent disclosure. The post > >> refers to the January 2006 license, which did not reference TLS > >> exporter. The #1004 patent disclosure refers to the October 2008 > >> license. > > > > I'm confused. TLS exporters has nothing to do with ECC crypto > > or X.509 certificates. It is about a PRF and a shared secret > > and random challenges between the TLS communication peers. > > That is right, but the #1004 patent disclosure claims to cover > tls-extractor. Could someone please ask Certicom to remove TLS-extractors from their IPR claim / IPR disclosure? To me, this claim sound ridiculous (assuming their patent claims are purely about patents around EC crypto). Can Bayer raise patent claims for a human being who has been treated with CiproBay? Or can Monsanto raise a patent claim for a human being who processed (i.e. ate and digested) roundup-ready corn? If such claims are really possible in the US, then you do have a problem with your patent system over there. -Martin From paul.hoffman@vpnc.org Wed May 13 09:59:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2F43A6C63 for ; Wed, 13 May 2009 09:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ljbbC57H3Mw for ; Wed, 13 May 2009 09:59:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0CBD83A6941 for ; Wed, 13 May 2009 09:59:48 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DH1IeQ063740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 10:01:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200905131649.n4DGn1T2009974@fs4113.wdf.sap.corp> References: <200905131649.n4DGn1T2009974@fs4113.wdf.sap.corp> Date: Wed, 13 May 2009 10:01:16 -0700 To: martin.rex@sap.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 16:59:50 -0000 At 6:49 PM +0200 5/13/09, Martin Rex wrote: >Could someone please ask Certicom to remove TLS-extractors from >their IPR claim / IPR disclosure? This might best be done by someone who works for a large vendor who has a business relationship with Certicom or their parent, RIM (hint, hint). >To me, this claim sound ridiculous (assuming their patent claims >are purely about patents around EC crypto). Why is what you think (or what I think) about their IPR relevant to the write-up? Joe is reporting that there is an IPR statement in which the draft is mentioned. That is a factual statement, even if it is unfortunate. --Paul Hoffman, Director --VPN Consortium From simon@josefsson.org Wed May 13 10:26:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BC63A6E24 for ; Wed, 13 May 2009 10:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4WBIefy+Q+l for ; Wed, 13 May 2009 10:26:19 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 250303A6FC9 for ; Wed, 13 May 2009 10:26:16 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M4IF7-0001Dc-0a; Wed, 13 May 2009 19:27:45 +0200 From: Simon Josefsson To: Eric Rescorla References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090513:ekr@networkresonance.com::XkyS0tDGneX9cLu0:0S6V X-Hashcash: 1:22:090513:tls@ietf.org::4tRTL0ElSFXHOtju:THPi Date: Wed, 13 May 2009 19:27:42 +0200 In-Reply-To: <20090513151244.2668950822@romeo.rtfm.com> (Eric Rescorla's message of "Wed, 13 May 2009 08:12:44 -0700") Message-ID: <87tz3okj5d.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 17:26:20 -0000 Eric Rescorla writes: > Do you have some reason to believe that extractors itself is encumbered absent > use of ECC? Some of the patents quoted by Certicom in that PDF do not appear to be specific to ECC. There is no analysis that they don't apply to tls-extractor. /Simon From simon@josefsson.org Wed May 13 10:27:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1750D3A6D67 for ; Wed, 13 May 2009 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN-Mi6YEaMJC for ; Wed, 13 May 2009 10:27:09 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2EA0F3A6CBE for ; Wed, 13 May 2009 10:27:09 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M4IFv-0001Dh-GG; Wed, 13 May 2009 19:28:36 +0200 From: Simon Josefsson To: Paul Hoffman References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090513:paul.hoffman@vpnc.org::pMQxxie0Jd0SG7hC:16oY X-Hashcash: 1:22:090513:jsalowey@cisco.com::iC/xZAiS1LKYPGp6:HraN X-Hashcash: 1:22:090513:tls@ietf.org::80mmM3k/VEk2bUkn:wOrV Date: Wed, 13 May 2009 19:28:34 +0200 In-Reply-To: (Paul Hoffman's message of "Wed\, 13 May 2009 08\:21\:59 -0700") Message-ID: <87preckj3x.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 17:27:10 -0000 Paul Hoffman writes: > At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: >>I don't support publishing tls-extractor on the standards track as long >>as there are unclear patent threat against it and no acceptable free >>software compatible patent license is available. > > This is absurd and obstructionist. You are saying that if anyone > publishes an IPR statement about a work in progress, they can stop > that document from becoming a standard. I'm absolutely not saying that. Please re-read what I wrote. /Simon From paul.hoffman@vpnc.org Wed May 13 10:57:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D423A67D1 for ; Wed, 13 May 2009 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp8aZDXe+uVj for ; Wed, 13 May 2009 10:57:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4D9C13A6962 for ; Wed, 13 May 2009 10:57:43 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DHxCTN068788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 10:59:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87preckj3x.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> Date: Wed, 13 May 2009 10:59:11 -0700 To: Simon Josefsson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 17:57:44 -0000 At 7:28 PM +0200 5/13/09, Simon Josefsson wrote: >Paul Hoffman writes: > >> At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: >>>I don't support publishing tls-extractor on the standards track as long > >>as there are unclear patent threat against it and no acceptable free > >>software compatible patent license is available. >> >> This is absurd and obstructionist. You are saying that if anyone >> publishes an IPR statement about a work in progress, they can stop >> that document from becoming a standard. > >I'm absolutely not saying that. Please re-read what I wrote. You are and I did, carefully. You know full well that any IPR statement in the IETF can be considered an "unclear patent threat" by many people. Further, you know that the phrase "no acceptable free software compatible patent license" is unclear to many IETF participants, much less to many patent owners. Given your two restrictions, I believe my statement is true. --Paul Hoffman, Director --VPN Consortium From simon@josefsson.org Wed May 13 11:42:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12983A6AB2 for ; Wed, 13 May 2009 11:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf7NfA5NuX8i for ; Wed, 13 May 2009 11:42:00 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id E92F83A69EC for ; Wed, 13 May 2009 11:41:59 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1M4JQQ-0001ET-0w; Wed, 13 May 2009 20:43:30 +0200 From: Simon Josefsson To: Paul Hoffman References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090513:paul.hoffman@vpnc.org::U1maQfC/QaTcbNPn:4AkW X-Hashcash: 1:22:090513:tls@ietf.org::cJAP25hrwiGZybVg:ICGU Date: Wed, 13 May 2009 20:43:28 +0200 In-Reply-To: (Paul Hoffman's message of "Wed\, 13 May 2009 10\:59\:11 -0700") Message-ID: <87k54kkfn3.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 18:42:00 -0000 Paul Hoffman writes: > At 7:28 PM +0200 5/13/09, Simon Josefsson wrote: >>Paul Hoffman writes: >> >>> At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: >>>>I don't support publishing tls-extractor on the standards track as long >> >>as there are unclear patent threat against it and no acceptable free >> >>software compatible patent license is available. >>> >>> This is absurd and obstructionist. You are saying that if anyone >>> publishes an IPR statement about a work in progress, they can stop >>> that document from becoming a standard. >> >>I'm absolutely not saying that. Please re-read what I wrote. > > You are and I did, carefully. > > You know full well that any IPR statement in the IETF can be > considered an "unclear patent threat" by many people. Further, you > know that the phrase "no acceptable free software compatible patent > license" is unclear to many IETF participants, much less to many > patent owners. > > Given your two restrictions, I believe my statement is true. Those two restrictions are something you invented, they are not in what I wrote and they are not what I intended. Conveniently, the restrictions you carefully chose made your statement true. The patent threat and patent license is unclear _to me_ and _right now_. That is sufficient for me to not support publishing the document at this point. WG's should discuss patent disclaimers and decide whether to live with the problem or not. That discussion had not taken place for tls-extractor before the proto-writeup was posted. I'm hoping the discussion will provide more grounds to base the decision on. The IETF needs to carefully weight patent threats when considering standardization. I believe implying that such considerations are obstructions hurt the credibility of the IETF as a standardization body for the Internet. /Simon From paul.hoffman@vpnc.org Wed May 13 12:53:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8C33A6FBE for ; Wed, 13 May 2009 12:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waW7Un4A9RSf for ; Wed, 13 May 2009 12:53:39 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C10133A6E5C for ; Wed, 13 May 2009 12:53:09 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DJsGkK077502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 12:54:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87k54kkfn3.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> <87k54kkfn3.fsf@mocca.josefsson.org> Date: Wed, 13 May 2009 12:54:15 -0700 To: Simon Josefsson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 19:53:40 -0000 At 8:43 PM +0200 5/13/09, Simon Josefsson wrote: >Paul Hoffman writes: > >> At 7:28 PM +0200 5/13/09, Simon Josefsson wrote: >>>Paul Hoffman writes: >>> >>>> At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: >>>>>I don't support publishing tls-extractor on the standards track as long > >> >>as there are unclear patent threat against it and no acceptable free >>> >>software compatible patent license is available. >>>> >>>> This is absurd and obstructionist. You are saying that if anyone >>>> publishes an IPR statement about a work in progress, they can stop >>>> that document from becoming a standard. >>> >>>I'm absolutely not saying that. Please re-read what I wrote. >> >> You are and I did, carefully. >> >> You know full well that any IPR statement in the IETF can be >> considered an "unclear patent threat" by many people. Further, you > > know that the phrase "no acceptable free software compatible patent > > license" is unclear to many IETF participants, much less to many >> patent owners. >> >> Given your two restrictions, I believe my statement is true. > >Those two restrictions are something you invented, they are not in what >I wrote Wait, what?!? Are you saying that I lied in the text at the top of this message, and that the official archive of your message at is also lying? >and they are not what I intended. Well, that is certainly believable. > Conveniently, the >restrictions you carefully chose made your statement true. The patent >threat and patent license is unclear _to me_ and _right now_. That is >sufficient for me to not support publishing the document at this point. That's not what you said. Further, it is still absurd and obstructionist to say that a document cannot be published on standards track as long as someone thinks it has one or more "unclear patent threat against it". Anyone can write an IPR statement that is unclear to someone. >WG's should discuss patent disclaimers and decide whether to live with >the problem or not. Sure. However, such discussions should not hinge on whether anyone finds the threat unclear. Nor should they hinge on how different people interpret acceptable free software compatible patent license". >That discussion had not taken place for >tls-extractor before the proto-writeup was posted. I'm hoping the >discussion will provide more grounds to base the decision on. Some people would find that starting this with un-meetable demands is not conducive to a discussion. >The IETF needs to carefully weight patent threats when considering >standardization. No, we don't. You have been repeatedly on the losing side of this discussion in the IPR WG. Bringing it up in every WG you follow does not change that fact. >I believe implying that such considerations are >obstructions hurt the credibility of the IETF as a standardization body >for the Internet. In whose eyes will the IETF's credibility be enhanced by re-opening this discussion every time you want it to? --Paul Hoffman, Director --VPN Consortium From n.mavrogiannopoulos@gmail.com Wed May 13 14:33:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7E73A6C11 for ; Wed, 13 May 2009 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG58azfe1KHR for ; Wed, 13 May 2009 14:33:15 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 76EEC3A69E6 for ; Wed, 13 May 2009 14:33:15 -0700 (PDT) Received: by fxm2 with SMTP id 2so921823fxm.37 for ; Wed, 13 May 2009 14:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=HZ6VquashqUNnSSNYgHDENgrsU18CM7EKxuaflt7gdk=; b=fOXKo1YSPYbzYRViFHVIvVBz37bJpm36Wj1P+TaUGrtbo8/8I8Pv7E+O7byfbmCrpH P4KYcLgm/ro02QqSTN8J7/4eiTJ8Fg/q1i91zTWFzKSDsd6abGhZjxio2EKcqDkTj6iN G2blZwFfYrJJjp3BDdXhrESpgHrILuW2g3F7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WgiVOx0WIAagieXbuFKcleSEQvDMTmv6eWrFHHo3IZaOzvdZUWXGkxcouDfwGCho1i dCdcQ48pZlatwV8C/v9eufqVKIlClEsiMNrvG9TKwlAI4AVz3nW0N27NxfAOfgof5wlF KLNi4RqRNUedb9XNbnmvG1YJ28R5WoHJ3zr2Y= MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.204.118.69 with SMTP id u5mr1340651bkq.77.1242250485274; Wed, 13 May 2009 14:34:45 -0700 (PDT) In-Reply-To: References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> <87k54kkfn3.fsf@mocca.josefsson.org> Date: Thu, 14 May 2009 00:34:45 +0300 X-Google-Sender-Auth: 8be5cb890af1da23 Message-ID: From: Nikos Mavrogiannopoulos To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 21:33:16 -0000 On Wed, May 13, 2009 at 10:54 PM, Paul Hoffman wrot= e: >> Conveniently, the >>restrictions you carefully chose made your statement true. =A0The patent >>threat and patent license is unclear _to me_ and _right now_. =A0That is >>sufficient for me to not support publishing the document at this point. > > That's not what you said. > > Further, it is still absurd and obstructionist to say that a document can= not be published on standards track as long as someone thinks it has one or= more "unclear patent threat against it". Anyone can write an IPR statement= that is unclear to someone. As far as I remember this was the consensus of this WG for the TLS-SRP now informational RFC. Once someone submitted an unclear patent thread against it, the WG decided not to move forward as a standards track, rather as informational. http://www.ietf.org/mail-archive/web/tls/current/msg01215.html >>WG's should discuss patent disclaimers and decide whether to live with >>the problem or not. > Sure. However, such discussions should not hinge on whether anyone finds = the threat unclear. Nor should they hinge on how different people interpret= acceptable free software compatible patent license". I do not understand the comments about. If it is some rant on free software I do not bother even discussing them. >>The IETF needs to carefully weight patent threats when considering >>standardization. > > No, we don't. You have been repeatedly on the losing side of this discuss= ion in the IPR WG. Bringing it up in every WG you follow does not change th= at fact. Nevertheless I see no reason not to bring it up if he thinks it the problem is there. . regards, Nikos From paul.hoffman@vpnc.org Wed May 13 15:52:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1E13A6E47 for ; Wed, 13 May 2009 15:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQSB+nXQIzNw for ; Wed, 13 May 2009 15:52:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3ED6F3A6AF1 for ; Wed, 13 May 2009 15:52:11 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DMrJdM089776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 15:53:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> <87k54kkfn3.fsf@mocca.josefsson.org> Date: Wed, 13 May 2009 15:53:18 -0700 To: Nikos Mavrogiannopoulos From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 22:52:13 -0000 At 12:34 AM +0300 5/14/09, Nikos Mavrogiannopoulos wrote: >On Wed, May 13, 2009 at 10:54 PM, Paul Hoffman wrote: > >>> Conveniently, the >>>restrictions you carefully chose made your statement true. The patent >>>threat and patent license is unclear _to me_ and _right now_. That is >>>sufficient for me to not support publishing the document at this point. >> >> That's not what you said. >> >> Further, it is still absurd and obstructionist to say that a document cannot be published on standards track as long as someone thinks it has one or more "unclear patent threat against it". Anyone can write an IPR statement that is unclear to someone. > >As far as I remember this was the consensus of this WG for the TLS-SRP >now informational RFC. Once someone submitted an unclear patent thread >against it, the WG decided not to move forward as a standards track, >rather as informational. On review of the archives, I disagree that the choice to go for Informational was because the patent status was unclear. It seemed that many people thought the status was clear and negative for standardization. This is, of course, subjective on my part. --Paul Hoffman, Director --VPN Consortium From ekr@networkresonance.com Wed May 13 15:55:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A0D3A6B83 for ; Wed, 13 May 2009 15:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YBUxr-W+w3c for ; Wed, 13 May 2009 15:55:33 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 72C993A6AF1 for ; Wed, 13 May 2009 15:55:33 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CF7C650822; Wed, 13 May 2009 16:00:17 -0700 (PDT) Date: Wed, 13 May 2009 16:00:17 -0700 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87tz3okj5d.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.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: <20090513230017.CF7C650822@romeo.rtfm.com> Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 13 May 2009 22:55:34 -0000 At Wed, 13 May 2009 19:27:42 +0200, Simon Josefsson wrote: > > Eric Rescorla writes: > > > Do you have some reason to believe that extractors itself is encumbered absent > > use of ECC? > > Some of the patents quoted by Certicom in that PDF do not appear to be > specific to ECC. There is no analysis that they don't apply to > tls-extractor. Again, the disclosure seems pretty clear to me. Namely, it states that the named documents apply "when used with... " So, again, I ask, "Do you have some reason to believe that extractors itself is encumbered absent use of ECC?" -Ekr From simon@josefsson.org Thu May 14 01:43:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A5A3A6F06 for ; Thu, 14 May 2009 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc1eRmozs+69 for ; Thu, 14 May 2009 01:43:13 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id C06FC3A6B93 for ; Thu, 14 May 2009 01:43:10 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4E8iTf3001074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 10:44:35 +0200 From: Simon Josefsson To: Paul Hoffman References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> <87k54kkfn3.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090514:paul.hoffman@vpnc.org::aFIVQXMwhfJppMU9:14g2 X-Hashcash: 1:22:090514:tls@ietf.org::i77W7gt/E6M3aZlx:BRCy Date: Thu, 14 May 2009 10:44:28 +0200 In-Reply-To: (Paul Hoffman's message of "Wed\, 13 May 2009 12\:54\:15 -0700") Message-ID: <877i0khy4z.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 08:43:14 -0000 Paul, allow me to explain what I originally intended and how you interpreted it: My position: I don't support tls-extractor on standards track if I believe there are unclear patent threats and/or no acceptable free software license. Your interpretation: Simon doesn't support tls-extractor on standards track as long as there is _someone_ that believes there are unclear patent threats and/or no acceptable free software licenses. I stand by my position. Your interpretation of what I said is not what I intended and I completely disagree with that interpretation. Don't put those words in my mouth. I agree that your interpretation is counter-productive. English isn't my native tongue, but even after re-reading what I wrote I don't see it saying what you believe it said. > Further, it is still absurd and obstructionist to say that a document > cannot be published on standards track as long as someone thinks it > has one or more "unclear patent threat against it". Anyone can write > an IPR statement that is unclear to someone. Sure, and that act should rightly delay publication until it has been discussed. I believe the patent disclaimer needs to be considered before publication. That does not mean it should stop the document. /Simon From simon@josefsson.org Thu May 14 02:15:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B537528C232 for ; Thu, 14 May 2009 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se+kwtz3WdA1 for ; Thu, 14 May 2009 02:15:34 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8201328C1DD for ; Thu, 14 May 2009 02:15:34 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4E9H2oU001114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 11:17:04 +0200 From: Simon Josefsson To: Eric Rescorla References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090514:ekr@networkresonance.com::LqptkZq8uyhZEHqV:0S1e X-Hashcash: 1:22:090514:tls@ietf.org::fPh6wYwaDeyPY0ny:1yLf Date: Thu, 14 May 2009 11:17:02 +0200 In-Reply-To: <20090513230017.CF7C650822@romeo.rtfm.com> (Eric Rescorla's message of "Wed, 13 May 2009 16:00:17 -0700") Message-ID: <87zldggi29.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 09:15:35 -0000 Eric Rescorla writes: > At Wed, 13 May 2009 19:27:42 +0200, > Simon Josefsson wrote: >> >> Eric Rescorla writes: >> >> > Do you have some reason to believe that extractors itself is encumbered absent >> > use of ECC? >> >> Some of the patents quoted by Certicom in that PDF do not appear to be >> specific to ECC. There is no analysis that they don't apply to >> tls-extractor. > > Again, the disclosure seems pretty clear to me. Namely, > it states that the named documents apply "when used with... > " > > So, again, I ask, "Do you have some reason to believe that extractors > itself is encumbered absent use of ECC?" I believe the PDF is a reason, at least without more information. My reasoning is as follows: The patent disclaimer filed with the IETF lists tls-extractor as one document that Certicom believes is covered by their patents. The PDF only covers when ECC is used. The PDF does not assert anything about non-ECC purposes. This allows Certicom to claim that the tls-extractor document is covered by their patents for non-ECC uses in the future. That claim would not be inconsistent with the information filed with the IETF so far. That is the loophole I'm concerned with. My inclination is to be conservative about assuming the intentions of patent holders without at least public statement to the contrary. /Simon From Pasi.Eronen@nokia.com Thu May 14 04:12:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093933A6C57 for ; Thu, 14 May 2009 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06sHwKcgbieB for ; Thu, 14 May 2009 04:12:27 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 048E33A67AA for ; Thu, 14 May 2009 04:12:26 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4EBDhD0010984; Thu, 14 May 2009 06:13:54 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 14:13:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 14:13:23 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 14 May 2009 13:13:23 +0200 From: To: , Date: Thu, 14 May 2009 13:13:22 +0200 Thread-Topic: Working Group Last Call for draft-ietf-tls-rfc4366-bis-04 Thread-Index: AcnE65aKNrAuthy3SxGjc6f6KpJ5igPmUbWA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2623C30@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 May 2009 11:13:23.0818 (UTC) FILETIME=[FF255CA0:01C9D484] X-Nokia-AV: Clean Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-rfc4366-bis-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 11:12:28 -0000 The document should have a section (perhaps after current 1.1) listing changes vs. RFC 4366 (making the hash in certificate_url mandatory; fixing handling of IDNs in server_name). There are also a couple of places that probably need some small=20 clarifications: - Section 7, 1st sentence ("Currently defined TLS cipher suites use the MAC construction HMAC with either MD5 or SHA-1 [RFC2104] to authenticate record layer communications") is not accurate any more. - Section 11, last sentence, should point to the TLS 1.2 RFC instead of 1.0/1.1. - In Section 11.3, just replacing "There are two major issues.." with "There were two major issues.." is confusing. We don't really need several paragraphs to describe a security issue that does not exist (although we might want to mention it in the "changes since RFC 4366" section), and the second issue still exists. Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Joseph Salowey (jsalowey) > Sent: 24 April, 2009 17:47 > To: TLS@ietf.org > Subject: [TLS] Working Group Last Call for draft-ietf-tls-rfc4366-bis- > 04 >=20 > This is a working group last call for comments on > draft-ietf-tls-rfc4366-bis-04 prior to sending this document on to the > IESG for publication as a proposed standard RFC. The document and > revision history can be found here: >=20 > http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-04 >=20 >=20 > Please send any comments to the list by May 15, 2009. >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ekr@networkresonance.com Thu May 14 06:58:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2654B3A6F33 for ; Thu, 14 May 2009 06:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmR0F5VzHvJ2 for ; Thu, 14 May 2009 06:58:39 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 268C73A6EFB for ; Thu, 14 May 2009 06:58:39 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E84F51A401F; Thu, 14 May 2009 07:04:37 -0700 (PDT) Date: Thu, 14 May 2009 07:04:37 -0700 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87zldggi29.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.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: <20090514140437.E84F51A401F@kilo.networkresonance.com> Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 13:58:40 -0000 At Thu, 14 May 2009 11:17:02 +0200, Simon Josefsson wrote: > > Eric Rescorla writes: > > > At Wed, 13 May 2009 19:27:42 +0200, > > Simon Josefsson wrote: > >> > >> Eric Rescorla writes: > >> > >> > Do you have some reason to believe that extractors itself is encumbered absent > >> > use of ECC? > >> > >> Some of the patents quoted by Certicom in that PDF do not appear to be > >> specific to ECC. There is no analysis that they don't apply to > >> tls-extractor. > > > > Again, the disclosure seems pretty clear to me. Namely, > > it states that the named documents apply "when used with... > > " > > > > So, again, I ask, "Do you have some reason to believe that extractors > > itself is encumbered absent use of ECC?" > > I believe the PDF is a reason, at least without more information. My > reasoning is as follows: > > The patent disclaimer filed with the IETF lists tls-extractor as one > document that Certicom believes is covered by their patents. > > The PDF only covers when ECC is used. > > The PDF does not assert anything about non-ECC purposes. > > This allows Certicom to claim that the tls-extractor document is covered > by their patents for non-ECC uses in the future. That claim would not > be inconsistent with the information filed with the IETF so far. That > is the loophole I'm concerned with. While, this is of course true, it's also possible that some other entity which doesn't participate in IETF at all has patents that apply to extractor. That wouldn't be inconsistent with the information filed with the IETF either. Either you think that Certicom has a BCP 79 obligation to accurately disclose their patents or they don't. If you do, I think it's reasonable to conclude that when they say "our patents may cover X" that they don't believe their patents cover !X. If you don't, then we could equally well conclude that their patents may cover drafts they don't even mention. -Ekr From mbadra@gmail.com Thu May 14 07:08:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9373A6CE3 for ; Thu, 14 May 2009 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK7r9JrgaXbL for ; Thu, 14 May 2009 07:08:31 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id E214C3A688B for ; Thu, 14 May 2009 07:08:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so402883fge.18 for ; Thu, 14 May 2009 07:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=F87hCyRzz6s1ZndykYYXVUJ6QjwDL5xJvIbjux6Kq8U=; b=mTSiWNCFAkma2t7sNeTyK2zaTwyrYflA7GVhS0B0iwtZLTMm6buu6P0oG7OhuUAZQX q3cJEs8n2rLfK5OH8ct/62fhfrk8ikgKvIY6zcqjzfaIdGqSA7cGEjjp+BOPT/98fn/B AJm7+qxtcDAnXx0aPAOav1r0DSy9uruJldy4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=L/gzt10l7AM/r29EmxjuukSGhy4dgLZ2heJ4nzy6fHF9AbbtvgENUGlamkVFhS2O+f OfuldLXK4XlfOr7GNA0HLt9GibZCUGBTSZr4G6/L9S5K9RwGfwzSYe0J4Z65fGHEWi7a F9HusyzQ2gf5lT/cWQe9ivGX7opBTmgi9Yrxk= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.61.18 with SMTP id j18mr2543089fga.68.1242310201682; Thu, 14 May 2009 07:10:01 -0700 (PDT) In-Reply-To: <20090514140437.E84F51A401F@kilo.networkresonance.com> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> Date: Thu, 14 May 2009 16:10:01 +0200 X-Google-Sender-Auth: c61e29f7e9921688 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=000e0cd289d845ad090469dfe20a Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:08:32 -0000 --000e0cd289d845ad090469dfe20a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > This allows Certicom to claim that the tls-extractor document is covered > > by their patents for non-ECC uses in the future. That claim would not > > be inconsistent with the information filed with the IETF so far. That > > is the loophole I'm concerned with. > > While, this is of course true, it's also possible that some other > entity which doesn't participate in IETF at all has patents that apply > to extractor. That wouldn't be inconsistent with the information filed > with the IETF either. > > Either you think that Certicom has a BCP 79 obligation to accurately > disclose their patents or they don't. If you do, I think it's > reasonable to conclude that when they say "our patents may cover > X" that they don't believe their patents cover !X. If you don't, > then we could equally well conclude that their patents may > cover drafts they don't even mention. May it be possible for the draft's authors to review the related Certicom's patents and conclude whatever they are or aren't related to the document in question? Best regards, Badra --000e0cd289d845ad090469dfe20a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> This allows Certicom to claim that the tls-extractor document is cover= ed
> by their patents for non-ECC uses in the future. =A0That claim would n= ot
> be inconsistent with the information filed with the IETF so far. =A0Th= at
> is the loophole I'm concerned with.

While, this is of course true, it's also possible that some= other
entity which doesn't participate in IETF at all has patents that apply<= br> to extractor. That wouldn't be inconsistent with the information filed<= br> with the IETF either.

Either you think that Certicom has a BCP 79 obligation to accurately
disclose their patents or they don't. If you do, I think it's
reasonable to conclude that when they say "our patents may cover
X" that they don't believe their patents cover !X. If you don'= t,
then we could equally well conclude that their patents may
cover drafts they don't even mention.


May it b= e possible for the draft's authors to review the related Certicom's= patents and conclude whatever they are or aren't related to the docume= nt in question?

Best regards,
Badra

--000e0cd289d845ad090469dfe20a-- From WWhyte@ntru.com Thu May 14 07:14:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75CE28C281 for ; Thu, 14 May 2009 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.021 X-Spam-Level: * X-Spam-Status: No, score=1.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDwQhswyLAEe for ; Thu, 14 May 2009 07:14:26 -0700 (PDT) Received: from homer.ntru.com (static-96-237-178-19.bstnma.fios.verizon.net [96.237.178.19]) by core3.amsl.com (Postfix) with ESMTP id 3936928C248 for ; Thu, 14 May 2009 07:14:25 -0700 (PDT) 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: Thu, 14 May 2009 10:15:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUneGad80lrwxOS2adHnSH3UJsewAAHqQA References: <87preeqpma.fsf@mocca.josefsson.org><20090513151244.2668950822@romeo.rtfm.com><87tz3okj5d.fsf@mocca.josefsson.org><20090513230017.CF7C650822@romeo.rtfm.com><87zldggi29.fsf@mocca.josefsson.org><20090514140437.E84F51A401F@kilo.networkresonance.com> From: "Whyte, William" To: "Badra" , "Eric Rescorla" Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:14:27 -0000 > May it be possible for the draft's authors to review the > related Certicom's patents and conclude whatever they are > or aren't related to the document in question? Surely it'd be more efficient to ask Certicom for a revised IPR making it clear whether or not they consider their=20 patents to cover the draft in the absence of ECC. William From paul.hoffman@vpnc.org Thu May 14 07:19:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE103A6F63 for ; Thu, 14 May 2009 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6r+r3w1iHQm for ; Thu, 14 May 2009 07:19:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 530C13A6F30 for ; Thu, 14 May 2009 07:19:33 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EEL2re050936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 07:21:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <877i0khy4z.fsf@mocca.josefsson.org> References: <87preeqpma.fsf@mocca.josefsson.org> <87eiutnri9.fsf@mocca.josefsson.org> <87preckj3x.fsf@mocca.josefsson.org> <87k54kkfn3.fsf@mocca.josefsson.org> <877i0khy4z.fsf@mocca.josefsson.org> Date: Thu, 14 May 2009 07:21:01 -0700 To: Simon Josefsson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:19:34 -0000 At 10:44 AM +0200 5/14/09, Simon Josefsson wrote: >Paul, allow me to explain what I originally intended and how you >interpreted it: > >My position: I don't support tls-extractor on standards track if I >believe there are unclear patent threats and/or no acceptable free >software license. Ah. That is good to hear. It certainly was not clear from your original message. >Your interpretation: Simon doesn't support tls-extractor on standards >track as long as there is _someone_ that believes there are unclear >patent threats and/or no acceptable free software licenses. Yes, that is how I (and others offline) interpreted it. Very glad to hear we were wrong. >I stand by my position. Your interpretation of what I said is not what >I intended and I completely disagree with that interpretation. Don't >put those words in my mouth. I agree that your interpretation is >counter-productive. English isn't my native tongue, but even after >re-reading what I wrote I don't see it saying what you believe it said. We can simply agree to disagree on that last part. As for your English: I have absolutely no criticisms of it. I always appreciate people who use English as a second language, given that I have no second language. I also know that I am quite lucky to have English as my first language, and to be a professional writer in it. > > Further, it is still absurd and obstructionist to say that a document >> cannot be published on standards track as long as someone thinks it >> has one or more "unclear patent threat against it". Anyone can write >> an IPR statement that is unclear to someone. > >Sure, and that act should rightly delay publication until it has been >discussed. I believe the patent disclaimer needs to be considered >before publication. That does not mean it should stop the document. That works for me. --Paul Hoffman, Director --VPN Consortium From uri@ll.mit.edu Thu May 14 07:30:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747D728C280 for ; Thu, 14 May 2009 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAt74CVKDwvb for ; Thu, 14 May 2009 07:30:29 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 77C913A6EFD for ; Thu, 14 May 2009 07:30:29 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n4EEVo2Z025110 for ; Thu, 14 May 2009 10:31:50 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA9DaiJr; Thu May 14 10:21:35 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 14 May 2009 10:21:35 -0400 From: "Blumenthal, Uri" To: "'TLS@ietf.org'" Date: Thu, 14 May 2009 10:21:34 -0400 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUnGdkouIueqMhQ3SR7hqdjQc8kAAAuGMo Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A631F21E1@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:30:30 -0000 RXJpYywNCg0KVGhlIHByb2JsZW0gaXMgKGlmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHkpIHRo YXQgKGEpIHRoZXJlIGlzIENlcnRpY29tJ3MgUERGIGRlc2NyaWJpbmcgQ2VydGljb20ncyBFQ0Mt cmVsYXRlZCBjbGFpbXMsIGFuZCAoYikgQ2VydGljb20ncyBleHRyYWN0b3ItcmVsYXRlZCBjbGFp bXMgdGhhdCBkbyBub3QgZXhwbGljaXRseSByZWZlciB0byBvciBjb25zdHJhaW4gdGhlbXNlbHZl cyB3aXRoIHRoZSBhYm92ZSBQREYgYm91bmRhcmllcy4NCg0KVGh1cyBpdCBpcyB1bmNsZWFyIChh dCBsZWFzdCB3aXRob3V0IGFuIGV4cGxpY2l0IHN0YXRlbWVudCBmcm9tIENlcnRpY29tKSB3aGV0 aGVyIHRoZWlyIHRscy1leHRyYWN0b3IgY2xhaW1zIGFyZSBvciBhcmUgbm90IGV4Y2x1c2l2ZWx5 IEVDQy1yZWxhdGVkLiANCg0KSW4gYWJzZW5jZSBvZiBzdWNoIHN0YXRlbWVudCBJIHNwZWFrIGFn YWluc3QgcGxhY2luZyB0aGlzIGRyYWZ0IG9uIGEgc3RhbmRhcmRzIHRyYWNrLg0KDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMt Ym91bmNlc0BpZXRmLm9yZz4NClRvOiBTaW1vbiBKb3NlZnNzb24gPHNpbW9uQGpvc2Vmc3Nvbi5v cmc+DQpDYzogVExTQGlldGYub3JnIDxUTFNAaWV0Zi5vcmc+DQpTZW50OiBUaHUgTWF5IDE0IDEw OjA0OjM3IDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIFByb3RvIHdyaXRlLXVwIGZvciBUTFMgZXhw b3J0ZXINCg0KQXQgVGh1LCAxNCBNYXkgMjAwOSAxMToxNzowMiArMDIwMCwNClNpbW9uIEpvc2Vm c3NvbiB3cm90ZToNCj4gDQo+IEVyaWMgUmVzY29ybGEgPGVrckBuZXR3b3JrcmVzb25hbmNlLmNv bT4gd3JpdGVzOg0KPiANCj4gPiBBdCBXZWQsIDEzIE1heSAyMDA5IDE5OjI3OjQyICswMjAwLA0K PiA+IFNpbW9uIEpvc2Vmc3NvbiB3cm90ZToNCj4gPj4gDQo+ID4+IEVyaWMgUmVzY29ybGEgPGVr ckBuZXR3b3JrcmVzb25hbmNlLmNvbT4gd3JpdGVzOg0KPiA+PiANCj4gPj4gPiBEbyB5b3UgaGF2 ZSBzb21lIHJlYXNvbiB0byBiZWxpZXZlIHRoYXQgZXh0cmFjdG9ycyBpdHNlbGYgaXMgZW5jdW1i ZXJlZCBhYnNlbnQNCj4gPj4gPiB1c2Ugb2YgRUNDPw0KPiA+PiANCj4gPj4gU29tZSBvZiB0aGUg cGF0ZW50cyBxdW90ZWQgYnkgQ2VydGljb20gaW4gdGhhdCBQREYgZG8gbm90IGFwcGVhciB0byBi ZQ0KPiA+PiBzcGVjaWZpYyB0byBFQ0MuICBUaGVyZSBpcyBubyBhbmFseXNpcyB0aGF0IHRoZXkg ZG9uJ3QgYXBwbHkgdG8NCj4gPj4gdGxzLWV4dHJhY3Rvci4NCj4gPg0KPiA+IEFnYWluLCB0aGUg ZGlzY2xvc3VyZSBzZWVtcyBwcmV0dHkgY2xlYXIgdG8gbWUuIE5hbWVseSwNCj4gPiBpdCBzdGF0 ZXMgdGhhdCB0aGUgbmFtZWQgZG9jdW1lbnRzIGFwcGx5ICJ3aGVuIHVzZWQgd2l0aC4uLg0KPiA+ IDx0aHJlZSBFQ0MtcmVsYXRlZCBkb2N1bWVudHM+Ig0KPiA+DQo+ID4gU28sIGFnYWluLCBJIGFz aywgIkRvIHlvdSBoYXZlIHNvbWUgcmVhc29uIHRvIGJlbGlldmUgdGhhdCBleHRyYWN0b3JzDQo+ ID4gaXRzZWxmIGlzIGVuY3VtYmVyZWQgYWJzZW50IHVzZSBvZiBFQ0M/Ig0KPiANCj4gSSBiZWxp ZXZlIHRoZSBQREYgaXMgYSByZWFzb24sIGF0IGxlYXN0IHdpdGhvdXQgbW9yZSBpbmZvcm1hdGlv bi4gIE15DQo+IHJlYXNvbmluZyBpcyBhcyBmb2xsb3dzOg0KPiANCj4gVGhlIHBhdGVudCBkaXNj bGFpbWVyIGZpbGVkIHdpdGggdGhlIElFVEYgbGlzdHMgdGxzLWV4dHJhY3RvciBhcyBvbmUNCj4g ZG9jdW1lbnQgdGhhdCBDZXJ0aWNvbSBiZWxpZXZlcyBpcyBjb3ZlcmVkIGJ5IHRoZWlyIHBhdGVu dHMuDQo+IA0KPiBUaGUgUERGIG9ubHkgY292ZXJzIHdoZW4gRUNDIGlzIHVzZWQuDQo+IA0KPiBU aGUgUERGIGRvZXMgbm90IGFzc2VydCBhbnl0aGluZyBhYm91dCBub24tRUNDIHB1cnBvc2VzLg0K PiANCj4gVGhpcyBhbGxvd3MgQ2VydGljb20gdG8gY2xhaW0gdGhhdCB0aGUgdGxzLWV4dHJhY3Rv ciBkb2N1bWVudCBpcyBjb3ZlcmVkDQo+IGJ5IHRoZWlyIHBhdGVudHMgZm9yIG5vbi1FQ0MgdXNl cyBpbiB0aGUgZnV0dXJlLiAgVGhhdCBjbGFpbSB3b3VsZCBub3QNCj4gYmUgaW5jb25zaXN0ZW50 IHdpdGggdGhlIGluZm9ybWF0aW9uIGZpbGVkIHdpdGggdGhlIElFVEYgc28gZmFyLiAgVGhhdA0K PiBpcyB0aGUgbG9vcGhvbGUgSSdtIGNvbmNlcm5lZCB3aXRoLg0KDQpXaGlsZSwgdGhpcyBpcyBv ZiBjb3Vyc2UgdHJ1ZSwgaXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgc29tZSBvdGhlcg0KZW50aXR5 IHdoaWNoIGRvZXNuJ3QgcGFydGljaXBhdGUgaW4gSUVURiBhdCBhbGwgaGFzIHBhdGVudHMgdGhh dCBhcHBseQ0KdG8gZXh0cmFjdG9yLiBUaGF0IHdvdWxkbid0IGJlIGluY29uc2lzdGVudCB3aXRo IHRoZSBpbmZvcm1hdGlvbiBmaWxlZA0Kd2l0aCB0aGUgSUVURiBlaXRoZXIuDQoNCkVpdGhlciB5 b3UgdGhpbmsgdGhhdCBDZXJ0aWNvbSBoYXMgYSBCQ1AgNzkgb2JsaWdhdGlvbiB0byBhY2N1cmF0 ZWx5DQpkaXNjbG9zZSB0aGVpciBwYXRlbnRzIG9yIHRoZXkgZG9uJ3QuIElmIHlvdSBkbywgSSB0 aGluayBpdCdzDQpyZWFzb25hYmxlIHRvIGNvbmNsdWRlIHRoYXQgd2hlbiB0aGV5IHNheSAib3Vy IHBhdGVudHMgbWF5IGNvdmVyDQpYIiB0aGF0IHRoZXkgZG9uJ3QgYmVsaWV2ZSB0aGVpciBwYXRl bnRzIGNvdmVyICFYLiBJZiB5b3UgZG9uJ3QsDQp0aGVuIHdlIGNvdWxkIGVxdWFsbHkgd2VsbCBj b25jbHVkZSB0aGF0IHRoZWlyIHBhdGVudHMgbWF5DQpjb3ZlciBkcmFmdHMgdGhleSBkb24ndCBl dmVuIG1lbnRpb24uIA0KDQotRWtyDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From simon@josefsson.org Thu May 14 07:46:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5603F28C291 for ; Thu, 14 May 2009 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-T5u71a0hyu for ; Thu, 14 May 2009 07:46:46 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8C6793A6F56 for ; Thu, 14 May 2009 07:46:10 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4EElcas001832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 16:47:40 +0200 From: Simon Josefsson To: Eric Rescorla References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090514:tls@ietf.org::oiJv7Dcp/7nDo6pc:TN/K X-Hashcash: 1:22:090514:ekr@networkresonance.com::I/Kh4KcvTsPd6IRG:k+15 Date: Thu, 14 May 2009 16:47:38 +0200 In-Reply-To: <20090514140437.E84F51A401F@kilo.networkresonance.com> (Eric Rescorla's message of "Thu, 14 May 2009 07:04:37 -0700") Message-ID: <87ws8jd9md.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:46:47 -0000 Eric Rescorla writes: > While, this is of course true, it's also possible that some other > entity which doesn't participate in IETF at all has patents that apply > to extractor. That wouldn't be inconsistent with the information filed > with the IETF either. Agreed. > Either you think that Certicom has a BCP 79 obligation to accurately > disclose their patents or they don't. Companies do not have obligations per BCP 79, individuals do. > If you do, I think it's reasonable to conclude that when they say "our > patents may cover X" that they don't believe their patents cover > !X. I don't believe that is relevant -- in this case, Certicom has filed a claim that they have patents that covers the tls-extractor document. Full stop. The additional information provided with the patent disclosure contains advertisement and a patent license for use with ECC. That doesn't imply anything for non-ECC uses. > If you don't, then we could equally well conclude that their patents > may cover drafts they don't even mention. That does not follow, but there is nothing in BCP 79 to prevent that situation from happening. /Simon From ekr@networkresonance.com Thu May 14 07:54:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF43F28C27F for ; Thu, 14 May 2009 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gInlC1Eap8PW for ; Thu, 14 May 2009 07:54:30 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 136C728C26E for ; Thu, 14 May 2009 07:54:30 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BC73E50822; Thu, 14 May 2009 07:59:15 -0700 (PDT) Date: Thu, 14 May 2009 07:59:15 -0700 From: Eric Rescorla To: "Blumenthal, Uri" In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E46A631F21E1@LLE2K7-BE01.mitll.ad.local> References: <90E934FC4BBC1946B3C27E673B4DB0E46A631F21E1@LLE2K7-BE01.mitll.ad.local> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.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: <20090514145915.BC73E50822@romeo.rtfm.com> Cc: "'TLS@ietf.org'" Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 14:54:31 -0000 At Thu, 14 May 2009 10:21:34 -0400, Blumenthal, Uri wrote: > > Eric, > > The problem is (if I understand it correctly) that (a) there is > Certicom's PDF describing Certicom's ECC-related claims, and (b) > Certicom's extractor-related claims that do not explicitly refer to > or constrain themselves with the above PDF boundaries. I'm unaware of anything that corresponds to (b). Certicom filled in an IETF-provided Web form that allows them to list a bunch of drafts and refer to an explicit statment. > Thus it is unclear (at least without an explicit statement from > Certicom) whether their tls-extractor claims are or are not > exclusively ECC-related. > > In absence of such statement I speak against placing this draft on a > standards track. Do you also opposed a putative TLS 1.3 being Standards Track? TLS is listed on their statement. -Ekr From Nicolas.Williams@sun.com Thu May 14 08:56:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB1A3A6F60 for ; Thu, 14 May 2009 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT3vE454ms2K for ; Thu, 14 May 2009 08:56:47 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id ADEE428C2E7 for ; Thu, 14 May 2009 08:56:38 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4EFwBND000370 for ; Thu, 14 May 2009 15:58:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4EFwB7J030490 for ; Thu, 14 May 2009 09:58:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4EFmSvn001190; Thu, 14 May 2009 10:48:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4EFmN1s001189; Thu, 14 May 2009 10:48:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 14 May 2009 10:48:23 -0500 From: Nicolas Williams To: Badra Message-ID: <20090514154822.GV29258@Sun.COM> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 15:56:48 -0000 On Thu, May 14, 2009 at 04:10:01PM +0200, Badra wrote: > May it be possible for the draft's authors to review the related Certicom's > patents and conclude whatever they are or aren't related to the document in > question? Absolutely not. A document author should _never_ have to do that unless they are the owners of (or work for the owners of) the relevant patents. Nor, to be clear, should the authors be required to produce such a review (e.g., done by their lawyers). If the IETF were ever to require me to do such analysis, in order to prorgress an I-D that I'm an author of, when I'm not the IPR owner or an agent thereof, then I'd simply refuse to do so and let the I-D expire without further ado if need be. I'm quite certain that my or my employer's lawyers would insist on that very course of action. Moreover, I'd stop participating in the IETF altogether, and I'm sure many others would too. It's not fair even to ask the authors to do such a review if they feel like it. It would probably be a dangerous expectation to set, that authors should "volunteer" to do such reviews. Moreover, such reviews would do everyone else exactly no good. Just because my or my lawyer's opinion is that some IPR does not cover a given document cannot mean that the IPR owner won't think otherwise and sue you if they think you infringe on their IPR. Simon is being unreasonable by acting as though assertions NOT made are nonetheless in force. We're not mind readers and the law does not and, indeed, _must_ not expect us to so be (no, I am not a lawyer). We can and should (nay, must) only make decisions based on IPR claims that are asserted, not on claims that are not asserted (again, IANAL, but you knew that). Simon should seek legal advice on that point, and hopefully remove his objection (or perhaps the TLS WG chairs and/or IESG can just declare consensus nonetheless and let Simon appeal if he likes). Cheers, Nico -- From mbadra@gmail.com Thu May 14 09:18:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DD53A67F0 for ; Thu, 14 May 2009 09:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHzQD1Hqs7iw for ; Thu, 14 May 2009 09:18:45 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id C162128C2C3 for ; Thu, 14 May 2009 09:18:44 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1138292fga.18 for ; Thu, 14 May 2009 09:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jaRkQG7qz24YkM3ooBcXoirGA31b7FhAivAnP2wQpQU=; b=vKCOqnd2MC+Kt++9GGFU9zDJ0fRyETE5RRr4u9do8l1lnJV7tI/Oq3O4jjm3U3byW4 0bvemQIr+4xi838AH/WTyMMhZLe0nj2nJjsh3vBcpAEWHRoiLMCMGBZdbGUR/8GSwXkw wUTOWGlIJBdQcYHoGPvFkCBYiuziRmjypUvCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DKal6YbcsNp5aV6uRKvrjI8CER8v3GWeT34yRJnfWUTYyaR1Q4opByzAHH/Yuh6QOe 490ujzGqiAjlMx4AK3QvOV9VG0JHtj617sf2xucJvKn1vJYJ+JKDxyTHLF9uhltwOEsW M2YV3SetooLeEPBa+pVtVa25suRteu6jxIZDA= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.23.20 with SMTP id 20mr2705852fgw.17.1242318012774; Thu, 14 May 2009 09:20:12 -0700 (PDT) In-Reply-To: <20090514154822.GV29258@Sun.COM> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <20090514154822.GV29258@Sun.COM> Date: Thu, 14 May 2009 18:20:12 +0200 X-Google-Sender-Auth: 7549367aef709fda Message-ID: From: Badra To: Nicolas Williams Content-Type: multipart/alternative; boundary=000e0cd29f7cd97abc0469e1b31b Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 16:18:46 -0000 --000e0cd29f7cd97abc0469e1b31b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, May 14, 2009 at 5:48 PM, Nicolas Williams wrote: > On Thu, May 14, 2009 at 04:10:01PM +0200, Badra wrote: > > May it be possible for the draft's authors to review the related > Certicom's > > patents and conclude whatever they are or aren't related to the document > in > > question? > > Absolutely not. A document author should _never_ have to do that unless > they are the owners of (or work for the owners of) the relevant patents. > Nor, to be clear, should the authors be required to produce such a > review (e.g., done by their lawyers). > > If the IETF were ever to require me to do such analysis, in order to > prorgress an I-D that I'm an author of, when I'm not the IPR owner or an > agent thereof, then I'd simply refuse to do so and let the I-D expire > without further ado if need be. I'm quite certain that my or my > employer's lawyers would insist on that very course of action. > Moreover, I'd stop participating in the IETF altogether, and I'm sure > many others would too. > > It's not fair even to ask the authors to do such a review if they feel > like it. It would probably be a dangerous expectation to set, that > authors should "volunteer" to do such reviews. Moreover, such reviews > would do everyone else exactly no good. Just because my or my lawyer's > opinion is that some IPR does not cover a given document cannot mean > that the IPR owner won't think otherwise and sue you if they think you > infringe on their IPR. > > Well I am not asking the authors to do a survey on existing patents, BUT on identified ones, which are in our case Certicom's Patents. If a patent is proposed to be related to an ID, it is for the authors (not the owners) benefits to do if they want to publish their document as ST since the owner may prefer to hide this info or to don't make a disclosure at all. In ID, we usually found (I am not sure if this is still applicable) By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. The above text doesn't make any difference between the owner and the author. So if the authors is not the owner, BUT are aware of any patents related to that, they are requested to tell about that. Badra --000e0cd29f7cd97abc0469e1b31b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 14, 2009 at 5:48 PM, Nicolas William= s <Nicolas= .Williams@sun.com> wrote:
On Thu, May 14, 2009 at 04:10:01PM +0200, Badra wrote:> May it be possible for the draft's authors to review the related = Certicom's
> patents and conclude whatever they are or aren't= related to the document in
> question?

Absolutely not. =A0A document author should _ne= ver_ have to do that unless
they are the owners of (or work for the owne= rs of) the relevant patents.
Nor, to be clear, should the authors be req= uired to produce such a
review (e.g., done by their lawyers).

If the IETF were ever to requi= re me to do such analysis, in order to
prorgress an I-D that I'm an = author of, when I'm not the IPR owner or an
agent thereof, then I= 9;d simply refuse to do so and let the I-D expire
without further ado if need be. =A0I'm quite certain that my or my
e= mployer's lawyers would insist on that very course of action.
Moreov= er, I'd stop participating in the IETF altogether, and I'm sure
many others would too.

It's not fair even to ask the authors to = do such a review if they feel
like it. =A0It would probably be a dangero= us expectation to set, that
authors should "volunteer" to do s= uch reviews. =A0Moreover, such reviews
would do everyone else exactly no good. =A0Just because my or my lawyer'= ;s
opinion is that some IPR does not cover a given document cannot mean<= br>that the IPR owner won't think otherwise and sue you if they think y= ou
infringe on their IPR.

=A0
=A0
Well I am not asking the authors to do a survey=A0on existing patents,= BUT on identified ones, which are in our case Certicom's Patents.
=A0
If a patent is proposed to be related to an ID, it is for=A0the author= s (not the owners) benefits to do if they want to publish their document as= ST since the owner may prefer to hide this info or to don't make a dis= closure at all.
=A0
In ID, we usually found (I=A0am not sure if this is still applicable)<= /div>
=A0
=A0=A0 By submitting this Internet-Draft, each author represents that = any
=A0=A0 applicable patent or other IPR claims of which he or she is = aware
=A0=A0 have been or will be disclosed, and any of which he or she= becomes
=A0=A0 aware will be disclosed, in accordance with Section 6 of BCP 79.=A0<= br>
The above text doesn't make any difference between the owner and t= he author.
So if the authors is not the owner, BUT=A0are aware of any patents rel= ated to that, they are=A0requested to=A0tell about that.
=A0
Badra=A0
--000e0cd29f7cd97abc0469e1b31b-- From Martin.Rex@sap.com Thu May 14 10:43:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D016128C26B for ; Thu, 14 May 2009 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdqAzKRuMxvk for ; Thu, 14 May 2009 10:43:27 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B27E528C2AB for ; Thu, 14 May 2009 10:43:26 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n4EHivqK017895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 19:44:57 +0200 (MEST) From: Martin Rex Message-Id: <200905141744.n4EHivIN008745@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 14 May 2009 19:44:57 +0200 (MEST) In-Reply-To: <20090514154822.GV29258@Sun.COM> from "Nicolas Williams" at May 14, 9 10:48:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: simon@josefsson.org, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 17:43:27 -0000 Nicolas Williams wrote: > > On Thu, May 14, 2009 at 04:10:01PM +0200, Badra wrote: > > May it be possible for the draft's authors to review the related Certicom's > > patents and conclude whatever they are or aren't related to the document in > > question? > > Absolutely not. A document author should _never_ have to do that unless > they are the owners of (or work for the owners of) the relevant patents. > Nor, to be clear, should the authors be required to produce such a > review (e.g., done by their lawyers). I agree with Nico. If anyone at all should be asked to do a review whether the Certicom patent claim covers tls-extractors by accident or intentionally (independent of its validity), then this would be the IPR holder, i.e. Certicom themselves. IMHO the discussion is not very fruitful. The PRF as described in TLS extractors is so totally similar to the PRF used in TLS itself over many years that I don't see a problem of going for the same track, i.e. standards track. If it helps (and Certicom doesn't want to drop its claim), how about adding a few words to the document describing the situation? Something like: There is the following IPR disclosure ABC from Company XYZ which claims to cover technology described in this document (TLS-extractors). Since the technology has been and still is used in exactly the same fashion in the base standard (TLS) for many years, the working group made a straw poll whether it is ok to assume that adding this technology to an existing implementation is not going to add more risk to the IPR claim (that does apply to TLS as well). The working group consensus was "........". -Martin From Nicolas.Williams@sun.com Thu May 14 13:40:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCA828C35D for ; Thu, 14 May 2009 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17WO56QIUF99 for ; Thu, 14 May 2009 13:40:01 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C332628C363 for ; Thu, 14 May 2009 13:40:01 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4EKfYkb012110 for ; Thu, 14 May 2009 20:41:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4EKfYnC005421 for ; Thu, 14 May 2009 14:41:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4EKVmSq001315; Thu, 14 May 2009 15:31:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4EKVjGG001314; Thu, 14 May 2009 15:31:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 14 May 2009 15:31:45 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20090514203145.GW29258@Sun.COM> References: <20090514154822.GV29258@Sun.COM> <200905141744.n4EHivIN008745@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905141744.n4EHivIN008745@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: simon@josefsson.org, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 20:40:02 -0000 On Thu, May 14, 2009 at 07:44:57PM +0200, Martin Rex wrote: > I agree with Nico. If anyone at all should be asked to do a review > whether the Certicom patent claim covers tls-extractors by accident > or intentionally (independent of its validity), then this would > be the IPR holder, i.e. Certicom themselves. The patent holder can't be forced to do that either, except by denying them the imprimatur of the IETF standards process for their technologies (assuming that they want that). We can ask them though. > IMHO the discussion is not very fruitful. Indeed. We should move on. There are no claims on the extractor itself as of right now, thus no need for further controversy. > The PRF as described in TLS extractors is so totally similar to > the PRF used in TLS itself over many years that I don't see a > problem of going for the same track, i.e. standards track. Some things are obvious. This is one of them. From Nicolas.Williams@sun.com Thu May 14 13:45:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A370728C370 for ; Thu, 14 May 2009 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibe-Eub7YEPI for ; Thu, 14 May 2009 13:45:10 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 2A7E228C363 for ; Thu, 14 May 2009 13:45:08 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4EKkMHV000006 for ; Thu, 14 May 2009 20:46:34 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4EKkMo3009142 for ; Thu, 14 May 2009 14:46:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4EKae61001323; Thu, 14 May 2009 15:36:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4EKadrk001322; Thu, 14 May 2009 15:36:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 14 May 2009 15:36:39 -0500 From: Nicolas Williams To: Badra Message-ID: <20090514203639.GX29258@Sun.COM> References: <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <20090514154822.GV29258@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Simon Josefsson , TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 20:45:11 -0000 On Thu, May 14, 2009 at 06:20:12PM +0200, Badra wrote: > Well I am not asking the authors to do a survey on existing patents, BUT on > identified ones, which are in our case Certicom's Patents. You clearly missed the point. My advice w.r.t. other people's patents is worthless to anyone but my employer or myself, and since I'm not an IPR lawyer my advice on such matters (beyond "go talk to your lawyers") is utterly worthless. Why would ask me, or anyone else, for it, then? Would you really risk your business on my legal advice when we have no business relationship at all? Worse, forcing one to come up with such advice and publish it would be detrimental to one's legal position should one get sued. Which is why any sensible authors should (would!) simply stop participating if your suggestion were IETF policy, or even just WG policy. Nico -- From Martin.Rex@sap.com Thu May 14 15:09:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E2D3A6A89 for ; Thu, 14 May 2009 15:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioATfY0N19sH for ; Thu, 14 May 2009 15:09:43 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A18C33A6A18 for ; Thu, 14 May 2009 15:09:42 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n4EMBENf015060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 00:11:14 +0200 (MEST) From: Martin Rex Message-Id: <200905142211.n4EMBDCr025278@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 15 May 2009 00:11:13 +0200 (MEST) In-Reply-To: <20090514203639.GX29258@Sun.COM> from "Nicolas Williams" at May 14, 9 03:36:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: simon@josefsson.org, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 14 May 2009 22:09:43 -0000 Nicolas Williams wrote: > > On Thu, May 14, 2009 at 06:20:12PM +0200, Badra wrote: > > Well I am not asking the authors to do a survey on existing patents, BUT on > > identified ones, which are in our case Certicom's Patents. > > You clearly missed the point. My advice w.r.t. other people's patents > is worthless to anyone but my employer or myself, and since I'm not an > IPR lawyer my advice on such matters (beyond "go talk to your lawyers") > is utterly worthless. Why would ask me, or anyone else, for it, then? > > Would you really risk your business on my legal advice when we have no > business relationship at all? > > Worse, forcing one to come up with such advice and publish it would be > detrimental to one's legal position should one get sued. Which is why > any sensible authors should (would!) simply stop participating if your > suggestion were IETF policy, or even just WG policy. I also have a serious problem with asking document authors or IETF participants to read specific patents and advise on their applicability. My employer has explicitly asked us software engineers to NOT read any (software) patents at all (and has blocked some well-known patent databases for that reason on our company web proxy). IIRC the reason is the US approach to patents where "willful infringement" results in extra punitive damages (was it something like 3x). If one is infringing on IPR, it is cheaper when not knowing about the infringement before being sued. So all I know about the Certicom ECC patents is what has been said by people from Certicom on IETF Meetings (somewhere around 97/98 in PKIX and TLS) or on IETF working group mailing lists, and at most the IPR disclosures listed on the IETF Web Server. And btw., I have serious problems reading patents anyway, particularly those written in english (not my native language). The few US patents I ever looked at were almost completely incomprehensible to me (from a technical standpoint what they actually describe). -Martin From uri@ll.mit.edu Thu May 14 18:00:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF0128C362 for ; Thu, 14 May 2009 18:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvlpvlpA+N92 for ; Thu, 14 May 2009 18:00:25 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id A405E28C360 for ; Thu, 14 May 2009 18:00:25 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n4F11w8I010400 for ; Thu, 14 May 2009 21:01:58 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAd8aOWt; Thu May 14 21:01:00 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 14 May 2009 21:01:00 -0400 From: "Blumenthal, Uri" To: "TLS@ietf.org" Date: Thu, 14 May 2009 21:00:57 -0400 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUpDpE96VpCPsORVe0EW1bKRgNpwAVGB4R Message-ID: In-Reply-To: <20090514145915.BC73E50822@romeo.rtfm.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C632370946D3urillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 15 May 2009 01:00:27 -0000 --_000_C632370946D3urillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> In absence of such statement I speak against placing this draft on a >> standards track. > > Do you also opposed a putative TLS 1.3 being Standards Track? > TLS is listed on their statement. I do not - and you've made a good point. -- Regards, Uri --_000_C632370946D3urillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Proto write-up for TLS exporter >> In absence of such statement I speak against placing this dr= aft on a
>> standards track.
>
> Do you also opposed a putative TLS 1.3 being Standards Track?
> TLS is listed on their statement.

I do not – and you’ve made a good point.
--
Regards,
Uri
<Disclaimer>
 --_000_C632370946D3urillmitedu_-- From jsalowey@cisco.com Fri May 15 08:01:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7EE3A6A78 for ; Fri, 15 May 2009 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLDtjqu6-ChR for ; Fri, 15 May 2009 08:01:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F12643A6D07 for ; Fri, 15 May 2009 08:01:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,200,1241395200"; d="scan'208";a="186041787" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 May 2009 15:02:41 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4FF2eZD029876 for ; Fri, 15 May 2009 08:02:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n4FF2a8O015246 for ; Fri, 15 May 2009 15:02:40 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 08:02:37 -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 Date: Fri, 15 May 2009 08:02:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of IPR discussion on draft-ietf-tls-extractor-05 Thread-Index: AcnVbi7GhM4abtBhTp2laSZZq/cB+g== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 May 2009 15:02:37.0584 (UTC) FILETIME=[2F714100:01C9D56E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1999; t=1242399760; x=1243263760; 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:=20Summary=20of=20IPR=20discussion=20on=20draft-ie tf-tls-extractor-05=20 |Sender:=20; bh=G/NRkXraR9MVB3+/cTOKhH70si0PEr0JzMWf/Scgsow=; b=nhwNiLBGm1awNXJh8oWbAp3Kfc/MR6i5Yl6ZKIu6MBFRxmiS/ISl4TQWut 8g10S6ltws8ogaaQhOeMNg2Uz9OothyqsURZ6j5HJib035fQGJWZ5rQRWowK Ub5fWTvrrS; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 15 May 2009 15:01:25 -0000 I haven't heard anyone dispute that the current statement referenced in https://datatracker.ietf.org/ipr/1004/ pertains to the use of the draft with ECC technology. I have heard concern that there may be IPR claims that may not be disclosed by Certicom or another party. However, this is always the case and no new evidence of the existence of additional claims has been brought forth. My recommendation is to move forward with publishing the draft on standards track. Here is a what I suggest should go in the PROTO write-up (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 The document shepherd has no concerns with the document. There is an IPR disclosure that lists this document: https://datatracker.ietf.org/ipr/1004/. There has been some discussion of this disclosure on the TLS list. In general the disclosure only discusses the use of the draft with ECC technology. Some members are worried that this leaves a loop hole for later assertions to be made by the owner of the #1004 disclosure or that another third party may try to assert claims. No new evidence about these existence of additional claims has been provided to the working group so the document shepherd has decided to move forward with progressing the draft on standards track. =20 From mcampagna@certicom.com Fri May 15 08:39:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220283A6D8F for ; Fri, 15 May 2009 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pRhQ9-+JKZp for ; Fri, 15 May 2009 08:39:53 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id 13DBA3A6A5A for ; Fri, 15 May 2009 08:39:52 -0700 (PDT) Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n4FFfCc1016604; Fri, 15 May 2009 11:41:12 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Fri, 15 May 2009 11:41:14 -0400 From: Matthew Campagna To: "Joseph Salowey (jsalowey)" , "TLS@ietf.org" Date: Fri, 15 May 2009 11:41:13 -0400 Thread-Topic: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 Thread-Index: AcnVbi7GhM4abtBhTp2laSZZq/cB+gABHElg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: mcampagna@certicom.com Cc: Sarah Guichard , Tony Rosati Subject: Re: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 15 May 2009 15:39:54 -0000 In hopes of clarifying, It is our intention to foster broad adoption of ECC technology. The grant = is meant to cover any necessary Certicom patents and patent applications to= implement RFC 4492, RFC 5289 or the draft-rescorla-tls-suiteb when used wi= th draft-ietf-tls-extractor. It is not making any statement to the draft-i= etf-tls-extractor when used absent of these three cipher suites. Regards, Matt Matthew Campagna Director, Certicom Research Office: 203.894.9777 Main: 905.507.4220=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Friday, May 15, 2009 11:03 AM > To: TLS@ietf.org > Subject: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 >=20 > I haven't heard anyone dispute that the current statement referenced in > https://datatracker.ietf.org/ipr/1004/ pertains to the use of the draft > with ECC technology. I have heard concern that there may be IPR claims > that may not be disclosed by Certicom or another party. However, this > is always the case and no new evidence of the existence of additional > claims has been brought forth. My recommendation is to move forward > with publishing the draft on standards track. Here is a what I suggest > should go in the PROTO write-up >=20 > (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 >=20 > 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. >=20 > The document shepherd has no concerns with the document. There is an > IPR disclosure that lists this document: > https://datatracker.ietf.org/ipr/1004/. There has been some discussion > of this disclosure on the TLS list. In general the disclosure only > discusses the use of the draft with ECC technology. Some members are > worried that this leaves a loop hole for later assertions to be made by > the owner of the #1004 disclosure or that another third party may try > to > assert claims. No new evidence about these existence of additional > claims has been provided to the working group so the document shepherd > has decided to move forward with progressing the draft on standards > track. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From uri@ll.mit.edu Fri May 15 09:03:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1CB3A6814 for ; Fri, 15 May 2009 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwTho8geUZvx for ; Fri, 15 May 2009 09:03:47 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 8DE093A7085 for ; Fri, 15 May 2009 09:03:47 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n4FG5GOn008011 for ; Fri, 15 May 2009 12:05:16 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAZYaibx; Fri May 15 11:49:13 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Fri, 15 May 2009 11:49:13 -0400 From: "Blumenthal, Uri" To: "TLS@ietf.org" Date: Fri, 15 May 2009 11:49:11 -0400 Thread-Topic: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 Thread-Index: AcnVbi7GhM4abtBhTp2laSZZq/cB+gABHElgAACEIvU= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C633073746EFurillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 15 May 2009 16:03:49 -0000 --_000_C633073746EFurillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Crisp, precise and to the point. Thank you! My objections are withdrawn. On 5/15/09 11:41 , "Matthew Campagna" wrote: In hopes of clarifying, It is our intention to foster broad adoption of ECC technology. The grant = is meant to cover any necessary Certicom patents and patent applications to= implement RFC 4492, RFC 5289 or the draft-rescorla-tls-suiteb when used wi= th draft-ietf-tls-extractor. It is not making any statement to the draft-i= etf-tls-extractor when used absent of these three cipher suites. Regards, Matt Matthew Campagna Director, Certicom Research Office: 203.894.9777 Main: 905.507.4220 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Friday, May 15, 2009 11:03 AM > To: TLS@ietf.org > Subject: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 > > I haven't heard anyone dispute that the current statement referenced in > https://datatracker.ietf.org/ipr/1004/ pertains to the use of the draft > with ECC technology. I have heard concern that there may be IPR claims > that may not be disclosed by Certicom or another party. However, this > is always the case and no new evidence of the existence of additional > claims has been brought forth. My recommendation is to move forward > with publishing the draft on standards track. Here is a what I suggest > should go in the PROTO write-up > > (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. > > The document shepherd has no concerns with the document. There is an > IPR disclosure that lists this document: > https://datatracker.ietf.org/ipr/1004/. There has been some discussion > of this disclosure on the TLS list. In general the disclosure only > discusses the use of the draft with ECC technology. Some members are > worried that this leaves a loop hole for later assertions to be made by > the owner of the #1004 disclosure or that another third party may try > to > assert claims. No new evidence about these existence of additional > claims has been provided to the working group so the document shepherd > has decided to move forward with progressing the draft on standards > track. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Regards, Uri --_000_C633073746EFurillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 12pt'>Crisp, precise and to the point. Thank you!<BR> <BR> My objections are withdrawn.<BR> <BR> <BR> On 5/15/09  11:41 , "Matthew Campagna" <<a href=3D"mcampa= gna@certicom.com">mcampagna@certicom.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:12pt'>In hopes of clarifying,<BR> <BR> It is our intention to foster broad adoption of ECC technology.  The g= rant is meant to cover any necessary Certicom patents and patent applicatio= ns to implement RFC 4492, RFC 5289 or the draft-rescorla-tls-suiteb when us= ed with draft-ietf-tls-extractor.  It is not making any statement to t= he draft-ietf-tls-extractor when used absent of these three cipher suites.<= BR> <BR> Regards,<BR>    Matt<BR> <BR> Matthew Campagna<BR> Director, Certicom Research<BR> Office: 203.894.9777 Main: 905.507.4220<BR> <BR> <BR> > -----Original Message-----<BR> > From: <a href=3D"tls-bounces@ietf.org">tls-bounces@ietf.org</a> [<a hr= ef=3D"mailto:tls-bounces@ietf.org">mailto:tls-bounces@ietf.org</a>] On Beha= lf Of<BR> > Joseph Salowey (jsalowey)<BR> > Sent: Friday, May 15, 2009 11:03 AM<BR> > To: <a href=3D"TLS@ietf.org">TLS@ietf.org</a><BR> > Subject: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-0= 5<BR> ><BR> > I haven't heard anyone dispute that the current statement referenced i= n<BR> > <a href=3D"https://datatracker.ietf.org/ipr/1004/">https://datatracker= ietf.org/ipr/1004/</a> pertains to the use of the draft<BR> > with ECC technology.  I have heard concern that there may be IPR = claims<BR> > that may not be disclosed by Certicom or another party.  However,= this<BR> > is always the case and no new evidence of the existence of additional<= BR> > claims has been brought forth.  My recommendation is to move forw= ard<BR> > with publishing the draft on standards track.  Here is a what I s= uggest<BR> > should go in the PROTO write-up<BR> ><BR> >    (1.d) Does the Document Shepherd have any specific c= oncerns or<BR> >           issues wit= h this document that the Responsible Area Director<BR> >           and/or the= IESG should be aware of? For example, perhaps he<BR> >           or she is = uncomfortable with certain parts of the document,<BR> > or<BR> ><BR> >           has concer= ns whether there really is a need for it. In any<BR> >           event, if = the WG has discussed those issues and has indicated<BR> >           that it st= ill wishes to advance the document, detail those<BR> >           concerns h= ere. Has an IPR disclosure related to this document<BR> >           been filed= ? If so, please include a reference to the<BR> >           disclosure= and summarize the WG discussion and conclusion on<BR> >           this issue= .<BR> ><BR> > The document shepherd has no concerns with the document.  There i= s an<BR> > IPR disclosure that lists this document:<BR> > <a href=3D"https://datatracker.ietf.org/ipr/1004/">https://datatracker= .ietf.org/ipr/1004/</a>.  There has been some discussion<BR> > of this disclosure on the TLS list.  In general the disclosure on= ly<BR> > discusses the use of the draft with ECC technology.  Some members= are<BR> > worried that this leaves a loop hole for later assertions to be made b= y<BR> > the owner of the #1004 disclosure or that another third party may try<= BR> > to<BR> > assert claims.   No new evidence about these existence of ad= ditional<BR> > claims has been provided to the working group so the document shepherd= <BR> > has decided to move forward with progressing the draft on standards<BR= > > track.<BR> ><BR> ><BR> > _______________________________________________<BR> > TLS mailing list<BR> > <a href=3D"TLS@ietf.org">TLS@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/tls">https://www.ietf= .org/mailman/listinfo/tls</a><BR> _______________________________________________<BR> TLS mailing list<BR> <a href=3D"TLS@ietf.org">TLS@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/tls">https://www.ietf.org/= mailman/listinfo/tls</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial= "><SPAN STYLE=3D'font-size:12pt'><BR> -- <BR> Regards,<BR> Uri<BR> <Disclaimer><BR> </SPAN></FONT> </BODY> </HTML> --_000_C633073746EFurillmitedu_-- From simon@josefsson.org Sat May 16 06:37:51 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCC53A6D1E for <tls@core3.amsl.com>; Sat, 16 May 2009 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjo8hCcD-Koz for <tls@core3.amsl.com>; Sat, 16 May 2009 06:37:50 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 742C43A6A24 for <TLS@ietf.org>; Sat, 16 May 2009 06:37:47 -0700 (PDT) Received: from mocca.josefsson.org (m83-178-5-35.cust.tele2.se [83.178.5.35]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4GDdAkv020115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 May 2009 15:39:15 +0200 From: Simon Josefsson <simon@josefsson.org> To: Nicolas Williams <Nicolas.Williams@sun.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090516:badra@isima.fr::u3GL7OOvIYd1q0Fz:4wts X-Hashcash: 1:22:090516:tls@ietf.org::RttA9QZaduvZlcdy:ZmND X-Hashcash: 1:22:090516:nicolas.williams@sun.com::xiaxzW5EkVWQVlRc:0UfRM Date: Sat, 16 May 2009 15:39:09 +0200 In-Reply-To: <20090514154822.GV29258@Sun.COM> (Nicolas Williams's message of "Thu, 14 May 2009 10:48:23 -0500") Message-ID: <87eiupmaki.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 May 2009 13:37:51 -0000 Nicolas Williams <Nicolas.Williams@sun.com> writes: > Simon is being unreasonable by acting as though assertions NOT made are > nonetheless in force. We're not mind readers and the law does not and, > indeed, _must_ not expect us to so be (no, I am not a lawyer). We can > and should (nay, must) only make decisions based on IPR claims that are > asserted, not on claims that are not asserted (again, IANAL, but you > knew that). That is not factual, assertions have been made: #1004 claims Certicom has patents that covers tls-extractor. To what extent those patents apply, and in what contexts, is more a legal question than a technical. > Simon should seek legal advice on that point, and hopefully remove his > objection (or perhaps the TLS WG chairs and/or IESG can just declare > consensus nonetheless and let Simon appeal if he likes). I believe everyone considering implementing this would be prudent to get legal advice on what the Certicom patents means for them. /Simon From simon@josefsson.org Sat May 16 06:48:23 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF053A6EB4 for <tls@core3.amsl.com>; Sat, 16 May 2009 06:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56M5ttvXtsPM for <tls@core3.amsl.com>; Sat, 16 May 2009 06:48:22 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 774F83A680A for <TLS@ietf.org>; Sat, 16 May 2009 06:48:22 -0700 (PDT) Received: from mocca.josefsson.org (m83-178-5-35.cust.tele2.se [83.178.5.35]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4GDnBKT020664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 May 2009 15:49:17 +0200 From: Simon Josefsson <simon@josefsson.org> To: Matthew Campagna <mcampagna@certicom.com> References: <AC1CFD94F59A264488DC2BEC3E890DE50803DF90@xmb-sjc-225.amer.cisco.com> <C49217E2D694874EB820EA90DCE676192693078AFC@EX40.exchserver.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090516:sguichard@rim.com::kD9kKkM8VV7ucE7R:84OQ X-Hashcash: 1:22:090516:trosati@certicom.com::FNfpBlMKacfRFQyZ:Ta50 X-Hashcash: 1:22:090516:mcampagna@certicom.com::cJUvcftN9Vu4QQHB:HHbh X-Hashcash: 1:22:090516:tls@ietf.org::JMpeYthFly8/TeFs:lVST X-Hashcash: 1:22:090516:jsalowey@cisco.com::6HDBNqBSYrL1pGQ9:vmD/ Date: Sat, 16 May 2009 15:49:10 +0200 In-Reply-To: <C49217E2D694874EB820EA90DCE676192693078AFC@EX40.exchserver.com> (Matthew Campagna's message of "Fri, 15 May 2009 11:41:13 -0400") Message-ID: <87ab5dma3t.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sarah Guichard <sguichard@rim.com>, "TLS@ietf.org" <TLS@ietf.org>, Tony Rosati <trosati@certicom.com> Subject: Re: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 May 2009 13:48:23 -0000 Matthew Campagna <mcampagna@certicom.com> writes: > In hopes of clarifying, Hi. I appreciate this, thanks for joining the discussion. > It is our intention to foster broad adoption of ECC technology. The > grant is meant to cover any necessary Certicom patents and patent > applications to implement RFC 4492, RFC 5289 or the > draft-rescorla-tls-suiteb when used with draft-ietf-tls-extractor. It > is not making any statement to the draft-ietf-tls-extractor when used > absent of these three cipher suites. If you have patents that covers tls-extractor, which you claim in the #1004 filing, it would help to understand if and how you believe those patents apply to non-ECC cipher suites. Thus, what I'm looking for is a statement on using tls-extractor without those three cipher suites. Absent such a statement, it seems reasonable to assume that anything is possible, including that you believe your patents cover the non-ECC situation, and that you will enforce them. /Simon From simon@josefsson.org Sat May 16 07:04:41 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0643A70D4 for <tls@core3.amsl.com>; Sat, 16 May 2009 07:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5So9UYtm2tls for <tls@core3.amsl.com>; Sat, 16 May 2009 07:04:40 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 48D3A3A6FBB for <TLS@ietf.org>; Sat, 16 May 2009 07:04:40 -0700 (PDT) Received: from mocca.josefsson.org (m83-178-5-35.cust.tele2.se [83.178.5.35]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4GE5wsi021884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 May 2009 16:06:04 +0200 From: Simon Josefsson <simon@josefsson.org> To: "Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com> References: <AC1CFD94F59A264488DC2BEC3E890DE50803DF90@xmb-sjc-225.amer.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090516:tls@ietf.org::Nz+KNzZAVFgu75O/:06xw X-Hashcash: 1:22:090516:jsalowey@cisco.com::UHbe4RfdP/5zgnlY:GSSF Date: Sat, 16 May 2009 16:05:57 +0200 In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50803DF90@xmb-sjc-225.amer.cisco.com> (Joseph Salowey's message of "Fri, 15 May 2009 08:02:36 -0700") Message-ID: <87zlddkure.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Summary of IPR discussion on draft-ietf-tls-extractor-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 May 2009 14:04:41 -0000 "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> writes: > I haven't heard anyone dispute that the current statement referenced in > https://datatracker.ietf.org/ipr/1004/ pertains to the use of the draft > with ECC technology. That is what I have been disputing. My reasoning is as follows: 1) The #1004 disclosure indicates that Certicom has patents that covers the tls-extractor document. 2) The PDF says that for use with ECC, Certicom will grant a particular license. As far as I understand, the conditions in that license is one reason the IETF have published ECC related documents as Informational rather than on the Standards Track. Other recent cipher suites, such as RFC 5288, is on the Standards Track. 3) The PDF says nothing about what Certicom's patents on tls-extractor means for non-ECC situations. It would be great if Matthew Campagna can clarify 3) for us. To further clarify my position: If the patent owner confirms that they do not believe their patents covers non-ECC situations, I would no longer oppose publication of tls-extractor on the Standards Track. As long as the patent owner prevents us from understanding this aspect, I would continue to oppose publication. /Simon From dean@av8.com Sun May 17 23:13:06 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CF53A6F6B for <tls@core3.amsl.com>; Sun, 17 May 2009 23:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eWwyxfUO5Cu for <tls@core3.amsl.com>; Sun, 17 May 2009 23:13:05 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 4DF043A6F75 for <TLS@ietf.org>; Sun, 17 May 2009 23:13:02 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4I6ESDX027892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 May 2009 02:14:36 -0400 Date: Mon, 18 May 2009 02:14:27 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Nicolas Williams <Nicolas.Williams@sun.com> In-Reply-To: <20090514154822.GV29258@Sun.COM> Message-ID: <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 06:13:07 -0000 Several messages inline: On Thu, 14 May 2009, Nicolas Williams wrote: > > Simon is being unreasonable by acting as though assertions NOT made > are nonetheless in force. We're not mind readers and the law does not > and, indeed, _must_ not expect us to so be (no, I am not a lawyer). > We can and should (nay, must) only make decisions based on IPR claims > that are asserted, not on claims that are not asserted (again, IANAL, > but you knew that). Actually, Simon is both right and reasonable. One doesn't need to be a mind reader, nor does one need to be a lawyer, to read patents [nor to read and obey any law]. The jury won't be made up of lawyers. It is a fallacy that only lawyers need to be concerned with legal matters. Lawyers have the special privilege to represent other people in Court, sort of like commercial pilots have the special privilege to fly other people for hire. In this case, the 'unstated' assertions are in the patents themselves, which the IPR Disclosures have disclosed. The law expects you to use due diligence to follow the references you've been given. Infringing on ignorance isn't excused--one still owes the money---and knowingly infringing a patent can be prosecuted as a crime. Lawyers have told me that merely doing a /patent search/ can be evidence that you knew of a patent--the lawyer was advising myself and other engineers against doing patent searches. In this case, the IPR disclosure has informed us of the patents, and so we can't plead ignorance. Inducing others to infringe is also a special kind of patent offense. Back to specifics: I've read a number of the Certicom patents, and they are /very/ broad. I can't imagine much use of ECC that would not infringe. To be perfectly clear: I don't see that there is a credible dispute for asserting non-infringement on ECC. The draft has disclosure; the patent holder offers a (not really free) license. The patents themselves are very broad, and there are a large number of them. I think we have to conclude that unlicenced use of ECC will infringe. > Simon should seek legal advice on that point, and hopefully remove his > objection (or perhaps the TLS WG chairs and/or IESG can just declare > consensus nonetheless and let Simon appeal if he likes). I'm not sure what your mean by 'declare consensus' here. Do you mean that the IESG should state that the patents don't apply? If so, I would point out that neither the Chairs nor the IESG can honestly "declare" consensus where there is no consensus. From RFC 2418: Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. There doesn't seem to be consensus on the draft as a whole so far. On Wed, 13 May 2009, Paul Hoffman wrote: > At 1:58 PM +0200 5/13/09, Simon Josefsson wrote: > >I don't support publishing tls-extractor on the standards track as > >long as there are unclear patent threat against it and no acceptable > >free software compatible patent license is available. > > This is absurd and obstructionist. You are saying that if anyone > publishes an IPR statement about a work in progress, they can stop > that document from becoming a standard. I don't think that is what he is saying. He is saying that he doesn't support the draft because of its patent licencing requirements. That is a perfectly valid reason to oppose the draft. That's why RFC 3979 requires disclosures and requires working groups to discuss non-patented alternatives. On Wed, 13 May 2009, Paul Hoffman wrote: > At 6:49 PM +0200 5/13/09, Martin Rex wrote: > >Could someone please ask Certicom to remove TLS-extractors from > >their IPR claim / IPR disclosure? > > This might best be done by someone who works for a large vendor who > has a business relationship with Certicom or their parent, RIM (hint, > hint). Removing the IPR claim has no effect. The only thing that can be done to remove the objection of many is for Certicom to offer a free, universal license to that technology. > >To me, this claim sound ridiculous (assuming their patent claims > >are purely about patents around EC crypto). > > Why is what you think (or what I think) about their IPR relevant to > the write-up? Joe is reporting that there is an IPR statement in which > the draft is mentioned. That is a factual statement, even if it is > unfortunate. On Fri, 15 May 2009, Matthew Campagna wrote: > In hopes of clarifying, > > It is our intention to foster broad adoption of ECC technology. The > grant is meant to cover any necessary Certicom patents and patent > applications to implement RFC 4492, RFC 5289 or the > draft-rescorla-tls-suiteb when used with draft-ietf-tls-extractor. It > is not making any statement to the draft-ietf-tls-extractor when used > absent of these three cipher suites. Very few patent holders /don't/ want to foster broad adoption of their technology. Its the right of patent holders to prevent all use, but broad adoption is frequently the goal of the patent holder, along with the accompanying license fees, of course. I do not dispute your goal of broad adoption. I dispute that your license is really free, and I dispute that we need to adopt ECC technology into TLS on a non-free basis. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From ekr@networkresonance.com Sun May 17 23:44:45 2009 Return-Path: <ekr@networkresonance.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DC03A6FDD for <tls@core3.amsl.com>; Sun, 17 May 2009 23:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaugMFn6EtPL for <tls@core3.amsl.com>; Sun, 17 May 2009 23:44:44 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5148B3A6FD2 for <TLS@ietf.org>; Sun, 17 May 2009 23:44:44 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 1B5331A52D0; Sun, 17 May 2009 23:51:09 -0700 (PDT) Date: Sun, 17 May 2009 23:51:08 -0700 From: Eric Rescorla <ekr@networkresonance.com> To: Dean Anderson <dean@av8.com> In-Reply-To: <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> References: <20090514154822.GV29258@Sun.COM> <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.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: <20090518065109.1B5331A52D0@kilo.networkresonance.com> Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 06:44:45 -0000 At Mon, 18 May 2009 02:14:27 -0400 (EDT), Dean Anderson wrote: > Very few patent holders /don't/ want to foster broad adoption of their > technology. Its the right of patent holders to prevent all use, but > broad adoption is frequently the goal of the patent holder, along with > the accompanying license fees, of course. I do not dispute your goal of > broad adoption. I dispute that your license is really free, and I > dispute that we need to adopt ECC technology into TLS on a non-free > basis. Nor is there any suggestion that we do so. TLS Exporters are a generic technology that applies to any TLS cipher suite. There's no ECC in it at all. -Ekr From dean@av8.com Mon May 18 02:06:17 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4B23A6C13 for <tls@core3.amsl.com>; Mon, 18 May 2009 02:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTz37R7GDaty for <tls@core3.amsl.com>; Mon, 18 May 2009 02:06:16 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 9F3C528C267 for <TLS@ietf.org>; Mon, 18 May 2009 02:06:14 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4I97mDD028762 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 May 2009 05:07:48 -0400 Date: Mon, 18 May 2009 05:07:47 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Eric Rescorla <ekr@networkresonance.com> In-Reply-To: <20090518065109.1B5331A52D0@kilo.networkresonance.com> Message-ID: <Pine.LNX.4.44.0905180453490.18992-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 09:06:17 -0000 I may have been unclear. Simon really has a firm grasp of the issues in this case, see his message of 13 May 2009 (below) The point is that we should figure out the IPR issue before we approve this document. We have a last minute disclosure which we don't understand, yet. As Simon notes, there is a lot not specific to ECC that might be in those patents, even the ECC patent documents could have patented something overlapped by the extractor draft. If there is really nothing there, then we'll figure that out and advance the document. But if there is something there, we will want to know that. Not knowing these answers, it seems prudent to wait. (I rather feel rushed by Paul Hoffman et al. I get the distinct feeling--like a used car saleman trying to keep me from taking another look at the used car they want to sell me.) This tends to make me more hesitant. Certicom could be helpful and state whether this draft infringes any of their patents, and which. Their offer to licence isn't an assurance of no infringement; just the opposite: their offer implies that the draft infringes something. What? I oppose the document at this time, until we have answers to the IPR questions. --Dean On Wed, 13 May 2009, Simon Josefsson wrote: > Eric Rescorla <ekr@networkresonance.com> writes: > > > Do you have some reason to believe that extractors itself is > > encumbered absent use of ECC? > > Some of the patents quoted by Certicom in that PDF do not appear to be > specific to ECC. There is no analysis that they don't apply to > tls-extractor. On Sun, 17 May 2009, Eric Rescorla wrote: > At Mon, 18 May 2009 02:14:27 -0400 (EDT), > Dean Anderson wrote: > > Very few patent holders /don't/ want to foster broad adoption of their > > technology. Its the right of patent holders to prevent all use, but > > broad adoption is frequently the goal of the patent holder, along with > > the accompanying license fees, of course. I do not dispute your goal of > > broad adoption. I dispute that your license is really free, and I > > dispute that we need to adopt ECC technology into TLS on a non-free > > basis. > > Nor is there any suggestion that we do so. > > TLS Exporters are a generic technology that applies to any TLS > cipher suite. There's no ECC in it at all. > > -Ekr > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean@av8.com Mon May 18 02:34:46 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411843A6892 for <tls@core3.amsl.com>; Mon, 18 May 2009 02:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa2Zhv+qQu3C for <tls@core3.amsl.com>; Mon, 18 May 2009 02:34:45 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 289993A6FF8 for <TLS@ietf.org>; Mon, 18 May 2009 02:34:45 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4I9aJsp028798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 May 2009 05:36:20 -0400 Date: Mon, 18 May 2009 05:36:19 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Nicolas Williams <Nicolas.Williams@sun.com> In-Reply-To: <20090514203639.GX29258@Sun.COM> Message-ID: <Pine.LNX.4.44.0905180512120.18992-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 09:34:46 -0000 On Thu, 14 May 2009, Nicolas Williams wrote: > On Thu, May 14, 2009 at 06:20:12PM +0200, Badra wrote: > > Well I am not asking the authors to do a survey on existing patents, BUT on > > identified ones, which are in our case Certicom's Patents. > > You clearly missed the point. My advice w.r.t. other people's patents > is worthless to anyone but my employer or myself, and since I'm not an > IPR lawyer my advice on such matters (beyond "go talk to your lawyers") > is utterly worthless. Why would ask me, or anyone else, for it, then? > > Would you really risk your business on my legal advice when we have no > business relationship at all? Whether a document infringes a patent isn't a legal opinion; Its a technical, factual opinion with legal consequences. Its a technical opinion that you are able to honestly answer. Of course, its just as possible for one to dishonestly answer a technical question; but the point is that its not your legal opinion that would have us concerned. > Worse, forcing one to come up with such advice and publish it would be > detrimental to one's legal position should one get sued. Which is why > any sensible authors should (would!) simply stop participating if your > suggestion were IETF policy, or even just WG policy. Its only detrimental if its found to be dishonest in some way. 'Anything you say can be used against you' is a warning not to lie; not an inducement to withhold truthful statements. But true statements usually doesn't work against you, unless, for example, you say it infringes, then you infringe anyway. In that case, the truth damns you. This gives a decision-trust tree that allows trust to be placed in the (non-patent-owning/employed) author when they say something /does/ infringe (because it increases their expenses), but not when the author claims the patents don't infringe (because it reduces their expenses). But, of course, it is indeed much better if the patent owner says it doesn't infringe. If the patent owner says that, and we rely on their statement, then they might have 'unclean hands" for having deceived us if they try to sue for infringement later. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Pasi.Eronen@nokia.com Mon May 18 03:41:43 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9CF3A6A4B for <tls@core3.amsl.com>; Mon, 18 May 2009 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4reP4oKm3xwd for <tls@core3.amsl.com>; Mon, 18 May 2009 03:41:42 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7E08E28C22B for <TLS@ietf.org>; Mon, 18 May 2009 03:41:39 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IAh5vA016523; Mon, 18 May 2009 13:43:07 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 13:42:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 13:42:12 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 18 May 2009 12:42:08 +0200 From: <Pasi.Eronen@nokia.com> To: <martin.rex@sap.com> Date: Mon, 18 May 2009 12:42:06 +0200 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUu8aYt7PD0emdQoSoQ6nSR8l5gQC6VoxQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D474@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090514154822.GV29258@Sun.COM> from "Nicolas Williams" at May 14, 9 10:48:23 am <200905141744.n4EHivIN008745@fs4113.wdf.sap.corp> In-Reply-To: <200905141744.n4EHivIN008745@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 10:42:12.0031 (UTC) FILETIME=[4D2054F0:01C9D7A5] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 10:41:43 -0000 Martin Rex wrote: > If it helps (and Certicom doesn't want to drop its claim), > how about adding a few words to the document describing the > situation? >=20 > Something like: >=20 > There is the following IPR disclosure ABC from Company XYZ which > claims to cover technology described in this document (TLS-extractors). > Since the technology has been and still is used in exactly the same > fashion in the base standard (TLS) for many years, the working group > made a straw poll whether it is ok to assume that adding this > technology to an existing implementation is not going to add > more risk to the IPR claim (that does apply to TLS as well). > The working group consensus was "........". No. See RFC 3979, Section 11. Best regards, Pasi From Pasi.Eronen@nokia.com Mon May 18 03:46:48 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5330C3A7008 for <tls@core3.amsl.com>; Mon, 18 May 2009 03:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivGMk0LrgUoE for <tls@core3.amsl.com>; Mon, 18 May 2009 03:46:47 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1D74A3A701B for <TLS@ietf.org>; Mon, 18 May 2009 03:46:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IAltnr021079; Mon, 18 May 2009 13:48:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 13:47:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 13:47:47 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 18 May 2009 12:47:40 +0200 From: <Pasi.Eronen@nokia.com> To: <badra@isima.fr> Date: Mon, 18 May 2009 12:47:29 +0200 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUr+1klIen/rhySBiV87mYoSUNtwC9WspA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D487@NOK-EUMSG-01.mgdnok.nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> <c24c21d80905140920n77db6c0do71e254c423a4b4e7@mail.gmail.com> In-Reply-To: <c24c21d80905140920n77db6c0do71e254c423a4b4e7@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 10:47:47.0352 (UTC) FILETIME=[14FE4180:01C9D7A6] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 10:46:48 -0000 Badra wrote: > If a patent is proposed to be related to an ID, it is for=A0the > authors (not the owners) benefits to do if they want to publish > their document as ST since the owner may prefer to hide this info or > to don't make a disclosure at all. > > In ID, we usually found (I=A0am not sure if this is still applicable) >=A0 >=A0=A0 By submitting this Internet-Draft, each author represents that any >=A0=A0 applicable patent or other IPR claims of which he or she is aware >=A0=A0 have been or will be disclosed, and any of which he or she becomes >=A0=A0 aware will be disclosed, in accordance with Section 6 of BCP 79.=A0 > > The above text doesn't make any difference between the owner and the > author. So if the authors is not the owner, BUT=A0are aware of any > patents related to that, they are=A0requested to=A0tell about that. Note that "Section 6 of BCP 79" mentioned above *does* make a rather big difference difference between the owner and the author (or other contributor).=20 Best regards, Pasi From Pasi.Eronen@nokia.com Mon May 18 04:11:19 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71513A6FFF for <tls@core3.amsl.com>; Mon, 18 May 2009 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyAElewQp0lZ for <tls@core3.amsl.com>; Mon, 18 May 2009 04:11:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9685E3A7002 for <TLS@ietf.org>; Mon, 18 May 2009 04:10:49 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IBC3HL016854; Mon, 18 May 2009 06:12:24 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:11:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:11:09 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 18 May 2009 13:11:09 +0200 From: <Pasi.Eronen@nokia.com> To: <simon@josefsson.org> Date: Mon, 18 May 2009 13:11:08 +0200 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnUdM2sfUzcGnHpSfuKLJrQn71OFQDMr6pw Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4B6@NOK-EUMSG-01.mgdnok.nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> In-Reply-To: <87zldggi29.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 11:11:09.0881 (UTC) FILETIME=[58F73290:01C9D7A9] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 11:11:19 -0000 Simon Josefsson wrote: > > So, again, I ask, "Do you have some reason to believe that extractors > > itself is encumbered absent use of ECC?" >=20 > I believe the PDF is a reason, at least without more information. My > reasoning is as follows: >=20 > The patent disclaimer filed with the IETF lists tls-extractor as one > document that Certicom believes is covered by their patents. The IPR disclosure form (not the PDF) filed with the IETF says the disclosure is "related to" a big list of IETF documents. I think there's a difference between saying "the disclosure is related to X" and "the patents cover X", but your reading may of course be different (and IANAL). (The PDF certainly has statements effectively saying "Certicom believes ..something.. is covered by their patents", but the "..something.." is more complex than just the list of RFCs/drafts.) Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Mon May 18 04:13:03 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6940D3A700D for <tls@core3.amsl.com>; Mon, 18 May 2009 04:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo4QNrZEiEER for <tls@core3.amsl.com>; Mon, 18 May 2009 04:13:02 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 463823A6CEC for <TLS@ietf.org>; Mon, 18 May 2009 04:13:01 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IBE4lF002475; Mon, 18 May 2009 14:14:07 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:13:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:13:45 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 18 May 2009 13:13:45 +0200 From: <Pasi.Eronen@nokia.com> To: <dean@av8.com> Date: Mon, 18 May 2009 13:13:43 +0200 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnXmDDn8LPqamutReurMlS7lUeqmgAETSIg Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4BC@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090518065109.1B5331A52D0@kilo.networkresonance.com> <Pine.LNX.4.44.0905180453490.18992-100000@citation2.av8.net> In-Reply-To: <Pine.LNX.4.44.0905180453490.18992-100000@citation2.av8.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 11:13:46.0025 (UTC) FILETIME=[B608E190:01C9D7A9] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 11:13:03 -0000 Dean Anderson wrote: > The point is that we should figure out the IPR issue before we approve > this document. We have a last minute disclosure which we don't > understand, yet. =20 BTW, the disclosure was filed over half a year ago. Best regards, Pasi From Pasi.Eronen@nokia.com Mon May 18 04:24:33 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAA328C120 for <tls@core3.amsl.com>; Mon, 18 May 2009 04:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip2Lkhe4fZvt for <tls@core3.amsl.com>; Mon, 18 May 2009 04:24:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D2E243A67FD for <TLS@ietf.org>; Mon, 18 May 2009 04:24:32 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IBO8Wr027749; Mon, 18 May 2009 06:26:10 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:25:00 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:25:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:24:55 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 May 2009 13:24:52 +0200 From: <Pasi.Eronen@nokia.com> To: <simon@josefsson.org>, <Nicolas.Williams@sun.com> Date: Mon, 18 May 2009 13:24:51 +0200 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnWK8SSkYBOzhU8T3G8TBfJ9sBfBwBfgK4A Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> <87eiupmaki.fsf@mocca.josefsson.org> In-Reply-To: <87eiupmaki.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 11:24:55.0505 (UTC) FILETIME=[45136C10:01C9D7AB] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 11:24:33 -0000 Simon Josefsson wrote: > That is not factual, assertions have been made: #1004 claims Certicom > has patents that covers tls-extractor. To what extent those patents > apply, and in what contexts, is more a legal question than a technical. Well, the assertion that has been factually made is the following: At this time, Certicom believes its patents and patent applications listed in Schedule A contain claims which may be necessary and essential to implementations of the following protocols: IETF TLS: <...> "Keying Material Extractors for Transport Layer Security (TLS)", draft-ietf-tls-extractor-02.txt when used with either: A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport=20 Layer Security(TLS)" RFC 4492, May 2006; or,=20 B. "TLS Elliptic Curve Cipher Suites with SHA-256/384 and=20 AES Galois Counter Mode," RFC 5289, or=20 C. "Suite B Cipher Suites for TLS,"=20 draft-rescorla-tls-suiteb-07.txt; Your summary ("Certicom has patents that covers tls-extractor") seems to take the opinion that the "when used with either: A or B or C" text=20 is either not part of the assertion, or that this part doesn't matter. My reading of the emails so far is that some others believe this part of the assertion text *does* matter (and has influenced their opinion about how to process the tls-extractor draft in IETF). =20 Best regards, Pasi <not wearing any hats> From simon@josefsson.org Mon May 18 04:46:20 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D99628C16D for <tls@core3.amsl.com>; Mon, 18 May 2009 04:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVtfKT9XxQuV for <tls@core3.amsl.com>; Mon, 18 May 2009 04:46:19 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6E8ED3A6965 for <TLS@ietf.org>; Mon, 18 May 2009 04:46:02 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4IBlMxA032574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2009 13:47:24 +0200 From: Simon Josefsson <simon@josefsson.org> To: <Pasi.Eronen@nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB773A6AA3D4B6@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090518:tls@ietf.org::0R1aXUCDNlq4gv4v:5hR8 X-Hashcash: 1:22:090518:pasi.eronen@nokia.com::P6NE4FB+dHHRU3T+:mncl Date: Mon, 18 May 2009 13:47:22 +0200 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4B6@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Mon, 18 May 2009 13:11:08 +0200") Message-ID: <87eiumpr91.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 11:46:20 -0000 <Pasi.Eronen@nokia.com> writes: > Simon Josefsson wrote: > >> > So, again, I ask, "Do you have some reason to believe that extractors >> > itself is encumbered absent use of ECC?" >> >> I believe the PDF is a reason, at least without more information. My >> reasoning is as follows: >> >> The patent disclaimer filed with the IETF lists tls-extractor as one >> document that Certicom believes is covered by their patents. > > The IPR disclosure form (not the PDF) filed with the IETF says the > disclosure is "related to" a big list of IETF documents. I think > there's a difference between saying "the disclosure is related to X" > and "the patents cover X", but your reading may of course be > different (and IANAL). I agree with you. For reference, the page says 'IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates:'. See <https://datatracker.ietf.org/ipr/1004/>. Fortunately, BCP79 is clear on what should be in the disclosure: 6.4.1. The disclosure must list the numbers of any issued patents or published patent applications or indicate that the claim is based on unpublished patent applications. The disclosure must also list the specific IETF or RFC Editor Document(s) or activity affected. If the IETF Document is an Internet-Draft, it must be referenced by specific version number. It seems as if the IETF web page, by using "relates", is partially to blame for this confusion. The intention (by my reading of BCP79 at least) is not that all documents that are related should be listed, but only those that are "actively affected". There is certainly a significant difference. I think what I'd like to see here is 1) The IETF web page uses language that is consistent with BCP 79, 2) That Certicom updates the patent disclosure. If the new patent disclosure no longer imply that Certicom believe they have patents on tls-extractor, my concern would be resolved. /Simon From simon@josefsson.org Mon May 18 04:55:32 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5923F28C2B1 for <tls@core3.amsl.com>; Mon, 18 May 2009 04:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuAmGfr9Yy7Q for <tls@core3.amsl.com>; Mon, 18 May 2009 04:55:25 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 3156D28C29E for <TLS@ietf.org>; Mon, 18 May 2009 04:55:25 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4IBuvx0032705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2009 13:56:58 +0200 From: Simon Josefsson <simon@josefsson.org> To: <Pasi.Eronen@nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> <87eiupmaki.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090518:tls@ietf.org::o1ra4aD12XZLYGSw:5KP7 X-Hashcash: 1:22:090518:pasi.eronen@nokia.com::OSKAq4YK8HJWjWce:5D09 X-Hashcash: 1:22:090518:nicolas.williams@sun.com::8vUBkcdt1b+MBxH1:unOw Date: Mon, 18 May 2009 13:56:57 +0200 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Mon, 18 May 2009 13:24:51 +0200") Message-ID: <87ab5apqt2.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 11:55:32 -0000 <Pasi.Eronen@nokia.com> writes: > Simon Josefsson wrote: > >> That is not factual, assertions have been made: #1004 claims Certicom >> has patents that covers tls-extractor. To what extent those patents >> apply, and in what contexts, is more a legal question than a technical. > > Well, the assertion that has been factually made is the following: > > At this time, Certicom believes its patents and patent applications > listed in Schedule A contain claims which may be necessary and > essential to implementations of the following protocols: > > IETF TLS: > > <...> "Keying Material Extractors for Transport Layer Security > (TLS)", draft-ietf-tls-extractor-02.txt when used with either: > > A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport > Layer Security(TLS)" RFC 4492, May 2006; or, > B. "TLS Elliptic Curve Cipher Suites with SHA-256/384 and > AES Galois Counter Mode," RFC 5289, or > C. "Suite B Cipher Suites for TLS," > draft-rescorla-tls-suiteb-07.txt; That is text from a PDF linked in 'Licensing information, comments, notes, or URL for further information'. > Your summary ("Certicom has patents that covers tls-extractor") seems > to take the opinion that the "when used with either: A or B or C" text > is either not part of the assertion, or that this part doesn't matter. That is right, I don't consider the PDF as part of the BCP79-required disclosure. It is extra information beyond what is required by BCP79. The PDF can certainly be useful in evaluating claims, but I believe the text that's in the #1004 disclosure should carry more weight. And the tls-extractor document is mentioned as a covered technology for the BCP 79 patent disclosure. > My reading of the emails so far is that some others believe this > part of the assertion text *does* matter (and has influenced their > opinion about how to process the tls-extractor draft in IETF). This seems to be the case. I don't believe that view is consistent with the requirements in BCP 79 on patent disclosures though. /Simon From Pasi.Eronen@nokia.com Mon May 18 06:48:05 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84C03A69A0 for <tls@core3.amsl.com>; Mon, 18 May 2009 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox+vt5IXcs4a for <tls@core3.amsl.com>; Mon, 18 May 2009 06:48:05 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id AAB533A6B1B for <TLS@ietf.org>; Mon, 18 May 2009 06:48:04 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IDn8wW002274; Mon, 18 May 2009 16:49:34 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:49:17 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:49:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:49:07 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 May 2009 15:49:06 +0200 From: <Pasi.Eronen@nokia.com> To: <simon@josefsson.org> Date: Mon, 18 May 2009 15:49:00 +0200 Thread-Topic: Proto write-up for TLS exporter Thread-Index: AcnXr8kZuhD5GdjZSaGAt7LYI/fuQQADRkyA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AA3D696@NOK-EUMSG-01.mgdnok.nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> <87eiupmaki.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> <87ab5apqt2.fsf@mocca.josefsson.org> In-Reply-To: <87ab5apqt2.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2009 13:49:07.0177 (UTC) FILETIME=[69DFCD90:01C9D7BF] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 13:48:05 -0000 Simon Josefsson wrote: > > Your summary ("Certicom has patents that covers tls-extractor") > > seems to take the opinion that the "when used with either: A or B > > or C" text is either not part of the assertion, or that this part > > doesn't matter. >=20 > That is right, I don't consider the PDF as part of the BCP79-required > disclosure. It is extra information beyond what is required by BCP79. > The PDF can certainly be useful in evaluating claims, but I believe the > text that's in the #1004 disclosure should carry more weight. And the > tls-extractor document is mentioned as a covered technology for the BCP > 79 patent disclosure. Hmm.. it's quite common to *not* use the web form, but instead put the disclosure information in a separate PDF or text file, and send that by email (BCP79 doesn't require using the web form, AFAIK). However, if you send the PDF/text/Word/whatever file by email, the secretariat posts it on ietf.org. Having just a link to a file hosted elsewhere is indeed unusual (and perhaps less than ideal for ensuring the file stays available forever and is not modified). If the PDF file linked in IPR disclosure #1004 was posted on ietf.org (the same way as other IPR disclosures done as PDF files, such as=20 https://datatracker.ietf.org/ipr/1040/), would that change your opinion here? Best regards, Pasi From simon@josefsson.org Mon May 18 07:26:14 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E531528C2DE for <tls@core3.amsl.com>; Mon, 18 May 2009 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTBYEK-UxXpc for <tls@core3.amsl.com>; Mon, 18 May 2009 07:26:14 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id DE0BA28C301 for <TLS@ietf.org>; Mon, 18 May 2009 07:25:45 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4IERGBL006635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2009 16:27:18 +0200 From: Simon Josefsson <simon@josefsson.org> To: <Pasi.Eronen@nokia.com> References: <AC1CFD94F59A264488DC2BEC3E890DE507FD11E4@xmb-sjc-225.amer.cisco.com> <87preeqpma.fsf@mocca.josefsson.org> <20090513151244.2668950822@romeo.rtfm.com> <87tz3okj5d.fsf@mocca.josefsson.org> <20090513230017.CF7C650822@romeo.rtfm.com> <87zldggi29.fsf@mocca.josefsson.org> <20090514140437.E84F51A401F@kilo.networkresonance.com> <c24c21d80905140710i1213c61cr8b92a418c04862d0@mail.gmail.com> <20090514154822.GV29258@Sun.COM> <87eiupmaki.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> <87ab5apqt2.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB773A6AA3D696@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090518:tls@ietf.org::tHd86Ntedkk/Bd5n:0fMh X-Hashcash: 1:22:090518:pasi.eronen@nokia.com::yCxN+TL+rv0EX+NK:2Tzq Date: Mon, 18 May 2009 16:27:16 +0200 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AA3D696@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Mon, 18 May 2009 15:49:00 +0200") Message-ID: <87skj232rf.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 14:26:15 -0000 <Pasi.Eronen@nokia.com> writes: > Simon Josefsson wrote: > >> > Your summary ("Certicom has patents that covers tls-extractor") >> > seems to take the opinion that the "when used with either: A or B >> > or C" text is either not part of the assertion, or that this part >> > doesn't matter. >> >> That is right, I don't consider the PDF as part of the BCP79-required >> disclosure. It is extra information beyond what is required by BCP79. >> The PDF can certainly be useful in evaluating claims, but I believe the >> text that's in the #1004 disclosure should carry more weight. And the >> tls-extractor document is mentioned as a covered technology for the BCP >> 79 patent disclosure. > > Hmm.. it's quite common to *not* use the web form, but instead put the > disclosure information in a separate PDF or text file, and send that > by email (BCP79 doesn't require using the web form, AFAIK). Sure, but everyone still have to follow BCP 79. > However, if you send the PDF/text/Word/whatever file by email, the > secretariat posts it on ietf.org. Having just a link to a file hosted > elsewhere is indeed unusual (and perhaps less than ideal for ensuring > the file stays available forever and is not modified). > > If the PDF file linked in IPR disclosure #1004 was posted on ietf.org > (the same way as other IPR disclosures done as PDF files, such as > https://datatracker.ietf.org/ipr/1040/), would that change > your opinion here? The important thing is the content of the disclosure, not its presentation. BCP 79 requires companies to disclose if they believe they have patents on a document. Certicom appears to have done that for tls-extractor, judging from the #1004 page. They provide no licensing or any information at all except for the already known patent encumbered context of ECC. If they were to publish details for non-ECC, we would at least know how to evaluate the patent claims on tls-extractor. Right now we just have an patent claim with no information beyond ECC. If Certicom changes their patent disclosure to not claim they have patents on tls-extractor, my concern would be addressed. I'm hoping this will happen. If Certicom changes their disclosure to give everyone a free software compatible patent license to implement tls-extractor in non-ECC situations, that would work too. If neither happens, and Certicom continue to claim as per BCP79 and in the #1004 disclosure that they have patents that cover tls-extractor, and provides no information on non-ECC use about those patents, I would not support publication without significant more justification that the Internet community cannot live without a patent encumbered tls-extractor (comparable to the justification for RSA). /Simon From mcampagna@certicom.com Mon May 18 07:51:21 2009 Return-Path: <mcampagna@certicom.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C616D3A69C3 for <tls@core3.amsl.com>; Mon, 18 May 2009 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfubK9S3qJub for <tls@core3.amsl.com>; Mon, 18 May 2009 07:51:15 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id 21A773A6A3D for <TLS@ietf.org>; Mon, 18 May 2009 07:51:11 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n4IEqcIf008241; Mon, 18 May 2009 10:52:41 -0400 Received: from EX40.exchserver.com ([192.168.162.205]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Mon, 18 May 2009 10:52:42 -0400 From: Matthew Campagna <mcampagna@certicom.com> To: Eric Rescorla <ekr@networkresonance.com> Date: Mon, 18 May 2009 10:52:44 -0400 Thread-Topic: [TLS] Proto write-up for TLS exporter Thread-Index: AcnXhGVwRxNzWqXpQ6q1hC9Rx4d1ZwAOfaHQ Message-ID: <C49217E2D694874EB820EA90DCE6761926930790A4@EX40.exchserver.com> References: <20090514154822.GV29258@Sun.COM> <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> <20090518065109.1B5331A52D0@kilo.networkresonance.com> In-Reply-To: <20090518065109.1B5331A52D0@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: mcampagna@certicom.com Cc: Simon Josefsson <simon@josefsson.org>, "TLS@ietf.org" <TLS@ietf.org> Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 14:51:21 -0000 Eric, I have updated the IPR disclosure #1004, which should post in a couple of= days. I have modified the patent disclosure and licensing declaration to = more carefully delineate which RFCs and I-D contain IP to which the grant p= ertains. In particular: Section IV of the form, "IETF Document or Other Contribution to Which this = IPR Disclosure Relates," remains largely unchanged with the exception of up= dated draft #s. This is to indicate the broader effected documents to whic= h the license extends. =20 Section V of the form, "Disclosure of Patent Information (i.e., patents or = patent applications required to be disclosed by Section 6 of RFC 3979)," ha= s been updated. Subsection C highlights the specific RFCs and I-Ds that ar= e believed to be covered by the patents and patent applications listed in S= chedule A of the linked IPR contribution (http://www.certicom.com/images/pd= fs/certicom%20-ipr-contribution-to-ietfsept08.pdf). Please note that no ve= rsion of the draft_ietf_tls_extractor appears in this section. We consider the PDF document the formal IPR statement and invite IETF to= host it internally if they believe that inclusion by external link changes= the significance of the patent disclosure and licensing declaration. I believe the confusion arises from interpreting Section IV "IETF Document = or Other Contribution to Which the IPR Disclosure Relates." A possible su= ggestion to remove future ambiguity might be to codify the form more in RFC= 3979, i.e. what is to be included in Section IV and what is meant by "rela= tes." Regards, Matt Matthew Campagna Certicom Research Office: 203.894.9777 Main: 905.507.4220=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Eric Rescorla > Sent: Monday, May 18, 2009 2:51 AM > To: Dean Anderson > Cc: Simon Josefsson; TLS@ietf.org; Nicolas Williams > Subject: Re: [TLS] Proto write-up for TLS exporter >=20 > At Mon, 18 May 2009 02:14:27 -0400 (EDT), > Dean Anderson wrote: > > Very few patent holders /don't/ want to foster broad adoption of > their > > technology. Its the right of patent holders to prevent all use, but > > broad adoption is frequently the goal of the patent holder, along > with > > the accompanying license fees, of course. I do not dispute your goal > of > > broad adoption. I dispute that your license is really free, and I > > dispute that we need to adopt ECC technology into TLS on a non-free > > basis. >=20 > Nor is there any suggestion that we do so. >=20 > TLS Exporters are a generic technology that applies to any TLS > cipher suite. There's no ECC in it at all. >=20 > -Ekr >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Mon May 18 08:54:42 2009 Return-Path: <simon@josefsson.org> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCBA28C210 for <tls@core3.amsl.com>; Mon, 18 May 2009 08:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSiPiq8Ql5fE for <tls@core3.amsl.com>; Mon, 18 May 2009 08:54:40 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 40B2428C270 for <TLS@ietf.org>; Mon, 18 May 2009 08:54:39 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4IFu4uN009773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2009 17:56:07 +0200 From: Simon Josefsson <simon@josefsson.org> To: Matthew Campagna <mcampagna@certicom.com> References: <20090514154822.GV29258@Sun.COM> <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> <20090518065109.1B5331A52D0@kilo.networkresonance.com> <C49217E2D694874EB820EA90DCE6761926930790A4@EX40.exchserver.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090518:mcampagna@certicom.com::S8uCZpHw9qpb2k1H:2DZ6 X-Hashcash: 1:22:090518:tls@ietf.org::72xnzyihv3UkoEH1:MaEV X-Hashcash: 1:22:090518:ekr@networkresonance.com::RoqMRBYpBYkogIDv:D+hW Date: Mon, 18 May 2009 17:56:03 +0200 In-Reply-To: <C49217E2D694874EB820EA90DCE6761926930790A4@EX40.exchserver.com> (Matthew Campagna's message of "Mon, 18 May 2009 10:52:44 -0400") Message-ID: <8763fy2yng.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "TLS@ietf.org" <TLS@ietf.org> Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 15:54:42 -0000 Matthew Campagna <mcampagna@certicom.com> writes: > Section V of the form, "Disclosure of Patent Information (i.e., > patents or patent applications required to be disclosed by Section 6 > of RFC 3979)," has been updated. Subsection C highlights the specific > RFCs and I-Ds that are believed to be covered by the patents and > patent applications listed in Schedule A of the linked IPR > contribution > (http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf). > Please note that no version of the draft_ietf_tls_extractor appears in > this section. Thank you, I hope this resolves my concern. > We consider the PDF document the formal IPR statement and invite > IETF to host it internally if they believe that inclusion by > external link changes the significance of the patent disclosure and > licensing declaration. I believe the IETF should host it, if the IETF considers it to be the BCP 79 disclosure. Otherwise it has no persistent archive of received disclosures. But this is not something you should be responsible for making happen. > I believe the confusion arises from interpreting Section IV "IETF > Document or Other Contribution to Which the IPR Disclosure Relates." > A possible suggestion to remove future ambiguity might be to codify > the form more in RFC 3979, i.e. what is to be included in Section IV > and what is meant by "relates." I strongly agree here. BCP 79 requires the disclosure to contain a list of patents and a list of documents affected by those patents. The web page should use consistent terminology to avoid generating future similar problems. Thanks, Simon From Nicolas.Williams@sun.com Mon May 18 09:47:20 2009 Return-Path: <Nicolas.Williams@sun.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C030D3A6D11 for <tls@core3.amsl.com>; Mon, 18 May 2009 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PEJRgKQmBCc for <tls@core3.amsl.com>; Mon, 18 May 2009 09:47:20 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 5E57A3A68AC for <TLS@ietf.org>; Mon, 18 May 2009 09:47:19 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4IGms4R018874 for <TLS@ietf.org>; Mon, 18 May 2009 16:48:54 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4IGmshZ049199 for <TLS@ietf.org>; Mon, 18 May 2009 10:48:54 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4IGVdah002850; Mon, 18 May 2009 11:31:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4IGVchg002849; Mon, 18 May 2009 11:31:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 18 May 2009 11:31:38 -0500 From: Nicolas Williams <Nicolas.Williams@sun.com> To: Dean Anderson <dean@av8.com> Message-ID: <20090518163137.GH29258@Sun.COM> References: <20090514154822.GV29258@Sun.COM> <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.44.0905180107380.18436-100000@citation2.av8.net> User-Agent: Mutt/1.5.7i Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 16:47:20 -0000 On Mon, May 18, 2009 at 02:14:27AM -0400, Dean Anderson wrote: > Several messages inline: > > On Thu, 14 May 2009, Nicolas Williams wrote: > > > > Simon is being unreasonable by acting as though assertions NOT made > > are nonetheless in force. We're not mind readers and the law does not > > and, indeed, _must_ not expect us to so be (no, I am not a lawyer). > > We can and should (nay, must) only make decisions based on IPR claims > > that are asserted, not on claims that are not asserted (again, IANAL, > > but you knew that). > > Actually, Simon is both right and reasonable. One doesn't need to be a > mind reader, nor does one need to be a lawyer, to read patents [nor to > read and obey any law]. The jury won't be made up of lawyers. It is a > fallacy that only lawyers need to be concerned with legal matters. > Lawyers have the special privilege to represent other people in Court, > sort of like commercial pilots have the special privilege to fly other > people for hire. Most of us are not, in fact, allowed to read patents -- our employers don't allow it. Therefore either the IPR claim in question is clearly applicable to the tls-exporter idea generally, or just in so far as it relates to ECC. If the latter then IMO the I-D should progress. If the former, then we have a problem. Nico -- From dean@av8.com Mon May 18 14:28:10 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B16F3A6B0C for <tls@core3.amsl.com>; Mon, 18 May 2009 14:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYNPOo-Gpsuc for <tls@core3.amsl.com>; Mon, 18 May 2009 14:28:09 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 28FA83A6964 for <TLS@ietf.org>; Mon, 18 May 2009 14:28:08 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4ILTgDp030726 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 May 2009 17:29:42 -0400 Date: Mon, 18 May 2009 17:29:41 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AA3D4E2@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: <Pine.LNX.4.44.0905181718220.19070-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: simon@josefsson.org, TLS@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 21:28:10 -0000 That isn't quite accurate. While the documents you list are indeed on the disclosure, so is: Internet-Draft: "Keying Material Exporters for Transport Layer Security (TLS)" (draft-ietf-tls-extractor-05) The above is also a factual assertion, made by the IPR 1004 disclosure. We have just recently learned of this disclosure in relation to draft-ietf-tls-extractor-05. The argument that the disclosure was _filed_ more than half a year ago is inconsequential; The consequential fact is that the Working Group didn't consider that IPR in evaluating draft-ietf-tls-extractor-05, and didn't consider non-patented alternatives as required by RFC 3979. That is a process failure which would be a basis for appeal, and is currently a basis for opposing the draft. The argument that IPR 1004 only pertains to ECC and that draft-ietf-tls-extractor-05 contains no ECC urging a conclusion that IPR Disclosure 1004 can be ignored is a fallacy. The patents can (and do) cover more than just ECC. They may indeed cover draft-ietf-tls-extractor-05 just as the IPR 1004 says they do. --Dean On Mon, 18 May 2009 Pasi.Eronen@nokia.com wrote: > Simon Josefsson wrote: > > > That is not factual, assertions have been made: #1004 claims Certicom > > has patents that covers tls-extractor. To what extent those patents > > apply, and in what contexts, is more a legal question than a technical. > > Well, the assertion that has been factually made is the following: > > At this time, Certicom believes its patents and patent applications > listed in Schedule A contain claims which may be necessary and > essential to implementations of the following protocols: > > IETF TLS: > > <...> "Keying Material Extractors for Transport Layer Security > (TLS)", draft-ietf-tls-extractor-02.txt when used with either: > > A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport > Layer Security(TLS)" RFC 4492, May 2006; or, > B. "TLS Elliptic Curve Cipher Suites with SHA-256/384 and > AES Galois Counter Mode," RFC 5289, or > C. "Suite B Cipher Suites for TLS," > draft-rescorla-tls-suiteb-07.txt; > > Your summary ("Certicom has patents that covers tls-extractor") seems > to take the opinion that the "when used with either: A or B or C" text > is either not part of the assertion, or that this part doesn't matter. > > My reading of the emails so far is that some others believe this > part of the assertion text *does* matter (and has influenced their > opinion about how to process the tls-extractor draft in IETF). > > Best regards, > Pasi > <not wearing any hats> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean@av8.com Mon May 18 14:53:24 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E7828C121 for <tls@core3.amsl.com>; Mon, 18 May 2009 14:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUctvYBW2jke for <tls@core3.amsl.com>; Mon, 18 May 2009 14:53:23 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 54F033A6E02 for <TLS@ietf.org>; Mon, 18 May 2009 14:53:23 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4ILswI7030822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 May 2009 17:54:58 -0400 Date: Mon, 18 May 2009 17:54:57 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Nicolas Williams <Nicolas.Williams@sun.com> In-Reply-To: <20090518163137.GH29258@Sun.COM> Message-ID: <Pine.LNX.4.44.0905181733140.19070-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <simon@josefsson.org>, TLS@ietf.org Subject: Re: [TLS] Proto write-up for TLS exporter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 May 2009 21:53:24 -0000 On Mon, 18 May 2009, Nicolas Williams wrote: > On Mon, May 18, 2009 at 02:14:27AM -0400, Dean Anderson wrote: > > Several messages inline: > > > > On Thu, 14 May 2009, Nicolas Williams wrote: > > > > > > Simon is being unreasonable by acting as though assertions NOT made > > > are nonetheless in force. We're not mind readers and the law does not > > > and, indeed, _must_ not expect us to so be (no, I am not a lawyer). > > > We can and should (nay, must) only make decisions based on IPR claims > > > that are asserted, not on claims that are not asserted (again, IANAL, > > > but you knew that). > > > > Actually, Simon is both right and reasonable. One doesn't need to be a > > mind reader, nor does one need to be a lawyer, to read patents [nor to > > read and obey any law]. The jury won't be made up of lawyers. It is a > > fallacy that only lawyers need to be concerned with legal matters. > > Lawyers have the special privilege to represent other people in Court, > > sort of like commercial pilots have the special privilege to fly other > > people for hire. > > Most of us are not, in fact, allowed to read patents -- our employers > don't allow it. Most? I doubt most. I do understand that /some/ are not allowed to do so. Of course, if someone can't participate in IETF IPR analysis due to job restrictions, that doesn't mean that others are unable to participate, nor does it mean that IPR analysis should not be performed, nor does it mean that asking for performance is unreasonable. Indeed, your company probably has a representative who can participate in the IPR analysis. I think it would be helpful if you would try to locate that person in your company and prompt their engagement in this discussion. > Therefore either the IPR claim in question is clearly applicable to > the tls-exporter idea generally, or just in so far as it relates to > ECC. If the latter then IMO the I-D should progress. If the former, > then we have a problem. With the exception of the qualifier "clearly", I agree with your analysis of the logic of the situation. But we should investigate the IPR question before we proceed on this draft. It occurs to me that if your employment agreement prevents you from reading patents and assuming you have not violated that agreement, then you are categorically uninformed about the specifics of these patents and their IPR disclosure and will remain so for the foreseeable future. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Pasi.Eronen@nokia.com Wed May 27 12:53:58 2009 Return-Path: <Pasi.Eronen@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21983A6D67 for <tls@core3.amsl.com>; Wed, 27 May 2009 12:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TP2nfyO3hOu for <tls@core3.amsl.com>; Wed, 27 May 2009 12:53:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 367BC3A6C83 for <TLS@ietf.org>; Wed, 27 May 2009 12:53:56 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4RJsd5F015958 for <TLS@ietf.org>; Wed, 27 May 2009 14:55:27 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 22:54:28 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 22:54:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 22:54:23 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 27 May 2009 21:54:22 +0200 From: <Pasi.Eronen@nokia.com> To: <TLS@ietf.org> Date: Wed, 27 May 2009 21:54:19 +0200 Thread-Topic: Posting of IPR disclosure (#1153) Thread-Index: AcnfBOyFaH9An8q2RlWkQWcQG+xPKg== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AE2C094@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 May 2009 19:54:23.0547 (UTC) FILETIME=[EEC438B0:01C9DF04] X-Nokia-AV: Clean Subject: [TLS] Posting of IPR disclosure (#1153) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 19:53:58 -0000 FYI, this was posted yesterday: https://datatracker.ietf.org/ipr/1153/ Best regards, Pasi=20 From mcampagna@certicom.com Wed May 27 13:25:35 2009 Return-Path: <mcampagna@certicom.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E863A68C4 for <tls@core3.amsl.com>; Wed, 27 May 2009 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAnZOy5LMnvJ for <tls@core3.amsl.com>; Wed, 27 May 2009 13:25:22 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 74EA23A7137 for <TLS@ietf.org>; Wed, 27 May 2009 13:25:21 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n4RKQAgj006785; Wed, 27 May 2009 16:26:10 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Wed, 27 May 2009 16:26:10 -0400 From: Matthew Campagna <mcampagna@certicom.com> To: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, "TLS@ietf.org" <TLS@ietf.org> Date: Wed, 27 May 2009 16:26:09 -0400 Thread-Topic: Posting of IPR disclosure (#1153) Thread-Index: AcnfBOyFaH9An8q2RlWkQWcQG+xPKgABCP0w Message-ID: <623ACC30D56D0B4DB72868C664C23704E689398CD4@EX41.exchserver.com> References: <808FD6E27AD4884E94820BC333B2DB773A6AE2C094@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AE2C094@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: mcampagna@certicom.com Subject: Re: [TLS] Posting of IPR disclosure (#1153) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 20:25:35 -0000 Pasi, Thank you. I am looking to get the form-mangled I-D names returned to t= he submitted names: draft?rescorla?tls?suiteb?12, draft?green?secsh?ecc?07, draft?igoe?secsh?su= iteb?00, draft?ietf?smime?3278bis?07, draft?ietf?smime?sha2?11 restored to draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-su= iteb-00, draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 Regards, Matt Matthew Campagna Certicom Research Office: 203.894.9777 Main: 905.507.4220=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Wednesday, May 27, 2009 3:54 PM > To: TLS@ietf.org > Subject: [TLS] Posting of IPR disclosure (#1153) >=20 > FYI, this was posted yesterday: >=20 > https://datatracker.ietf.org/ipr/1153/ >=20 > Best regards, > Pasi >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dean@av8.com Wed May 27 13:55:07 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501953A6F77 for <tls@core3.amsl.com>; Wed, 27 May 2009 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd17ub+v6ILL for <tls@core3.amsl.com>; Wed, 27 May 2009 13:55:06 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 302B63A6A7E for <TLS@ietf.org>; Wed, 27 May 2009 13:55:05 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4RKul15013156 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 27 May 2009 16:56:47 -0400 Date: Wed, 27 May 2009 16:56:46 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AE2C094@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: <Pine.LNX.4.44.0905271651020.16573-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: TLS@ietf.org Subject: Re: [TLS] Posting of IPR disclosure (#1153) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 20:55:07 -0000 I don't see any difference between this disclosure and IPR 1004. Same 19 RFCs Same 11 drafts Same linked document Same contact information. Is there an error here? --Dean On Wed, 27 May 2009 Pasi.Eronen@nokia.com wrote: > FYI, this was posted yesterday: > > https://datatracker.ietf.org/ipr/1153/ > > Best regards, > Pasi > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From wwwrun@core3.amsl.com Wed May 27 15:31:33 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BF22F3A6D1A; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: Nagendra@cs.stanford.edu,ekr@rtfm.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223133.BF22F3A6D1A@core3.amsl.com> Date: Wed, 27 May 2009 15:31:33 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:33 -0000 Dear Nagendra Modadugu, Eric Rescorla: An IPR disclosure that pertains to your Internet-Draft entitled "Datagram Transport Layer Security version 1.2" (draft-ietf-tls-rfc4347-bis) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:33 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CBFEB3A6DBF; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: ekr@rtfm.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223133.CBFEB3A6DBF@core3.amsl.com> Date: Wed, 27 May 2009 15:31:33 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:33 -0000 Dear Eric Rescorla: An IPR disclosure that pertains to your Internet-Draft entitled "Keying Material Exporters for Transport Layer Security (TLS)" (draft-ietf-tls-extractor) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:34 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 07A973A7137; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: ekr@networkresonance.com,TimD@Consensus.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223134.07A973A7137@core3.amsl.com> Date: Wed, 27 May 2009 15:31:34 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:34 -0000 Dear Eric Rescorla, Tim Dierks: An IPR disclosure that pertains to your RFC entitled "The The Transport Layer Security (TLS) Protocol Version 1.1" (RFC4346) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:34 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0C6F63A713E; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: ekr@networkresonance.com,TimD@Consensus.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223134.0C6F63A713E@core3.amsl.com> Date: Wed, 27 May 2009 15:31:34 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:34 -0000 Dear Eric Rescorla, Tim Dierks: An IPR disclosure that pertains to your RFC entitled "The Transport Layer Security (TLS) Protocol Version 1.2" (RFC5246) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:34 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 16CC53A6F2B; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: ekr@rtfm.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223134.16CC53A6F2B@core3.amsl.com> Date: Wed, 27 May 2009 15:31:34 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:34 -0000 Dear Eric Rescorla: An IPR disclosure that pertains to your RFC entitled "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)" (RFC5289) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:34 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1B2273A7147; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: vipul.gupta@eng.sun.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223134.1B2273A7147@core3.amsl.com> Date: Wed, 27 May 2009 15:31:34 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:34 -0000 Dear Vipul Gupta: An IPR disclosure that pertains to your RFC entitled "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)" (RFC4492) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From wwwrun@core3.amsl.com Wed May 27 15:31:34 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 78B3D3A7175; Wed, 27 May 2009 15:31:34 -0700 (PDT) To: sblakewilson@certicom.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223134.78B3D3A7175@core3.amsl.com> Date: Wed, 27 May 2009 15:31:34 -0700 (PDT) X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Cc: ekr@rtfm.com, tim.polk@nist.gov, pasi.eronen@nokia.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:34 -0000 Dear Simon Blake-Wilson: An IPR disclosure that pertains to your RFC entitled "Transport Layer Security (TLS) Extensions" (RFC4366) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From tim987@email.com Wed May 27 22:12:43 2009 Return-Path: <tim987@email.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5067C3A6836 for <tls@core3.amsl.com>; Wed, 27 May 2009 22:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHwovNNdEqYp for <tls@core3.amsl.com>; Wed, 27 May 2009 22:12:42 -0700 (PDT) Received: from outbound1-1.us4.outblaze.com (outbound1-1.us4.outblaze.com [208.36.123.129]) by core3.amsl.com (Postfix) with ESMTP id 62A223A63C9 for <tls@ietf.org>; Wed, 27 May 2009 22:12:42 -0700 (PDT) Received: from wfilter3.us4.outblaze.com.int (wfilter3.us4.outblaze.com.int [192.168.8.242]) by outbound1-1.us4.outblaze.com (Postfix) with QMQP id DC8B87A065A for <tls@ietf.org>; Thu, 28 May 2009 05:14:22 +0000 (GMT) X-OB-Received: from unknown (208.36.123.73) by wfilter3.us4.outblaze.com; 28 May 2009 05:14:22 -0000 Received: by ws1-9.us4.outblaze.com (Postfix, from userid 1001) id 73CA3BE407F; Thu, 28 May 2009 05:14:23 +0000 (GMT) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1243487663128700" MIME-Version: 1.0 From: "tim robertson" <tim987@email.com> To: tls@ietf.org Date: Thu, 28 May 2009 00:14:23 -0500 Importance: high X-Priority: 1 Received: from [222.152.65.178] by ws1-9.us4.outblaze.com with http for tim987@email.com; Thu, 28 May 2009 00:14:23 -0500 X-Originating-Ip: 222.152.65.178 X-Originating-Server: ws1-9.us4.outblaze.com X-Ob-Auth: tim987:email.com@mail.com Message-Id: <20090528051423.73CA3BE407F@ws1-9.us4.outblaze.com> X-Mailman-Approved-At: Thu, 28 May 2009 06:20:09 -0700 Subject: [TLS] Suggestion for Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 05:18:10 -0000 This is a multi-part message in MIME format. --_----------=_1243487663128700 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, I have a suggestion for Transport Layer Security (tls). You should have a feature that makes the Transport Layer Security anonymous, so no ip address will be seen or recorded. It could work by the ip address being transformed into a random encrypted public key, so the web server will only see the encrypted public key and not the ip address of the computer.=A0Can you pass on my suggestion?Thanks --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com --_----------=_1243487663128700 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" <DIV>Hi, I have a suggestion for Transport Layer Security (tls). You should= have a feature that makes the Transport Layer Security anonymous, so no ip= address will be seen or recorded. It could work by the ip address being tr= ansformed into a random encrypted public key, so the web server will only s= ee the encrypted public key and not the ip address of the computer.</DIV> <DIV> </DIV> <DIV>Can you pass on my suggestion?</DIV> <DIV>Thanks</DIV><BR> --=20 <div> Be Yourself @ mail.com!<br> Choose From 200+ Email Addresses<br> Get a <b>Free</b> Account at <a href=3D"http://www.mail.com/Product.aspx" t= arget=3D"_blank">www.mail.com</a>!</div> --_----------=_1243487663128700-- From dean@av8.com Thu May 28 09:44:16 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E333A6FA0 for <tls@core3.amsl.com>; Thu, 28 May 2009 09:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY0dg+sE3HkM for <tls@core3.amsl.com>; Thu, 28 May 2009 09:44:11 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id BE7193A6FCD for <tls@ietf.org>; Thu, 28 May 2009 09:44:10 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4SGeOJP016567 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 May 2009 12:40:24 -0400 Date: Thu, 28 May 2009 12:40:24 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: tim robertson <tim987@email.com> In-Reply-To: <20090528051423.73CA3BE407F@ws1-9.us4.outblaze.com> Message-ID: <Pine.LNX.4.44.0905281206590.23855-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org Subject: Re: [TLS] Suggestion for Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 16:44:17 -0000 Hi, Tim. I think that remote endpoint IP addreses are exposed to the client web application through the server logs and the web server api. The client web application usually doesn't form TLS packets directly, but through an API of some sort offered by the web server itself. Should the web server operator want to hide IP addresses of remote endpoints from the client web application, they could alter what is exposed in logs and throught the API available to the client. I think its possible to implement your suggestion by changes to the API and maybe by changes to the web server itself (to have options to control whether IP addresses are exposed), but that API and software is not the subject of the protocol working group. Genuine anonymity is hard to ever truly achieve in the internet or electronically, and there are really just administrative limitations on who knows or has access to the identity of the endpoints. Security in TLS is based on proving knowledge of a private key in a public/private key pair, which is a kind of identification. Secure, genuine anonymity and electronic cash (as distinct from traceable electronic payments) are closely related problems, I think. Solve either, and you'll be rich... --Dean On Thu, 28 May 2009, tim robertson wrote: > Hi, I have a suggestion for Transport Layer Security (tls). You should > have a feature that makes the Transport Layer Security anonymous, so no > ip address will be seen or recorded. It could work by the ip address > being transformed into a random encrypted public key, so the web server > will only see the encrypted public key and not the ip address of the > computer. Can you pass on my suggestion?Thanks -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Jeremey.Barrett@nokia.com Thu May 28 10:20:18 2009 Return-Path: <Jeremey.Barrett@nokia.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9587A3A6C5C for <tls@core3.amsl.com>; Thu, 28 May 2009 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhWoC6Ix8XYK for <tls@core3.amsl.com>; Thu, 28 May 2009 10:20:17 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D74D23A6B48 for <tls@ietf.org>; Thu, 28 May 2009 10:20:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4SHG1vM014709; Thu, 28 May 2009 12:16:05 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 20:14:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 20:14:53 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 28 May 2009 19:14:53 +0200 From: <Jeremey.Barrett@nokia.com> To: <dean@av8.com>, <tim987@email.com> Date: Thu, 28 May 2009 19:14:51 +0200 Thread-Topic: [TLS] Suggestion for Transport Layer Security (tls) Thread-Index: Acnfs9uW2imfY8ryQc+pF7n5l076mwAA/PoV Message-ID: <C64430BB.4DC9%jeremey.barrett@nokia.com> In-Reply-To: <Pine.LNX.4.44.0905281206590.23855-100000@citation2.av8.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 May 2009 17:14:53.0994 (UTC) FILETIME=[D14810A0:01C9DFB7] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Suggestion for Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 17:20:18 -0000 On 5/28/09 11:40 AM, "ext Dean Anderson" <dean@av8.com> wrote: >=20 > Genuine anonymity is hard to ever truly achieve in the internet or > electronically, and there are really just administrative limitations on > who knows or has access to the identity of the endpoints. Security in > TLS is based on proving knowledge of a private key in a public/private > key pair, which is a kind of identification. Secure, genuine anonymity > and electronic cash (as distinct from traceable electronic payments) are > closely related problems, I think. Solve either, and you'll be rich... Actually, you'll have to solve both. :) (buying anonymity with traceable payments, not so good) Kidding aside, both of these problems have been largely solved, in the sens= e that we know how to do them, people have implemented things, companies have been formed, and everyone lost a bunch of money. Anonymity is a tough sell, and in many cases, not even a good idea (or at least very poorly defined). Tim, have a look at Tor: http://www.torproject.org/ Jeremey. From dean@av8.com Thu May 28 13:08:53 2009 Return-Path: <dean@av8.com> X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640EF3A6DA2 for <tls@core3.amsl.com>; Thu, 28 May 2009 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUQDWpL-NqG7 for <tls@core3.amsl.com>; Thu, 28 May 2009 13:08:47 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 1182B3A6D89 for <tls@ietf.org>; Thu, 28 May 2009 13:08:46 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n4SKAFqs017710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 May 2009 16:10:15 -0400 Date: Thu, 28 May 2009 16:10:14 -0400 (EDT) From: Dean Anderson <dean@av8.com> X-X-Sender: dean@citation2.av8.net To: Jeremey.Barrett@nokia.com In-Reply-To: <C64430BB.4DC9%jeremey.barrett@nokia.com> Message-ID: <Pine.LNX.4.44.0905281519270.17569-100000@citation2.av8.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tim987@email.com, tls@ietf.org Subject: Re: [TLS] Suggestion for Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tls> List-Post: <mailto:tls@ietf.org> List-Help: <mailto:tls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 20:08:53 -0000 Tor project isn't true anonymity. It just increases the set of adminstrative domains that are necessary to identify the endpoint. I don't think Tim wants to be able to access a web server anonymously, as any open proxy enables that. He wants (I think) to assure the web app client's customers that they are anonymous, as in an electronic voting system. I think he want's to say (essentially) something like: "The vote you cast is anonymous, because we do not share the IP address with the people collecting the votes." This is something a service provider could do, for example, to allow companies like ARIN to have anonymous and verifiable voting in corporate elections. I don't think the problems of anonymity and security are solved. There have indeed been ecash systems, but those weren't truly anonymous---just offline versions of online systems. Cash is (supposed to be) truly anonymous. People pay for drugs and illegal weapons in cash and diamonds for a reason: anonymity and security. Cash has to be both anonymous and secure (hard/impossible to forge). There are no electronic cash systems that have this property. All systems I know of so far are merely electronic payment systems, all roughly equivalent to a credit/debit card in anonymity. Payments can be done offline sometimes, but its always possible to identify the parties later. Open web proxies appear to be just a means of abuse. Open web proxies are distinct from open smtp relays which do not offer anonymity at all. There seems to be very little legitimacy to open web proxies, though recently I noticed that they can help show that google ads are location dependent, and enable one to view the ads being shown to a particular geography. But, even systems like Tor that attempt to offer a legitimized anonymity are vulnerable to abuse. But anonymity in cash is a tougher sell. Cash has historically had the property of anonymity because of its nature as a unforgeable or difficult to forge token of value that can be exchanged with anyone. But its hard to think of a really compelling social reason to maintain the property of anonymity in payments. Anyway, given the proper credentials, most administrative domains can be accessed. For example, a couple years ago most of New England lost power. For day or so, it was suspected that this was due to a computer virus released about the same time. It turned out the power disruption had nothing to do with the virus, whose release was just coincidental. However, the FBI had no trouble finding the 14 year-old who released the virus when it was thought the power grid was at stake. Script kiddies are usually not really anonymous; its just that those of us not in law enforcement (and sometimes even those who are) don't have the credentials to access all the administrative domains necessary to obtain the identity. But, do something bad enough, and the identity information can be retrieved. Well-known services like Tor, that may try to offer a service with no logs (I don't know that Tor does that--I didn't see anything explicitly promise that)--but supposing a service that did attempt that, would probably just be subject to more law enforcement attention and surveilance through CALEA, NSA, etc, and other similar LEA and national agencies in other countries--so the logs may still exist even when the operators are actually _trying_ to prevent that. There is probably a pretty good reason that while Al-quaeda is allowed to run web sites, Osama Bin Laden never participates online. But TLS doesn't enhance anonymity at all and doesn't try, since the private key is a form of identification. Even when 'anonymous certificates' are used on a per-session basis, translating the IP address to something physical (like what pair of wrists to slap cuffs on), is often just a matter of appropriate administrative access. --Dean On Thu, 28 May 2009 Jeremey.Barrett@nokia.com wrote: > On 5/28/09 11:40 AM, "ext Dean Anderson" <dean@av8.com> wrote: > > > > > Genuine anonymity is hard to ever truly achieve in the internet or > > electronically, and there are really just administrative limitations on > > who knows or has access to the identity of the endpoints. Security in > > TLS is based on proving knowledge of a private key in a public/private > > key pair, which is a kind of identification. Secure, genuine anonymity > > and electronic cash (as distinct from traceable electronic payments) are > > closely related problems, I think. Solve either, and you'll be rich... > > Actually, you'll have to solve both. :) (buying anonymity with traceable > payments, not so good) > > Kidding aside, both of these problems have been largely solved, in the sense > that we know how to do them, people have implemented things, companies have > been formed, and everyone lost a bunch of money. > > Anonymity is a tough sell, and in many cases, not even a good idea (or at > least very poorly defined). > > Tim, have a look at Tor: http://www.torproject.org/ > > Jeremey. > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000