From fweimer@bfk.de Wed Jul 1 00:11: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 935243A6EBE for ; Wed, 1 Jul 2009 00:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, HELO_EQ_DE=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 XcDpE8O7zmBQ for ; Wed, 1 Jul 2009 00:11:05 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id A0EDC3A68E7 for ; Wed, 1 Jul 2009 00:11:04 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MLu1E-0006Aj-BL; Wed, 01 Jul 2009 09:14:12 +0200 Received: by bfk.de with local id 1MLtyP-00071H-JC; Wed, 01 Jul 2009 07:11:17 +0000 To: Stefan Santesson References: From: Florian Weimer Date: Wed, 01 Jul 2009 07:11:17 +0000 In-Reply-To: (Stefan Santesson's message of "Wed\, 01 Jul 2009 03\:12\:30 +0200") Message-ID: <82ws6s27ze.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Cached Info extension - Draft 01 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, 01 Jul 2009 07:11:06 -0000 * Stefan Santesson: > One difficulty I have is that I don't see, and never have seen, the reason > to provide different levels of hash algorithms for a usage that does not > require a strong hash. Why do you think this doesn't need a strong hash? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Martin.Rex@sap.com Wed Jul 1 15:01: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 EB1BC3A6A45 for ; Wed, 1 Jul 2009 15:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 XZPhb+zHI0gg for ; Wed, 1 Jul 2009 15:01:24 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 46F253A6C57 for ; Wed, 1 Jul 2009 15:00:47 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n61M16NO004477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 00:01:06 +0200 (MEST) From: Martin Rex Message-Id: <200907012201.n61M15kE029676@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Thu, 2 Jul 2009 00:01:05 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Jul 1, 9 03:12:30 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] Cached Info extension - Draft 01 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, 01 Jul 2009 22:01:25 -0000 Stefan Santesson wrote: > > I might be missing something, but I'm not sure I get the problem. I'll try to elaborate on my idea, inspired by Simons "mild problem". The scheme of the current proposal, when and how does a client learn that a server supports caching (and for which handshake data), and what hash algorithm the server supports looks mildly awkward and requires guessing, i.e. trial-and-error. We could improve the entire proposal in the following fashion: ClientHelloExtension: allow&recommend the client to send the extension without actual hash values on first connect to a server. ServerHelloExtension: have the server indicate for which handshake data it supports caching in principle, and with which hash algorithm With this scheme, the client can learn even before creating cache entries whether the server supports caching of that handshake data at all--or wether it will be entirely pointless to cache such data and announce hashes for it in future requests to the same server. And the client can also learn which hash algorithm the server supports before creating actually receiving the data for the first time and creating the cache entry, so it will be unnecessary for the client to ever use more than one hash algorithm to compute a hash value for cached data. A client may decide to create negative cache entries for a server, so that it will not bother asking the server (through ClientHelloExtension) for caching support for a certain amount of time (like an hour) during successive requests. Such an approach will cut down on client side cache size and handshake network bandwidth. The current optimistic/probabilistic approach of the client trying to cache first and then propose to use it can and should be avoided. There can be situations where making assumptions and trial-and-error about server features might be OK or even necessary, but IMHO, this tls caching extension does not seem to be a situation where such an approach is adequate. Btw. we are defining a caching mechanism here, so there should be a small amount of guidance on cache management. The above idea should facilitate cache management somewhat. -Martin From stefan@aaa-sec.com Wed Jul 1 15:29: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 D967C3A6B4B for ; Wed, 1 Jul 2009 15:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Qc5AbulZT2jS for ; Wed, 1 Jul 2009 15:29:22 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id AB6D73A68B6 for ; Wed, 1 Jul 2009 15:29:20 -0700 (PDT) Received: (qmail 20030 invoked from network); 1 Jul 2009 22:29:45 -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 ; 1 Jul 2009 22:29:45 -0000 Received: (qmail 13413 invoked from network); 1 Jul 2009 22:29:35 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Jul 2009 22:29:35 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 00:29:33 +0200 From: Stefan Santesson To: Florian Weimer Message-ID: Thread-Topic: [TLS] Cached Info extension - Draft 01 Thread-Index: Acn6m2gX/N4KwYyFl0Cy6UxOxo6RKw== In-Reply-To: <82ws6s27ze.fsf@mid.bfk.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Cached Info extension - Draft 01 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, 01 Jul 2009 22:29:22 -0000 Because no one has presented a scenario where any attacker could benefit from a week hash to launch any realistic attack. The worst thing an attacker can accomplish by tampering with data exchange, is to cause the handshake to fail, which then, in the worst scenario, will force the parties to do a new handshake without caching. Unless the attacker has a way to convince the parties to accept some fake data that has never been part of a real successful handshake, then the attacker has no way to capitalize on the fact that a collision is found. /Stefan On 09-07-01 9:11 AM, "Florian Weimer" wrote: > * Stefan Santesson: > >> One difficulty I have is that I don't see, and never have seen, the reason >> to provide different levels of hash algorithms for a usage that does not >> require a strong hash. > > Why do you think this doesn't need a strong hash? From Martin.Rex@sap.com Wed Jul 1 16:00: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 288F63A6CA3 for ; Wed, 1 Jul 2009 16:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 8-NyGHPe0va0 for ; Wed, 1 Jul 2009 16:00:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F05AE3A6A25 for ; Wed, 1 Jul 2009 16:00:45 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n61N0sC4020409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 01:00:54 +0200 (MEST) From: Martin Rex Message-Id: <200907012300.n61N0rf7003442@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Thu, 2 Jul 2009 01:00:53 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Jul 2, 9 00:29:33 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Cached Info extension - Draft 01 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, 01 Jul 2009 23:00:47 -0000 Stefan Santesson wrote: > > Because no one has presented a scenario where any attacker could benefit > from a week hash to launch any realistic attack. > > The worst thing an attacker can accomplish by tampering with data exchange, > is to cause the handshake to fail, which then, in the worst scenario, will > force the parties to do a new handshake without caching. > > Unless the attacker has a way to convince the parties to accept some fake > data that has never been part of a real successful handshake, then the > attacker has no way to capitalize on the fact that a collision is found. This roughly describes my own view on this issue when the caching proposal was initially resurrected based on the fast-track idea. I've since changed my mind. Although I still don't see any problems with this so far, a more conservative approach might be better. As long as a state-of-the-art hash algorithm is used to hash the cached real data, and that hash value is part of the SSL handshake, we are _not_ changing the cryptographic properties of the handshake beyond assumptions that are generally believed to be safe. Time-stamping is based on a hashing(signing) over a hash value, xml-signatures use a hashing(signing) over one or more hash values, and doesn't PKCS7/CMS uses hashing(signing) over a hash value as well? If the real data is no longer part of the SSL handshake, but instead either a weak hash or even a static "cache handle", then there is a change in the cryptographic properties of the SSL handshake using cached handshake data and the full handshake with the real data. By using a strong hash and hash agility, the caching extension can maintain the same cryptographic properties as the full handshake (at least in a fashion that seems to be common for many cryptograhic protocols), so I am much less worried about things that I may have missed in assessing the security impact when there is no more cryptographic binding of the real data to the cache-using TLS handshake. -Martin From ekr@networkresonance.com Wed Jul 1 20:57:31 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 C111D3A68F5 for ; Wed, 1 Jul 2009 20:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.422, 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, MIME_8BIT_HEADER=0.3, 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 Bvc++1VlZHmA for ; Wed, 1 Jul 2009 20:57:30 -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 CD7223A68C5 for ; Wed, 1 Jul 2009 20:57:30 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 2A7601C61F9; Wed, 1 Jul 2009 20:58:09 -0700 (PDT) Date: Wed, 01 Jul 2009 20:58:09 -0700 From: Eric Rescorla To: Michael =?ISO-8859-1?Q?T=FCxen?= In-Reply-To: References: <20090630162443.D51561C5ED3@kilo.networkresonance.com> 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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090702035809.2A7601C61F9@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] DTLS record layer processing 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, 02 Jul 2009 03:57:31 -0000 At Tue, 30 Jun 2009 20:33:57 +0200, Michael T=FCxen wrote: >=20 > On Jun 30, 2009, at 6:24 PM, Eric Rescorla wrote: >=20 > > At Mon, 29 Jun 2009 16:49:44 +0200, > > Michael T=FCxen wrote: > >> > >> Dear all, > >> > >> when DTLS receives a packet is has to do input validation on > >> the version number and the length given in the record header > >> and the actual length of the UDP packet. > >> > >> When should this be done and what should be the action taken > >> when the checks fail? > > > > It should discard the datagram. > Silently, I assume. Should this be specified somewhere? >=20 > http://www.ietf.org/rfc/rfc5246.txt says: >=20 > record_overflow > A TLSCiphertext record was received that had a length more than > 2^14+2048 bytes, or a record decrypted to a TLSCompressed record > with more than 2^14+1024 bytes. This message is always fatal and > should never be observed in communication between proper > implementations (except when messages were corrupted in the > network). >=20 > Maybe people use this TLS based procedure also for DTLS (like =20 > OpenSSL)... I agree that this is bad. I'll try to add a specific comment to this effect in the document. > >> There is an implementation out, which considers a version > >> mismatch or a length given in the record layer which is > >> larger than allowed by the protocol a fatal error. > >> This might be OK for TLS, but I think is inacceptable for > >> DTLS. An attacker only needs to guess the UDP port numbers > >> and IP addresses and can craft a UDP packet with an illegal > >> record length field and the DTLS connection is gone. > > > > I agree, that that's not how implementations should behave. > > > > > >> Also > >> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt > >> states > >> > >> In general, DTLS implementations SHOULD silently discard data with > >> bad MACs. If a DTLS implementation chooses to generate an alert > >> when > >> it receives a message with an invalid MAC, it MUST generate a > >> bad_record_mac alert with level fatal and terminate its connection > >> state. > >> > >> If I understand things correctly, this means that as an attacker > >> I need only to send a UDP packet with a wrong MAC to perform > >> a DOS attack. > >> > >> Am I wrong? Any suggestions? > > > > I don't read the text that way. Rather, I think it says: > > > > If you receive a packet with a bad MAC, you must either: > > > > (a) Silently discard [Preferred] > > (b) Generate a bad_record_mac alert and terminate the connection. > I agree, but my point is: > If an implementation chooses (b), you can just send a malicious > packet and the connection is gone. Or am I missing something? Agreed. > > What you must not do is generate any other alert and continue > > the connection. > Understood. > > > > This was designed to avoid attacks where the attacker repeatedly > > probed the victim implementation to see which error it generated. > Understood, but I think (b) is bad in any case for DTLS. So why > not get rid of it and just require that implementation MUST > use (a), or at least SHOULD. At least for DTLS/UDP. >=20 > For DTLS/SCTP it is OK to send an alert since an attacker can > not insert packets because they are protected also with SCTP-AUTH. I could live with that, I think. What do other people in the WG think? -Ekr From stefan@aaa-sec.com Wed Jul 1 23:16:56 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 A9BF13A687C for ; Wed, 1 Jul 2009 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.407, 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 TTEnWLwgMnVQ for ; Wed, 1 Jul 2009 23:16:56 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id B83C13A6C20 for ; Wed, 1 Jul 2009 23:15:25 -0700 (PDT) Received: (qmail 57496 invoked from network); 2 Jul 2009 06:15:46 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Jul 2009 06:15:46 -0000 Received: (qmail 38291 invoked from network); 2 Jul 2009 06:15:44 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Jul 2009 06:15:44 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 08:15:43 +0200 From: Stefan Santesson To: Message-ID: Thread-Topic: [TLS] Cached Info extension - Draft 01 Thread-Index: Acn63IeCQkNa6oM20keMPL4NQf09UA== In-Reply-To: <200907012300.n61N0rf7003442@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Cached Info extension - Draft 01 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, 02 Jul 2009 06:16:56 -0000 Martin, On 09-07-02 1:00 AM, "Martin Rex" wrote: > If the real data is no longer part of the SSL handshake, but instead > either a weak hash or even a static "cache handle", then there is > a change in the cryptographic properties of the SSL handshake using > cached handshake data and the full handshake with the real data. I don't believe this conclusion is correct. The handshake will proceed exactly as it would have if the real data was exchanged, preserving the cryptographic properties of a full handshake with the original data. This is true with only one exception. It changes the data used to calculate the finished message. With cached data, the finished message is calculated over the "weak" hashes instead of the original data. For this to be turned into an attack, you have to make it plausible that one could force two different TLS sessions to produce colliding finished messages through a "weak" caching hash. This can't be the case if the hash algorithm used to calculate the finished message is solid. From Martin.Rex@sap.com Thu Jul 2 09:33: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 5FC923A6B15 for ; Thu, 2 Jul 2009 09:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 9lJ5uTYVokea for ; Thu, 2 Jul 2009 09:33:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 5A5803A6B11 for ; Thu, 2 Jul 2009 09:33:31 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n62GXoBc005404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 18:33:50 +0200 (MEST) From: Martin Rex Message-Id: <200907021633.n62GXnGV009098@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Thu, 2 Jul 2009 18:33:49 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Jul 2, 9 08:15:43 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] Cached Info extension - Draft 01 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, 02 Jul 2009 16:33:32 -0000 Stefan Santesson wrote: > > On 09-07-02 1:00 AM, "Martin Rex" wrote: > > > > If the real data is no longer part of the SSL handshake, but instead > > either a weak hash or even a static "cache handle", then there is > > a change in the cryptographic properties of the SSL handshake using > > cached handshake data and the full handshake with the real data. > > I don't believe this conclusion is correct. I think you might be misreading my conclusion. I think that we're cryptographically safe in modyfying the handshake by making a strong (agile) hash value over the original data part of the handshake instead. This is even safe for handling errors. If we drop the cryptographic binding of the original data in the handshake, we might create problems that we haven't thought of so far, and the architecure becomes brittle to handling errors. Without the cryptographic binding, cache poisoning will become feasible. The (server) endpoint identification that many/most clients currently perform is so ridiculously weak that I'm worried about cache poisoning. And how about caching of handshake data from incomplete TLS-handshakes that are incomplete, common and non-malicious? (like when a server requests a client cert, the client doesn't send one, and the server terminates the handshake with a fatal alert? Without the cryptographic binding of the original data to the cache-using handshake, we should probably need to explicitly prohibit caching there. For the TLS extension client certificate URL the previously optional hash over the client cert was made mandatory. I think that it is a sensible action to play safe and to try to maintain the cryptographic binding to the full SSL handshake by including a strong agile hash value over the original handshake data when the original data is omitted or replaced by a weak reference. -Martin From jsalowey@cisco.com Tue Jul 7 10:54:29 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 7635728C2C1 for ; Tue, 7 Jul 2009 10:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 owz4Jv6tNVOy for ; Tue, 7 Jul 2009 10:54:28 -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 D083B3A6E9C for ; Tue, 7 Jul 2009 10:54:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="210588042" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2009 17:54:33 +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 n67HsXrF028434 for ; Tue, 7 Jul 2009 10:54:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n67HsXwl015231 for ; Tue, 7 Jul 2009 17:54:33 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:54:32 -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, 7 Jul 2009 10:54:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Items for TLS Thread-Index: Acn/K/s7DZNnxcF/Q/mbBAhSkK1uFA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 07 Jul 2009 17:54:33.0004 (UTC) FILETIME=[FBCE2EC0:01C9FF2B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=229; t=1246989273; x=1247853273; 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:=20Agenda=20Items=20for=20TLS |Sender:=20; bh=pAfG299m0gFTi6QKad0/Vc7xsXY4bxJwvpOM4mYmPfI=; b=o4miS8PU08Sq0lg3QxZ/pBLZfyIe49qxG9vkgO6qW7wG0Zzja+7AUavjgw UJGy0PQB5XwLuCoHQhq6ll9mNE4gk8PRj86tIqaPGpUgfgTOD6WRh8jrJp+A QacSRN1VHV; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [TLS] Agenda Items for 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:54:29 -0000 The TLS meeting is scheduled for Friday afternoon (1300-1400). I tried to get this moved earlier in the week, but was unsuccessful. Please send me agenda items you would like to discuss at the meeting. =20 Thanks, Joe From yngve@opera.com Tue Jul 7 13:05: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 55DDC3A6A88 for ; Tue, 7 Jul 2009 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 uYYeaYZL+sqc for ; Tue, 7 Jul 2009 13:05:01 -0700 (PDT) Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id F3EAC3A67F0 for ; Tue, 7 Jul 2009 13:05:00 -0700 (PDT) Received: from nimisha.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n67K1P5P021969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Jul 2009 20:01:29 GMT Date: Tue, 07 Jul 2009 22:01:22 +0200 To: "tls@ietf.org" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera Mail/9.26 (Win32) Subject: [TLS] rfc4366-bis: Certificate Status for intermediate CA certificates 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, 07 Jul 2009 20:05:02 -0000 Hi, The current Certificate Status request and response is currently only able to handle a single OCSP respose, for the site certificate. A number of CAs have started to put OCSP URLs in their intermediate certificates, and using these URLs would help provide a more timely revocation information for Intermediate CA certificates too (not that it should normally be needed for CA certificates), not just for site certificates. However, CAs have already been concerned about the network traffic generated by clients just performing OCSP checks directly, not via the Certificate Status request, and I am aware of at least one case were the number of such requests caused serious problems for a CA. Adding direct retrieval of OCSP for the intermediates, and therefore significantly increasing the network traffic (particularly after the Certificate Status extension starts handling the majority of responses) is therefore not recommended. The problem with OCSP traffic for intermediates could be solved if the client could get the responses via the TLS server, similar to what the Certificate Status extension already do for site certificates. But given the definition of the Certificate Status extension it cannot be used to provide OCSP information for intermediates, so a new extension will be needed. My suggestion would be to add an extension to indicate support for multiple Certificate Status responses, e.g. "Certificate Chain Status", which the server have to use in the Server Hello extension list, followed either by a new Certificate Chain Status handshake record containing an array of status responses, or multiple Certificate Status messages. Whichever record method is chose, in either case the list of responses must either be in the sequence the certificates are placed in the chain, or the responses have to be matched with the certificate somehow. An issue with following the sequence is that some CAs are using cross-signed certificates linking to multiple roots, e.g. to allow EV chains (which in many cases chain to new Roots) to be validated by legacy clients, or new CAs have their certificate signed by a CA already in most Rootstores to be able to enter the market. Based on this I would suggest a new record, at least for the intermediates, in which each entry in the list identifies the Certificate it is the OCSP response for. This might be the same key used to request the OCSP response from the server, or some other way to identify the certificate (name, serialnumber, pubkeyhash, etc.) Thoughts? -- Sincerely, Yngve N. Pettersen   ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From Michael.Tuexen@lurchi.franken.de Tue Jul 7 14:05:36 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 ED88F3A6A27 for ; Tue, 7 Jul 2009 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 PNY81Ir+jUpD for ; Tue, 7 Jul 2009 14:05:36 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 8B8423A6EAE for ; Tue, 7 Jul 2009 14:03:50 -0700 (PDT) Received: from [192.168.1.100] (p508FC5B6.dip.t-dialin.net [80.143.197.182]) by mail-n.franken.de (Postfix) with ESMTP id EB8D21C0B4601; Tue, 7 Jul 2009 23:04:13 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Joseph Salowey (jsalowey) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 23:04:13 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: TLS@ietf.org Subject: Re: [TLS] Agenda Items for 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:05:37 -0000 Hi Joe, I would like to present http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt Best regards Michael On Jul 7, 2009, at 7:54 PM, Joseph Salowey (jsalowey) wrote: > The TLS meeting is scheduled for Friday afternoon (1300-1400). I > tried > to get this moved earlier in the week, but was unsuccessful. Please > send me agenda items you would like to discuss at the meeting. > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From stefan@aaa-sec.com Wed Jul 8 18:08:09 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 BE3B73A6B54 for ; Wed, 8 Jul 2009 18:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.356, 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 KoTIfJyOmctf for ; Wed, 8 Jul 2009 18:08:09 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id A34313A6AE2 for ; Wed, 8 Jul 2009 18:08:07 -0700 (PDT) Received: (qmail 87231 invoked from network); 9 Jul 2009 01:08:41 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Jul 2009 01:08:41 -0000 Received: (qmail 29805 invoked from network); 9 Jul 2009 01:08:31 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Jul 2009 01:08:31 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 09 Jul 2009 03:08:33 +0200 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" , Message-ID: Thread-Topic: [TLS] Agenda Items for TLS Thread-Index: Acn/K/s7DZNnxcF/Q/mbBAhSkK1uFABBcwI8 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Agenda Items for 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 01:08:09 -0000 Hi Joe, I would like some time to discuss and resolve the design issues concerning the cached information draft. Thanks /Stefan On 09-07-07 7:54 PM, "Joseph Salowey (jsalowey)" wrote: > The TLS meeting is scheduled for Friday afternoon (1300-1400). I tried > to get this moved earlier in the week, but was unsuccessful. Please > send me agenda items you would like to discuss at the meeting. > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From root@core3.amsl.com Sun Jul 12 16:45:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3135728C1CE; Sun, 12 Jul 2009 16:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090712234501.3135728C1CE@core3.amsl.com> Date: Sun, 12 Jul 2009 16:45:01 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-extractor-06.txt 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, 12 Jul 2009 23:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Keying Material Exporters for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-ietf-tls-extractor-06.txt Pages : 8 Date : 2009-07-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-extractor-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-12164342.I-D@ietf.org> --NextPart-- From axos88@gmail.com Wed Jul 15 01:39: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 554953A6A40 for ; Wed, 15 Jul 2009 01:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=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 PfiRpbABblWC for ; Wed, 15 Jul 2009 01:39:44 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 439DE3A6B2A for ; Wed, 15 Jul 2009 01:39:01 -0700 (PDT) Received: by bwz28 with SMTP id 28so1264376bwz.37 for ; Wed, 15 Jul 2009 01:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=bDPZ9QP0Pr8RDjd/dEMX4H56jFUoJlvF+/7YLKcsaOY=; b=E+TkSUVwHMUb8Amku7t27qbAW+0SN4aDrSGByGnb8z3EtFZ9WN+07wpb5JylfTN0Ek UtdCZxaIBvCO2GRGCCZ65x/QkRr0Qi4DrtZiyw3IfAR8GN7G1ygC0OGMYq0i+uOjDWaL ls9kgXVdh31NdULzKhNdWdDrS6z0QaGSyge5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TyJvzRzWX7KApgXsGPC+WlLaDhW0cKK3TQuuZZ7iXnad15NG3+pkpOOqgLEJDFLy21 LbATSatFw8n1oolUgKuFULAr0iTwstCfbLIvNccGq7akP1Yuv5PCcAHnqavhRuLXKCU0 4ig+AWGkkjJ4FdZb5Rk4P/SlYEe+DLHFagVUQ= MIME-Version: 1.0 Received: by 10.204.116.69 with SMTP id l5mr7359451bkq.52.1247647054203; Wed, 15 Jul 2009 01:37:34 -0700 (PDT) Date: Wed, 15 Jul 2009 10:37:34 +0200 Message-ID: From: Akos Vandra To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [TLS] TLS1.2 CertificateVerify deocding 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, 15 Jul 2009 09:01:52 -0000 Hello, I have written to half a dozen mailing lists, but never got an answer. This is why I am contacting you, in spite of the fact that I don't think my email is on-topic here. I am a student doing some research on the inner workings of TLSv1.2, for implementation on a custom hardware. Currently I am sniffing traffic between gnutls-serv and gnutls-cli, and trying to work out each bytes meaning (yeah I am a little bit crazy, but this helps me understand the protocol top to bottom. :) I am trying to decode the CertificateVerify structure, but have thus far fa= iled. I have access to both client(512bit) and server(1024bit) keys, and have sniffed their communication, what I came up with (along the stream) is this CertificateVerify packet sent from the client to the server: 0x16, 0x03, 0x03, 0x00, 0x46, 0x0f, 0x00, 0x00, 0x42, 0x00, 0x40, 0xe4, 0xe9, 0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67, 0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d, 0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6, 0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48, 0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49, 0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30, 0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b, 0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3 As far as I know, this means the next things: TLSPlainText. ContentType =3D 0x16 (Handshake) ProtocolVersion =3D 0x03, 0x03, Length =3D 0x00, 0x46, Fragment =3D Handshake TLSPlainText.Handshake. HandshakeType =3D 0x0f (certificate_verify) Length =3D 0x00, 0x00, 0x42, Body =3D CertificateVerify TLSPlainText.Handshake. CertificateVerify Length =3D 0x00, 0x40, <-- The RFC doesn't say that there should be a length info here, but this certainly is the remaining part's length. Data =3D 0xe4, 0xe9, 0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67, 0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d, 0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6, 0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48, 0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49, 0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30, 0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b, 0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3 I tried decoding this signed data with openssl (successfully), it yielded: $openssl rsautl -verify -inkey clientkey.pem -in sign.bin -hexdump 0000 - 47 f6 a5 1b a9 cb 4a a6-90 63 2c 65 ec 6f 6d 20 0010 - 10 af a8 f0 f0 80 0d 99-a3 22 cf 2b 07 b0 a4 c8 0020 - c7 ec 1d 33 My question is how to interpret this data? From the rfc I understood that this should be a .DER encoded struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; But this certainly isn't one (for ex. the second byte which should be a length byte is way too long). What am I missing? I am not sure what is the hash that should be calculated, so I am not sending that along, because I don't think it would be correct. Thanks in advance for your help, Vandra =C1kos From carlyoung@keycomm.co.uk Wed Jul 15 03:24: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 941DE3A69F7 for ; Wed, 15 Jul 2009 03:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV4gAp9wxjMh for ; Wed, 15 Jul 2009 03:24:13 -0700 (PDT) Received: from deferred-out-118.livemail.co.uk (deferred-out-117.livemail.co.uk [213.171.216.117]) by core3.amsl.com (Postfix) with ESMTP id 619D73A6BBE for ; Wed, 15 Jul 2009 03:23:44 -0700 (PDT) Received: from cust-smtp-192.fasthosts.net.uk (smtp-out-50.livemail.co.uk [213.171.216.50]) by deferred-out-118.livemail.co.uk (Postfix) with ESMTP id B52E0BE5C3A for ; Wed, 15 Jul 2009 10:24:22 +0100 (BST) Received: from localhost (mail213-171-216-231.livemail.co.uk [213.171.216.231]) by cust-smtp-192.fasthosts.net.uk (Postfix) with ESMTP id 56F977700BA; Wed, 15 Jul 2009 10:23:10 +0100 (BST) MIME-Version: 1.0 X-Mailer: AtMail PHP 5.4 Message-ID: <54530.1247649790@keycomm.co.uk> To: , "Akos Vandra" Content-Type: text/plain; charset="utf-8" X-Origin: 93.96.210.102 X-Atmail-Account: carlyoung@keycomm.co.uk Date: Wed, 15 Jul 2009 10:23:10 +0100 From: carlyoung@keycomm.co.uk Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] TLS1.2 CertificateVerify deocding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlyoung@keycomm.co.uk 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, 15 Jul 2009 10:24:14 -0000 >>On Wed 15/07/09 9:37 AM , Akos Vandra axos88@gmail.com sent: >>Hello, >> >>I have written to half a dozen mailing lists, but never got an answer. >>This is why I am contacting you, in spite of the fact that I don't >>think my email is on-topic here. >> >>My question is how to interpret this data? From the rfc I understood >>that this should be a .DER encoded >> >>struct { >>SignatureAndHashAlgorithm algorithm; >> >>opaque signature<0..2^16-1>; >>} DigitallySigned; Refer to RFC 5246, section 7.4.1.4.1 - this is not DER encoded - SignatureA= ndHashAlgorithm are just two octets I think. First octet is hash algorithm = - second is signature algorithm. From jsalowey@cisco.com Wed Jul 15 11:17: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 AFE513A6BAC for ; Wed, 15 Jul 2009 11:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 1JM6mgaffLWC for ; Wed, 15 Jul 2009 11:17:34 -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 EAD6B3A67A3 for ; Wed, 15 Jul 2009 11:17:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIO5XUqrR7PE/2dsb2JhbAC6D4gjkRgFhAk X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208";a="347282866" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2009 18:15:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6FIFOgC030568 for ; Wed, 15 Jul 2009 11:15:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6FIFOmZ003828 for ; Wed, 15 Jul 2009 18:15:24 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.3959); Wed, 15 Jul 2009 11:15:24 -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: Wed, 15 Jul 2009 11:15:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-75 TLS meeting agenda Thread-Index: AcoFeDg/2/Jy9pa3RDWDwJwlSQCkZQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Jul 2009 18:15:24.0147 (UTC) FILETIME=[38D97430:01CA0578] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=179; t=1247681724; x=1248545724; 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:=20IETF-75=20TLS=20meeting=20agenda |Sender:=20; bh=WMDhHYbLpkmDOXL+/kVxd428je6yt3xizFou6PQhbB0=; b=S2c/SrlQvkYtGF03tyOmWQUgrl5Q0dr6AT9roscn1osWpovzutQFVdqaKF TUMC0prRZQc3B56M5As/16C/dguxO3ujAzWE4duEWvLYq8UAcAPHo/DoPG67 fgXM9XOEAh; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [TLS] IETF-75 TLS meeting agenda 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, 15 Jul 2009 18:17:35 -0000 The TLS meeting agenda is available here: http://www.ietf.org/proceedings/09jul/agenda/tls.txt Let the chairs know if you have any additions or comments. Thanks, Joe From ekr@networkresonance.com Thu Jul 16 12:10:31 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 6BCC53A6930 for ; Thu, 16 Jul 2009 12:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 XEHHskWctLRN for ; Thu, 16 Jul 2009 12:10:30 -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 423873A6894 for ; Thu, 16 Jul 2009 12:10:30 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D28EA1CF021 for ; Thu, 16 Jul 2009 12:12:45 -0700 (PDT) Date: Thu, 16 Jul 2009 12:12:45 -0700 From: Eric Rescorla To: tls@ietf.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: <20090716191245.D28EA1CF021@kilo.networkresonance.com> Subject: [TLS] Review of draft-huang-tls-ibe-00 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, 16 Jul 2009 19:10:31 -0000 $Id: draft-huang-tls-ibe-00-rev.txt,v 1.1 2009/07/16 18:08:41 ekr Exp $ This draft describes how to use Identity Based Encryption algorithms (BF and BB) to exchange keys for TLS. GENERAL COMMENTS I don't find the motivation for this work particularly convincing. The drawbacks that the authors attribute to the current PKI-based authentication for TLS are not really ameliorated by IBE, and in some respects the IBE system is worse - The authors argue that the cost of CRL verification is high. This is probably true (although most current clients don't do CRL verification regularly), but it's not clear that it's any better with IBE. The IBE revocation strategy is effectively to use very short lived credentials and then refuse to reissue if the identity is compromised. This is completely compatible with PKI, it's just that it's not widely done because certificate reissuance is inconvenient. IBE places a similar burden on the server operator. - There definitely are UI issues with users accepting mismatched certificates, but it's not clear that IBE will really solve the problem here; if you're going to mount an attack it's about equally convenient to have a bogus CA as a bogus domain name. Unless you're going to prohibit users from accepting PKGs that their clients don't know about (we tried this with CAs and it didn't work out), it seems to me that we're going to still have the user override problem. - The argument offered in S 1 about P2P environments is simply false. There is no respect in which it is easier for a user to get an IBE key than it is to get a PKI certificate. Moreover, the main benefit of IBE, namely that Alice can send an encrypted message to Bob without communicating with Bob and before Bob has enrolled doesn't pay off here because TLS involves direct communication and expects the server to be able to decrypt the PMS in real time. The mechanism described here is extremely clumsy: I find it highly implausible that the client is going to send its entire list of PKGs (if X.509 is any guide, this would run to a hundred or so) in every ClientHello. Actually, due to the unique security properties of IBE, I would imagine there would be more PKGs because the amount of trust placed in a PKG is much higher than a CA. DETAILED COMMENTS S 1. user. In this procedure, user must get all certificates of CAs involved in this authority chain and make requests for Certificate Revocation Lists (CRLs) to check if the certificates are still valid. In TLS, it's standard practice to send the whole chain. CAs. Users may consume significant time for this processing. Besides, it is an overburden to maintain and issue certificates and CRLs. I'm not sure what resource you're talking about here. RSA verification is much faster than IBE key exchange. In current actual application of TLS, most users would like to ignore the failure alert of certificate verification that pop up from their browsers and continue to complete the connections to these HTTPS websites. This neglect can be utilized by attackers to masquerade websites using the forged certificates. In IBE-based system, there is no need to verify the receiver's public key for users. Because the identity information used as the public key is well-known and user authentication relies on the authentication performed by PKG. Therefore, the risks brought by user's neglect will be eliminated. I don't buy this. What happens when the server offers a PPS you've never heard of. o An authentication method allowing the users to compute digital signatures using their private keys from the PKG. Each side can validate the signature with the public key of the other side. It can support both server authentication and client authentication. What's the value of this at all? Why not just use certificates. S 3. Unless I'm missing something, this is going to involve sending every PPS you trust, which even if each of these record is only 100 bytes, is something like 10k. Moreover, it basically rules out any use of PKGs which aren't known to the client. As I said earlier, this general concept failed badly when certificates were in play. S 4.1.1. struct { opaque not_before[16]; opaque not_after[16]; }ValidityPeriod; Why not use standard unix times here? The public_parameter_data contains the actual cryptographic parameters depending on the specific algorithm. Where is this specified. Items in server_id_list are strings that can be used as the public keys of server. The server chooses one ID from this list contained in the ClientHello message or appoints a new ID which is not contained in this list. The structure of IDInfo is defined as follows: struct { opaque id_info<1..2^8-1>; }IDInfo; It is RECOMMENDED that the client and the server use the well-known and unique in certain community identities as their public keys, e.g. the server's domain name. This seems to me to be missing actual support for short-lived keys. In order to avoid needing revocation, you need to include a date string as part of the server's identity. Where is this stored, how is it agreed upon, etc? The client_id_list field is a list of client identities that can be used as or be used to compute the public key of client. The server can select one of the client IDs as the client's public key according to the configured policies. The selected ID can then be used to verify the client's signature sent in the client's CertificateVerify message. The value of the IDInfo can be an IP address, a domain name, an email address, a phone number or a host name, etc. What if I dont want to do client auth? S 6. The security considerations really need to accurately describe the consequences of compromise of the PKG, which are much worse than that of a CA. From jsalowey@cisco.com Thu Jul 16 15:49:18 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 0CB4A28C205 for ; Thu, 16 Jul 2009 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 PycS4FRelKxr for ; Thu, 16 Jul 2009 15:49:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 58D1228C254 for ; Thu, 16 Jul 2009 15:49:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADtLX0qrR7MV/2dsb2JhbAC4YYgjkRIFhA0 X-IronPort-AV: E=Sophos;i="4.42,413,1243814400"; d="scan'208";a="186973318" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2009 22:49:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GMnYtS017612 for ; Thu, 16 Jul 2009 15:49:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GMnYPI012034 for ; Thu, 16 Jul 2009 22:49:34 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 15:49:34 -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: Thu, 16 Jul 2009 15:49:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Take 2 of IETF-75 TLS agenda Thread-Index: AcoGZ65fdGWJ1RMkRAS70otMa7NT4g== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 16 Jul 2009 22:49:34.0178 (UTC) FILETIME=[B03EBC20:01CA0667] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=99; t=1247784574; x=1248648574; c=relaxed/simple; s=sjdkim1004; 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:=20Take=202=20of=20IETF-75=20TLS=20agenda |Sender:=20; bh=wGEuE8d6BtjTXypECetaq//qt0ukC9t5of6AfYorQ7E=; b=SqEKDhy6ddMBudAC0MIj8EzruhFhn7ineRd1tlgkXjnrwOFmje4764hZd9 ngc37mmD2LaHbiAJxGyjoLgVlLHbElGnwU/eIXLl2m6QLISl1kFaLff9aLdE ChW9nGbPyp73lHi9Cqed5/rD0DFd31gyKA2S6++s/zJW2OKou6ucc=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [TLS] Take 2 of IETF-75 TLS agenda 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, 16 Jul 2009 22:49:18 -0000 Take two of the agenda is available here: http://www.ietf.org/proceedings/09jul/agenda/tls.txt From pgut001@cs.auckland.ac.nz Fri Jul 17 01:37: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 953CA3A6D30 for ; Fri, 17 Jul 2009 01:37:40 -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=[AWL=0.000, 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 a6sSM6mJ3J7s for ; Fri, 17 Jul 2009 01:37:39 -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 CA5253A6A11 for ; Fri, 17 Jul 2009 01:37:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2F1D766893C; Fri, 17 Jul 2009 20:37:59 +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 v4ySjjlqcyih; Fri, 17 Jul 2009 20:37:59 +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 BCE0E668933; Fri, 17 Jul 2009 20:37: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 E8240E0808A; Fri, 17 Jul 2009 20:37:55 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1MRix1-0003Hx-Pw; Fri, 17 Jul 2009 20:37:55 +1200 From: Peter Gutmann To: ekr@networkresonance.com, tls@ietf.org In-Reply-To: <20090716191245.D28EA1CF021@kilo.networkresonance.com> Message-Id: Sender: pgut001 Date: Fri, 17 Jul 2009 20:37:55 +1200 Subject: Re: [TLS] Review of draft-huang-tls-ibe-00 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, 17 Jul 2009 08:37:40 -0000 Eric Rescorla writes: >What's the value of this at all? Why not just use certificates. That pretty much sums up all of IBE as far as I can see. However just because it's pointless I don't see what harm there is in publishing an RFC on it (if that was an argument not to do something, PKIX would have had to shut down years ago :-). As far as I can see no-one's being forced to implement it, we can just ignore it at our leisure, it's only an informational after all. Peter. From wwwrun@core3.amsl.com Mon Jul 20 09:48:16 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 328D928C1C8; Mon, 20 Jul 2009 09:48:15 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090720164816.328D928C1C8@core3.amsl.com> Date: Mon, 20 Jul 2009 09:48:16 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 16:48:16 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Keying Material Exporters for Transport Layer Security (TLS) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 From dean@av8.com Mon Jul 20 12:16: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 CE94128C1E8; Mon, 20 Jul 2009 12:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLG-gDoSnKT8; Mon, 20 Jul 2009 12:15:57 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 8B53B3A6D97; Mon, 20 Jul 2009 12:15:57 -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 n6KJFsSr004314 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Jul 2009 15:15:54 -0400 Date: Mon, 20 Jul 2009 15:15:53 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: ietf@ietf.org In-Reply-To: <20090720164816.328D928C1C8@core3.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, tls@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 20 Jul 2009 19:16:05 -0000 I am against this standard because of its patent encumbrances and non-free licencing terms. The working group did not get any clear answers on what particular patents this draft may infringe, but a patent holder (Certicom) did assert an IPR disclosure (1004) listing many patents. We have no alternative but to accept the Certicom disclosure statements as meaning that the TLS Extractor draft is patent-encumbered without a universal, free defensive license. The statement by https://datatrackerietf.org/ipr/1004/ referring to http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf which states: "Certicom will, upon request, provide a nonexclusive, royalty free patent license, to manufacturers to permit end users (including both client and server sides), to use the patents in schedule A when implementing any of these protocols, including those requiring third party certificates provided the certificate is obtained from a licensed Certificate Authority (CA). This license does not cover the issuing of certificates by a Certification Authority (CA)." That is not a free license, since Certicom must respond to the "request" before any license is granted. After the IETF finally approves the necessary standards, Certicom is free to stop approving the requests. I ask others who support free software to join me in opposing this document by sending a message stating opposition to the IETF@IETF.ORG mailing list. IETF participation is open to the public, and anyone may voice their view on IETF standards. It is also substantive to oppose a document because of its patent status, and in fact, any topic that is considered during or related to the IETF process is substantive. --Dean On Mon, 20 Jul 2009, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 > > _______________________________________________ > 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 Jul 20 13:56: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 2AAC53A6D7E; Mon, 20 Jul 2009 13:56:25 -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 bapeHMh3238g; Mon, 20 Jul 2009 13:56:17 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id B35A43A6DE1; Mon, 20 Jul 2009 13:56:17 -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 n6KKsbsT004606 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Jul 2009 16:54:37 -0400 Date: Mon, 20 Jul 2009 16:54:36 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Dan Harkins In-Reply-To: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 20 Jul 2009 20:56:25 -0000 Its possible to use any draft as toilet paper---a use that doesn't infringe---but that doesn't mean the draft is free and unencumbered. It is not the patents on these other standards that are the problem with TLS-extractor. It is that using the methods described in the extractor draft further infringe patents owned by Certicom. So we should either use other methods, or require that Certicom offer a suitable license. If we find ways to implement those other standards without infringing patents, we would still be caught by TLS-extractor. So it is imperative to avoid that trap. --Dean On Mon, 20 Jul 2009, Dan Harkins wrote: > > Certicom's IPR statement dated 13 October 2008 lists some patents > that "may be necessary and essential to implementations of..." the > TLS extractor draft "when used with either: " RFC4492, RFC5289 > or draft-rescorla-tls-suiteb. Check it out: > > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf > > Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and > then the IPR statement does not apply. If it's possible to use the TLS > extractor draft in a way that the IPR statement doesn't apply then I > don't think you can say "the TLS Extractor draft is patent-encumbered". > > I support free software* and I have no problem with this draft being > advanced as a Proposed Standard. > > regards, > > Dan. > > * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297 > for OpenSSL, and check out the "authsae" project on Source Forge. > > On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote: > > I am against this standard because of its patent encumbrances and > > non-free licencing terms. The working group did not get any clear > > answers on what particular patents this draft may infringe, but a patent > > holder (Certicom) did assert an IPR disclosure (1004) listing many > > patents. We have no alternative but to accept the Certicom disclosure > > statements as meaning that the TLS Extractor draft is patent-encumbered > > without a universal, free defensive license. > > > > The statement by https://datatrackerietf.org/ipr/1004/ referring to > > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf > > which states: > > > > "Certicom will, upon request, provide a nonexclusive, royalty free > > patent license, to manufacturers to permit end users (including both > > client and server sides), to use the patents in schedule A when > > implementing any of these protocols, including those requiring third > > party certificates provided the certificate is obtained from a licensed > > Certificate Authority (CA). This license does not cover the issuing of > > certificates by a Certification Authority (CA)." > > > > That is not a free license, since Certicom must respond to the "request" > > before any license is granted. After the IETF finally approves the > > necessary standards, Certicom is free to stop approving the requests. > > > > I ask others who support free software to join me in opposing this > > document by sending a message stating opposition to the IETF@IETF.ORG > > mailing list. IETF participation is open to the public, and anyone may > > voice their view on IETF standards. It is also substantive to oppose a > > document because of its patent status, and in fact, any topic that is > > considered during or related to the IETF process is substantive. > > > > --Dean > > > > > > On Mon, 20 Jul 2009, The IESG wrote: > > > >> The IESG has received a request from the Transport Layer Security WG > >> (tls) to consider the following document: > >> > >> - 'Keying Material Exporters for Transport Layer Security (TLS) ' > >> as a Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > >> comments may be sent to iesg@ietf.org instead. In either case, please > >> retain the beginning of the Subject line to allow automated sorting. > >> > >> The file can be obtained via > >> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > >> > >> > >> IESG discussion can be tracked via > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 > >> > >> _______________________________________________ > >> 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 > > > > > > > > > > > > > > > > _______________________________________________ > > 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 dharkins@lounge.org Mon Jul 20 14:41:59 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 A99053A6DEF; Mon, 20 Jul 2009 14:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, 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 HFBMUUsQ150j; Mon, 20 Jul 2009 14:41:49 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 571DD3A6DB1; Mon, 20 Jul 2009 14:41:44 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3C70CA888108; Mon, 20 Jul 2009 13:24:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Jul 2009 13:24:44 -0700 (PDT) Message-ID: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 20 Jul 2009 13:24:44 -0700 (PDT) From: "Dan Harkins" To: "Dean Anderson" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ietf@ietf.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 20 Jul 2009 21:41:59 -0000 Certicom's IPR statement dated 13 October 2008 lists some patents that "may be necessary and essential to implementations of..." the TLS extractor draft "when used with either: " RFC4492, RFC5289 or draft-rescorla-tls-suiteb. Check it out: http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and then the IPR statement does not apply. If it's possible to use the TLS extractor draft in a way that the IPR statement doesn't apply then I don't think you can say "the TLS Extractor draft is patent-encumbered". I support free software* and I have no problem with this draft being advanced as a Proposed Standard. regards, Dan. * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297 for OpenSSL, and check out the "authsae" project on Source Forge. On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote: > I am against this standard because of its patent encumbrances and > non-free licencing terms. The working group did not get any clear > answers on what particular patents this draft may infringe, but a patent > holder (Certicom) did assert an IPR disclosure (1004) listing many > patents. We have no alternative but to accept the Certicom disclosure > statements as meaning that the TLS Extractor draft is patent-encumbered > without a universal, free defensive license. > > The statement by https://datatrackerietf.org/ipr/1004/ referring to > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf > which states: > > "Certicom will, upon request, provide a nonexclusive, royalty free > patent license, to manufacturers to permit end users (including both > client and server sides), to use the patents in schedule A when > implementing any of these protocols, including those requiring third > party certificates provided the certificate is obtained from a licensed > Certificate Authority (CA). This license does not cover the issuing of > certificates by a Certification Authority (CA)." > > That is not a free license, since Certicom must respond to the "request" > before any license is granted. After the IETF finally approves the > necessary standards, Certicom is free to stop approving the requests. > > I ask others who support free software to join me in opposing this > document by sending a message stating opposition to the IETF@IETF.ORG > mailing list. IETF participation is open to the public, and anyone may > voice their view on IETF standards. It is also substantive to oppose a > document because of its patent status, and in fact, any topic that is > considered during or related to the IETF process is substantive. > > --Dean > > > On Mon, 20 Jul 2009, The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> >> - 'Keying Material Exporters for Transport Layer Security (TLS) ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt >> >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 >> >> _______________________________________________ >> 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 > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From douglas@stebila.ca Tue Jul 21 01:32:36 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 C29F128C1DE; Tue, 21 Jul 2009 01:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 zjomNQ2L13lV; Tue, 21 Jul 2009 01:32:35 -0700 (PDT) Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by core3.amsl.com (Postfix) with ESMTP id C37133A6A07; Tue, 21 Jul 2009 01:32:35 -0700 (PDT) Received: from [131.181.101.246] ([131.181.101.246]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n6L8WRc7013280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2009 04:32:32 -0400 (EDT) Message-Id: <10B26916-E4EC-4678-B35E-0C09D58E4169@stebila.ca> From: Douglas Stebila To: IETF Discussion In-Reply-To: <20090720164816.328D928C1C8@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 18:32:21 +1000 References: <20090720164816.328D928C1C8@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Tue, 21 Jul 2009 04:32:34 -0400 (EDT) X-Miltered: at mailchk-w03 with ID 4A657D1B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.2 at mailchk-w01 X-Virus-Status: Clean X-UUID: 9f9bbb25-3068-4844-bedb-4bdc2cdad915 Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 08:32:36 -0000 I have implemented draft-ietf-tls-extractor-06 in the TLS v1.0 implementation in OpenSSL. I found the draft easy to implement with no ambiguities or concerns. I believe that the functionality provided by the draft will be extremely valuable for building application-level security protocols and encourage its standardization. It is my interpretation of the draft that it can be implemented in any version of TLS, not just TLS v1.2. Obviously the derived key may be different if the underlying TLS PRF is defined differently (as it is for TLS v1.2), but the draft is still well-defined for previous versions of TLS. For those interested in the OpenSSL implementation, I have posted a page on my website with the patch. http://www.douglas.stebila.ca/code/keying-material-exporters/ In addition to a patch for OpenSSL, I have also done patches to Apache and PHP to expose a PHP function that allows a PHP application to derive keying material from the underlying TLS connection according to the draft specification. Douglas On 2009-Jul-21, at 2:48 AM, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dean@av8.com Tue Jul 21 07:37: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 928FB3A69CB; Tue, 21 Jul 2009 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 3z-zwV12xVyA; Tue, 21 Jul 2009 07:36:59 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 83C493A68DD; Tue, 21 Jul 2009 07:36:59 -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 n6LEZRsb007195 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Jul 2009 10:35:40 -0400 Date: Tue, 21 Jul 2009 10:35:27 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Douglas Stebila In-Reply-To: <10B26916-E4EC-4678-B35E-0C09D58E4169@stebila.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, IETF Discussion , rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 14:37:06 -0000 Hi Douglas, OpenSSL has implemented patented technology before, and distributed it without license but with statement that it contained patented technology that users weren't licenced to use. While challenging the law can sometimes be a good thing and no criticism of OpenSSL project is intended, their actions do not improve our licensing options. For many years, I had to purchase Stronghold--a licensed version of OpenSSL. However easy these patented standards are to implement, they remain patented. And we continue to have the right in the IETF process to demand other, non-patented alternatives, and reject those standards that don't have suitable licensing terms. RFC3979 requires the WG to consider non-patented alternatives, and that didn't happen. --Dean On Tue, 21 Jul 2009, Douglas Stebila wrote: > I have implemented draft-ietf-tls-extractor-06 in the TLS v1.0 > implementation in OpenSSL. I found the draft easy to implement with > no ambiguities or concerns. I believe that the functionality provided > by the draft will be extremely valuable for building application-level > security protocols and encourage its standardization. > > It is my interpretation of the draft that it can be implemented in any > version of TLS, not just TLS v1.2. Obviously the derived key may be > different if the underlying TLS PRF is defined differently (as it is > for TLS v1.2), but the draft is still well-defined for previous > versions of TLS. > > For those interested in the OpenSSL implementation, I have posted a > page on my website with the patch. > http://www.douglas.stebila.ca/code/keying-material-exporters/ > In addition to a patch for OpenSSL, I have also done patches to Apache > and PHP to expose a PHP function that allows a PHP application to > derive keying material from the underlying TLS connection according to > the draft specification. > > Douglas > > On 2009-Jul-21, at 2:48 AM, The IESG wrote: > > > The IESG has received a request from the Transport Layer Security WG > > (tls) to consider the following document: > > > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > > the > > ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 > > > > _______________________________________________ > > 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 > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From n.mavrogiannopoulos@gmail.com Tue Jul 21 07:56:53 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 36E6428C299; Tue, 21 Jul 2009 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 cfpk1Gh29vDo; Tue, 21 Jul 2009 07:56:52 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id AB4263A68DD; Tue, 21 Jul 2009 07:56:51 -0700 (PDT) Received: by ewy26 with SMTP id 26so3109551ewy.37 for ; Tue, 21 Jul 2009 07:56:32 -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=8HwMGRpeEf4AsvWYA43wYaWr5054X8O6hTLCfuDAfNs=; b=urqocv/y1i2VwtLwxLRBFfohiKg7VjxazgWZXeT4YD5W0Uu4WOi479H12sjFziocc+ L2SOyIVJW/rQ+VIX/ZQ5+87s8qJmNdy1Oc/Qn7l9HqhwpZ6LZdXXpgB8E9fPqlYh9c/N aPAa9CEACKcaM4kmrrivtO5uHdGWC+q7wcfZ0= 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=hRwQT3zrnYhqh9KsxvYIylvy2piRKt00fO7KxUKrkbxsgKoOCDFdmWU16/Tb3jp9hb m2Oe9su44KqAkWlWOxCZomXVx5Ky6tTY8khdsFOSBXJb0mTl2LXvOIiRyDwGrGfpR99A hITsylYHg8hdBdvWwRQTUFr0se3WShKIud43M= MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.216.21.65 with SMTP id q43mr1551393weq.43.1248187733279; Tue, 21 Jul 2009 07:48:53 -0700 (PDT) In-Reply-To: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> Date: Tue, 21 Jul 2009 17:48:53 +0300 X-Google-Sender-Auth: 1fcb6e035479611d Message-ID: From: Nikos Mavrogiannopoulos To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 14:56:53 -0000 I'd propose to add this text to the standard: This protocol MUST NOT be used with RFC4492, RFC5289 and draft-rescorla-tls-suiteb. That way the certicom's patents are not applicable. On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkins wrote: > > =A0Certicom's IPR statement dated 13 October 2008 lists some patents > that "may be necessary and essential to implementations of..." the > TLS extractor draft "when used with either: " RFC4492, RFC5289 > or draft-rescorla-tls-suiteb. Check it out: > > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfs= ept08.pdf > > =A0Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and > then the IPR statement does not apply. If it's possible to use the TLS > extractor draft in a way that the IPR statement doesn't apply then I > don't think you can say "the TLS Extractor draft is patent-encumbered". > > =A0I support free software* and I have no problem with this draft being > advanced as a Proposed Standard. > > =A0regards, > > =A0Dan. > > * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297 > =A0for OpenSSL, and check out the "authsae" project on Source Forge. > > On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote: >> I am against this standard because of its patent encumbrances and >> non-free licencing terms. =A0The working group did not get any clear >> answers on what particular patents this draft may infringe, but a patent >> holder (Certicom) did assert an IPR disclosure (1004) listing many >> patents. =A0We have no alternative but to accept the Certicom disclosure >> statements as meaning that the TLS Extractor draft is patent-encumbered >> without a universal, free defensive license. >> >> The statement by https://datatrackerietf.org/ipr/1004/ referring to >> http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietf= sept08.pdf >> which states: >> >> =A0 "Certicom will, upon request, provide a nonexclusive, royalty free >> patent license, to manufacturers to permit end users (including both >> client and server sides), to use the patents in schedule A when >> implementing any of these protocols, including those requiring third >> party certificates provided the certificate is obtained from a licensed >> Certificate Authority (CA). This license does not cover the issuing of >> certificates by a Certification Authority (CA)." >> >> That is not a free license, since Certicom must respond to the "request" >> before any license is granted. After the IETF finally approves the >> necessary standards, Certicom is free to stop approving the requests. >> >> I ask others who support free software to join me in opposing this >> document by sending a message stating opposition to the IETF@IETF.ORG >> mailing list. =A0IETF participation is open to the public, and anyone ma= y >> voice their view on IETF standards. =A0It is also substantive to oppose = a >> document because of its patent status, and in fact, any topic that is >> considered during or related to the IETF process is substantive. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 --Dean >> >> >> On Mon, 20 Jul 2009, The IESG wrote: >> >>> The IESG has received a request from the Transport Layer Security WG >>> (tls) to consider the following document: >>> >>> - 'Keying Material Exporters for Transport Layer Security (TLS) ' >>> =A0 =A0 as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. =A0Please send substantive comments to t= he >>> ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, >>> comments may be sent to iesg@ietf.org instead. In either case, please >>> retain the beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt >>> >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dT= ag=3D16821&rfc_flag=3D0 >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> -- >> Av8 Internet =A0 Prepared to pay a premium for better service? >> www.av8.net =A0 =A0 =A0 =A0 faster, more reliable, better service >> 617 344 9000 >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > From Martin.Rex@sap.com Tue Jul 21 08:33:18 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 349DF28C2F8; Tue, 21 Jul 2009 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.933 X-Spam-Level: X-Spam-Status: No, score=-3.933 tagged_above=-999 required=5 tests=[AWL=2.316, 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 hnxv-bO7Wxe2; Tue, 21 Jul 2009 08:33:17 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3378028C2EF; Tue, 21 Jul 2009 08:33:17 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n6LFWVZK023590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 17:32:31 +0200 (MEST) From: Martin Rex Message-Id: <200907211532.n6LFWUxp015495@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 21 Jul 2009 17:32:30 +0200 (MEST) In-Reply-To: from "Nikos Mavrogiannopoulos" at Jul 21, 9 05:48:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: ietf@ietf.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material 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, 21 Jul 2009 15:33:18 -0000 Nikos Mavrogiannopoulos wrote: > > I'd propose to add this text to the standard: > This protocol MUST NOT be used with RFC4492, RFC5289 and > draft-rescorla-tls-suiteb. How much longer are we going to beat that dead horse? I'm not aware of information that the Certicom patents apply to TLS extractors. I'm not even aware of information that Certicom claims that the patent applies to TLS extractors when ECC crypto is used. The information that I've seen is that the Certicom patent claim "covers" TLS extractors when TLS is used with ECC crypto, and they acutally imply that their patents claims "cover" pretty much all standards around TLS when TLS is used with ECC crypto. TLS extractors is essentially the TLS PRF exposed with an API, so really, for IP lawyers, TLS with extractors has the exact same attack surface as TLS without TLS extractors. -Martin From dean@av8.com Tue Jul 21 08:59:31 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 62E013A6AAB; Tue, 21 Jul 2009 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-DWLYwmnOMg; Tue, 21 Jul 2009 08:59:29 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id A8F563A6E5F; Tue, 21 Jul 2009 08:58:42 -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 n6LFwWuF007393 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Jul 2009 11:58:33 -0400 Date: Tue, 21 Jul 2009 11:58:32 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Nikos Mavrogiannopoulos In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org, ietf-honest@lists.iadl.org, rms@gnu.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 15:59:31 -0000 I think you misunderstand how patents work or what the license says. The licence is available for the case "when used with either ...". It is not the case that a patent only applies to specific RFCs. RFC's aren't mentioned in patents. Patent claims covering tls-extractor very likely* apply to any use of extractor, not just those uses that also use other Certicom technology in other RFCs. I think you are assuming that because Certicom offers a license for a certain situation (or maybe 'use configuration' is a better phrase), that different use configurations then won't need a license, but that isn't usually* the case. Those other 'use configurations' that infringe a claim still require a license. Note also the Certicom license isn't available for use by Certificate Authorities. But note also that identifying the specific claims is not the best approach for developing non-infringing technology. One starts with prior art which cannot be patented. So the question to ask yourself is: "How difficult would it be to start from unpatentable prior art, and produce something that does what is needed, but differently from how Certicom et al did it?" Except for some very fundamental technology, the answer is almost always "Easy". The alternative is to pay license fees, create more income for patented standards, and encourage even more patenting of standards. So, please, just say "no", and oppose this document. --Dean [* Can't say for certain because Certicom has been unhelpful with specific claims, and the bulk of patents is large--I've read some, but not all.] On Tue, 21 Jul 2009, Nikos Mavrogiannopoulos wrote: > I'd propose to add this text to the standard: > This protocol MUST NOT be used with RFC4492, RFC5289 and > draft-rescorla-tls-suiteb. > > That way the certicom's patents are not applicable. > > On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkins wrote: > > > >  Certicom's IPR statement dated 13 October 2008 lists some patents > > that "may be necessary and essential to implementations of..." the > > TLS extractor draft "when used with either: " RFC4492, RFC5289 > > or draft-rescorla-tls-suiteb. Check it out: > > > > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf > > > >  Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and > > then the IPR statement does not apply. If it's possible to use the TLS > > extractor draft in a way that the IPR statement doesn't apply then I > > don't think you can say "the TLS Extractor draft is patent-encumbered". > > > >  I support free software* and I have no problem with this draft being > > advanced as a Proposed Standard. > > > >  regards, > > > >  Dan. > > > > * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297 > >  for OpenSSL, and check out the "authsae" project on Source Forge. > > > > On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote: > >> I am against this standard because of its patent encumbrances and > >> non-free licencing terms.  The working group did not get any clear > >> answers on what particular patents this draft may infringe, but a patent > >> holder (Certicom) did assert an IPR disclosure (1004) listing many > >> patents.  We have no alternative but to accept the Certicom disclosure > >> statements as meaning that the TLS Extractor draft is patent-encumbered > >> without a universal, free defensive license. > >> > >> The statement by https://datatrackerietf.org/ipr/1004/ referring to > >> http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf > >> which states: > >> > >>   "Certicom will, upon request, provide a nonexclusive, royalty free > >> patent license, to manufacturers to permit end users (including both > >> client and server sides), to use the patents in schedule A when > >> implementing any of these protocols, including those requiring third > >> party certificates provided the certificate is obtained from a licensed > >> Certificate Authority (CA). This license does not cover the issuing of > >> certificates by a Certification Authority (CA)." > >> > >> That is not a free license, since Certicom must respond to the "request" > >> before any license is granted. After the IETF finally approves the > >> necessary standards, Certicom is free to stop approving the requests. > >> > >> I ask others who support free software to join me in opposing this > >> document by sending a message stating opposition to the IETF@IETF.ORG > >> mailing list.  IETF participation is open to the public, and anyone may > >> voice their view on IETF standards.  It is also substantive to oppose a > >> document because of its patent status, and in fact, any topic that is > >> considered during or related to the IETF process is substantive. > >> > >>               --Dean > >> > >> > >> On Mon, 20 Jul 2009, The IESG wrote: > >> > >>> The IESG has received a request from the Transport Layer Security WG > >>> (tls) to consider the following document: > >>> > >>> - 'Keying Material Exporters for Transport Layer Security (TLS) ' > >>>     as a Proposed Standard > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits > >>> final comments on this action.  Please send substantive comments to the > >>> ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > >>> comments may be sent to iesg@ietf.org instead. In either case, please > >>> retain the beginning of the Subject line to allow automated sorting. > >>> > >>> The file can be obtained via > >>> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > >>> > >>> > >>> IESG discussion can be tracked via > >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > -- 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 Jul 21 09:39:17 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 A71FB3A6B69; Tue, 21 Jul 2009 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1dzjF8VuoSX; Tue, 21 Jul 2009 09:39:16 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id CEC2D3A6848; Tue, 21 Jul 2009 09:38:36 -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 n6LGcSCv007531 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Jul 2009 12:38:29 -0400 Date: Tue, 21 Jul 2009 12:38:28 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Martin Rex In-Reply-To: <200907211532.n6LFWUxp015495@fs4113.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org, ietf@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material 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, 21 Jul 2009 16:39:17 -0000 On Tue, 21 Jul 2009, Martin Rex wrote: > I'm not aware of information that the Certicom patents apply to TLS > extractors. > > I'm not even aware of information that Certicom claims that the patent > applies to TLS extractors when ECC crypto is used. Actually, you are "aware" of these patents by any reasonable standard, because you are "aware" of IPR disclosure 1004 and you are "aware" of at least this discussion informing you of the patents. Willfully disregarding the patent notices does not make you "unaware", but just serves to discredit any defense your lawyer might raise against charges of intentional infringement. To put it as plainly as possible, if the demand letter from the patent holder isn't the first time you heard of the patent, you might have a problem with intentional infringement. At that point, it is often too late to challenge the validity of the patent. > The information that I've seen is that the Certicom patent claim > "covers" TLS extractors when TLS is used with ECC crypto, and they > acutally imply that their patents claims "cover" pretty much all > standards around TLS when TLS is used with ECC crypto. Some of their patents are indeed very broad in scope. > TLS extractors is essentially the TLS PRF exposed with an API, so > really, for IP lawyers, TLS with extractors has the exact same attack > surface as TLS without TLS extractors. If this is an argument against the validity of a patent, you should bring it to the patent office. This body cannot challenge the validity of a patent. Except in certain circumstances, a court cannot challenge the validity of a patent. It is unwise to ignore a patent, since a court is to presume the validity of a patent. Court cases, like Bilsky, that invalidate a patent, invalidate a whole class of patents when their reasoning is statutory or constitutional. (Bilsky is statutory and if upheld, may invalidate all software patents--unless Congress alters the law) When one wins an ordinary patent case, it is usually a factual matter that the claims don't actually cover the use, or the other party has committed some misconduct (eg. Qualcomm v. Broadcomm). That you think the patent is a bad patent that should never have been granted isn't a valid legal reason to ignore a patent. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From paul.hoffman@vpnc.org Tue Jul 21 09:43:37 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 D3C3D3A69DB; Tue, 21 Jul 2009 09:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 7FOvrm0QwMRx; Tue, 21 Jul 2009 09:43:37 -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 BCC9B3A6857; Tue, 21 Jul 2009 09:43:36 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LGhY1D051791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 09:43:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 21 Jul 2009 09:43:33 -0700 To: tls@ietf.org, ietf@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 16:43:38 -0000 At 3:15 PM -0400 7/20/09, Dean Anderson wrote: >I am against this standard because of its patent encumbrances and >non-free licencing terms. In the past, I think that Dean Anderson has stated that he is not a lawyer (although I can't find the specific reference). Note that the statement above is legal advice: he is saying that a particular protocol is encumbered. Readers of this thread may or may not want to listen to his legal advice. > The working group did not get any clear >answers on what particular patents this draft may infringe, but a patent >holder (Certicom) did assert an IPR disclosure (1004) listing many >patents. That statement did not say "we have a patent that encumbers the specific documents in question". > We have no alternative but to accept the Certicom disclosure >statements as meaning that the TLS Extractor draft is patent-encumbered >without a universal, free defensive license. Who is "we"? Dean Anderson is not a leader in the IETF, nor of the TLS protocol or developer community. "We" have plenty of alternatives, for almost any value of "we" that make sense here. --Paul Hoffman, Director --VPN Consortium From Martin.Rex@sap.com Tue Jul 21 09:49: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 9B0273A6813; Tue, 21 Jul 2009 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.091 X-Spam-Level: X-Spam-Status: No, score=-5.091 tagged_above=-999 required=5 tests=[AWL=1.158, 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 fiVYoo9xk8n8; Tue, 21 Jul 2009 09:49:11 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A5A953A684C; Tue, 21 Jul 2009 09:49:10 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n6LGmnWk022565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 18:48:49 +0200 (MEST) From: Martin Rex Message-Id: <200907211648.n6LGmm31021113@fs4113.wdf.sap.corp> To: dean@av8.com (Dean Anderson) Date: Tue, 21 Jul 2009 18:48:48 +0200 (MEST) In-Reply-To: from "Dean Anderson" at Jul 21, 9 12:38:28 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, rms@gnu.org, Martin.Rex@sap.com, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material 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, 21 Jul 2009 16:49:11 -0000 The Certicom IPR disclosure says that their patent claims cover pretty much all of the TLS documents when TLS is used with ECC Crypto. You're constantly arguing that Certicoms patent claims *APPLY* to TLS extractors -- which it is not, and which no one from Certicom seems to claim. The difference between "covers" and "applies" is, that the TLS extractors technology does not, by itself, infringe on any of the patent claims in their patents--otherwise, there would not be the precondition with the use of ECC crypto. -Martin From dean@av8.com Tue Jul 21 12:34: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 316673A6D07; Tue, 21 Jul 2009 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, SARE_CHILDPRN1=1.15] 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 iLq4gHbWxerm; Tue, 21 Jul 2009 12:33:59 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 922663A6E1D; Tue, 21 Jul 2009 12:33:56 -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 n6LJXNMe007946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Jul 2009 15:33:23 -0400 Date: Tue, 21 Jul 2009 15:33:23 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Paul Hoffman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 19:34:00 -0000 On Tue, 21 Jul 2009, Paul Hoffman wrote: > At 3:15 PM -0400 7/20/09, Dean Anderson wrote: > >I am against this standard because of its patent encumbrances and > >non-free licencing terms. > > In the past, I think that Dean Anderson has stated that he is not a > lawyer (although I can't find the specific reference). Note that the > statement above is legal advice: he is saying that a particular > protocol is encumbered. Readers of this thread may or may not want to > listen to his legal advice. My statement above is not legal advice. I am not a lawyer, and have not claimed to be a lawyer. I am the President of the League for Programming Freedom (LPF), which opposes software patents, and have been involved with the LPF since 1989. I am a member of the Boston Social Law Library and I also have access to lawyers and extensive legal materials. I've heard variations of Paul Hoffman's accusations above from people who want to to advocate their own position by encouraging people to ignore indisputable facts or by advocating disregard the law in some cases. I first heard that claim when I told a network admin that the newsgroup alt.sex.pedophilia shouldn't be carried because it is used for distributing child pornography. The admin wrote back asserting that he would report me to the bar association for practicing law without a license. I did contact a lawyer; stating facts, opinion, and my position are not legal advice and are not the practice of law without a license. Paul's claims here are false. Please ignore them. > > The working group did not get any clear > >answers on what particular patents this draft may infringe, but a patent > >holder (Certicom) did assert an IPR disclosure (1004) listing many > >patents. > > That statement did not say "we have a patent that encumbers the > specific documents in question". Yes, it does indeed state that. That's what an IPR statement discloses, and IPR 1004 lists this document, and cites the patents. > > We have no alternative but to accept the Certicom disclosure > > statements as meaning that the TLS Extractor draft is > > patent-encumbered without a universal, free defensive license. > > Who is "we"? Dean Anderson is not a leader in the IETF, nor of the TLS > protocol or developer community. "We" have plenty of alternatives, for > almost any value of "we" that make sense here. Paul Hoffman is also not the leader of the IETF, and of course, "we" as used by both Paul and myself does not mean that either of us speak for the IETF. I used "we" just as Paul used it. Paul's objection to "we" has no relevance. Please ignore it. However, contrary to Paul's assertion that '"we" have many alternatives', there are in fact only two alternatives available to the IETF at present: Either approve the document with its licencing terms as-is, or reject the document. I argue, on a firm factual basis, for rejecting that document. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Nicolas.Williams@sun.com Tue Jul 21 13:15:53 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 A50473A6AAF; Tue, 21 Jul 2009 13:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 B521qhxkJoAx; Tue, 21 Jul 2009 13:15:52 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 98F1F3A6A9D; Tue, 21 Jul 2009 13:15:51 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6LKFpXp006648; Tue, 21 Jul 2009 20:15:51 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 n6LKFoxc002768; Tue, 21 Jul 2009 14:15:50 -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 n6LJoTcq002072; Tue, 21 Jul 2009 14:50:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6LJoSN3002071; Tue, 21 Jul 2009 14:50:28 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Jul 2009 14:50:28 -0500 From: Nicolas Williams To: Dean Anderson Message-ID: <20090721195028.GQ1020@Sun.COM> References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org, ietf-honest@lists.iadl.org, rms@gnu.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 20:15:53 -0000 On Mon, Jul 20, 2009 at 04:54:36PM -0400, Dean Anderson wrote: > Its possible to use any draft as toilet paper---a use that doesn't > infringe---but that doesn't mean the draft is free and unencumbered. The IPR applies to ECC, so don't use ECC. I don't see draft-ietf-tls-extractor as explicitly encumbered, but as encumbered when used with ECC, and in encumbered ways. But see below. > It is not the patents on these other standards that are the problem with > TLS-extractor. It is that using the methods described in the extractor > draft further infringe patents owned by Certicom. So we should either > use other methods, or require that Certicom offer a suitable license. Arguably any IPR claim on draft-ietf-tls-extractor based on ECC IPR is wrong: if you infringe on the ECC IPR then use of draft-ietf-tls-extractor does not make this infringement worse. The interesting question is: Suppose you have an implementation of TLS that has a license to Certicom's ECC IPR, and suppose that you have an application that uses draft-ietf-tls-extractor, and the application does not have its own license to Certicom's ECC IPR -- is the application then infringing on Certicom's IPR?? IANAL and will not speculate as to what the answer to that is. Each TLS implementor should get their own legal advice on this question. However if the answer is yes, then the TLS implementation must not export the TLS extractor to applications when doing so would cause the applications to infringe. That might make the APIs obnoxious (apps would have to indicate what IPR they've licensed, if any), but the result would still be useable and useful. IMO draft-ietf-tls-extractor should progress. TLS implementors may want to get legal advice as to whether draft-ietf-tls-extractor APIs puts third-party applications at risk, and if so how they should communicate this risk to third-parties. Such a note might well belong in the RFC itself. Ideally Certicom would say that draft-ietf-tls-extractor does not put applications at risk of infringment regardless of whether ECC cipher suites [that could infringe on Certicom IPR] are in use. But draft-ietf-tls-extractor should proceed even without such a statement. Nico -- From dean@av8.com Tue Jul 21 13:16:07 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 9A0D83A6E8C; Tue, 21 Jul 2009 13:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 tsm4jjln1o9S; Tue, 21 Jul 2009 13:16:05 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 879993A67A3; Tue, 21 Jul 2009 13:16: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 n6LKFtTx008044 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Jul 2009 16:15:55 -0400 Date: Tue, 21 Jul 2009 16:15:54 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Martin Rex In-Reply-To: <200907211648.n6LGmm31021113@fs4113.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org, ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material 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, 21 Jul 2009 20:16:07 -0000 On Tue, 21 Jul 2009, Martin Rex wrote: > The Certicom IPR disclosure says that their patent claims cover > pretty much all of the TLS documents when TLS is used with ECC Crypto. > > You're constantly arguing that Certicoms patent claims *APPLY* > to TLS extractors -- which it is not, and which no one from > Certicom seems to claim. Certicom claimed this when they added TLS extractor to IPR 1004. > The difference between "covers" and "applies" is, that the TLS > extractors technology does not, by itself, infringe on any of the > patent claims in their patents--otherwise, there would not be the > precondition with the use of ECC crypto. There is no factual basis for your statement. The terms to which you refer are in the _license_, which is distinct from the patents. But In order to add this document to the license, they should have a patent claim somewhere that covers extractor, otherwise they would be subject to a claim of misuse by trying to extend the patent to non-patented components. Certicom has an army of lawyers, and I have no reason to think they would overlook that. You have provided no factual statements to back up your assertion that they don't have patent coverage on extractor. ============= Quote "Misuse" means that the patent owner has over-reached and tried to do more than legitimately is authorized by the patent monopoly. This can involve more than just patent law, for the abuse of a legal monopoly easily become a forbidden monopoly prohibited by the antitrust laws. But somewhere between legitimate use and antitrust violation lies a wide range of acts that, although not so gross as to constitute antitrust violations, are nevertheless abuses of the patent right for which the penalty is temporary loss of the patent privilege. [...] Misuse is the "attempt to 'extend the patent' and thus monopolize the market for the unpatented component." Rohm & Hass Co. v. Dawson Chemical Co. (1979) ============= End Quote Section 8.7, pg 137, "Intellectual Property, Patents, Trademarks and Copyright" by Arther Miller and Michael Davis (1990) I see no reason to assume there is no patent coverage on TLS extractor. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From n.mavrogiannopoulos@gmail.com Tue Jul 21 14:29: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 606AF3A67A3; Tue, 21 Jul 2009 14:29:15 -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 00VIJxnr7h+e; Tue, 21 Jul 2009 14:29:14 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2FB8C3A683A; Tue, 21 Jul 2009 14:29:13 -0700 (PDT) Received: by fxm18 with SMTP id 18so2884640fxm.37 for ; Tue, 21 Jul 2009 14:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=mKVLnNgKykujtyJTIFrPaRZScEdoohFHWiXpFFDJzDw=; b=AObcUqwqDcLCPaN//T3nrwl4EUEmORi1GnIoHKPkQCim/i6snPFzlacV6/bxax5Vjo g+fNoS6A6GfjHNaM2iMTCuq70dAYULscNLLC1kTJzP2dKvtYXEkUN+PysbONO3Vpj1lI HOc/zm7hxIkYEVsZWshXU8lQZxvkl3B5l9nBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=QLgqrX9jCpvxt3HyFKaH+6ORxwLnN2WcRyFGoGrVMC5omz4CJw4+TfxmMOGUVZKCDn 6rMh6ZIheZ/sHKMbFbmqWkm8FuwmaI6CZ2jvg2KjstuioKvrVN8SApHW0HrBAKmTd8RG f89BGBpyTZKujovnnoqPVok3NEvglkKlDgzuo= Received: by 10.204.61.204 with SMTP id u12mr113992bkh.149.1248211751508; Tue, 21 Jul 2009 14:29:11 -0700 (PDT) Received: from ?10.100.1.196? (adsl89-51.ath.forthnet.gr [212.251.110.51]) by mx.google.com with ESMTPS id f31sm10421338fkf.8.2009.07.21.14.29.10 (version=SSLv3 cipher=RC4-MD5); Tue, 21 Jul 2009 14:29:10 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4A663325.4070903@gnutls.org> Date: Wed, 22 Jul 2009 00:29:09 +0300 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: ietf@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-honest@lists.iadl.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 21:29:15 -0000 Dean Anderson wrote: > I think you misunderstand how patents work or what the license says. > > The licence is available for the case "when used with either ...". It is > not the case that a patent only applies to specific RFCs. RFC's aren't > mentioned in patents. Patent claims covering tls-extractor very likely* > apply to any use of extractor, not just those uses that also use other > Certicom technology in other RFCs. I think you are assuming that > because Certicom offers a license for a certain situation (or maybe 'use > configuration' is a better phrase), that different use configurations > then won't need a license, but that isn't usually* the case. Those other > 'use configurations' that infringe a claim still require a license. After this clarification I would object draft-ietf-tls-extractor to be published as proposed standard. regards, Nikos From jwkckid1@ix.netcom.com Tue Jul 21 14:34:29 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 BAAF128C397; Tue, 21 Jul 2009 14:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_CHILDPRN1=1.15] 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 VDulTWSAbbeG; Tue, 21 Jul 2009 14:34:28 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C2CFE3A6EB6; Tue, 21 Jul 2009 14:34:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ri6mxLEattgkAROsfnFmY+xJkiu/8D5lEzr3tBBiG4JWwTQrcMDgJiAiV/mOZxbC; 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.103.77] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTMyI-0003MG-7k; Tue, 21 Jul 2009 17:34:03 -0400 Message-ID: <4A665054.2B8CB4E1@ix.netcom.com> Date: Tue, 21 Jul 2009 16:33:41 -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: Dean Anderson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606888983a54d1840a5ea23987e47ae81498c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.77 Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 21:34:29 -0000 Dean, Paul, and all, Sorry Paul but in this instance I have to agree with Dean, I didn't see anything in his previous remarks that constituted legal advice, and I DO have a law degree but do not practice law. I also agree with Deans previous remarks that the standard indeed is patent incumbered. Such incumbrences may/will price many small companies out of the market which is not a economically or socially healthy thing. Dean Anderson wrote: > On Tue, 21 Jul 2009, Paul Hoffman wrote: > > > At 3:15 PM -0400 7/20/09, Dean Anderson wrote: > > >I am against this standard because of its patent encumbrances and > > >non-free licencing terms. > > > > In the past, I think that Dean Anderson has stated that he is not a > > lawyer (although I can't find the specific reference). Note that the > > statement above is legal advice: he is saying that a particular > > protocol is encumbered. Readers of this thread may or may not want to > > listen to his legal advice. > > My statement above is not legal advice. I am not a lawyer, and have not > claimed to be a lawyer. I am the President of the League for Programming > Freedom (LPF), which opposes software patents, and have been involved > with the LPF since 1989. I am a member of the Boston Social Law Library > and I also have access to lawyers and extensive legal materials. > > I've heard variations of Paul Hoffman's accusations above from people > who want to to advocate their own position by encouraging people to > ignore indisputable facts or by advocating disregard the law in some > cases. I first heard that claim when I told a network admin that the > newsgroup alt.sex.pedophilia shouldn't be carried because it is used for > distributing child pornography. The admin wrote back asserting that he > would report me to the bar association for practicing law without a > license. I did contact a lawyer; stating facts, opinion, and my > position are not legal advice and are not the practice of law without a > license. Paul's claims here are false. Please ignore them. > > > > The working group did not get any clear > > >answers on what particular patents this draft may infringe, but a patent > > >holder (Certicom) did assert an IPR disclosure (1004) listing many > > >patents. > > > > That statement did not say "we have a patent that encumbers the > > specific documents in question". > > Yes, it does indeed state that. That's what an IPR statement discloses, > and IPR 1004 lists this document, and cites the patents. > > > > We have no alternative but to accept the Certicom disclosure > > > statements as meaning that the TLS Extractor draft is > > > patent-encumbered without a universal, free defensive license. > > > > Who is "we"? Dean Anderson is not a leader in the IETF, nor of the TLS > > protocol or developer community. "We" have plenty of alternatives, for > > almost any value of "we" that make sense here. > > Paul Hoffman is also not the leader of the IETF, and of course, "we" as > used by both Paul and myself does not mean that either of us speak for > the IETF. I used "we" just as Paul used it. Paul's objection to "we" > has no relevance. Please ignore it. > > However, contrary to Paul's assertion that '"we" have many > alternatives', there are in fact only two alternatives available to the > IETF at present: Either approve the document with its licencing terms > as-is, or reject the document. I argue, on a firm factual basis, for > rejecting that document. > > --Dean > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > _______________________________________________ > TLS mailing list > TLS@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 jwkckid1@ix.netcom.com Tue Jul 21 14:42:03 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 D075228C397; Tue, 21 Jul 2009 14:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 iRPx9msEpLJ6; Tue, 21 Jul 2009 14:42:01 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 9A35A28C3A4; Tue, 21 Jul 2009 14:42:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=NYN9blVHYmqs64tE3AL0CZdk1tyEJdtXKGUhiDVZXrhnvotVrV8TZ5uWd7K4fIkQ; 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.103.77] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTN60-0002xZ-SQ; Tue, 21 Jul 2009 17:42:01 -0400 Message-ID: <4A665233.A5ABB42A@ix.netcom.com> Date: Tue, 21 Jul 2009 16:41:39 -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: Nicolas Williams References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f94fa011a10ee2e9eafd3a0f7b3ec5d4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.77 Cc: Todd Glassy , ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 21 Jul 2009 21:42:03 -0000 Nic and all, What is suggested here is not a reasonable solution or rational suggestion. I use ECC and was an early supporter of ECC. Our ECC product exceeds the current IETF standards track. We will continue to use ECC and improve on our ECC product as we see fit. The IPR, like FISMA, is misguided as thankfully the recent GAO report clearly pointed out. Nicolas Williams wrote: > On Mon, Jul 20, 2009 at 04:54:36PM -0400, Dean Anderson wrote: > > Its possible to use any draft as toilet paper---a use that doesn't > > infringe---but that doesn't mean the draft is free and unencumbered. > > The IPR applies to ECC, so don't use ECC. I don't see > draft-ietf-tls-extractor as explicitly encumbered, but as encumbered > when used with ECC, and in encumbered ways. But see below. > > > It is not the patents on these other standards that are the problem with > > TLS-extractor. It is that using the methods described in the extractor > > draft further infringe patents owned by Certicom. So we should either > > use other methods, or require that Certicom offer a suitable license. > > Arguably any IPR claim on draft-ietf-tls-extractor based on ECC IPR is > wrong: if you infringe on the ECC IPR then use of > draft-ietf-tls-extractor does not make this infringement worse. > > The interesting question is: > > Suppose you have an implementation of TLS that has a license to > Certicom's ECC IPR, and suppose that you have an application that > uses draft-ietf-tls-extractor, and the application does not have its > own license to Certicom's ECC IPR -- is the application then > infringing on Certicom's IPR?? > > IANAL and will not speculate as to what the answer to that is. Each TLS > implementor should get their own legal advice on this question. > > However if the answer is yes, then the TLS implementation must not > export the TLS extractor to applications when doing so would cause the > applications to infringe. That might make the APIs obnoxious (apps > would have to indicate what IPR they've licensed, if any), but the > result would still be useable and useful. > > IMO draft-ietf-tls-extractor should progress. TLS implementors may want > to get legal advice as to whether draft-ietf-tls-extractor APIs puts > third-party applications at risk, and if so how they should communicate > this risk to third-parties. Such a note might well belong in the RFC > itself. > > Ideally Certicom would say that draft-ietf-tls-extractor does not put > applications at risk of infringment regardless of whether ECC cipher > suites [that could infringe on Certicom IPR] are in use. But > draft-ietf-tls-extractor should proceed even without such a statement. > > Nico > -- > _______________________________________________ > 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 jwkckid1@ix.netcom.com Tue Jul 21 17:13: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 C71423A6E0D; Tue, 21 Jul 2009 17:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 l1wDvgP18mZi; Tue, 21 Jul 2009 17:13:01 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 9AF253A6967; Tue, 21 Jul 2009 17:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RgyYCMHfsZ2ggU12lzocKIizo0mS49O0Whhn7sxNlP5QRbQzbQMu8mTmwnkx9G1c; 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.96.252] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTPS8-00008m-IK; Tue, 21 Jul 2009 20:13:01 -0400 Message-ID: <4A66758C.552F0D02@ix.netcom.com> Date: Tue, 21 Jul 2009 19:12:29 -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: Nikos Mavrogiannopoulos References: <4A663325.4070903@gnutls.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068816fe20349f1f4550560ca8dcbb3e7518350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.252 Cc: tls@ietf.org, ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 00:13:02 -0000 Nikos and all, I concur. Nikos Mavrogiannopoulos wrote: > Dean Anderson wrote: > > I think you misunderstand how patents work or what the license says. > > > > The licence is available for the case "when used with either ...". It is > > not the case that a patent only applies to specific RFCs. RFC's aren't > > mentioned in patents. Patent claims covering tls-extractor very likely* > > apply to any use of extractor, not just those uses that also use other > > Certicom technology in other RFCs. I think you are assuming that > > because Certicom offers a license for a certain situation (or maybe 'use > > configuration' is a better phrase), that different use configurations > > then won't need a license, but that isn't usually* the case. Those other > > 'use configurations' that infringe a claim still require a license. > > After this clarification I would object draft-ietf-tls-extractor to be > published as proposed standard. > > regards, > Nikos > _______________________________________________ > 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 ekr@networkresonance.com Tue Jul 21 18:39:29 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 EDA673A6EDF; Tue, 21 Jul 2009 18:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[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 pmTBwFoUY3PM; Tue, 21 Jul 2009 18:39:27 -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 57FDF3A697A; Tue, 21 Jul 2009 18:38:36 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9D9381D0F2E; Tue, 21 Jul 2009 18:40:50 -0700 (PDT) Date: Tue, 21 Jul 2009 18:40:50 -0700 From: Eric Rescorla To: Dean Anderson In-Reply-To: References: <20090720164816.328D928C1C8@core3.amsl.com> 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: <20090722014050.9D9381D0F2E@kilo.networkresonance.com> Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 01:39:29 -0000 At Mon, 20 Jul 2009 15:15:53 -0400 (EDT), Dean Anderson wrote: > > I am against this standard because of its patent encumbrances and > non-free licencing terms. The working group did not get any clear > answers on what particular patents this draft may infringe, but a patent > holder (Certicom) did assert an IPR disclosure (1004) listing many > patents. We have no alternative but to accept the Certicom disclosure > statements as meaning that the TLS Extractor draft is patent-encumbered > without a universal, free defensive license. This isn't really a complete description of the situation. As others have stated, Certicom's has a variety of patents that apply to ECC technology. When TLS Extractor (or indeed any other IETF technology) is used with the TLS ECC cipher suites, then there is a potential issue with regard to Certicom's patents, but that issue is produced not by Extractor, but by the use of ECC. After Certicom's disclosure (1004), there were questions about whether Certicom's IPR also applied to Extractor with non-ECC cipher suites. During this discussion, Certicom posted a clarification: http://www.ietf.org/mail-archive/web/tls/current/msg03508.html 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. You can find the new disclosure at: https://datatracker.ietf.org/ipr/1153/. In addition, Certicom posted: (see also http://www.ietf.org/mail-archive/web/tls/current/msg03526.html), which reads in part: 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. I consider this pair of statements combined with the IPR statement quite satisfactory. You of course are free to feel differently. -Ekr From huangmin@huaweisymantec.com Tue Jul 21 20:17:01 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 8EE453A6909 for ; Tue, 21 Jul 2009 20:17:01 -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 FwR+da6nXkiU for ; Tue, 21 Jul 2009 20:17:00 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 30D453A68DF for ; Tue, 21 Jul 2009 20:17:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KN5009WUYGA4X30@hstga02-in.huaweisymantec.com> for tls@ietf.org; Wed, 22 Jul 2009 11:16:58 +0800 (CST) Received: from h00104745 ([10.27.154.144]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KN500I0SYG6PR10@hstml01-in.huaweisymantec.com> for tls@ietf.org; Wed, 22 Jul 2009 11:16:58 +0800 (CST) From: Min Huang To: ekr@networkresonance.com Date: Wed, 22 Jul 2009 11:16:54 +0800 Message-id: <005501ca0a7a$dd3d4b30$909a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 Thread-index: AcoKetzWtXcMHox3TbKHtRu34Z4IQA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailman-Approved-At: Tue, 21 Jul 2009 21:07:15 -0700 Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-huang-tls-ibe-00 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, 22 Jul 2009 03:20:05 -0000 Hi,Eric Thanks very much for your review. Reply inline. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eric Rescorla writes: > - There definitely are UI issues with users accepting mismatched > certificates, but it's not clear that IBE will really > solve the problem here; if you're going to mount an attack > it's about equally convenient to have a bogus CA as a > bogus domain name. Unless you're going to prohibit users > from accepting PKGs that their clients don't know about > (we tried this with CAs and it didn't work out), it seems > to me that we're going to still have the user override > problem. The certificate (or public parameters) is sent from the server to the client. There always is a mismatching problem, either a distrusted CA or a distrusted PKG. So in this proposal I thought that the client provides the sets of public parameters from PKGs it trusts before the server sends its public parameters. The public parameters set sent by the server must be one of the sets provided by the client. If there is no matched set, the server can not choose IBE cipher suites or this connection is failed. This is also one reason of putting public parameters sets in the ClientHello message. However, as you mentioned, this mechanism is not so good. There is another mechanism. I am considering how about putting the public parameters set in the Server Certificate message. The client only provides the IBE cipher suites. If the server chooses an IBE cipher suite, it needs to provide the public parameters retrieved from the PKG/PPS from which it acquired the private key. I will call the original mechanism "mechanism 1" and this alternative mechanism "mechanism 2" for convenience in the following description. Mechanism 1 supports obtaining private keys in real time if there is no matching PKG from which it has obtained the private key and in advance if there is a matching PKG. In mechanism 2 the server can also acquire its private key in real time or in advance depending on the policies configured. It needs to consider which mechanism is better. I wonder we can reach consensus in the wg. > Moreover, the main benefit of IBE, namely that Alice can send an > encrypted message to Bob without communicating with Bob and before > Bob has enrolled doesn't pay off here because TLS involves direct > communication and expects the server to be able to decrypt the PMS in real time. In TLS this benefit of IBE is not utilized because TLS involves real time communication. If the time taken by obtaining private key is within the tolerance of real time communication, then the server can obtain its private key in the process of TLS handshake. > The mechanism described here is extremely clumsy: I find it highly implausible that the > client is going to send its entire list of PKGs (if X.509 is any guide, this would run to a hundred > or so) in every ClientHello. Actually, due to the unique security properties of IBE, I would imagine > there would be more PKGs because the amount of trust placed in a PKG is much higher than a CA. Here "list of PKGs" you mentioned above actually is a list of public parameters sets from PPSs/PKGs trusted by client. What I considered earlier is that the number of PKGs in one domain is not large, but in the whole internet environment, this mechanism seems clumsy. I am considering another mechanism described in front. The public parameters and server ID used in key exchange are provided by the server who has already acquired its private key from one PKG. "Actually, due to the unique security properties of IBE, I would imagine there would be more PKGs because the amount of trust placed in a PKG is much higher than a CA." It means that if one PKG is compromised, all of the users' private keys are compromised. So there must be many PKGs that undertake the responsibility of generating private keys together. Then if one PKG is compromised, it only affects the parts of users' private keys and the users' private keys are still secret. So the security degree of the private keys and the number of PKGs are increased. > S 1. > user. In this procedure, user must get all certificates of CAs > involved in this authority chain and make requests for Certificate > Revocation Lists (CRLs) to check if the certificates are still valid. > > In TLS, it's standard practice to send the whole chain. The meaning I want to express is the same as yours. The server sends the whole chain of certificates. The client who receives this chain checks the CRL and verifies the signatures contained in these certificates. In IBE, the client needs to check the public parameters, server's ID and associated private key is still valid. > What's the value of this at all? Why not just use certificates. I just want to provide an more option for key exchange and user authentication in some circumstances. > Why not use standard unix times here? Good suggestion, I will rewrite the definition of this structure. And maybe ietf standard times format described in RFC3339 will be better. > The public_parameter_data contains the actual cryptographic > parameters depending on the specific algorithm. > Where is this specified. The parameters contained in IBE public parameters are specified in RFC 5408 and I consulted that specification. Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms are described in IBCS (RFC 5091). > This seems to me to be missing actual support for short-lived keys. > In order to avoid needing revocation, you need to include a date string as part of > the server's identity. Where is this stored, how is it agreed upon, etc? Agree. I will add a date string into the IDInfo structure in new version. > What if I dont want to do client auth? If the server doesn't want to do client auth, it just ignores the client_id_list field and CertificateRequest message will not be sent by server. I will add appropriate description to the doc, is it right? > S 6. > The security considerations really need to accurately describe the consequences > of compromise of the PKG, which are much worse than that of a CA. I will reword the security considerations section to describe the issues clearly and accurately. regards, Min Huang From ekr@networkresonance.com Tue Jul 21 21:22: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 4B6C83A690B for ; Tue, 21 Jul 2009 21:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.954, 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, J_CHICKENPOX_24=0.6, 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 eytDmhz+kVrt for ; Tue, 21 Jul 2009 21:22:11 -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 EE1EB3A67A1 for ; Tue, 21 Jul 2009 21:22:10 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 378521D0F73; Tue, 21 Jul 2009 21:24:26 -0700 (PDT) Date: Tue, 21 Jul 2009 21:24:26 -0700 From: Eric Rescorla To: Min Huang In-Reply-To: <005501ca0a7a$dd3d4b30$909a1b0a@china.huawei.com> References: <005501ca0a7a$dd3d4b30$909a1b0a@china.huawei.com> 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: <20090722042426.378521D0F73@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-huang-tls-ibe-00 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, 22 Jul 2009 04:22:12 -0000 At Wed, 22 Jul 2009 11:16:54 +0800, Min Huang wrote: > > > Hi,Eric > > Thanks very much for your review. > Reply inline. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Eric Rescorla writes: > > > - There definitely are UI issues with users accepting mismatched > > certificates, but it's not clear that IBE will really > > solve the problem here; if you're going to mount an attack > > it's about equally convenient to have a bogus CA as a > > bogus domain name. Unless you're going to prohibit users > > from accepting PKGs that their clients don't know about > > (we tried this with CAs and it didn't work out), it seems > > to me that we're going to still have the user override > > problem. > > The certificate (or public parameters) is sent from the > server to the client. There always is a mismatching > problem, either a distrusted CA or a distrusted PKG. > So in this proposal I thought that the client provides > the sets of public parameters from PKGs it trusts > before the server sends its public parameters. > The public parameters set sent by the server must > be one of the sets provided by the client. If there is > no matched set, the server can not choose IBE > cipher suites or this connection is failed. This is > also one reason of putting public parameters sets > in the ClientHello message. However, as you > mentioned, this mechanism is not so good. There > is another mechanism. I am considering how > about putting the public parameters set in the > Server Certificate message. The client only > provides the IBE cipher suites. If the server chooses > an IBE cipher suite, it needs to provide the public > parameters retrieved from the PKG/PPS from which > it acquired the private key. I will call the original > mechanism "mechanism 1" and this alternative > mechanism "mechanism 2" for convenience in > the following description. Mechanism 1 supports > obtaining private keys in real time if there is no > matching PKG from which it has obtained the > private key and in advance if there is a matching > PKG. In mechanism 2 the server can also acquire > its private key in real time or in advance depending > on the policies configured. > It needs to consider which mechanism is better. > I wonder we can reach consensus in the wg. But Mechanism 2 has the same issues as certificates in terms of the user being able to override invalid credentials. > > Moreover, the main benefit of IBE, namely that Alice can send an > > encrypted message to Bob without communicating with Bob and before > > Bob has enrolled doesn't pay off here because TLS involves direct > > communication and expects the server to be able to decrypt the PMS in > real time. > > In TLS this benefit of IBE is not utilized because TLS > involves real time communication. If the time taken > by obtaining private key is within the tolerance of real > time communication, then the server can obtain its > private key in the process of TLS handshake. I agree that this benefit is not applicable to TLS. But since that's the main technical benefit of IBE... > > The mechanism described here is extremely clumsy: I find it highly > implausible that the > > client is going to send its entire list of PKGs (if X.509 is any guide, > this would run to a hundred > > or so) in every ClientHello. Actually, due to the unique security > properties of IBE, I would imagine > > there would be more PKGs because the amount of trust placed in a PKG is > much higher than a CA. > > Here "list of PKGs" you mentioned above actually > is a list of public parameters sets from PPSs/PKGs > trusted by client. What I considered earlier is that > the number of PKGs in one domain is not large, > but in the whole internet environment, this > mechanism seems clumsy. I am considering > another mechanism described in front. The public > parameters and server ID used in key exchange > are provided by the server who has already > acquired its private key from one PKG. > "Actually, due to the unique security properties > of IBE, I would imagine there would be more PKGs > because the amount of trust placed in a PKG is > much higher than a CA." > It means that if one PKG is compromised, > all of the users' private keys are compromised. > So there must be many PKGs that undertake the > responsibility of generating private keys together. > Then if one PKG is compromised, it only affects > the parts of users' private keys and the users' > private keys are still secret. So the security > degree of the private keys and the number of > PKGs are increased. I don't understand what you're suggesting here. > > What's the value of this at all? Why not just use certificates. > > I just want to provide an more option for key exchange > and user authentication in some circumstances. I'm not convinced that adding new options is good here. What does this bring to the party. > > The public_parameter_data contains the actual cryptographic > > parameters depending on the specific algorithm. > > Where is this specified. > > The parameters contained in IBE public parameters > are specified in RFC 5408 and I consulted that specification. > Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms > are described in IBCS (RFC 5091). OK, but you need to describe the actual encoding. Is it an IBESysParams or what? > > This seems to me to be missing actual support for short-lived keys. > > In order to avoid needing revocation, you need to include a date string > as part of > > the server's identity. Where is this stored, how is it agreed upon, etc? > > Agree. > I will add a date string into the IDInfo structure in new version. But this makes the real time problem worse, since the client needs to know in advance what keys the server might potentially have, otherwise the server will need to get a new key for each client. -Ekr From fweimer@bfk.de Wed Jul 22 03:03: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 100D23A6A3C; Wed, 22 Jul 2009 03:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 fORfM0Qw4ggx; Wed, 22 Jul 2009 03:03:11 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id F3EED3A68DA; Wed, 22 Jul 2009 03:03:09 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MTYgE-0000nC-5f; Wed, 22 Jul 2009 12:04:10 +0200 Received: by bfk.de with local id 1MTYbq-0003xE-NY; Wed, 22 Jul 2009 09:59:38 +0000 To: Paul Hoffman References: From: Florian Weimer Date: Wed, 22 Jul 2009 09:59:38 +0000 In-Reply-To: (Paul Hoffman's message of "Tue\, 21 Jul 2009 09\:43\:33 -0700") Message-ID: <82fxcpdomt.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 10:03:12 -0000 * Paul Hoffman: > At 3:15 PM -0400 7/20/09, Dean Anderson wrote: >>I am against this standard because of its patent encumbrances and >>non-free licencing terms. > > In the past, I think that Dean Anderson has stated that he is not a > lawyer (although I can't find the specific reference). Note that the > statement above is legal advice: he is saying that a particular > protocol is encumbered. Readers of this thread may or may not want > to listen to his legal advice. Eh, no. It's a recommendation not to publish the draft as an RFC. It does not even voice a legal opinion. I really don't see what this is about. Certicom is pretty close to making the IETF process pointless, by overzealous filing of IPR claims. But apparently, there was a recent clarification that this key agreement extension is only affected by Certicom's IP if it's used with ECC, so it's hard to argue that Certicom is carrying out a denial of service attack on the WG. > That statement did not say "we have a patent that encumbers the > specific documents in question". The IETF process doesn't reward IPR holders for precise IPR statements. Anyway, those who object to the ECC infection should strive to remove it from the base TLS spec. It doesn't make sense to rehash this discussion over and over again, for each draft produced by the WG which happens to be compatible with ECC algorithms and for which Certicom files an IPR claim. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ekr@networkresonance.com Wed Jul 22 07:02: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 0A6173A68D2; Wed, 22 Jul 2009 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=-0.336, 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 d8Fll7kA1IDm; Wed, 22 Jul 2009 07:02:25 -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 49D6E3A68C5; Wed, 22 Jul 2009 07:02:25 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0B7411D1078; Wed, 22 Jul 2009 06:51:37 -0700 (PDT) Date: Wed, 22 Jul 2009 06:51:36 -0700 From: Eric Rescorla To: Florian Weimer In-Reply-To: <82fxcpdomt.fsf@mid.bfk.de> References: <82fxcpdomt.fsf@mid.bfk.de> 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: <20090722135137.0B7411D1078@kilo.networkresonance.com> Cc: ietf@ietf.org, Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 14:02:26 -0000 At Wed, 22 Jul 2009 09:59:38 +0000, Florian Weimer wrote: > Anyway, those who object to the ECC infection should strive to remove > it from the base TLS spec. It doesn't make sense to rehash this > discussion over and over again, for each draft produced by the WG > which happens to be compatible with ECC algorithms and for which > Certicom files an IPR claim. Note: ECC isn't in the base spec, really. More precisely, the code points are defined in 4492. All the ECC that's defined in 5246 is the rules for what sorts of certificates may be used for a given algorithm, and that's because 5246 changed the rules beyond 4346 and so we wanted to have them all in one place. -Ekr From dean@av8.com Wed Jul 22 12:29: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 3F4813A68A6; Wed, 22 Jul 2009 12:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 pDmAsCeB+gFl; Wed, 22 Jul 2009 12:29:29 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 2A2C13A6B3D; Wed, 22 Jul 2009 12:28:52 -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 n6MJQsZr012514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jul 2009 15:26:57 -0400 Date: Wed, 22 Jul 2009 15:26:54 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla In-Reply-To: <20090722014050.9D9381D0F2E@kilo.networkresonance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 19:29:30 -0000 Hi Eric, On Tue, 21 Jul 2009, Eric Rescorla wrote: > As others have stated, Certicom's has a variety of patents that > apply to ECC technology. When TLS Extractor (or indeed any other > IETF technology) is used with the TLS ECC cipher suites, then > there is a potential issue with regard to Certicom's patents, > but that issue is produced not by Extractor, but by the use > of ECC. After Certicom's disclosure (1004), there were > questions about whether Certicom's IPR also applied to Extractor > with non-ECC cipher suites. Err, no. See the message on the misuse of patents. IF* there is no patent claim to cover extractor, adding extractor would raise the issue of misuse for trying to cover extractor with its patent licence. IF* there is a claim or claims covering extractor, we cannot be sure they are limited to use with ECC. The test for infringement is when the use performs "substantially the same function" as claimed. It would seem that anything that is similar to ECC, (but not ECC) probably performs substantially the same function with respect to extractor claims. [* Again, more exact statements cannot be made because Certicom has been unhelpful in identifying the precise patent(s) and claims that cover extractor.] > 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. > > You can find the new disclosure at: https://datatracker.ietf.org/ipr/1153/. Then they updated that with IPR 1154. While necessary updates of details, I find no differences that significantly alter the key facts: 1. The Certicom disclosures state that Extractor is covered by a patent. 2. There is no universal free license. There is only the offer to request a free license. Certicom can refuse requests at anytime. 3. Certificate Authorities are already denied any free licence. The statement you quote above doesn't alter anything, and I am mystified why people continue to cite that statement as evidence of "good intent" or that this is free software. It is not free software. Obviously, _every_ proprietary software vendor's intention is to 'foster broad adoption' of their technology. They often give out free samples to do that. And of course, they then extract as much money for that software as they can; the software doesn't remain free. Certicom's stated intent is to foster broad adoption, not produce free software. But the Certicom statement is still slightly misleading because there is no actual grant made in the document, even though the document refers to "the grant". The document states only that one may _request_ a free license. But one doesn't need a 'grant' to request free licence. Anyone can _ask_ Oracle, MS, etc for a free license too---Maybe that request will be granted. And BTW, I have no doubt that Certicom will give out _some_ free licenses to encourage adoption---I'm not accusing them of outright deception. But proprietary vendors like Oracle also give out free samples. The difference is that free software is inherently free, and proprietary software is free for a limited time. Don't be fooled by the limited offer. > 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. > > I consider this pair of statements combined with the IPR statement quite > satisfactory. You of course are free to feel differently. The Certicom statements are satisfactory only in the sense that Certicom has met the minimum requirements for disclosure. Once the disclosure content is analyzed for their terms, I find the terms offered unacceptable and recommend against approving the document. But I think the process is not satisfactory because the Working Group didn't discuss non-patented alternatives to extractor as mandated by RFC 3979. If the WG did discuss non-patented alternatives, I missed that discussion, and I would appreciate a pointer to the record. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From simon@josefsson.org Wed Jul 22 12:32: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 5AF683A681D; Wed, 22 Jul 2009 12:32:39 -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 jp0b+EoyambG; Wed, 22 Jul 2009 12:32:38 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 30C9B3A68C5; Wed, 22 Jul 2009 12:32:37 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6MJVi06024434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2009 21:31:45 +0200 From: Simon Josefsson To: ietf@ietf.org, tls@ietf.org References: <20090720164816.328D928C1C8@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090722:tls@ietf.org::9jU5XNU3M+XWxaAv:98V X-Hashcash: 1:22:090722:ietf-announce@ietf.org::eKS59J+bF8RI9P/T:iEd X-Hashcash: 1:22:090722:ietf@ietf.org::5PAh5zhrryUaq9qQ:DVmY Date: Wed, 22 Jul 2009 21:31:44 +0200 In-Reply-To: <20090720164816.328D928C1C8@core3.amsl.com> (The IESG's message of "Mon, 20 Jul 2009 09:48:16 -0700 (PDT)") Message-ID: <87y6qg8qfz.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 19:32:39 -0000 With the caveat that I have recently returned from vacation, and consequently may have missed some clarifications or paged out some context: If the #1154 IPR disclosure is the final word from Certicom on this document, I don't support advancing this document on the standards track. My concern remains that Certicom claims they have IPR that covers the document -- that is what the #1154 disclosure says (section IV). The additional information provided in the PDF is not helping: it grants a license for use together with ECC. It doesn't say anything about the use without ECC. The way I see it, TLS implementers and the broader Internet does not gain something significant by having this document published. Other IETF documents can use the TLS PRF to derive keying material. On the contrary, it seems both TLS implementers and the broader Internet community would be hurt by publishing the document since having patent threats looming over widely used techniques has stability and interoperability impacts. I recall that Certicom was positive about clarifying their intentions so maybe we can continue that discussion and get something more useful than the recent disclosure. Speaking as TLS implementer of the document and document [1] author that reference this document, /Simon [1] http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 The IESG writes: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0 From jsalowey@cisco.com Wed Jul 22 14:00: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 CBE4728C129; Wed, 22 Jul 2009 14:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 VYySb6UR8bBm; Wed, 22 Jul 2009 14:00:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 47EC83A67AA; Wed, 22 Jul 2009 14:00:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIMZZ0qrR7PD/2dsb2JhbAC5RYglkQ8FhA4 X-IronPort-AV: E=Sophos;i="4.43,248,1246838400"; d="scan'208";a="188729747" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2009 20:57:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6MKvDtG015474; Wed, 22 Jul 2009 13:57:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6MKvD7K022556; Wed, 22 Jul 2009 20:57:13 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:57:13 -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: Wed, 22 Jul 2009 13:57:12 -0700 Message-ID: In-Reply-To: <87y6qg8qfz.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AcoLAzV7AEiNLHV6QqyVS4HXGmh/lgACgBLw References: <20090720164816.328D928C1C8@core3.amsl.com> <87y6qg8qfz.fsf@mocca.josefsson.org> From: "Joseph Salowey (jsalowey)" To: "Simon Josefsson" , , X-OriginalArrivalTime: 22 Jul 2009 20:57:13.0232 (UTC) FILETIME=[FCCE8100:01CA0B0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3395; t=1248296233; x=1249160233; c=relaxed/simple; s=sjdkim3002; 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=20Last=20Call=3A=20draft-ietf-tls-extract or=20(Keying=20Material=20Exportersfor=20Transport=20Layer=2 0Security=20(TLS))=20to=20Proposed=20Standard |Sender:=20; bh=DUz2JkXhSCMUa2Z1YKyou8s5Bl8YdWCcqE+TNt1yrf0=; b=YeXhfTFzy8k+kjFBZtuf6I7+rvlIm56GTum2QfV2WkvTTeUVxTOVjTGLHk h2RTojA0RLac1Mzesu4qo8LGFVDPiI/QPn4zZX+NhVCE7jU8GKcYeIPQ8wTA G5m66JX+Ji; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 21:00:54 -0000 While I see that draft-ietf-tls-extractor is listed in section IV of #1154 IPR disclosure as related material, I see that it is explicitly not listed in section V part C which lists what is specifically covered by the disclosure. I don't think Certicom is claiming IPR on draft-ietf-tls-extractor because it is not among the list of documents in section V. =20 Joe > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Simon Josefsson > Sent: Wednesday, July 22, 2009 12:32 PM > To: ietf@ietf.org; tls@ietf.org > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying=20 > Material Exportersfor Transport Layer Security (TLS)) to=20 > Proposed Standard >=20 > With the caveat that I have recently returned from vacation,=20 > and consequently may have missed some clarifications or paged out some > context: >=20 > If the #1154 IPR disclosure is the final word from Certicom=20 > on this document, I don't support advancing this document on=20 > the standards track. My concern remains that Certicom claims=20 > they have IPR that covers the document -- that is what the=20 > #1154 disclosure says (section IV). The additional=20 > information provided in the PDF is not helping: it grants a=20 > license for use together with ECC. It doesn't say anything=20 > about the use without ECC. >=20 > The way I see it, TLS implementers and the broader Internet=20 > does not gain something significant by having this document=20 > published. Other IETF documents can use the TLS PRF to=20 > derive keying material. On the contrary, it seems both TLS=20 > implementers and the broader Internet community would be hurt=20 > by publishing the document since having patent threats=20 > looming over widely used techniques has stability and=20 > interoperability impacts. >=20 > I recall that Certicom was positive about clarifying their=20 > intentions so maybe we can continue that discussion and get=20 > something more useful than the recent disclosure. >=20 > Speaking as TLS implementer of the document and document [1]=20 > author that reference this document, /Simon >=20 > [1]=20 > http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 >=20 > The IESG writes: >=20 > > The IESG has received a request from the Transport Layer Security WG > > (tls) to consider the following document: > > > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive comments to=20 > > the ietf@ietf.org mailing lists by 2009-08-10.=20 > Exceptionally, comments=20 > > may be sent to iesg@ietf.org instead. In either case, please retain=20 > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > > > > IESG discussion can be tracked via > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > g=3D16821&rfc_flag=3D0 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From simon@josefsson.org Wed Jul 22 14:29:29 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 320FF3A69DD; Wed, 22 Jul 2009 14:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 GEPpZrggTaZn; Wed, 22 Jul 2009 14:29:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 3528828C0E3; Wed, 22 Jul 2009 14:29:05 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6MLQga2027398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2009 23:26:44 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: <20090720164816.328D928C1C8@core3.amsl.com> <87y6qg8qfz.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090722:tls@ietf.org::B1LP/KUmJQ16FK0t:0/b4 X-Hashcash: 1:22:090722:jsalowey@cisco.com::AEjt5cigukHJVRse:28UY X-Hashcash: 1:22:090722:ietf@ietf.org::+bfNkPVLUGzBfz/8:Y2RT Date: Wed, 22 Jul 2009 23:26:41 +0200 In-Reply-To: (Joseph Salowey's message of "Wed, 22 Jul 2009 13:57:12 -0700") Message-ID: <87ab2wwgry.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 21:29:29 -0000 Let's go back to RFC 3979: 6.4. What Must be in a 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. The "draft-ietf-tls-extractor-06" name is mentioned in the disclosure. For what it's worth, the PDF referenced in the disclosure also mentions draft-ietf-tls-extractor-06. Together, I can't read this in any other way that Certicom believes they have some patents covering draft-ietf-tls-extractor-06 and have followed the RFC 3979 rules and informed the IETF about this. If Certicom didn't intend to claim they believe they own patents that they believe covers draft-ietf-tls-extractor-06 they need to supersede the disclosure with one that does not mention that document. The reason for this situation may be the poor terminology used by the IETF IPR web pages. I understand and appreciate that Certicom has tried to clarify the situation, but to me the updated form does not improve the situation. Perhaps Certicom would be able to more easily create a disclosure that matches RFC 3979 rules if the web pages were improved. /Simon "Joseph Salowey (jsalowey)" writes: > While I see that draft-ietf-tls-extractor is listed in section IV of > #1154 IPR disclosure as related material, I see that it is explicitly > not listed in section V part C which lists what is specifically covered > by the disclosure. I don't think Certicom is claiming IPR on > draft-ietf-tls-extractor because it is not among the list of documents > in section V. > > Joe > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >> Behalf Of Simon Josefsson >> Sent: Wednesday, July 22, 2009 12:32 PM >> To: ietf@ietf.org; tls@ietf.org >> Subject: Re: Last Call: draft-ietf-tls-extractor (Keying >> Material Exportersfor Transport Layer Security (TLS)) to >> Proposed Standard >> >> With the caveat that I have recently returned from vacation, >> and consequently may have missed some clarifications or paged out some >> context: >> >> If the #1154 IPR disclosure is the final word from Certicom >> on this document, I don't support advancing this document on >> the standards track. My concern remains that Certicom claims >> they have IPR that covers the document -- that is what the >> #1154 disclosure says (section IV). The additional >> information provided in the PDF is not helping: it grants a >> license for use together with ECC. It doesn't say anything >> about the use without ECC. >> >> The way I see it, TLS implementers and the broader Internet >> does not gain something significant by having this document >> published. Other IETF documents can use the TLS PRF to >> derive keying material. On the contrary, it seems both TLS >> implementers and the broader Internet community would be hurt >> by publishing the document since having patent threats >> looming over widely used techniques has stability and >> interoperability impacts. >> >> I recall that Certicom was positive about clarifying their >> intentions so maybe we can continue that discussion and get >> something more useful than the recent disclosure. >> >> Speaking as TLS implementer of the document and document [1] >> author that reference this document, /Simon >> >> [1] >> http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 >> >> The IESG writes: >> >> > The IESG has received a request from the Transport Layer Security WG >> > (tls) to consider the following document: >> > >> > - 'Keying Material Exporters for Transport Layer Security (TLS) ' >> > as a Proposed Standard >> > >> > The IESG plans to make a decision in the next few weeks, >> and solicits >> > final comments on this action. Please send substantive comments to >> > the ietf@ietf.org mailing lists by 2009-08-10. >> Exceptionally, comments >> > may be sent to iesg@ietf.org instead. In either case, please retain >> > the beginning of the Subject line to allow automated sorting. >> > >> > The file can be obtained via >> > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt >> > >> > >> > IESG discussion can be tracked via >> > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa >> > g=16821&rfc_flag=0 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> From dean@av8.com Wed Jul 22 15:16:17 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 04E6A3A6B12; Wed, 22 Jul 2009 15:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 YTwy-BAPA+7F; Wed, 22 Jul 2009 15:16:15 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 6BBC73A68A5; Wed, 22 Jul 2009 15:16:15 -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 n6MLvTKR013141 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jul 2009 17:57:29 -0400 Date: Wed, 22 Jul 2009 17:57:29 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Joseph Salowey (jsalowey)" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson , ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 22:16:17 -0000 If your interpretation were correct, then we would have to say that Certicom is not claiming IPR on _any_ IETF document---draft or RFC---since none are listed in Section V. But I think that is obviously incorrect---I think you have misinterpreted what should be in which section. Section titles and descriptions: Section IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates: Section V. Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by Section 6 of RFC 3979) Section IV lists the drafts and RFCs. Section V lists the patents. One would not expect to find a draft or RFC listed in Section V, nor a patent listed in Section IV. Extractor and other documents are listed in section IV. --Dean On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote: > While I see that draft-ietf-tls-extractor is listed in section IV of > #1154 IPR disclosure as related material, I see that it is explicitly > not listed in section V part C which lists what is specifically covered > by the disclosure. I don't think Certicom is claiming IPR on > draft-ietf-tls-extractor because it is not among the list of documents > in section V. > > Joe > > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > > Behalf Of Simon Josefsson > > Sent: Wednesday, July 22, 2009 12:32 PM > > To: ietf@ietf.org; tls@ietf.org > > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying > > Material Exportersfor Transport Layer Security (TLS)) to > > Proposed Standard > > > > With the caveat that I have recently returned from vacation, > > and consequently may have missed some clarifications or paged out some > > context: > > > > If the #1154 IPR disclosure is the final word from Certicom > > on this document, I don't support advancing this document on > > the standards track. My concern remains that Certicom claims > > they have IPR that covers the document -- that is what the > > #1154 disclosure says (section IV). The additional > > information provided in the PDF is not helping: it grants a > > license for use together with ECC. It doesn't say anything > > about the use without ECC. > > > > The way I see it, TLS implementers and the broader Internet > > does not gain something significant by having this document > > published. Other IETF documents can use the TLS PRF to > > derive keying material. On the contrary, it seems both TLS > > implementers and the broader Internet community would be hurt > > by publishing the document since having patent threats > > looming over widely used techniques has stability and > > interoperability impacts. > > > > I recall that Certicom was positive about clarifying their > > intentions so maybe we can continue that discussion and get > > something more useful than the recent disclosure. > > > > Speaking as TLS implementer of the document and document [1] > > author that reference this document, /Simon > > > > [1] > > http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 > > > > The IESG writes: > > > > > The IESG has received a request from the Transport Layer Security WG > > > (tls) to consider the following document: > > > > > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > > > as a Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive comments to > > > the ietf@ietf.org mailing lists by 2009-08-10. > > Exceptionally, comments > > > may be sent to iesg@ietf.org instead. In either case, please retain > > > the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa > > > g=16821&rfc_flag=0 > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > 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 rms@gnu.org Wed Jul 22 15:22: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 47B6A28C15A; Wed, 22 Jul 2009 15:22:16 -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 K3j+AegoRGkk; Wed, 22 Jul 2009 15:22:15 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 41A5D28C132; Wed, 22 Jul 2009 15:22:15 -0700 (PDT) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MTkBi-0007Gi-5e; Wed, 22 Jul 2009 18:21:26 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Nicolas Williams In-reply-to: <20090721195028.GQ1020@Sun.COM> (message from Nicolas Williams on Tue, 21 Jul 2009 14:50:28 -0500) References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> Message-Id: Date: Wed, 22 Jul 2009 18:21:26 -0400 Cc: tls@ietf.org, ietf-honest@lists.iadl.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:22:16 -0000 The IPR applies to Since we're talking about patents, calling them "IPR" just introduces gratuitous vagueness. Patent law and copyright law have very little in common, so lumping them together is basically a mistake. And there are a dozen other areas of laws which you're generalizing about each time you say "IPR". See http://www.gnu.org/philosophy/not-ipr.html for more explaation of why the term "intellectual property" is harmful. If you call them "patents", it takes 4 more characters and avoids the confusion. So the real question is this: Suppose you have an implementation of TLS that has a license to Certicom's ECC patents, and suppose that you have an application that uses draft-ietf-tls-extractor, and the application does not have its own license to Certicom's ECC patents -- is the application then infringing Certicom's patents? (An analogous question about copyrights would not be meaningful or interesting, because copyright does totally different things.) I don't know the answer to that question, but I can follow you in considering the consequences of a possible yes answer. However if the answer is yes, then the TLS implementation must not export the TLS extractor to applications when doing so would cause the applications to infringe. There is no technical way that the TLS implementation can tell whether the application has a patent license. That could be changed from the day to the next, by the actions of lawyers and businessmen, without any change in the code of the application. So the question that would follow is, what good is a standard which people are free to implement in a library, but cannot actually use without asking permission? From jsalowey@cisco.com Wed Jul 22 15:39:37 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 3D8493A6AB0; Wed, 22 Jul 2009 15:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 G1OLR+qWnOgV; Wed, 22 Jul 2009 15:39:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6C4D33A68A5; Wed, 22 Jul 2009 15:38:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANIvZ0qrR7PD/2dsb2JhbAC5IoglNAmQRwWCTYFBgUQ X-IronPort-AV: E=Sophos;i="4.43,248,1246838400"; d="scan'208";a="188766945" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2009 22:31:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6MMV2FN020244; Wed, 22 Jul 2009 15:31:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6MMV2Pv019987; Wed, 22 Jul 2009 22:31:02 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.3959); Wed, 22 Jul 2009 15:31:02 -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: Wed, 22 Jul 2009 15:31:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AcoLF422lXo1BnRWRsC/KsmTF1T41gAAYnyA References: From: "Joseph Salowey (jsalowey)" To: "Dean Anderson" X-OriginalArrivalTime: 22 Jul 2009 22:31:02.0551 (UTC) FILETIME=[18246A70:01CA0B1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5938; t=1248301862; x=1249165862; c=relaxed/simple; s=sjdkim3002; 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]=20Last=20Call=3A=20draft-ietf-tls -extractor=20(Keying=20Material=20Exportersfor=20Transport=2 0Layer=20Security=20(TLS))=20to=20Proposed=20Standard |Sender:=20; bh=owtRFOrU30l7NRlCpt41DxDFoSMGXZ86TAiERWhFODg=; b=m8E1lBHw0eDU5uBfvzBJ4SG+WoG5COI/56bH26Rl3AQ+q/eT6zOC3JSmLk 31SLkA8Kl6Zqxr7s68LgVa/weWeIgSfffjkKZTuq2hxuS8gplgW+sPEAjm4r h7lZJ2kUnu; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Simon Josefsson , ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 22:39:37 -0000 I agree with Simon that the IETF's disclosure page could use some work, it seems rather confusing and it is not consistently filled out. Comments inline below: =20 > If your interpretation were correct, then we would have to=20 > say that Certicom is not claiming IPR on _any_ IETF=20 > document---draft or RFC---since none are listed in Section V.=20 > But I think that is obviously incorrect---I think you have=20 > misinterpreted what should be in which section. > [Joe] Are we both looking at https://datatracker.ietf.org/ipr/1154/? In section V I see several documents listed: "RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11" > Section titles and descriptions:=20 >=20 > Section IV. IETF Document or Other Contribution to Which=20 > this IPR Disclosure Relates:=20 >=20 > Section V. Disclosure of Patent Information (i.e., patents=20 > or patent applications required to be disclosed by Section 6=20 > of RFC 3979) >=20 > Section IV lists the drafts and RFCs. Section V lists the patents. =20 > One would not expect to find a draft or RFC listed in Section=20 > V, nor a patent listed in Section IV. >=20 > Extractor and other documents are listed in section IV.=20 >=20 [Joe] Section V also has a sub-section C, which allows you to specify what parts of IETF documents are covered by the patent information disclosed in section V. This section lists several documents which is a subset of what is mentioned in section IV. This seems straight forward to me. =20 Joe > --Dean >=20 > On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote: >=20 > > While I see that draft-ietf-tls-extractor is listed in section IV of > > #1154 IPR disclosure as related material, I see that it is=20 > explicitly=20 > > not listed in section V part C which lists what is specifically=20 > > covered by the disclosure. I don't think Certicom is=20 > claiming IPR on=20 > > draft-ietf-tls-extractor because it is not among the list=20 > of documents > > in section V. =20 > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: ietf-bounces@ietf.org=20 > [mailto:ietf-bounces@ietf.org] On Behalf=20 > > > Of Simon Josefsson > > > Sent: Wednesday, July 22, 2009 12:32 PM > > > To: ietf@ietf.org; tls@ietf.org > > > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying Material=20 > > > Exportersfor Transport Layer Security (TLS)) to Proposed Standard > > >=20 > > > With the caveat that I have recently returned from vacation, and=20 > > > consequently may have missed some clarifications or paged out some > > > context: > > >=20 > > > If the #1154 IPR disclosure is the final word from=20 > Certicom on this=20 > > > document, I don't support advancing this document on the=20 > standards=20 > > > track. My concern remains that Certicom claims they have=20 > IPR that=20 > > > covers the document -- that is what the > > > #1154 disclosure says (section IV). The additional information=20 > > > provided in the PDF is not helping: it grants a license for use=20 > > > together with ECC. It doesn't say anything about the use without=20 > > > ECC. > > >=20 > > > The way I see it, TLS implementers and the broader=20 > Internet does not=20 > > > gain something significant by having this document=20 > published. Other=20 > > > IETF documents can use the TLS PRF to derive keying material. On=20 > > > the contrary, it seems both TLS implementers and the broader=20 > > > Internet community would be hurt by publishing the document since=20 > > > having patent threats looming over widely used techniques has=20 > > > stability and interoperability impacts. > > >=20 > > > I recall that Certicom was positive about clarifying their=20 > > > intentions so maybe we can continue that discussion and get=20 > > > something more useful than the recent disclosure. > > >=20 > > > Speaking as TLS implementer of the document and document=20 > [1] author=20 > > > that reference this document, /Simon > > >=20 > > > [1] > > >=20 > http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 > > >=20 > > > The IESG writes: > > >=20 > > > > The IESG has received a request from the Transport=20 > Layer Security=20 > > > > WG > > > > (tls) to consider the following document: > > > > > > > > - 'Keying Material Exporters for Transport Layer=20 > Security (TLS) ' > > > > as a Proposed Standard > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > and solicits > > > > final comments on this action. Please send substantive=20 > comments=20 > > > > to the ietf@ietf.org mailing lists by 2009-08-10. > > > Exceptionally, comments > > > > may be sent to iesg@ietf.org instead. In either case, please=20 > > > > retain the beginning of the Subject line to allow=20 > automated sorting. > > > > > > > > The file can be obtained via > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.tx > > > > t > > > > > > > > > > > > IESG discussion can be tracked via > > > >=20 > > >=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&d > > > Ta > > > > g=3D16821&rfc_flag=3D0 > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf > > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > >=20 > >=20 >=20 > --=20 > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 =20 >=20 >=20 >=20 >=20 From Nicolas.Williams@sun.com Wed Jul 22 16:03:56 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 E7FFF3A689F; Wed, 22 Jul 2009 16:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=0.763, 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 1IeQY7ueoOxg; Wed, 22 Jul 2009 16:03:56 -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 156213A6900; Wed, 22 Jul 2009 16:03:44 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6MN1onu022268; Wed, 22 Jul 2009 23:01:50 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 n6MN1l2o007907; Wed, 22 Jul 2009 17:01:47 -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 n6MMaQOH003288; Wed, 22 Jul 2009 17:36:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6MMaNqX003287; Wed, 22 Jul 2009 17:36:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 22 Jul 2009 17:36:23 -0500 From: Nicolas Williams To: Richard Stallman Message-ID: <20090722223622.GP1020@Sun.COM> References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@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: tls@ietf.org, ietf-honest@lists.iadl.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 23:03:57 -0000 On Wed, Jul 22, 2009 at 06:21:26PM -0400, Richard Stallman wrote: > I don't know the answer to that question, but I can follow you in > considering the consequences of a possible yes answer. > > However if the answer is yes, then the TLS implementation must not > export the TLS extractor to applications when doing so would cause the > applications to infringe. > > There is no technical way that the TLS implementation can tell whether > the application has a patent license. That could be changed from the > day to the next, by the actions of lawyers and businessmen, without > any change in the code of the application. > > So the question that would follow is, what good is a standard which > people are free to implement in a library, but cannot actually use > without asking permission? I agree. The question is: must each participant go pay a lawyer to answer that question? But suppose that we simply say that the very fact that this question is raised is enough to drop the standardization effort (e.g., because not every participant, in a volunteer organization like the IETF, can pay for a lawyer every time something like this comes up), are we not then making it trivial to DoS the standards process? The operative word here is uncertainty. A patent-holder creates uncertainty. How should an SDO respond? I'm not sure. I'm only sure that I don't like getting DoSed, either into dropping a standard or into not implementing it for fear of infringing. In this case Mr. Campana sent a clarification with a specific claim, but not disclaiming other potential claims. To me that's sufficient to proceed. But IANAL, and I don't represent my employer (as is the norm at the IETF). Nico -- From dean@av8.com Wed Jul 22 16:51:31 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 DDD653A6C7E; Wed, 22 Jul 2009 16:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, 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 nVNw3TRbyyaq; Wed, 22 Jul 2009 16:51:30 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id B50073A6C5F; Wed, 22 Jul 2009 16:51:30 -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 n6MNpMct013535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jul 2009 19:51:22 -0400 Date: Wed, 22 Jul 2009 19:51:21 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Joseph Salowey (jsalowey)" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson , ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 22 Jul 2009 23:51:32 -0000 On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote: > Comments inline below: > > > If your interpretation were correct, then we would have to > > say that Certicom is not claiming IPR on _any_ IETF > > document---draft or RFC---since none are listed in Section V. > > But I think that is obviously incorrect---I think you have > > misinterpreted what should be in which section. > > > > [Joe] Are we both looking at https://datatracker.ietf.org/ipr/1154/? In > section V I see several documents listed: > > "RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, > RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, > draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07, > draft-ietf-smime-sha2-11" You are refering to Section V.C: ==================== C. If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered: RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 ==================== Section V.C of IPR 1154 is probably not filled out correctly since it just states the document name. As you can see from the instructions, the purpose of Section V.C is to clarify which /sections/ of documents are covered, and no sections of documents are identified. Section V.C is only needed if there are sections of a document that need identification because it is not reasonably apparent which sections are covered by patent. By not putting a document in Section V.C, all that is indicated is that it is 'reasonably apparent' which sections are covered by patent. Excluding a document (tls-extractor) from Section V.C doesn't mean that it isn't covered by a patent, it only means that it should be reasonably apparent which sections of the document are covered. The fact of patent coverage is indicated by the presence of the document in Section IV. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jwkckid1@ix.netcom.com Wed Jul 22 18:23:58 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 509C53A6A0A; Wed, 22 Jul 2009 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI5eHOa6yrZo; Wed, 22 Jul 2009 18:23:57 -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 66B4B3A6CA7; Wed, 22 Jul 2009 18:23:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=I2+EvJH17JEWUwyoINckW20mA4+Wi0Wy+HzdlapoRX2NT1lou6McNgxhdDwDXVqI; 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.97.215] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTn0Z-0001lk-2l; Wed, 22 Jul 2009 21:22:08 -0400 Message-ID: <4A67D745.A4AAAD2E@ix.netcom.com> Date: Wed, 22 Jul 2009 20:21:41 -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: Dean Anderson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688a0c1511a7cf4a6c5fb64901630a8cb43350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.215 Cc: Simon Josefsson , ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExportersfor Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 01:23:58 -0000 Dean and all, I believe that you are correct here Dean. Further it seems to me that Certicom is in a round about way attempting to claim a near manopoly on Extractor technology. If so, I have no doubt that they will face serious challanges to such a claim. Dean Anderson wrote: > If your interpretation were correct, then we would have to say that > Certicom is not claiming IPR on _any_ IETF document---draft or > RFC---since none are listed in Section V. But I think that is obviously > incorrect---I think you have misinterpreted what should be in which > section. > > Section titles and descriptions: > > Section IV. IETF Document or Other Contribution to Which this IPR > Disclosure Relates: > > Section V. Disclosure of Patent Information (i.e., patents or patent > applications required to be disclosed by Section 6 of RFC 3979) > > Section IV lists the drafts and RFCs. Section V lists the patents. > One would not expect to find a draft or RFC listed in Section V, nor a > patent listed in Section IV. > > Extractor and other documents are listed in section IV. > > --Dean > > On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote: > > > While I see that draft-ietf-tls-extractor is listed in section IV of > > #1154 IPR disclosure as related material, I see that it is explicitly > > not listed in section V part C which lists what is specifically covered > > by the disclosure. I don't think Certicom is claiming IPR on > > draft-ietf-tls-extractor because it is not among the list of documents > > in section V. > > > > Joe > > > > > -----Original Message----- > > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > > > Behalf Of Simon Josefsson > > > Sent: Wednesday, July 22, 2009 12:32 PM > > > To: ietf@ietf.org; tls@ietf.org > > > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying > > > Material Exportersfor Transport Layer Security (TLS)) to > > > Proposed Standard > > > > > > With the caveat that I have recently returned from vacation, > > > and consequently may have missed some clarifications or paged out some > > > context: > > > > > > If the #1154 IPR disclosure is the final word from Certicom > > > on this document, I don't support advancing this document on > > > the standards track. My concern remains that Certicom claims > > > they have IPR that covers the document -- that is what the > > > #1154 disclosure says (section IV). The additional > > > information provided in the PDF is not helping: it grants a > > > license for use together with ECC. It doesn't say anything > > > about the use without ECC. > > > > > > The way I see it, TLS implementers and the broader Internet > > > does not gain something significant by having this document > > > published. Other IETF documents can use the TLS PRF to > > > derive keying material. On the contrary, it seems both TLS > > > implementers and the broader Internet community would be hurt > > > by publishing the document since having patent threats > > > looming over widely used techniques has stability and > > > interoperability impacts. > > > > > > I recall that Certicom was positive about clarifying their > > > intentions so maybe we can continue that discussion and get > > > something more useful than the recent disclosure. > > > > > > Speaking as TLS implementer of the document and document [1] > > > author that reference this document, /Simon > > > > > > [1] > > > http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 > > > > > > The IESG writes: > > > > > > > The IESG has received a request from the Transport Layer Security WG > > > > (tls) to consider the following document: > > > > > > > > - 'Keying Material Exporters for Transport Layer Security (TLS) ' > > > > as a Proposed Standard > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > and solicits > > > > final comments on this action. Please send substantive comments to > > > > the ietf@ietf.org mailing lists by 2009-08-10. > > > Exceptionally, comments > > > > may be sent to iesg@ietf.org instead. In either case, please retain > > > > the beginning of the Subject line to allow automated sorting. > > > > > > > > The file can be obtained via > > > > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt > > > > > > > > > > > > IESG discussion can be tracked via > > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa > > > > g=16821&rfc_flag=0 > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 mcampagna@certicom.com Wed Jul 22 18:50: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 5681F3A6CB0; Wed, 22 Jul 2009 18:50:30 -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 jKZueqvycaAP; Wed, 22 Jul 2009 18:50:29 -0700 (PDT) Received: from cx297.800onemail.com (CX297.800onemail.com [209.20.1.115]) by core3.amsl.com (Postfix) with ESMTP id 0FC463A6CA5; Wed, 22 Jul 2009 18:50:28 -0700 (PDT) Received: from EX13-N05.exchserver.com ([10.7.5.66]) by cx297.800onemail.com (8.13.8/8.13.8) with ESMTP id n6N1iXGj028151; Wed, 22 Jul 2009 21:44:33 -0400 Received: from EX41.exchserver.com ([169.254.1.62]) by EX13-N05.exchserver.com ([10.7.40.160]) with mapi; Wed, 22 Jul 2009 21:49:35 -0400 From: Matthew Campagna To: "tls@ietf.org" Date: Wed, 22 Jul 2009 21:49:42 -0400 Thread-Topic: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AcoLIcTPJKSKahw5Q02tlpzKvd7yvQAET6oA Message-ID: <623ACC30D56D0B4DB72868C664C23704E68ADBC7E7@EX41.exchserver.com> References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> In-Reply-To: <20090722223622.GP1020@Sun.COM> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="iso-2022-jp" 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: "ietf-honest@lists.iadl.org" , "ietf@ietf.org" Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 01:50:30 -0000 In Hopes of Clarifying, Since I filled out the form in question I would hope that you consider t= hese comments with a little more weight than others' wild speculations abou= t the intention of IPR #1154. I do not read that IPR #1154 claims to have patents that cover the draft= -ietf-tls-extractor, and perhaps more importantly, nor was it my intention = to indicate any such claims. I do recognize that it is listed in the section IV. IETF Document or Other Contribution to Which this IPR Disclosure Rel= ates: I believe this to be correct as the free license being offered extends a = license to use the following suites, to which we are making some claims, A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Se= curity(TLS)" RFC 4492, May 2006; or, B. =1B$B!H=1B(BTLS Elliptic Curve Cipher Suites with SHA=1B$B!>=1B(B256/38= 4 and AES Galois Counter Mode,=1B$B!I=1B(B RFC 5289, or C. =1B$B!H=1B(BSuite B Cipher Suites for TLS,=1B$B!I=1B(B draft=1B$B!>=1B(= Brescorla=1B$B!>=1B(Btls=1B$B!>=1B(Bsuiteb=1B$B!>=1B(B 07.txt; if one wants to use them in the draft-ietf-tls-extractor, under the condi= tions in a linked document. Hence, I believe that the license is extending= intellectual property rights that 'relates' to draft-ietf-tls-extractor. = I do not equate 'relates' to claiming rights over. I do read that IPR #1154 claims to have patents that cover parts of docum= ents listed in, V Disclosure of Patent Information (i.e., patents or patent application= s required to be disclosed by Section 6 of RFC 3979) C If an Internet-Draft or RFC includes multiple parts and it is not re= asonably apparent which part of such Internet-Draft or RFC is alleged to be= covered by the patent information disclosed in Section V(A) or V(B), it is= helpful if the discloser identifies here the sections of the Internet-Draf= t or RFC that are alleged to be so covered: Where it lists: RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC= 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-s= ecsh-suiteb-00, draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 Note that draft-ietf-tls-extractor is not listed in the I-D or RFCs part = of which the listed patents claim to cover. Therefore a reasonable person should be able to conclude that the statement= is not making a claim that patents listed cover parts of the draft-ietf-tl= s-extractor.=20 As stated prior, I think the form being used creates the confusion at han= d. There is no clear definition of what should be in section IV versus sec= tion V. C. Should more exact language be added to the form, I would be hap= py to update the IPR statement to help remove some stated uncertainties. Further the RFC 3979 indicates the following: 6.3. How Must a Disclosure be Made? IPR disclosures are made by following the instructions at http://www.ietf.org/ipr-instructions.=20 A link I think most will find particularly amusing. Regards, Matt Matthew Campagna | Director, Certicom Research Certicom Corp. | A Subsidiary of Research In Motion Limited mcampagna@certicom.com =20 direct 203.894.9777 = =20 mobile 203.240.1269 www.certicom.com From jwkckid1@ix.netcom.com Wed Jul 22 21:55: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 0984E3A6961; Wed, 22 Jul 2009 21:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 MHpzMNNLRFwH; Wed, 22 Jul 2009 21:55:15 -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 DE1933A68F4; Wed, 22 Jul 2009 21:55:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=bRdngdaXtOiR5mlFyO+8CP2vpitrzgm8PRkBgIewMmCrLx7HQNiEXkS6H0PP1m+N; 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.98.230] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTpsg-0001Xd-8L; Thu, 23 Jul 2009 00:26:11 -0400 Message-ID: <4A680267.2CC453F0@ix.netcom.com> Date: Wed, 22 Jul 2009 23:25:44 -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: Matthew Campagna References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> <623ACC30D56D0B4DB72868C664C23704E68ADBC7E7@EX41.exchserver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688df87215ea577bcde6447a19a949a9e8b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.230 Cc: "ietf-honest@lists.iadl.org" , "tls@ietf.org" , "ietf@ietf.org" Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (KeyingMaterial Exporters for Transport Layer Security (TLS)) toProposed Standard 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, 23 Jul 2009 04:55:16 -0000 Matthew and all, I don't and haven't assumed that Certicom has any "Protections" with respect to any form or type of "TLS extractor". But I for one am glad that you have taken the time to clarify such as true. I also have serious doubts that Certicom has any Patent claim to ECC other than perhaps your own specific product that may/does use ECC. Could please clarify that please? Matthew Campagna wrote: > In Hopes of Clarifying, > > Since I filled out the form in question I would hope that you consider these comments with a little more weight than others' wild speculations about the intention of IPR #1154. > > I do not read that IPR #1154 claims to have patents that cover the draft-ietf-tls-extractor, and perhaps more importantly, nor was it my intention to indicate any such claims. > > I do recognize that it is listed in the section > > IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates: > > I believe this to be correct as the free license being offered extends a license to use the following suites, to which we are making some claims, > > A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security(TLS)" RFC 4492, May 2006; or, > B. $B!H(BTLS Elliptic Curve Cipher Suites with SHA$B!>(B256/384 and AES Galois Counter Mode,$B!I(B RFC 5289, or > C. $B!H(BSuite B Cipher Suites for TLS,$B!I(B draft$B!>(Brescorla$B!>(Btls$B!>(Bsuiteb$B!>(B 07.txt; > > if one wants to use them in the draft-ietf-tls-extractor, under the conditions in a linked document. Hence, I believe that the license is extending intellectual property rights that 'relates' to draft-ietf-tls-extractor. I do not equate 'relates' to claiming rights over. > > I do read that IPR #1154 claims to have patents that cover parts of documents listed in, > > V Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by Section 6 of RFC 3979) > > C If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered: > > Where it lists: > > RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07, > draft-ietf-smime-sha2-11 > > Note that draft-ietf-tls-extractor is not listed in the I-D or RFCs part of which the listed patents claim to cover. > > Therefore a reasonable person should be able to conclude that the statement is not making a claim that patents listed cover parts of the draft-ietf-tls-extractor. > > As stated prior, I think the form being used creates the confusion at hand. There is no clear definition of what should be in section IV versus section V. C. Should more exact language be added to the form, I would be happy to update the IPR statement to help remove some stated uncertainties. > > Further the RFC 3979 indicates the following: > > 6.3. How Must a Disclosure be Made? > > IPR disclosures are made by following the instructions at > http://www.ietf.org/ipr-instructions. > > A link I think most will find particularly amusing. > > Regards, > Matt > > Matthew Campagna | Director, Certicom Research > Certicom Corp. | A Subsidiary of Research In Motion Limited > > mcampagna@certicom.com > direct 203.894.9777 > mobile 203.240.1269 > www.certicom.com > > _______________________________________________ > 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 dean@av8.com Thu Jul 23 10:20:04 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 D807028C126; Thu, 23 Jul 2009 10:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aLaG9Kz22pP; Thu, 23 Jul 2009 10:20:03 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 7237228C0FF; Thu, 23 Jul 2009 10:20:03 -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 n6NGjXVH016469 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Jul 2009 12:45:36 -0400 Date: Thu, 23 Jul 2009 12:45:33 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Matthew Campagna In-Reply-To: <623ACC30D56D0B4DB72868C664C23704E68ADBC7E7@EX41.exchserver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Cc: "ietf-honest@lists.iadl.org" , "tls@ietf.org" , "ietf@ietf.org" Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 17:20:04 -0000 On Wed, 22 Jul 2009, Matthew Campagna wrote: > In Hopes of Clarifying, > > Since I filled out the form in question I would hope that you > consider these comments with a little more weight than others' wild > speculations about the intention of IPR #1154. > > I do not read that IPR #1154 claims to have patents that cover the > draft-ietf-tls-extractor, and perhaps more importantly, nor was it my > intention to indicate any such claims. The above is a good statement about your intent with regard to patent claims on draft-ietf-tls-extractor. > I do recognize that it is listed in the section > > IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates: > > I believe this to be correct as the free license being offered > extends a license to use the following suites, to which we are making > some claims, > > A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security(TLS)" RFC 4492, May 2006; or, > B. $B!H(BTLS Elliptic Curve Cipher Suites with SHA$B!>(B256/384 and AES Galois Counter Mode,$B!I(B RFC 5289, or > C. $B!H(BSuite B Cipher Suites for TLS,$B!I(B draft$B!>(Brescorla$B!>(Btls$B!>(Bsuiteb$B!>(B 07.txt; > > if one wants to use them in the draft-ietf-tls-extractor, under the > conditions in a linked document. Hence, I believe that the license is > extending intellectual property rights that 'relates' to > draft-ietf-tls-extractor. I do not equate 'relates' to claiming > rights over. I don't think this is what is meant by "relates". If lower protocol layers "related" to the above cipher suites, then IP (RFC791) and TCP (RFC793) also "relate" in the same way, and you did not list those drafts. > I do read that IPR #1154 claims to have patents that cover parts of > documents listed in, > > V Disclosure of Patent Information (i.e., patents or patent > applications required to be disclosed by Section 6 of RFC 3979) > > C If an Internet-Draft or RFC includes multiple parts and it is > not reasonably apparent which part of such Internet-Draft or RFC is > alleged to be covered by the patent information disclosed in Section > V(A) or V(B), it is helpful if the discloser identifies here the > sections of the Internet-Draft or RFC that are alleged to be so > covered: > > Where it lists: > > RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC > 5008, RFC 5289, draft-rescorla-tls-suiteb-12, > draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, > draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 > > Note that draft-ietf-tls-extractor is not listed in the I-D or RFCs > part of which the listed patents claim to cover. > > Therefore a reasonable person should be able to conclude that the > statement is not making a claim that patents listed cover parts of the > draft-ietf-tls-extractor. It is good to know that this is your interpretation; that you mean that there are patent claims only on RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 These documents (only these documents) should be listed in Section IV. If you read the instructions for Section V.C, it is plain that you are to identify "sections of the Internet-Draft or RFC that are alleged to be so covered:", and you don't identify any sections. If you have no patent claims on a draft, there should not be an IPR disclosure on that document, except perhaps to make clear (via the additional notes in Section V) that you have no patent claims on a document. > As stated prior, I think the form being used creates the confusion > at hand. There is no clear definition of what should be in section IV > versus section V. C. Should more exact language be added to the form, > I would be happy to update the IPR statement to help remove some > stated uncertainties. It appears that your interpretation of Section IV, V and Section V.C cannot be correct by reading the text for those sections. You apparently did not read the instructions carefully. If one isn't going to read the text there now, there is no point in adding more text. > Further the RFC 3979 indicates the following: > > 6.3. How Must a Disclosure be Made? > > IPR disclosures are made by following the instructions at > http://www.ietf.org/ipr-instructions. > > A link I think most will find particularly amusing. I didn't find the link amusing. I rather expected that you had found a dead link or something, but that isn't the case. The link you cite provides contact information and directs one to the disclosure template, which you filled out. On that template, Section V.C contains the same instructions as appear on the Disclosure. ====================== C. If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered: ====================== Your interpretation of Section V.C cannot be correct by reading the text for section V.C on the template. One wonders if you took the proper time and solemnity to prepare the Certicom disclosures. But I guess we have the information we need, now. Thanks. I hope you quickly update the IPR disclosure to comply with the instructions for each section and the actual facts Certicom is supposed to convey for those sections. Given the confusion so far, I think you will need to add a comment for each document previously incorrectly listed in Section IV for which there are no patent claims, clearly stating the fact of no patent encumbrance on those specific documents. Once that is done, and it is clear there are no patent encumbrances on the extractor draft, I will be happy to reconsider my objection to the extractor draft. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From mcampagna@certicom.com Thu Jul 23 10:56: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 9B6C43A67B3 for ; Thu, 23 Jul 2009 10:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnNgGEE2mIQt for ; Thu, 23 Jul 2009 10:56:25 -0700 (PDT) Received: from cx298.800onemail.com (CX298.800onemail.com [209.171.41.77]) by core3.amsl.com (Postfix) with ESMTP id B87F028C1D4 for ; Thu, 23 Jul 2009 10:56:22 -0700 (PDT) Received: from EX13-N04.exchserver.com ([10.7.5.66]) by cx298.800onemail.com (8.13.8/8.13.8) with ESMTP id n6NHnHRE029288; Thu, 23 Jul 2009 13:49:17 -0400 Received: from EX41.exchserver.com ([169.254.1.62]) by EX13-N04.exchserver.com ([10.7.40.180]) with mapi; Thu, 23 Jul 2009 13:54:36 -0400 From: Matthew Campagna To: "tglassey@earthlink.net" , "dean@av8.com" Date: Thu, 23 Jul 2009 13:54:36 -0400 Thread-Topic: [Ietf-honest] [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AcoLvDq0au85rMptQoSCtM2pe6AEqAAAmnvo Message-ID: <623ACC30D56D0B4DB72868C664C23704E68AC01A36@EX41.exchserver.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: mcampagna@certicom.com Cc: "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 17:56:26 -0000 VG9kZCwNCg0KIFRoZSBvZmZpY2lhbCBzdGF0ZW1lbnQgaXMgdGhlIGxpbmtlZCBkb2N1bWVudCwg d2UgdXBkYXRlIGl0IGZyb20gdGltZSB0byB0aW1lLiANCg0KUmVnYXJkcywNCiAgIE1hdHQNCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogVG9kZCBHbGFzc2V5IDx0Z2xhc3Nl eUBlYXJ0aGxpbmsubmV0Pg0KVG86IERlYW4gQW5kZXJzb24gPGRlYW5AYXY4LmNvbT4NCkNjOiBN YXR0aGV3IENhbXBhZ25hOyBpZXRmLWhvbmVzdEBsaXN0cy5pYWRsLm9yZyA8aWV0Zi1ob25lc3RA bGlzdHMuaWFkbC5vcmc+OyB0bHNAaWV0Zi5vcmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFRodSBK dWwgMjMgMTM6Mzc6MDcgMjAwOQpTdWJqZWN0OiBSZTogW0lldGYtaG9uZXN0XSBbVExTXSBMYXN0 IENhbGw6IGRyYWZ0LWlldGYtdGxzLWV4dHJhY3RvciAoS2V5aW5nIE1hdGVyaWFsIEV4cG9ydGVy cyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpKSB0bwlQcm9wb3NlZCBTdGFuZGFy ZA0KDQpEZWFuIEFuZGVyc29uIHdyb3RlOg0KPiBPbiBXZWQsIDIyIEp1bCAyMDA5LCBNYXR0aGV3 IENhbXBhZ25hIHdyb3RlOg0KPg0KPiAgIA0KPj4gSW4gSG9wZXMgb2YgQ2xhcmlmeWluZywNCj4+ DQo+PiAgICBTaW5jZSBJIGZpbGxlZCBvdXQgdGhlIGZvcm0gaW4gcXVlc3Rpb24gSSB3b3VsZCBo b3BlIHRoYXQgeW91DQo+PiBjb25zaWRlciB0aGVzZSBjb21tZW50cyB3aXRoIGEgbGl0dGxlIG1v cmUgd2VpZ2h0IHRoYW4gb3RoZXJzJyB3aWxkDQo+PiBzcGVjdWxhdGlvbnMgYWJvdXQgdGhlIGlu dGVudGlvbiBvZiBJUFIgIzExNTQuDQo+Pg0KPj4gICAgSSBkbyBub3QgcmVhZCB0aGF0IElQUiAj MTE1NCBjbGFpbXMgdG8gaGF2ZSBwYXRlbnRzIHRoYXQgY292ZXIgdGhlDQo+PiBkcmFmdC1pZXRm LXRscy1leHRyYWN0b3IsIGFuZCBwZXJoYXBzIG1vcmUgaW1wb3J0YW50bHksIG5vciB3YXMgaXQg bXkNCj4+IGludGVudGlvbiB0byBpbmRpY2F0ZSBhbnkgc3VjaCBjbGFpbXMuDQo+Pg0KPj4gICAg IA0KTWF0dGhldyAtDQpJIGRvbnQgd2FudCB0byBrbm93IHlvdXIgaW50ZW50aW9ucyB3ZXJlIHdo ZW4geW91IGZpbGVkIGl0IGJ1dCB3aGF0IEkgZG8gDQp3YW50IHRvIGtub3cgaXMgd2hhdCBDZXJ0 aWNvbSdzIGNvbW1pdG1lbnQncyBhcmUgYW5kIGluIHdyaXRpbmcgLSBhbmQgDQpoZXJlIGlzIHRo ZSBrZXkgdGhpbmcgLSBpdCBoYXMgdG8gZm9ybWFsbHkgY29tZSBmcm9tIHNvbWVvbmUgbGVnYWxs eSANCmVtcG93ZXJlZCBieSB0aGUgQ29ycG9yYXRpb24gdG8gZG8gc28uDQoNCk90aGVyd2lzZSAo bm8gb2ZmZW5zZSBtZWFudCkgd2hhdCB5b3UgcGVyc29uYWxseSB3YW50IGlzIGlycmVsZXZhbnQg DQp1bmxlc3MgeW91IGFyZSBzcGVjaWZpY2FsbHkgdGhlIGludmVudG9yIGFuZCBhcmUgcmVjbGFp bWluZyB0aGF0IElQLi4uDQo+DQo+IFRoZSBhYm92ZSBpcyBhIGdvb2Qgc3RhdGVtZW50IGFib3V0 IHlvdXIgaW50ZW50IHdpdGggcmVnYXJkIHRvIHBhdGVudCANCj4gY2xhaW1zIG9uIGRyYWZ0LWll dGYtdGxzLWV4dHJhY3Rvci4NCj4NCj4NCj4gICANCj4+ICAgIEkgZG8gcmVjb2duaXplIHRoYXQg aXQgaXMgbGlzdGVkIGluIHRoZSBzZWN0aW9uDQo+Pg0KPj4gICAgSVYuIElFVEYgRG9jdW1lbnQg b3IgT3RoZXIgQ29udHJpYnV0aW9uIHRvIFdoaWNoIHRoaXMgSVBSIERpc2Nsb3N1cmUgUmVsYXRl czoNCj4+DQo+PiAgIEkgYmVsaWV2ZSB0aGlzIHRvIGJlIGNvcnJlY3QgYXMgdGhlIGZyZWUgbGlj ZW5zZSBiZWluZyBvZmZlcmVkDQo+PiBleHRlbmRzIGEgbGljZW5zZSB0byB1c2UgdGhlIGZvbGxv d2luZyBzdWl0ZXMsIHRvIHdoaWNoIHdlIGFyZSBtYWtpbmcNCj4+IHNvbWUgY2xhaW1zLA0KPj4N Cj4+IAlBLiAiRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IChFQ0MpIENpcGhlciBTdWl0ZXMg Zm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eShUTFMpIiBSRkMgNDQ5MiwgTWF5IDIwMDY7IG9y LA0KPj4gCUIuIBskQiFIGyhCVExTIEVsbGlwdGljIEN1cnZlIENpcGhlciBTdWl0ZXMgd2l0aCBT SEEbJEIhPhsoQjI1Ni8zODQgYW5kIEFFUyBHYWxvaXMgQ291bnRlciBNb2RlLBskQiFJGyhCIFJG QyA1Mjg5LCBvcg0KPj4gCUMuIBskQiFIGyhCU3VpdGUgQiBDaXBoZXIgU3VpdGVzIGZvciBUTFMs GyRCIUkbKEIgZHJhZnQbJEIhPhsoQnJlc2NvcmxhGyRCIT4bKEJ0bHMbJEIhPhsoQnN1aXRlYhsk QiE+GyhCIDA3LnR4dDsNCj4+DQo+PiAgIGlmIG9uZSB3YW50cyB0byB1c2UgdGhlbSBpbiB0aGUg ZHJhZnQtaWV0Zi10bHMtZXh0cmFjdG9yLCB1bmRlciB0aGUNCj4+IGNvbmRpdGlvbnMgaW4gYSBs aW5rZWQgZG9jdW1lbnQuICBIZW5jZSwgSSBiZWxpZXZlIHRoYXQgdGhlIGxpY2Vuc2UgaXMNCj4+ IGV4dGVuZGluZyBpbnRlbGxlY3R1YWwgcHJvcGVydHkgcmlnaHRzIHRoYXQgJ3JlbGF0ZXMnIHRv DQo+PiBkcmFmdC1pZXRmLXRscy1leHRyYWN0b3IuICBJIGRvIG5vdCBlcXVhdGUgJ3JlbGF0ZXMn IHRvIGNsYWltaW5nDQo+PiByaWdodHMgb3Zlci4NCj4+ICAgICANCj4NCj4gSSBkb24ndCB0aGlu ayB0aGlzIGlzIHdoYXQgaXMgbWVhbnQgYnkgInJlbGF0ZXMiLiBJZiBsb3dlciBwcm90b2NvbA0K PiBsYXllcnMgInJlbGF0ZWQiIHRvIHRoZSBhYm92ZSBjaXBoZXIgc3VpdGVzLCB0aGVuIElQIChS RkM3OTEpIGFuZCBUQ1ANCj4gKFJGQzc5MykgYWxzbyAicmVsYXRlIiBpbiB0aGUgc2FtZSB3YXks IGFuZCB5b3UgZGlkIG5vdCBsaXN0IHRob3NlDQo+IGRyYWZ0cy4NCj4NCj4NCj4gICANCj4+ICAg SSBkbyByZWFkIHRoYXQgSVBSICMxMTU0IGNsYWltcyB0byBoYXZlIHBhdGVudHMgdGhhdCBjb3Zl ciBwYXJ0cyBvZg0KPj4gZG9jdW1lbnRzIGxpc3RlZCBpbiwNCj4+DQo+PiAgICBWIERpc2Nsb3N1 cmUgb2YgUGF0ZW50IEluZm9ybWF0aW9uIChpLmUuLCBwYXRlbnRzIG9yIHBhdGVudA0KPj4gYXBw bGljYXRpb25zIHJlcXVpcmVkIHRvIGJlIGRpc2Nsb3NlZCBieSBTZWN0aW9uIDYgb2YgUkZDIDM5 NzkpDQo+Pg0KPj4gICAgICBDIElmIGFuIEludGVybmV0LURyYWZ0IG9yIFJGQyBpbmNsdWRlcyBt dWx0aXBsZSBwYXJ0cyBhbmQgaXQgaXMNCj4+IG5vdCByZWFzb25hYmx5IGFwcGFyZW50IHdoaWNo IHBhcnQgb2Ygc3VjaCBJbnRlcm5ldC1EcmFmdCBvciBSRkMgaXMNCj4+IGFsbGVnZWQgdG8gYmUg Y292ZXJlZCBieSB0aGUgcGF0ZW50IGluZm9ybWF0aW9uIGRpc2Nsb3NlZCBpbiBTZWN0aW9uDQo+ PiBWKEEpIG9yIFYoQiksIGl0IGlzIGhlbHBmdWwgaWYgdGhlIGRpc2Nsb3NlciBpZGVudGlmaWVz IGhlcmUgdGhlDQo+PiBzZWN0aW9ucyBvZiB0aGUgSW50ZXJuZXQtRHJhZnQgb3IgUkZDIHRoYXQg YXJlIGFsbGVnZWQgdG8gYmUgc28NCj4+IGNvdmVyZWQ6DQo+Pg0KPj4gICBXaGVyZSBpdCBsaXN0 czoNCj4+DQo+PiAgIFJGQyAzMjc4LCBSRkMgNDEwOSwgUkZDIDQ0OTIsIFJGQyA0NzUzLCBSRkMg NDc1NCwgUkZDIDQ4NjksIFJGQw0KPj4gNTAwOCwgUkZDIDUyODksIGRyYWZ0LXJlc2NvcmxhLXRs cy1zdWl0ZWItMTIsDQo+PiBkcmFmdC1ncmVlbi1zZWNzaC1lY2MtMDcsIGRyYWZ0LWlnb2Utc2Vj c2gtc3VpdGViLTAwLA0KPj4gZHJhZnQtaWV0Zi1zbWltZS0zMjc4YmlzLTA3LCBkcmFmdC1pZXRm LXNtaW1lLXNoYTItMTENCj4+DQo+PiAgIE5vdGUgdGhhdCBkcmFmdC1pZXRmLXRscy1leHRyYWN0 b3IgaXMgbm90IGxpc3RlZCBpbiB0aGUgSS1EIG9yIFJGQ3MNCj4+IHBhcnQgb2Ygd2hpY2ggdGhl IGxpc3RlZCBwYXRlbnRzIGNsYWltIHRvIGNvdmVyLg0KPj4NCj4+IFRoZXJlZm9yZSBhIHJlYXNv bmFibGUgcGVyc29uIHNob3VsZCBiZSBhYmxlIHRvIGNvbmNsdWRlIHRoYXQgdGhlDQo+PiBzdGF0 ZW1lbnQgaXMgbm90IG1ha2luZyBhIGNsYWltIHRoYXQgcGF0ZW50cyBsaXN0ZWQgY292ZXIgcGFy dHMgb2YgdGhlDQo+PiBkcmFmdC1pZXRmLXRscy1leHRyYWN0b3IuDQo+PiAgICAgDQo+DQo+IEl0 IGlzIGdvb2QgdG8ga25vdyB0aGF0IHRoaXMgaXMgeW91ciBpbnRlcnByZXRhdGlvbjsgdGhhdCB5 b3UgbWVhbg0KPiB0aGF0IHRoZXJlIGFyZSBwYXRlbnQgY2xhaW1zIG9ubHkgb24gDQo+ICAgUkZD IDMyNzgsIA0KPiAgIFJGQyA0MTA5LCANCj4gICBSRkMgNDQ5MiwgDQo+ICAgUkZDIDQ3NTMsIA0K PiAgIFJGQyA0NzU0LCANCj4gICBSRkMgNDg2OSwgDQo+ICAgUkZDIDUwMDgsIA0KPiAgIFJGQyA1 Mjg5LCANCj4gICBkcmFmdC1yZXNjb3JsYS10bHMtc3VpdGViLTEyLA0KPiAgIGRyYWZ0LWdyZWVu LXNlY3NoLWVjYy0wNywgDQo+ICAgZHJhZnQtaWdvZS1zZWNzaC1zdWl0ZWItMDAsDQo+ICAgZHJh ZnQtaWV0Zi1zbWltZS0zMjc4YmlzLTA3LCANCj4gICBkcmFmdC1pZXRmLXNtaW1lLXNoYTItMTEN Cj4NCj4gVGhlc2UgZG9jdW1lbnRzIChvbmx5IHRoZXNlIGRvY3VtZW50cykgc2hvdWxkIGJlIGxp c3RlZCBpbiBTZWN0aW9uIElWLg0KPiAgDQo+IElmIHlvdSByZWFkIHRoZSBpbnN0cnVjdGlvbnMg Zm9yIFNlY3Rpb24gVi5DLCBpdCBpcyBwbGFpbiB0aGF0IHlvdSBhcmUNCj4gdG8gaWRlbnRpZnkg InNlY3Rpb25zIG9mIHRoZSBJbnRlcm5ldC1EcmFmdCBvciBSRkMgdGhhdCBhcmUgYWxsZWdlZCB0 bw0KPiBiZSBzbyBjb3ZlcmVkOiIsIGFuZCB5b3UgZG9uJ3QgaWRlbnRpZnkgYW55IHNlY3Rpb25z Lg0KPg0KPiBJZiB5b3UgaGF2ZSBubyBwYXRlbnQgY2xhaW1zIG9uIGEgZHJhZnQsIHRoZXJlIHNo b3VsZCBub3QgYmUgYW4gSVBSDQo+IGRpc2Nsb3N1cmUgb24gdGhhdCBkb2N1bWVudCwgZXhjZXB0 IHBlcmhhcHMgdG8gbWFrZSBjbGVhciAodmlhIHRoZQ0KPiBhZGRpdGlvbmFsIG5vdGVzIGluIFNl Y3Rpb24gVikgdGhhdCB5b3UgaGF2ZSBubyBwYXRlbnQgY2xhaW1zIG9uIGENCj4gZG9jdW1lbnQu DQo+DQo+ICAgDQo+PiAgIEFzIHN0YXRlZCBwcmlvciwgSSB0aGluayB0aGUgZm9ybSBiZWluZyB1 c2VkIGNyZWF0ZXMgdGhlIGNvbmZ1c2lvbg0KPj4gYXQgaGFuZC4gIFRoZXJlIGlzIG5vIGNsZWFy IGRlZmluaXRpb24gb2Ygd2hhdCBzaG91bGQgYmUgaW4gc2VjdGlvbiBJVg0KPj4gdmVyc3VzIHNl Y3Rpb24gVi4gQy4gIFNob3VsZCBtb3JlIGV4YWN0IGxhbmd1YWdlIGJlIGFkZGVkIHRvIHRoZSBm b3JtLA0KPj4gSSB3b3VsZCBiZSBoYXBweSB0byB1cGRhdGUgdGhlIElQUiBzdGF0ZW1lbnQgdG8g aGVscCByZW1vdmUgc29tZQ0KPj4gc3RhdGVkIHVuY2VydGFpbnRpZXMuDQo+PiAgICAgDQo+DQo+ IEl0IGFwcGVhcnMgdGhhdCB5b3VyIGludGVycHJldGF0aW9uIG9mIFNlY3Rpb24gSVYsIFYgYW5k IFNlY3Rpb24gVi5DDQo+IGNhbm5vdCBiZSBjb3JyZWN0IGJ5IHJlYWRpbmcgdGhlIHRleHQgZm9y IHRob3NlIHNlY3Rpb25zLiBZb3UgYXBwYXJlbnRseQ0KPiBkaWQgbm90IHJlYWQgdGhlIGluc3Ry dWN0aW9ucyBjYXJlZnVsbHkuICBJZiBvbmUgaXNuJ3QgZ29pbmcgdG8gcmVhZCB0aGUNCj4gdGV4 dCB0aGVyZSBub3csIHRoZXJlIGlzIG5vIHBvaW50IGluIGFkZGluZyBtb3JlIHRleHQuDQo+DQo+ ICAgDQo+PiAgIEZ1cnRoZXIgdGhlIFJGQyAzOTc5IGluZGljYXRlcyB0aGUgZm9sbG93aW5nOg0K Pj4NCj4+IDYuMy4gIEhvdyBNdXN0IGEgRGlzY2xvc3VyZSBiZSBNYWRlPw0KPj4NCj4+ICAgIElQ UiBkaXNjbG9zdXJlcyBhcmUgbWFkZSBieSBmb2xsb3dpbmcgdGhlIGluc3RydWN0aW9ucyBhdA0K Pj4gICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHItaW5zdHJ1Y3Rpb25zLiANCj4+DQo+PiBBIGxp bmsgSSB0aGluayBtb3N0IHdpbGwgZmluZCBwYXJ0aWN1bGFybHkgYW11c2luZy4NCj4+ICAgICAN Cj4NCj4gSSBkaWRuJ3QgZmluZCB0aGUgbGluayBhbXVzaW5nLiBJIHJhdGhlciBleHBlY3RlZCB0 aGF0IHlvdSBoYWQgZm91bmQgYQ0KPiBkZWFkIGxpbmsgb3Igc29tZXRoaW5nLCBidXQgdGhhdCBp c24ndCB0aGUgY2FzZS4gDQo+DQo+IFRoZSBsaW5rIHlvdSBjaXRlIHByb3ZpZGVzIGNvbnRhY3Qg aW5mb3JtYXRpb24gYW5kIGRpcmVjdHMgb25lIHRvIHRoZQ0KPiBkaXNjbG9zdXJlIHRlbXBsYXRl LCB3aGljaCB5b3UgZmlsbGVkIG91dC4gIE9uIHRoYXQgdGVtcGxhdGUsIFNlY3Rpb24NCj4gVi5D IGNvbnRhaW5zIHRoZSBzYW1lIGluc3RydWN0aW9ucyBhcyBhcHBlYXIgb24gdGhlIERpc2Nsb3N1 cmUuDQo+DQo+ID09PT09PT09PT09PT09PT09PT09PT0gDQo+IEMuIElmIGFuIEludGVybmV0LURy YWZ0IG9yIFJGQyBpbmNsdWRlcyBtdWx0aXBsZSBwYXJ0cyBhbmQgaXQgaXMgbm90IA0KPiByZWFz b25hYmx5IGFwcGFyZW50IHdoaWNoIHBhcnQgb2Ygc3VjaCBJbnRlcm5ldC1EcmFmdCBvciBSRkMg aXMgYWxsZWdlZCANCj4gdG8gYmUgY292ZXJlZCBieSB0aGUgcGF0ZW50IGluZm9ybWF0aW9uIGRp c2Nsb3NlZCBpbiBTZWN0aW9uIFYoQSkgb3IgDQo+IFYoQiksIGl0IGlzIGhlbHBmdWwgaWYgdGhl IGRpc2Nsb3NlciBpZGVudGlmaWVzIGhlcmUgdGhlIHNlY3Rpb25zIG9mIHRoZSANCj4gSW50ZXJu ZXQtRHJhZnQgb3IgUkZDIHRoYXQgYXJlIGFsbGVnZWQgdG8gYmUgc28gY292ZXJlZDogDQo+ID09 PT09PT09PT09PT09PT09PT09PT0gDQo+DQo+IFlvdXIgaW50ZXJwcmV0YXRpb24gb2YgU2VjdGlv biBWLkMgY2Fubm90IGJlIGNvcnJlY3QgYnkgcmVhZGluZyB0aGUgdGV4dA0KPiBmb3Igc2VjdGlv biBWLkMgb24gdGhlIHRlbXBsYXRlLiBPbmUgd29uZGVycyBpZiB5b3UgdG9vayB0aGUgcHJvcGVy IHRpbWUNCj4gYW5kIHNvbGVtbml0eSB0byBwcmVwYXJlIHRoZSBDZXJ0aWNvbSBkaXNjbG9zdXJl cy4NCj4NCj4gQnV0IEkgZ3Vlc3Mgd2UgaGF2ZSB0aGUgaW5mb3JtYXRpb24gd2UgbmVlZCwgbm93 LiBUaGFua3MuIEkgaG9wZSB5b3UNCj4gcXVpY2tseSB1cGRhdGUgdGhlIElQUiBkaXNjbG9zdXJl IHRvIGNvbXBseSB3aXRoIHRoZSBpbnN0cnVjdGlvbnMgZm9yDQo+IGVhY2ggc2VjdGlvbiBhbmQg dGhlIGFjdHVhbCBmYWN0cyBDZXJ0aWNvbSBpcyBzdXBwb3NlZCB0byBjb252ZXkgZm9yDQo+IHRo b3NlIHNlY3Rpb25zLiAgR2l2ZW4gdGhlIGNvbmZ1c2lvbiBzbyBmYXIsIEkgdGhpbmsgeW91IHdp bGwgbmVlZCB0bw0KPiBhZGQgYSBjb21tZW50IGZvciBlYWNoIGRvY3VtZW50IHByZXZpb3VzbHkg aW5jb3JyZWN0bHkgbGlzdGVkIGluIFNlY3Rpb24NCj4gSVYgZm9yIHdoaWNoIHRoZXJlIGFyZSBu byBwYXRlbnQgY2xhaW1zLCBjbGVhcmx5IHN0YXRpbmcgdGhlIGZhY3Qgb2Ygbm8NCj4gcGF0ZW50 IGVuY3VtYnJhbmNlIG9uIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cy4gIE9uY2UgdGhhdCBpcyBk b25lLCBhbmQNCj4gaXQgaXMgY2xlYXIgdGhlcmUgYXJlIG5vIHBhdGVudCBlbmN1bWJyYW5jZXMg b24gdGhlIGV4dHJhY3RvciBkcmFmdCwgSQ0KPiB3aWxsIGJlIGhhcHB5IHRvIHJlY29uc2lkZXIg bXkgb2JqZWN0aW9uIHRvIHRoZSBleHRyYWN0b3IgZHJhZnQuDQo+DQo+IAkJLS1EZWFuDQo+DQo+ DQo+DQo+DQo+ICAgDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KPiBObyB2aXJ1cyBmb3VuZCBp biB0aGlzIGluY29taW5nIG1lc3NhZ2UuDQo+IENoZWNrZWQgYnkgQVZHIC0gd3d3LmF2Zy5jb20g DQo+IFZlcnNpb246IDguNS4zOTIgLyBWaXJ1cyBEYXRhYmFzZTogMjcwLjEzLjI1LzIyNTYgLSBS ZWxlYXNlIERhdGU6IDA3LzIzLzA5IDA2OjAyOjAwDQo+DQo+ICAgDQoNCg0K From dean@av8.com Thu Jul 23 12:14:19 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 025793A6855 for ; Thu, 23 Jul 2009 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 P2+4lhuN-P+s for ; Thu, 23 Jul 2009 12:14:18 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id AE09E3A6AAC for ; Thu, 23 Jul 2009 12:13:42 -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 n6NJBqgo017504 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Jul 2009 15:11:53 -0400 Date: Thu, 23 Jul 2009 15:11:52 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Matthew Campagna In-Reply-To: <623ACC30D56D0B4DB72868C664C23704E68AC01A36@EX41.exchserver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "tglassey@earthlink.net" , "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 19:14:19 -0000 On Thu, 23 Jul 2009, Matthew Campagna wrote: > Todd, > > The official statement is the linked document, we update it from time to time. > > Regards, > Matt This is a problem. The official statement is the IPR disclosure, which should contain the terms used by the IETF in its decision to approve the document. Certicom should not be able to alter the terms after the fact, which it seems to have just admitted doing. I think that we have to consider rejecting documents where the terms are not definite and/or can be altered at the whim of the patent holder. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Nicolas.Williams@sun.com Thu Jul 23 13:11: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 72D5C3A6A0D for ; Thu, 23 Jul 2009 13:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=0.572, 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 VIY0eOlYwzdy for ; Thu, 23 Jul 2009 13:11:15 -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 3343B3A676A for ; Thu, 23 Jul 2009 13:10:55 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6NJm0Jx021751 for ; Thu, 23 Jul 2009 19:48:00 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 n6NJm0Vd024288 for ; Thu, 23 Jul 2009 13:48:00 -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 n6NJF7uq004265; Thu, 23 Jul 2009 14:15:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6NJF6lF004264; Thu, 23 Jul 2009 14:15:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 23 Jul 2009 14:15:06 -0500 From: Nicolas Williams To: Dean Anderson Message-ID: <20090723191506.GM1020@Sun.COM> References: <623ACC30D56D0B4DB72868C664C23704E68AC01A36@EX41.exchserver.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: "tglassey@earthlink.net" , "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 20:11:16 -0000 On Thu, Jul 23, 2009 at 03:11:52PM -0400, Dean Anderson wrote: > On Thu, 23 Jul 2009, Matthew Campagna wrote: > > The official statement is the linked document, we update it from time to time. > > This is a problem. The official statement is the IPR disclosure, which > should contain the terms used by the IETF in its decision to approve the > document. Certicom should not be able to alter the terms after the fact, > which it seems to have just admitted doing. > > I think that we have to consider rejecting documents where the terms are > not definite and/or can be altered at the whim of the patent holder. There must at the very least be an audit trail and diffs for each change, otherwise an implementor might think they're not infringing on the basis of having read a version of an IPR disclosure that is later changed, and how would they prove this in court? Nico -- From jwkckid1@ix.netcom.com Thu Jul 23 13:28: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 19D573A6A22 for ; Thu, 23 Jul 2009 13:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 GC8XfQzVVUhj for ; Thu, 23 Jul 2009 13:28:11 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id AFA783A676A for ; Thu, 23 Jul 2009 13:28:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=jUx1nQDJ2Y4FyVtHCh9r1dlbD8ZPG264DlmJFy8zBZkPJJCrqMt6bZdVgpCLBuGU; 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.103.28] (helo=ix.netcom.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MU4sn-0001Ht-0S; Thu, 23 Jul 2009 16:27:17 -0400 Message-ID: <4A68E3AB.2304C9FE@ix.netcom.com> Date: Thu, 23 Jul 2009 15:26:51 -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: Dean Anderson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688ec8f90d9dd181e959e4f1c6f7f86cdad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.28 Cc: "tglassey@earthlink.net" , "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterial Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 20:28:13 -0000 Dean and all, Good suggestion, but one that should have been obvious to the IETF long ago. Better late than never I suppose though... BTW, who's representing the IETF these days? I am afraid I haven't kept as current on that as well as I should have... Dean Anderson wrote: > On Thu, 23 Jul 2009, Matthew Campagna wrote: > > > Todd, > > > > The official statement is the linked document, we update it from time to time. > > > > Regards, > > Matt > > This is a problem. The official statement is the IPR disclosure, which > should contain the terms used by the IETF in its decision to approve the > document. Certicom should not be able to alter the terms after the fact, > which it seems to have just admitted doing. > > I think that we have to consider rejecting documents where the terms are > not definite and/or can be altered at the whim of the patent holder. > > --Dean > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > _______________________________________________ > TLS mailing list > TLS@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 tglassey@earthlink.net Thu Jul 23 11:00: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 0396E3A6B0C for ; Thu, 23 Jul 2009 11:00:39 -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 XDxzGYPErWVg for ; Thu, 23 Jul 2009 11:00:36 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 3694B28C13B for ; Thu, 23 Jul 2009 10:58:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kWVEFWzeZboe1JM8tbtsfeNstjjmynNVVodSr1Qi5gBfYeAp2ENxWS1AgWIzha27; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU2E7-0001C4-IK; Thu, 23 Jul 2009 13:37:07 -0400 Message-ID: <4A689FC3.4070805@earthlink.net> Date: Thu, 23 Jul 2009 10:37:07 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dean Anderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b6fc0355ddb1a686ce9de4f04303a4a7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 X-Mailman-Approved-At: Thu, 23 Jul 2009 14:21:28 -0700 Cc: "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 18:00:39 -0000 Dean Anderson wrote: > On Wed, 22 Jul 2009, Matthew Campagna wrote: > > =20 >> In Hopes of Clarifying, >> >> Since I filled out the form in question I would hope that you >> consider these comments with a little more weight than others' wild >> speculations about the intention of IPR #1154. >> >> I do not read that IPR #1154 claims to have patents that cover the >> draft-ietf-tls-extractor, and perhaps more importantly, nor was it my >> intention to indicate any such claims. >> >> =20 Matthew - I dont want to know your intentions were when you filed it but what I do = want to know is what Certicom's commitment's are and in writing - and=20 here is the key thing - it has to formally come from someone legally=20 empowered by the Corporation to do so. Otherwise (no offense meant) what you personally want is irrelevant=20 unless you are specifically the inventor and are reclaiming that IP... > > The above is a good statement about your intent with regard to patent=20 > claims on draft-ietf-tls-extractor. > > > =20 >> I do recognize that it is listed in the section >> >> IV. IETF Document or Other Contribution to Which this IPR Disclosur= e Relates: >> >> I believe this to be correct as the free license being offered >> extends a license to use the following suites, to which we are making >> some claims, >> >> A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Lay= er Security(TLS)" RFC 4492, May 2006; or, >> B. =1B$B!H=1B(BTLS Elliptic Curve Cipher Suites with SHA=1B$B!>=1B(B2= 56/384 and AES Galois Counter Mode,=1B$B!I=1B(B RFC 5289, or >> C. =1B$B!H=1B(BSuite B Cipher Suites for TLS,=1B$B!I=1B(B draft=1B$B!= >=1B(Brescorla=1B$B!>=1B(Btls=1B$B!>=1B(Bsuiteb=1B$B!>=1B(B 07.txt; >> >> if one wants to use them in the draft-ietf-tls-extractor, under the >> conditions in a linked document. Hence, I believe that the license is= >> extending intellectual property rights that 'relates' to >> draft-ietf-tls-extractor. I do not equate 'relates' to claiming >> rights over. >> =20 > > I don't think this is what is meant by "relates". If lower protocol > layers "related" to the above cipher suites, then IP (RFC791) and TCP > (RFC793) also "relate" in the same way, and you did not list those > drafts. > > > =20 >> I do read that IPR #1154 claims to have patents that cover parts of >> documents listed in, >> >> V Disclosure of Patent Information (i.e., patents or patent >> applications required to be disclosed by Section 6 of RFC 3979) >> >> C If an Internet-Draft or RFC includes multiple parts and it is >> not reasonably apparent which part of such Internet-Draft or RFC is >> alleged to be covered by the patent information disclosed in Section >> V(A) or V(B), it is helpful if the discloser identifies here the >> sections of the Internet-Draft or RFC that are alleged to be so >> covered: >> >> Where it lists: >> >> RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC >> 5008, RFC 5289, draft-rescorla-tls-suiteb-12, >> draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, >> draft-ietf-smime-3278bis-07, draft-ietf-smime-sha2-11 >> >> Note that draft-ietf-tls-extractor is not listed in the I-D or RFCs >> part of which the listed patents claim to cover. >> >> Therefore a reasonable person should be able to conclude that the >> statement is not making a claim that patents listed cover parts of the= >> draft-ietf-tls-extractor. >> =20 > > It is good to know that this is your interpretation; that you mean > that there are patent claims only on=20 > RFC 3278,=20 > RFC 4109,=20 > RFC 4492,=20 > RFC 4753,=20 > RFC 4754,=20 > RFC 4869,=20 > RFC 5008,=20 > RFC 5289,=20 > draft-rescorla-tls-suiteb-12, > draft-green-secsh-ecc-07,=20 > draft-igoe-secsh-suiteb-00, > draft-ietf-smime-3278bis-07,=20 > draft-ietf-smime-sha2-11 > > These documents (only these documents) should be listed in Section IV. > =20 > If you read the instructions for Section V.C, it is plain that you are > to identify "sections of the Internet-Draft or RFC that are alleged to > be so covered:", and you don't identify any sections. > > If you have no patent claims on a draft, there should not be an IPR > disclosure on that document, except perhaps to make clear (via the > additional notes in Section V) that you have no patent claims on a > document. > > =20 >> As stated prior, I think the form being used creates the confusion >> at hand. There is no clear definition of what should be in section IV= >> versus section V. C. Should more exact language be added to the form,= >> I would be happy to update the IPR statement to help remove some >> stated uncertainties. >> =20 > > It appears that your interpretation of Section IV, V and Section V.C > cannot be correct by reading the text for those sections. You apparentl= y > did not read the instructions carefully. If one isn't going to read th= e > text there now, there is no point in adding more text. > > =20 >> Further the RFC 3979 indicates the following: >> >> 6.3. How Must a Disclosure be Made? >> >> IPR disclosures are made by following the instructions at >> http://www.ietf.org/ipr-instructions.=20 >> >> A link I think most will find particularly amusing. >> =20 > > I didn't find the link amusing. I rather expected that you had found a > dead link or something, but that isn't the case.=20 > > The link you cite provides contact information and directs one to the > disclosure template, which you filled out. On that template, Section > V.C contains the same instructions as appear on the Disclosure. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > C. If an Internet-Draft or RFC includes multiple parts and it is not=20 > reasonably apparent which part of such Internet-Draft or RFC is alleged= =20 > to be covered by the patent information disclosed in Section V(A) or=20 > V(B), it is helpful if the discloser identifies here the sections of th= e=20 > Internet-Draft or RFC that are alleged to be so covered:=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > Your interpretation of Section V.C cannot be correct by reading the tex= t > for section V.C on the template. One wonders if you took the proper tim= e > and solemnity to prepare the Certicom disclosures. > > But I guess we have the information we need, now. Thanks. I hope you > quickly update the IPR disclosure to comply with the instructions for > each section and the actual facts Certicom is supposed to convey for > those sections. Given the confusion so far, I think you will need to > add a comment for each document previously incorrectly listed in Sectio= n > IV for which there are no patent claims, clearly stating the fact of no= > patent encumbrance on those specific documents. Once that is done, and= > it is clear there are no patent encumbrances on the extractor draft, I > will be happy to reconsider my objection to the extractor draft. > > --Dean > > > > > =20 > -----------------------------------------------------------------------= - > > > No virus found in this incoming message. > Checked by AVG - www.avg.com=20 > Version: 8.5.392 / Virus Database: 270.13.25/2256 - Release Date: 07/23= /09 06:02:00 > > =20 From tglassey@earthlink.net Thu Jul 23 13:51:29 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 017F628C0F7 for ; Thu, 23 Jul 2009 13:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkaC-kSXv5tO for ; Thu, 23 Jul 2009 13:51:28 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 2B4663A6849 for ; Thu, 23 Jul 2009 13:51:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qkIzAYlEL81MpRVranCU61b7/APf/umEjn43EhOoeJpL8P0F790MK3z94bd5yFwN; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU4HQ-0008UW-3D; Thu, 23 Jul 2009 15:48:40 -0400 Message-ID: <4A68BE99.2060808@earthlink.net> Date: Thu, 23 Jul 2009 12:48:41 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nicolas Williams References: <623ACC30D56D0B4DB72868C664C23704E68AC01A36@EX41.exchserver.com> <20090723191506.GM1020@Sun.COM> In-Reply-To: <20090723191506.GM1020@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793f6a8c781b717df435e5672ac8942a9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 X-Mailman-Approved-At: Thu, 23 Jul 2009 14:21:28 -0700 Cc: "ietf-honest@lists.iadl.org" , "tls@ietf.org" Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 23 Jul 2009 20:51:29 -0000 Nicolas Williams wrote: > On Thu, Jul 23, 2009 at 03:11:52PM -0400, Dean Anderson wrote: > >> On Thu, 23 Jul 2009, Matthew Campagna wrote: >> >>> The official statement is the linked document, we update it from time to time. >>> >> This is a problem. The official statement is the IPR disclosure, which >> should contain the terms used by the IETF in its decision to approve the >> document. Certicom should not be able to alter the terms after the fact, >> which it seems to have just admitted doing. >> >> I think that we have to consider rejecting documents where the terms are >> not definite and/or can be altered at the whim of the patent holder. >> > > There must at the very least be an audit trail and diffs for each > change, otherwise an implementor might think they're not infringing on > the basis of having read a version of an IPR disclosure that is later > changed, and how would they prove this in court? > Nico the real issue is the liability profile this opens for the IETF and its a nasty one IMHO. Todd Glassey > Nico > -- > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.25/2256 - Release Date: 07/23/09 06:02:00 > > From Martin.Rex@sap.com Thu Jul 23 14:34: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 E9D963A6B03 for ; Thu, 23 Jul 2009 14:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.477 X-Spam-Level: X-Spam-Status: No, score=-5.477 tagged_above=-999 required=5 tests=[AWL=0.772, 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 QhRg7kWNMxpl for ; Thu, 23 Jul 2009 14:34:49 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D8B893A6B46 for ; Thu, 23 Jul 2009 14:34:48 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n6NLYGse015637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 23:34:16 +0200 (MEST) From: Martin Rex Message-Id: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> To: dean@av8.com (Dean Anderson) Date: Thu, 23 Jul 2009 23:34:16 +0200 (MEST) In-Reply-To: from "Dean Anderson" at Jul 23, 9 03:11:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tglassey@earthlink.net, ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying 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, 23 Jul 2009 21:34:50 -0000 Dean Anderson wrote: > > On Thu, 23 Jul 2009, Matthew Campagna wrote: > > > > The official statement is the linked document, we update it from time to time. > > This is a problem. The official statement is the IPR disclosure, which > should contain the terms used by the IETF in its decision to approve the > document. Certicom should not be able to alter the terms after the fact, > which it seems to have just admitted doing. The IETF is NOT asking for an irrevocable "Grant" in an IPR disclosure. The problem here is that submitting an URL for the real IPR disclosure in the IETF disclosure form is subverting to idea that the IETF can archive the IPR disclosures in their original form. > > I think that we have to consider rejecting documents where the terms are > not definite and/or can be altered at the whim of the patent holder. Copyright terms stick to the published text or code when they're published (under the condition they're rightfully issued). AFAIK, License grants for patents are rarely issued as "irrevocable", which means that the terms can be cancelled/terminated. -Martin From dean@av8.com Thu Jul 23 15:41: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 9AE853A6B91 for ; Thu, 23 Jul 2009 15:41:20 -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 WD3rZgS7Ewqf for ; Thu, 23 Jul 2009 15:41:19 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 055A13A6866 for ; Thu, 23 Jul 2009 15:41:18 -0700 (PDT) Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n6NMeWpW018015 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Jul 2009 18:40:32 -0400 Date: Thu, 23 Jul 2009 18:40:32 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@sr22.av8.net To: Martin Rex In-Reply-To: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tglassey@earthlink.net, ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying 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, 23 Jul 2009 22:41:20 -0000 On Thu, 23 Jul 2009, Martin Rex wrote: > Dean Anderson wrote: > > > > On Thu, 23 Jul 2009, Matthew Campagna wrote: > > > > > > The official statement is the linked document, we update it from time to time. > > > > This is a problem. The official statement is the IPR disclosure, which > > should contain the terms used by the IETF in its decision to approve the > > document. Certicom should not be able to alter the terms after the fact, > > which it seems to have just admitted doing. > > The IETF is NOT asking for an irrevocable "Grant" in an IPR disclosure. Of course not. The IETF just wants to know what the terms are. We take those terms into consideration in our decision to approve or reject the document. But if the terms of license are variable or indefinite, then there really are no terms. The patented technology is not free and we don't have any idea what it will cost--it will probably be expensive. We often reject such documents as being unfavorable. > The problem here is that submitting an URL for the real IPR disclosure > in the IETF disclosure form is subverting to idea that the IETF > can archive the IPR disclosures in their original form. I agree > > I think that we have to consider rejecting documents where the terms are > > not definite and/or can be altered at the whim of the patent holder. > > Copyright terms stick to the published text or code when they're > published (under the condition they're rightfully issued). I don't know what copyrights have to do with anything, here. They have nothing to do with what I said. My point above is that the disclosures required by RFC 3979 enable us to make informed decisions regarding the patent-encumbered document, which includes any licensing terms. If a patent-holder offers unspecific or variable terms that it can change them at whim, that fact by itself is a good reason to reject the document. > AFAIK, License grants for patents are rarely issued as "irrevocable", > which means that the terms can be cancelled/terminated. Well, actually, just the opposite is true. Rarely do patent licenses have terms of revocation. Most commercial patent holders just want the money and don't care what you do after that. But free universal licenses usually contain revocation terms that revoke the license if you use a patent non-defensively. But at present, those licenses are (unfortunately) the exception, not the rule. In any case, if the license is revocable, one has to state the conditions on which the licence can be revoked. We can consider the license terms in our decision, and I think we should reject documents where the patent holder can subsequently refuse licenses in the future, or alter the terms at its whim. Such patents can be expected to be expensive in the future when the patent is part of a standard, and users have no choice but to pay whatever is demanded. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jwkckid1@ix.netcom.com Thu Jul 23 15:49:29 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 CF8D43A68E7 for ; Thu, 23 Jul 2009 15:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 XYLk+9+t9Ij7 for ; Thu, 23 Jul 2009 15:49:28 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id ADF363A6866 for ; Thu, 23 Jul 2009 15:49:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=kGWruL/dvHFD8c/6O1ZW7N7yhUpM1Qd7ugxQacv8pj3lSE/cdzYiIccq3SAzqWrF; 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.96.47] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MU76H-0003fy-9H; Thu, 23 Jul 2009 18:49:22 -0400 Message-ID: <4A6904F7.9309C744@ix.netcom.com> Date: Thu, 23 Jul 2009 17:48:55 -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: martin.rex@sap.com References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606883f2d0424ddbdc7377cf63fdf2871bf3d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.47 Cc: tglassey@earthlink.net, ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying 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, 23 Jul 2009 22:49:29 -0000 Martin and all, Right! Getting a license grant that is NOT "irrevocable", is of VERY questionable value. Same is true of a patent grant to use. If I am paying for either, it is either "irrevocable" or no deal. Simple as that. If I am no paying for it than I want at least a time limit before the terms can be modified in any way. Otherwise anything else is of VERY questionable value. Martin Rex wrote: > Dean Anderson wrote: > > > > On Thu, 23 Jul 2009, Matthew Campagna wrote: > > > > > > The official statement is the linked document, we update it from time to time. > > > > This is a problem. The official statement is the IPR disclosure, which > > should contain the terms used by the IETF in its decision to approve the > > document. Certicom should not be able to alter the terms after the fact, > > which it seems to have just admitted doing. > > The IETF is NOT asking for an irrevocable "Grant" in an IPR disclosure. > > The problem here is that submitting an URL for the real IPR disclosure > in the IETF disclosure form is subverting to idea that the IETF > can archive the IPR disclosures in their original form. > > > > > I think that we have to consider rejecting documents where the terms are > > not definite and/or can be altered at the whim of the patent holder. > > Copyright terms stick to the published text or code when they're > published (under the condition they're rightfully issued). > > AFAIK, License grants for patents are rarely issued as "irrevocable", > which means that the terms can be cancelled/terminated. > > -Martin > _______________________________________________ > 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 rms@gnu.org Thu Jul 23 18:37:56 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 97F833A6A8E; Thu, 23 Jul 2009 18:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 ZB+KGlc9gy1v; Thu, 23 Jul 2009 18:37:55 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id D49823A69BA; Thu, 23 Jul 2009 18:37:55 -0700 (PDT) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MU9jO-0007UF-Sl; Thu, 23 Jul 2009 21:37:54 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Nicolas Williams In-reply-to: <20090722223622.GP1020@Sun.COM> (message from Nicolas Williams on Wed, 22 Jul 2009 17:36:23 -0500) References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> Message-Id: Date: Thu, 23 Jul 2009 21:37:54 -0400 Cc: tls@ietf.org, ietf-honest@lists.iadl.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 01:37:56 -0000 The operative word here is uncertainty. A patent-holder creates uncertainty. How should an SDO respond? I'm not sure. I'm only sure that I don't like getting DoSed, either into dropping a standard or into not implementing it for fear of infringing. That's the nature of software patents: each one denies people the freedom to write and run certain kinds of software. This is why we must abolish software patents. Until we succeed in doing that, we can resist in certain ways. One of them is to refuse to establish standards that encourage their use. Generally speaking, standards are useful, because they enable people to converge what they are doing. But that ceases to be true when the use of the standard is patented. It is better to have no standard than have a standard that invites people into danger. From jwkckid1@ix.netcom.com Thu Jul 23 21:44: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 EB39B28C126; Thu, 23 Jul 2009 21:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 EqmMyY5wvy0e; Thu, 23 Jul 2009 21:44:12 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id CE2423A68DB; Thu, 23 Jul 2009 21:44:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RyrWEG7GXNw6lxPyrwpF4C3PuWLYpAhKPkJLEBN0XXZVwZMSt3OqhhktG2482TJi; 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.98.214] (helo=ix.netcom.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MUBJP-0006tM-Bk; Thu, 23 Jul 2009 23:19:12 -0400 Message-ID: <4A69282D.DA170554@ix.netcom.com> Date: Thu, 23 Jul 2009 20:19:09 -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: rms@gnu.org References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688ae446c6598bc85ca98ef0fd5f4e64007350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.214 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, Nicolas Williams , ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 24 Jul 2009 04:44:14 -0000 Richard and all, I agree largely. Very little software warrents patenting. Protection of any authors software can much better and easily be done in other ways. Open source is not the total answer either as some types of software in open source format would be ill advised. Richard Stallman wrote: > The operative word here is uncertainty. A patent-holder creates > uncertainty. How should an SDO respond? I'm not sure. I'm only sure > that I don't like getting DoSed, either into dropping a standard or into > not implementing it for fear of infringing. > > That's the nature of software patents: each one denies people the > freedom to write and run certain kinds of software. This is why we > must abolish software patents. > > Until we succeed in doing that, we can resist in certain ways. One of > them is to refuse to establish standards that encourage their use. > > Generally speaking, standards are useful, because they enable people > to converge what they are doing. But that ceases to be true when the > use of the standard is patented. It is better to have no standard > than have a standard that invites people into danger. > _______________________________________________ > 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 huangmin@huaweisymantec.com Fri Jul 24 01:54: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 E55133A688D for ; Fri, 24 Jul 2009 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.116 X-Spam-Level: * X-Spam-Status: No, score=1.116 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_24=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=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 S9DSYkP01Hu3 for ; Fri, 24 Jul 2009 01:54:39 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 3BF083A657C for ; Fri, 24 Jul 2009 01:54:39 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNA00MEV0F3IW20@hstga02-in.huaweisymantec.com> for tls@ietf.org; Fri, 24 Jul 2009 15:49:52 +0800 (CST) Received: from h00104745 ([10.27.154.144]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KNA006NH0F0A710@hstml01-in.huaweisymantec.com> for tls@ietf.org; Fri, 24 Jul 2009 15:49:51 +0800 (CST) From: Min Huang To: 'Eric Rescorla' Date: Fri, 24 Jul 2009 15:49:47 +0800 Message-id: <001801ca0c33$5149d8e0$909a1b0a@china.huawei.com> Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090722042426.378521D0F73@kilo.networkresonance.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcoKg/3jJxKJQEGET+iuc6xqd0hgdwBqErtw Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-huang-tls-ibe-00 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, 24 Jul 2009 08:54:41 -0000 hi, Eric Rescorla wrote: >But Mechanism 2 has the same issues as certificates in terms=20 >of the user being able to override invalid credentials. Mechanism 1 is intended to solve this problem, if the client=20 sends the public parameter sets list which it trusts to server,=20 and the server only can choose one from the parameter sets list,=20 there will be no override invalid credentials problems. But as=20 you metioned before, it brings some other problems to be solved.=20 So mechanism 2 is provided, it seems more similar to the traditional=20 PKI mechanism, but it also has the override invalid credentials problem. >I agree that this benefit is not applicable to TLS. But since >that's the main technical benefit of IBE... It=A1=AFs true. But in some cases, it can work well. For example,=20 (1)The server obtains its private key in advance and tells the client=20 the corresponding public parameter set and ID to be used in keyexchange. = There is no relationship with the main benefit of IBE.=20 (2)The client tells the public parameter sets and ID to the server=20 in handshake process. If there is a real time authentication method=20 used by the PKG to authenticate the server effectively, then the=20 server can obtain its private key in the TLS handshake process=20 immediately. >I don't understand what you're suggesting here. I meant that in one specific domain the number of PKGs is not large.=20 You said "Actually, due to the unique security properties of IBE,=20 I would imagine there would be more PKGs because the amount of=20 trust placed in a PKG is much higher than a CA." I am not sure=20 do you mean that there must be many PKGs that undertake the=20 responsibility of generating a user=A1=AFs private key together?=20 for example, each PKG just shares just one piece of private key,=20 and a private key can be computed after putting all piece together. >OK, but you need to describe the actual encoding. Is it an=20 >IBESysParams or what? It is a BFPublicParameters or a BB1PublicParameters structure=20 defined in RFC 5091.=20 >But this makes the real time problem worse, since the client needs >to know in advance what keys the server might potentially have, >otherwise the server will need to get a new key for each client. In mechanism 1, the server IDs list is provided by the client and=20 there must be a problem if the ID contains a data string. There=20 what they negotiate is the identity information, e.g., email address,=20 IP address, domain name or other identities which can be used to=20 indicate the identity of the server. This information does not include=20 a date string. The actual ID used to compute the public key is provided=20 by the server after the negotiation. In mechanism 2, it is not a = problem.=20 Because the server ID used in encryption is sent by the server. So it=20 can directly provide a valid ID containing a valid date string. regards, Shirley -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Eric Rescorla [mailto:ekr@networkresonance.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA7=D4=C222=C8=D5 12:24 =CA=D5=BC=FE=C8=CB: Min Huang =B3=AD=CB=CD: ekr@networkresonance.com; tls@ietf.org =D6=F7=CC=E2: Re: [TLS] Review of draft-huang-tls-ibe-00 At Wed, 22 Jul 2009 11:16:54 +0800, Min Huang wrote: >=20 >=20 > Hi,Eric >=20 > Thanks very much for your review. > Reply inline. >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >=20 > Eric Rescorla writes: >=20 > > - There definitely are UI issues with users accepting mismatched > > certificates, but it's not clear that IBE will really > > solve the problem here; if you're going to mount an attack > > it's about equally convenient to have a bogus CA as a > > bogus domain name. Unless you're going to prohibit users > > from accepting PKGs that their clients don't know about > > (we tried this with CAs and it didn't work out), it seems > > to me that we're going to still have the user override > > problem. >=20 > The certificate (or public parameters) is sent from the server to the=20 > client. There always is a mismatching problem, either a distrusted CA=20 > or a distrusted PKG. > So in this proposal I thought that the client provides the sets of=20 > public parameters from PKGs it trusts before the server sends its=20 > public parameters. > The public parameters set sent by the server must be one of the sets=20 > provided by the client. If there is no matched set, the server can not = > choose IBE cipher suites or this connection is failed. This is also=20 > one reason of putting public parameters sets in the ClientHello=20 > message. However, as you mentioned, this mechanism is not so good.=20 > There is another mechanism. I am considering how about putting the=20 > public parameters set in the Server Certificate message. The client=20 > only provides the IBE cipher suites. If the server chooses an IBE=20 > cipher suite, it needs to provide the public parameters retrieved from = > the PKG/PPS from which it acquired the private key. I will call the=20 > original mechanism "mechanism 1" and this alternative mechanism=20 > "mechanism 2" for convenience in the following description. Mechanism=20 > 1 supports obtaining private keys in real time if there is no matching = > PKG from which it has obtained the private key and in advance if there = > is a matching PKG. In mechanism 2 the server can also acquire its=20 > private key in real time or in advance depending on the policies=20 > configured. > It needs to consider which mechanism is better.=20 > I wonder we can reach consensus in the wg. But Mechanism 2 has the same issues as certificates in terms of the user being able to override invalid credentials. > > Moreover, the main benefit of IBE, namely that Alice can send an=20 > > encrypted message to Bob without communicating with Bob and before=20 > > Bob has enrolled doesn't pay off here because TLS involves direct=20 > > communication and expects the server to be able to decrypt the PMS=20 > > in > real time. >=20 > In TLS this benefit of IBE is not utilized because TLS involves real=20 > time communication. If the time taken by obtaining private key is=20 > within the tolerance of real time communication, then the server can=20 > obtain its private key in the process of TLS handshake. I agree that this benefit is not applicable to TLS. But since that's the main technical benefit of IBE... > > The mechanism described here is extremely clumsy: I find it highly > implausible that the > > client is going to send its entire list of PKGs (if X.509 is any=20 > > guide, > this would run to a hundred > > or so) in every ClientHello. Actually, due to the unique security > properties of IBE, I would imagine > > there would be more PKGs because the amount of trust placed in a=20 > > PKG is > much higher than a CA. >=20 > Here "list of PKGs" you mentioned above actually is a list of public=20 > parameters sets from PPSs/PKGs trusted by client. What I considered=20 > earlier is that the number of PKGs in one domain is not large, but in=20 > the whole internet environment, this mechanism seems clumsy. I am=20 > considering another mechanism described in front. The public=20 > parameters and server ID used in key exchange are provided by the=20 > server who has already acquired its private key from one PKG. > "Actually, due to the unique security properties of IBE, I would=20 > imagine there would be more PKGs because the amount of trust placed in = > a PKG is much higher than a CA." > It means that if one PKG is compromised, all of the users' private=20 > keys are compromised. > So there must be many PKGs that undertake the responsibility of=20 > generating private keys together. > Then if one PKG is compromised, it only affects the parts of users'=20 > private keys and the users' > private keys are still secret. So the security degree of the private=20 > keys and the number of PKGs are increased. I don't understand what you're suggesting here. > > What's the value of this at all? Why not just use certificates. >=20 > I just want to provide an more option for key exchange and user=20 > authentication in some circumstances. I'm not convinced that adding new options is good here. What does this bring to the party. > > The public_parameter_data contains the actual cryptographic > > parameters depending on the specific algorithm. > > Where is this specified. >=20 > The parameters contained in IBE public parameters are specified in RFC = > 5408 and I consulted that specification. > Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms are described in=20 > IBCS (RFC 5091). OK, but you need to describe the actual encoding. Is it an IBESysParams = or what? > > This seems to me to be missing actual support for short-lived keys. > > In order to avoid needing revocation, you need to include a date = string > as part of > > the server's identity. Where is this stored, how is it agreed upon, etc? >=20 > Agree. > I will add a date string into the IDInfo structure in new version. But this makes the real time problem worse, since the client needs to know in advance what keys the server might potentially have, otherwise the server will need to get a new key for each client. -Ekr From ekr@networkresonance.com Fri Jul 24 19:04: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 8B2633A6868 for ; Fri, 24 Jul 2009 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=-1.078, 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, MIME_BASE64_TEXT=1.753, 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 jzRmKAU2Bts0 for ; Fri, 24 Jul 2009 19:04:48 -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 72C663A6781 for ; Fri, 24 Jul 2009 19:04:48 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 008311D1DC1; Fri, 24 Jul 2009 19:07:21 -0700 (PDT) Date: Fri, 24 Jul 2009 19:07:21 -0700 From: Eric Rescorla To: Min Huang In-Reply-To: <001801ca0c33$5149d8e0$909a1b0a@china.huawei.com> References: <20090722042426.378521D0F73@kilo.networkresonance.com> <001801ca0c33$5149d8e0$909a1b0a@china.huawei.com> 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=GB2312 Content-Transfer-Encoding: base64 Message-Id: <20090725020722.008311D1DC1@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-huang-tls-ibe-00 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, 25 Jul 2009 02:04:49 -0000 QXQgRnJpLCAyNCBKdWwgMjAwOSAxNTo0OTo0NyArMDgwMCwNCk1pbiBIdWFuZyB3cm90ZToNCj4g DQo+IA0KPiBoaSwNCj4gDQo+IEVyaWMgUmVzY29ybGEgPGVrciBhdCBuZXR3b3JrcmVzb25hbmNl LmNvbT4gd3JvdGU6DQo+IA0KPiA+QnV0IE1lY2hhbmlzbSAyIGhhcyB0aGUgc2FtZSBpc3N1ZXMg YXMgY2VydGlmaWNhdGVzIGluIHRlcm1zIA0KPiA+b2YgdGhlIHVzZXIgYmVpbmcgYWJsZSB0byBv dmVycmlkZSBpbnZhbGlkIGNyZWRlbnRpYWxzLg0KPiANCj4gTWVjaGFuaXNtIDEgaXMgaW50ZW5k ZWQgdG8gc29sdmUgdGhpcyBwcm9ibGVtLCBpZiB0aGUgY2xpZW50IA0KPiBzZW5kcyB0aGUgcHVi bGljIHBhcmFtZXRlciBzZXRzIGxpc3Qgd2hpY2ggaXQgdHJ1c3RzIHRvIHNlcnZlciwgDQo+IGFu ZCB0aGUgc2VydmVyIG9ubHkgY2FuIGNob29zZSBvbmUgZnJvbSB0aGUgcGFyYW1ldGVyIHNldHMg bGlzdCwgDQo+IHRoZXJlIHdpbGwgYmUgbm8gb3ZlcnJpZGUgaW52YWxpZCBjcmVkZW50aWFscyBw cm9ibGVtcy4gQnV0IGFzIA0KPiB5b3UgbWV0aW9uZWQgYmVmb3JlLCBpdCBicmluZ3Mgc29tZSBv dGhlciBwcm9ibGVtcyB0byBiZSBzb2x2ZWQuDQo+IFNvIG1lY2hhbmlzbSAyIGlzIHByb3ZpZGVk LCBpdCBzZWVtcyBtb3JlIHNpbWlsYXIgdG8gdGhlIHRyYWRpdGlvbmFsIA0KPiBQS0kgbWVjaGFu aXNtLCBidXQgaXQgYWxzbyBoYXMgdGhlIG92ZXJyaWRlIGludmFsaWQgY3JlZGVudGlhbHMgcHJv YmxlbS4NCg0KWWVzLCBteSBwb2ludCBpcyB0aGF0IG1lY2hhbmlzbSAxIGlzIHVud29ya2FibGUg ZXhjZXB0IGluDQp2ZXJ5IGxpbWl0ZWQgYXBwbGljYXRpb25lIHdoZXJlIHlvdSBjb3VsZCBqdXN0 IGFzIHdlbGwNCmhhdmUgdGhlIGNsaWVudCBjb25maWd1cmVkIG5vdCB0byBhbGxvdyBvdmVycmlk ZSBieSB0aGUNCnVzZXIsIGFuZCB0aGF0IG1lY2hhbmlzbSAyIGRvZXMgbm90IGhhdmUgd2hhdCB0 aGlzIGRyYWZ0DQpjbGFpbXMgaXMgdGhlIHByaW1hcnkgYmVuZWZpdCBvZiBJQkUgZm9yIFRMUy4N Cg0KVGhpcyBpc24ndCB0byBzYXkgdGhhdCBJQkUgZm9yIFRMUyBkb2Vzbid0IHdvcmssIGJ1dCBh cw0KZmFyIGFzIEkgY2FuIHRlbGwgaXQgZG9lc24ndCBoYXZlIGFueSByZWFsIGFkdmFudGFnZXMu DQoNCg0KPiA+SSBhZ3JlZSB0aGF0IHRoaXMgYmVuZWZpdCBpcyBub3QgYXBwbGljYWJsZSB0byBU TFMuIEJ1dCBzaW5jZQ0KPiA+dGhhdCdzIHRoZSBtYWluIHRlY2huaWNhbCBiZW5lZml0IG9mIElC RS4uLg0KPiANCj4gSXShr3MgdHJ1ZS4gQnV0IGluIHNvbWUgY2FzZXMsIGl0IGNhbiB3b3JrIHdl bGwuIEZvciBleGFtcGxlLCANCj4gKDEpVGhlIHNlcnZlciBvYnRhaW5zIGl0cyBwcml2YXRlIGtl eSBpbiBhZHZhbmNlIGFuZCB0ZWxscyB0aGUgY2xpZW50IA0KPiB0aGUgY29ycmVzcG9uZGluZyBw dWJsaWMgcGFyYW1ldGVyIHNldCBhbmQgSUQgdG8gYmUgdXNlZCBpbiBrZXlleGNoYW5nZS4gDQo+ IFRoZXJlIGlzIG5vIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBtYWluIGJlbmVmaXQgb2YgSUJFLiAN Cg0KUmlnaHQsIGFuZCBubyBiZW5lZml0IG92ZXIgdGhlIGN1cnJlbnQgUEtJLWJhc2VkIG1lY2hh bmlzbXMuDQoNCg0KPiAoMilUaGUgY2xpZW50IHRlbGxzIHRoZSBwdWJsaWMgcGFyYW1ldGVyIHNl dHMgYW5kIElEIHRvIHRoZSBzZXJ2ZXIgDQo+IGluIGhhbmRzaGFrZSBwcm9jZXNzLiBJZiB0aGVy ZSBpcyBhIHJlYWwgdGltZSBhdXRoZW50aWNhdGlvbiBtZXRob2QgDQo+IHVzZWQgYnkgdGhlIFBL RyB0byBhdXRoZW50aWNhdGUgdGhlIHNlcnZlciBlZmZlY3RpdmVseSwgdGhlbiB0aGUgDQo+IHNl cnZlciBjYW4gb2J0YWluIGl0cyBwcml2YXRlIGtleSBpbiB0aGUgVExTIGhhbmRzaGFrZSBwcm9j ZXNzIA0KPiBpbW1lZGlhdGVseS4NCiAgDQpUaGlzIHNlZW1zIGRpc3RpbmN0bHkgaW1wbGF1c2li bGUuDQoNCg0KPiA+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIHN1Z2dlc3RpbmcgaGVy ZS4NCj4gDQo+IEkgbWVhbnQgdGhhdCBpbiBvbmUgc3BlY2lmaWMgZG9tYWluIHRoZSBudW1iZXIg b2YgUEtHcyBpcyBub3QgbGFyZ2UuIA0KPiBZb3Ugc2FpZCAiQWN0dWFsbHksIGR1ZSB0byB0aGUg dW5pcXVlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgSUJFLCANCj4gSSB3b3VsZCBpbWFnaW5lIHRo ZXJlIHdvdWxkIGJlIG1vcmUgUEtHcyBiZWNhdXNlIHRoZSBhbW91bnQgb2YgDQo+IHRydXN0IHBs YWNlZCBpbiBhIFBLRyBpcyBtdWNoIGhpZ2hlciB0aGFuIGEgQ0EuIiBJIGFtIG5vdCBzdXJlIA0K PiBkbyB5b3UgbWVhbiB0aGF0IHRoZXJlIG11c3QgYmUgbWFueSBQS0dzIHRoYXQgdW5kZXJ0YWtl IHRoZSANCj4gcmVzcG9uc2liaWxpdHkgb2YgZ2VuZXJhdGluZyBhIHVzZXKhr3MgcHJpdmF0ZSBr ZXkgdG9nZXRoZXI/IA0KPiBmb3IgZXhhbXBsZSwgZWFjaCBQS0cganVzdCBzaGFyZXMganVzdCBv bmUgcGllY2Ugb2YgcHJpdmF0ZSBrZXksIA0KPiBhbmQgYSBwcml2YXRlIGtleSBjYW4gYmUgY29t cHV0ZWQgYWZ0ZXIgcHV0dGluZyBhbGwgcGllY2UgdG9nZXRoZXIuDQoNCk5vLCBJIG1lYW4gdGhh dCBzaXRlcyBhcmUgY3VycmVudGx5IHdpbGxpbmcgdG8gdHJ1c3QgVmVyaVNpZ24NCnRvIGlzc3Vl IHRoZWlyIGNlcnRpZmljYXRlcyBiZWNhdXNlIGV2ZW4gYSB0b3RhbCBjb21wcm9taXNlIG9mDQpW ZXJpU2lnbidzIGluZnJhc3RydWN0dXJlIGRvZXNuJ3QgcmV0cm9hY3RpdmVseSBkZXN0cm95IHRo ZQ0Kc2VjdXJpdHkgb2YgdGhlaXIgY29tbXVuaWNhdGlvbnMuIEJ1dCB0aGlzIGlzbid0IHNvIHdp dGggSUJFLA0Kd2hpY2ggbW90aXZhdGVzIG1vcmUgbG9jYWwgUEtHcy4NCg0KDQo+ID5CdXQgdGhp cyBtYWtlcyB0aGUgcmVhbCB0aW1lIHByb2JsZW0gd29yc2UsIHNpbmNlIHRoZSBjbGllbnQgbmVl ZHMNCj4gPnRvIGtub3cgaW4gYWR2YW5jZSB3aGF0IGtleXMgdGhlIHNlcnZlciBtaWdodCBwb3Rl bnRpYWxseSBoYXZlLA0KPiA+b3RoZXJ3aXNlIHRoZSBzZXJ2ZXIgd2lsbCBuZWVkIHRvIGdldCBh IG5ldyBrZXkgZm9yIGVhY2ggY2xpZW50Lg0KPiANCj4gSW4gbWVjaGFuaXNtIDEsIHRoZSBzZXJ2 ZXIgSURzIGxpc3QgaXMgcHJvdmlkZWQgYnkgdGhlIGNsaWVudCBhbmQgDQo+IHRoZXJlIG11c3Qg YmUgYSBwcm9ibGVtIGlmIHRoZSBJRCBjb250YWlucyBhIGRhdGEgc3RyaW5nLiBUaGVyZSANCj4g d2hhdCB0aGV5IG5lZ290aWF0ZSBpcyB0aGUgaWRlbnRpdHkgaW5mb3JtYXRpb24sIGUuZy4sIGVt YWlsIGFkZHJlc3MsIA0KPiBJUCBhZGRyZXNzLCBkb21haW4gbmFtZSBvciBvdGhlciBpZGVudGl0 aWVzIHdoaWNoIGNhbiBiZSB1c2VkIHRvIA0KPiBpbmRpY2F0ZSB0aGUgaWRlbnRpdHkgb2YgdGhl IHNlcnZlci4gVGhpcyBpbmZvcm1hdGlvbiBkb2VzIG5vdCBpbmNsdWRlIA0KPiBhIGRhdGUgc3Ry aW5nLiBUaGUgYWN0dWFsIElEIHVzZWQgdG8gY29tcHV0ZSB0aGUgcHVibGljIGtleSBpcyBwcm92 aWRlZCANCj4gYnkgdGhlIHNlcnZlciBhZnRlciB0aGUgbmVnb3RpYXRpb24uDQoNCkJ1dCB0aGUg Y29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IHRoZXJlJ3Mgbm8gbWVhbmluZ2Z1bCB3YXkgdG8N CmRvIHJldm9jYXRpb24uDQoNCj4gSW4gbWVjaGFuaXNtIDIsIGl0IGlzIG5vdCBhIHByb2JsZW0u IA0KPiBCZWNhdXNlIHRoZSBzZXJ2ZXIgSUQgdXNlZCBpbiBlbmNyeXB0aW9uIGlzIHNlbnQgYnkg dGhlIHNlcnZlci4gU28gaXQgDQo+IGNhbiBkaXJlY3RseSBwcm92aWRlIGEgdmFsaWQgSUQgY29u dGFpbmluZyBhIHZhbGlkIGRhdGUgc3RyaW5nLg0KDQpTdXJlLCBidXQgYWdhaW4gdGhpcyBoYXMg bm8gcmVhbCBiZW5lZml0cyBvdmVyIFBLSS4NCg0KLUVrcg0K From rms@gnu.org Fri Jul 24 21:55: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 124F93A6805; Fri, 24 Jul 2009 21:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 HZlflwsessg8; Fri, 24 Jul 2009 21:55:21 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 284D03A6407; Fri, 24 Jul 2009 21:55:21 -0700 (PDT) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MUZHz-0006Qb-QW; Sat, 25 Jul 2009 00:55:19 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: "Jeffrey A. Williams" In-reply-to: <4A69282D.DA170554@ix.netcom.com> (jwkckid1@ix.netcom.com) References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> <4A69282D.DA170554@ix.netcom.com> Message-Id: Date: Sat, 25 Jul 2009 00:55:19 -0400 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, Nicolas.Williams@sun.com, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 04:55:22 -0000 I have never argued in favor of open source software. I am a free software activist. (See http://www.gnu.org/philosophy/open-source-misses-the-point.html.) From jwkckid1@ix.netcom.com Fri Jul 24 23:41: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 29C423A6975; Fri, 24 Jul 2009 23:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 enYPedNcT-qj; Fri, 24 Jul 2009 23:41:09 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id C967A3A693A; Fri, 24 Jul 2009 23:41:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=t4AwqNyHAY8D3AOr+MG53c3E+w8vKW1UnFYtKFsBp4BJcm4cS0VzFcvm+88TJLSn; 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.99.139] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MUawH-0005rP-Su; Sat, 25 Jul 2009 02:41:02 -0400 Message-ID: <4A6AC417.4175D402@ix.netcom.com> Date: Sat, 25 Jul 2009 01:36:39 -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: rms@gnu.org References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> <4A69282D.DA170554@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606883c5e38e47ea7b20bedebde126ba99a45350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.99.139 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, Nicolas.Williams@sun.com, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 25 Jul 2009 06:41:11 -0000 Richard and all, Open source software for some uses does provide for some utility. By a opposite token, open source software for other uses is an inhearent privacy and security risk for obvious reasons so indeed such also misses the point. I am in favor of any Good free software, but not a proponent of all software being free of course. Free software is the choice of the creator, not of the potential user. Richard Stallman wrote: > I have never argued in favor of open source software. > I am a free software activist. > > (See http://www.gnu.org/philosophy/open-source-misses-the-point.html.) 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 jnc@mercury.lcs.mit.edu Mon Jul 27 09:46:53 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 AAE893A6C79; Mon, 27 Jul 2009 09:46:53 -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=[AWL=0.000, 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 RAGBn0qzh6Ft; Mon, 27 Jul 2009 09:46:53 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CF44B3A6AD5; Mon, 27 Jul 2009 09:46:52 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DB5636BE59A; Mon, 27 Jul 2009 12:46:52 -0400 (EDT) To: ietf@ietf.org, tls@ietf.org Message-Id: <20090727164652.DB5636BE59A@mercury.lcs.mit.edu> Date: Mon, 27 Jul 2009 12:46:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 27 Jul 2009 16:46:53 -0000 > From: Richard Stallman > Generally speaking, standards are useful, because they enable people to > converge what they are doing. But that ceases to be true when the use of > the standard is patented. It is better to have no standard than have a > standard that invites people into danger. But for any standard, there might be a 'submarine' patent (i.e. one not declared to the IETF, which will be sprung once use of the standard is widespread). That standard will have "invite[d] people into danger". Or if I don't like a particular proposed standard, I can say 'hey, I have this patent, and I claim it applies'. (Hey, it's going to take a patent lawyer - or, more formally, a legal proceeding - to _guarantee_ that that threat is smoke, right?) if we have a strict rule about patents, all we've done is created a mechanism which will allow anyone to torpedo a standard they don't like. So what's the answer - no standards at all? Of course not, we take a calculated risk, based on an intuitive cost-benefit analysis, and do the standards. This has to be on a case-by-case basis, really; every situation is a little different. (And sometimes the benefits of an encumbered standard are actually worth the costs. Case in point, the standards which used RSA public-private keysystems.) Noel From jwkckid1@ix.netcom.com Mon Jul 27 15:44:07 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 C2CE73A6CCC for ; Mon, 27 Jul 2009 15:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 bF2GcezRLPig for ; Mon, 27 Jul 2009 15:44:06 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 5AAC13A6CD1 for ; Mon, 27 Jul 2009 15:44:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=e/XIrfbNB9oJL5nSnL64//uXAQcUFkOCMBzk6+XzAgJBdWPUlP8SGqKMtIIf7XjK; 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.103.20] (helo=ix.netcom.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MVYvA-0007CR-Bk; Mon, 27 Jul 2009 18:43:53 -0400 Message-ID: <4A6E48BB.E61C5F41@ix.netcom.com> Date: Mon, 27 Jul 2009 17:39:23 -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: "Wes Beebee (wbeebee)" References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net><20090721195028.GQ1020@Sun.COM><20090722223622.GP1020@Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068808d42a0d634c43ddbe02e003a452e5d3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.20 Cc: ietf-honest@lists.iadl.org, rms@gnu.org, Nicolas Williams , tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard 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, 27 Jul 2009 22:44:07 -0000 Wes and all, Not entirely true here. First use in commerce supersedes any patent if the person of a product that didn't file a patent for it has used it in commerce before another and can prove such that is patenting the product or similar even some types of service has filed the patent and it has been approved. The problem with this scenario is that one may not even know even with a through patent search if such a patent has been filed, not to mention when, and so legal proceedings may ensue as a result, costing both litigants significant $$. Standards should only set basic parameters by which any number of products, in this fora a security product of some sort. Products that exceed the standard parameters should than be considered standardized. Any standard that is set that does not is a bad standard. "Wes Beebee (wbeebee)" wrote: > Many patents are filed for defensive reasons. Ie. If I don't patent it, > then someone else will, and then I won't be able to use the idea I came > up with. The other defensive reason is so that if company A tries to > sue company B for infringing patents, then company B can threaten to sue > company A back - and the end result of the mutual assured destruction is > that no one ends up suing anyone else. In other words, patents can > actually reduce the number of law suits out there. In many cases, > patents are filed long before the technology is standardized - and, if > disclosed properly through the IETF process, can be weighed when > determining whether to adopt a standard. In some cases, the IETF may > choose to adopt a patent-encumbered standard simply because it's > technically superior to other options - and because the encumberence is > not judged to be too much of a barrier to adoption. One great way to > find out if the patent is too much of a barrier would be to label the > technology as "Experimental" with the experiment being whether anybody > would implement it given the patent encumberence, and if enough people > can implement it, striking the right deals, then the technology can move > onto the standards track. > > - Wes > > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Richard Stallman > Sent: Thursday, July 23, 2009 9:38 PM > To: Nicolas Williams > Cc: tls@ietf.org; dean@av8.com; ietf-honest@lists.iadl.org; > ietf@ietf.org > Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying > MaterialExporters for Transport Layer Security (TLS)) to Proposed > Standard > > The operative word here is uncertainty. A patent-holder creates > uncertainty. How should an SDO respond? I'm not sure. I'm only > sure > that I don't like getting DoSed, either into dropping a standard or > into > not implementing it for fear of infringing. > > That's the nature of software patents: each one denies people the > freedom to write and run certain kinds of software. This is why we must > abolish software patents. > > Until we succeed in doing that, we can resist in certain ways. One of > them is to refuse to establish standards that encourage their use. > > Generally speaking, standards are useful, because they enable people to > converge what they are doing. But that ceases to be true when the use > of the standard is patented. It is better to have no standard than have > a standard that invites people into danger. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf-honest mailing list > Ietf-honest@lists.iadl.org > http://lists.iadl.org/mailman/listinfo/ietf-honest 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 rms@gnu.org Mon Jul 27 21:36: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 B3CC73A6C24; Mon, 27 Jul 2009 21:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 jqsCo8QxXFBG; Mon, 27 Jul 2009 21:36:26 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id E470F3A6BD2; Mon, 27 Jul 2009 21:36:25 -0700 (PDT) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MVeQM-0004rN-57; Tue, 28 Jul 2009 00:36:26 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-reply-to: <20090727164652.DB5636BE59A@mercury.lcs.mit.edu> (jnc@mercury.lcs.mit.edu) References: <20090727164652.DB5636BE59A@mercury.lcs.mit.edu> Message-Id: Date: Tue, 28 Jul 2009 00:36:26 -0400 Cc: jnc@mercury.lcs.mit.edu, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 04:36:26 -0000 > Generally speaking, standards are useful, because they enable people to > converge what they are doing. But that ceases to be true when the use of > the standard is patented. It is better to have no standard than have a > standard that invites people into danger. But for any standard, there might be a 'submarine' patent (i.e. one not declared to the IETF, which will be sprung once use of the standard is widespread). That standard will have "invite[d] people into danger". That argument seems to be based on the general premise that "Since we can never be perfectly safe, we should ignore even obvious risks." Or if I don't like a particular proposed standard, I can say 'hey, I have this patent, and I claim it applies'. In theory yes, but it seems unlikely that anyone wants to do this. We should not ignore a real danger to avoid an imaginary one. So what's the answer - no standards at all? Of course not, we take a calculated risk, based on an intuitive cost-benefit analysis, and do the standards. In this case we see a real and specific threat, and we can live without the standard just fine. (And sometimes the benefits of an encumbered standard are actually worth the costs. Case in point, the standards which used RSA public-private keysystems.) Since the patents mostly prevented the use of RSA, there was no room for the standards to do any good, or much harm. From rms@gnu.org Mon Jul 27 21:36: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 8F2483A6C53; Mon, 27 Jul 2009 21:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 EL4twPLTaKvp; Mon, 27 Jul 2009 21:36:43 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id ADAE23A6BD2; Mon, 27 Jul 2009 21:36:43 -0700 (PDT) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MVeQe-0004tw-3u; Tue, 28 Jul 2009 00:36:44 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: "Wes Beebee (wbeebee)" In-reply-to: (wbeebee@cisco.com) References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net><20090721195028.GQ1020@Sun.COM><20090722223622.GP1020@Sun.COM> Message-Id: Date: Tue, 28 Jul 2009 00:36:44 -0400 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, Nicolas.Williams@sun.com, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 04:36:44 -0000 Many patents are filed for defensive reasons. Ie. If I don't patent it, then someone else will, and then I won't be able to use the idea I came up with. The other defensive reason is so that if company A tries to sue company B for infringing patents, then company B can threaten to sue company A back - and the end result of the mutual assured destruction is that no one ends up suing anyone else. In other words, patents can actually reduce the number of law suits out there. If you are claiming that one additional software patent can result in fewer software patent infringement lawsuits, indeed that can sometimes be true. But lawsuits are just the tip of the iceberg of the danger of patents. When people decide not to distribute a program, or not to implement a feature, because they fear they would be sued, no lawsuit occurs, but the patent has done harm. In many cases, patents are filed long before the technology is standardized - and, if disclosed properly through the IETF process, can be weighed when determining whether to adopt a standard. IETF should use this leverage to refuse to issue a standard unless the companies in question allow it to be freely implemented and used. In some cases, the IETF may choose to adopt a patent-encumbered standard simply because it's technically superior to other options That is an example of what not to do. From simon@josefsson.org Tue Jul 28 00: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 A51013A6C8E; Tue, 28 Jul 2009 00:22:28 -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 xd3xfGFcUsrq; Tue, 28 Jul 2009 00:22:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8964E3A6C24; Tue, 28 Jul 2009 00:22:27 -0700 (PDT) Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S7MO5Z028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 09:22:26 +0200 From: Simon Josefsson To: David Morris References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090728:ietf@ietf.org::ciA+/Ccbo0id01DF:6QzL X-Hashcash: 1:22:090728:tls@ietf.org::P0Hx9RN2t9NH72+o:Q+Ew X-Hashcash: 1:22:090728:dwm@xpasc.com::lyWPzW19PnJSZCbh:y5Pk Date: Tue, 28 Jul 2009 09:22:24 +0200 In-Reply-To: (David Morris's message of "Mon, 27 Jul 2009 18:34:54 -0700 (PDT)") Message-ID: <87ljm9w9u7.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 28 Jul 2009 07:22:28 -0000 David Morris writes: > On Thu, 23 Jul 2009, Richard Stallman wrote: > > >> Generally speaking, standards are useful, because they enable people >> to converge what they are doing. But that ceases to be true when the >> use of the standard is patented. It is better to have no standard >> than have a standard that invites people into danger. > > An opinion with which I would differ ... patent encumbered documented > behavior is ALWAYS better than no public documentation for commonly > used protocols. As a person with frequent exposure to the operational > troubleshooting side of networks, lack of accessible documentation is > intolerable. I agree, but I don't see anyone making an argument against that. What the question here is about is to classify this (already accessible) documentation as an Internet Standard. That sends a message that the document is what the IETF recommends to use. There is a significant difference. > There is no trap when an SDO documents a protocol and publishes that > documentation with a caveat that includes documentation of one or more > patent claims related to the published protocol. Any fool who > implements the protocol without resolving those issues deserves what > the get. The trap is the case where the patent or other IP claim isn't > revealed. I believe the problem with this patent disclosure is that it isn't clear what is claimed. People are trying to resolve the issue, and this is what the IETF process is about: we need to evaluate things on a document-by-document basis. Fear of patent claims have been successfully used as arguments to publish documents as Informational instead of Proposed Standard before, compare, e.g., RFC 5054 on TLS-SRP. Thanks, Simon From wbeebee@cisco.com Mon Jul 27 09:52: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 58AA528C31A; Mon, 27 Jul 2009 09:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.322 X-Spam-Level: X-Spam-Status: No, score=-5.322 tagged_above=-999 required=5 tests=[AWL=1.277, 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 zwY5kN-GZKck; Mon, 27 Jul 2009 09:52:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9FFEE28C30E; Mon, 27 Jul 2009 09:51:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFt3bUpAZnme/2dsb2JhbAC7Bogoji0FhAyEDw X-IronPort-AV: E=Sophos;i="4.43,277,1246838400"; d="scan'208";a="52000739" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2009 16:51:06 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6RGp6Ue020613; Mon, 27 Jul 2009 12:51:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RGp6pE011312; Mon, 27 Jul 2009 16:51:06 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 12:51:06 -0400 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, 27 Jul 2009 12:51:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AcoO1u7jVOZGD3RVT0OBvMTmtjwjjAAAjQ1Q References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net><20090721195028.GQ1020@Sun.COM><20090722223622.GP1020@Sun.COM> From: "Wes Beebee (wbeebee)" To: , "Nicolas Williams" X-OriginalArrivalTime: 27 Jul 2009 16:51:06.0712 (UTC) FILETIME=[6F571D80:01CA0EDA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2633; t=1248713466; x=1249577466; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[TLS]=20Last=20Call=3A=20draft-ietf-tls -extractor=20(Keying=20MaterialExporters=20for=20Transport=2 0Layer=20Security=20(TLS))=20to=20Proposed=20Standard |Sender:=20 |To:=20,=20=22Nicolas=20Williams=22=20; bh=xUper2LswPdoKfX3g43sWGGVPkh3gSOfCgCBRjF2Wxs=; b=TQtOaR0Xtwn4Uvr9T0PfNrYdiYSBDjFjZjPGpi6Qcqp4pRrCGnV4C3mOCg 622v2enQpj/RVLeFsStXABLNI/Ag9fRVFtMBV4nAJfHpkHIWlA5JzSONlPiu kIIMRp4nQn; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Tue, 28 Jul 2009 08:09:39 -0700 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 27 Jul 2009 16:52:05 -0000 Many patents are filed for defensive reasons. Ie. If I don't patent it, then someone else will, and then I won't be able to use the idea I came up with. The other defensive reason is so that if company A tries to sue company B for infringing patents, then company B can threaten to sue company A back - and the end result of the mutual assured destruction is that no one ends up suing anyone else. In other words, patents can actually reduce the number of law suits out there. In many cases, patents are filed long before the technology is standardized - and, if disclosed properly through the IETF process, can be weighed when determining whether to adopt a standard. In some cases, the IETF may choose to adopt a patent-encumbered standard simply because it's technically superior to other options - and because the encumberence is not judged to be too much of a barrier to adoption. One great way to find out if the patent is too much of a barrier would be to label the technology as "Experimental" with the experiment being whether anybody would implement it given the patent encumberence, and if enough people can implement it, striking the right deals, then the technology can move onto the standards track. - Wes=20 -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Richard Stallman Sent: Thursday, July 23, 2009 9:38 PM To: Nicolas Williams Cc: tls@ietf.org; dean@av8.com; ietf-honest@lists.iadl.org; ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard The operative word here is uncertainty. A patent-holder creates uncertainty. How should an SDO respond? I'm not sure. I'm only sure that I don't like getting DoSed, either into dropping a standard or into not implementing it for fear of infringing. That's the nature of software patents: each one denies people the freedom to write and run certain kinds of software. This is why we must abolish software patents. Until we succeed in doing that, we can resist in certain ways. One of them is to refuse to establish standards that encourage their use. Generally speaking, standards are useful, because they enable people to converge what they are doing. But that ceases to be true when the use of the standard is patented. It is better to have no standard than have a standard that invites people into danger. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From dwm@xpasc.com Mon Jul 27 18:34:58 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 4A62C3A6AAB; Mon, 27 Jul 2009 18:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 IXXrqFeDwfU9; Mon, 27 Jul 2009 18:34:57 -0700 (PDT) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 8FBAA3A68B9; Mon, 27 Jul 2009 18:34:57 -0700 (PDT) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 039F1100585; Mon, 27 Jul 2009 18:34:56 -0700 (PDT) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.1.9347 $Rev: 9262 $) id iz6Ur97s1yT0; Mon, 27 Jul 2009 18:34:55 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id D85A9100584; Mon, 27 Jul 2009 18:34:55 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id n6S1Ysue001789; Mon, 27 Jul 2009 18:34:54 -0700 Date: Mon, 27 Jul 2009 18:34:54 -0700 (PDT) From: David Morris To: tls@ietf.org, ietf@ietf.org In-Reply-To: Message-ID: References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net> <20090721195028.GQ1020@Sun.COM> <20090722223622.GP1020@Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Propel-ID: iz6Ur97s1yT0 X-Mailman-Approved-At: Tue, 28 Jul 2009 08:09:39 -0700 Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 28 Jul 2009 01:34:58 -0000 On Thu, 23 Jul 2009, Richard Stallman wrote: > Generally speaking, standards are useful, because they enable people > to converge what they are doing. But that ceases to be true when the > use of the standard is patented. It is better to have no standard > than have a standard that invites people into danger. An opinion with which I would differ ... patent encumbered documented behavior is ALWAYS better than no public documentation for commonly used protocols. As a person with frequent exposure to the operational troubleshooting side of networks, lack of accessible documentation is intolerable. There is no trap when an SDO documents a protocol and publishes that documentation with a caveat that includes documentation of one or more patent claims related to the published protocol. Any fool who implements the protocol without resolving those issues deserves what the get. The trap is the case where the patent or other IP claim isn't revealed. From dean@av8.com Tue Jul 28 10:58:04 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 5FC263A6D15; Tue, 28 Jul 2009 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] 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 WeQuxGsChGVU; Tue, 28 Jul 2009 10:58:03 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 383293A6CD1; Tue, 28 Jul 2009 10:58:03 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n6SHvv3d014271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Jul 2009 13:57:58 -0400 Date: Tue, 28 Jul 2009 13:57:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Wes Beebee (wbeebee)" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, rms@gnu.org, Nicolas Williams , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 28 Jul 2009 17:58:04 -0000 On Mon, 27 Jul 2009, Wes Beebee (wbeebee) wrote: > Many patents are filed for defensive reasons. Ie. If I don't patent it, > then someone else will, and then I won't be able to use the idea I came > up with. The other defensive reason is so that if company A tries to > sue company B for infringing patents, then company B can threaten to sue > company A back - and the end result of the mutual assured destruction is > that no one ends up suing anyone else. What you say is true, and is basically why the LPF accepts mutually defensive patents. http://www.progfree.org/Patents/mutual-def.html Of course, they key is the nonagression policy and the universal free license. But the above just recognizes the realities imposed by the laws of an unfair patent system. Patents (mutally defensive) are better than no patents whatsoever. While publication and prior are helpful, the law gives (unfairly we argue) benefits to patent holders including mutually defensive patent holders. So, there is still a reason to change the law on patents. These mutually defensive patents are still expensive, and must still be defended to some extent: e.g. against an agressive patent holder of an overlapping patent who seeks to enjoin against the mut-def patent application. I think there are two reasons for the IETF to consider patented technology: First, I think the IETF is made up of a majority of people who are anti-patent in their views. But industry players who are agressively pro-patent (as we have seen) also participate, and it seems (strangely) control the leadership. Despite the actions of the IESG silencing critics, the IETF does not actually have a right to deny participation to those players who merely disagree with the majority. To do so is a violation of the Hobbs Act on democratic participation, and a violation of anti-trust laws. Morally, it would just be wrong to deny participation to the opposition. We have to respect the rights of the opposition to participate, even when they don't respect our right to participate. Second, Truly novel, superior patents are very, very rare. The example I hold up is the (hypothetical) patenting of the fast fourier transform (FFT). The FFT is so superior and so novel in signal processing, that if it were patented people doing signal processing would have no choice but to standardize it and pay whatever fees were demanded. If something like that happened, it would be a very, very sad day. But that possibility it is really just another reason to change the law on patents. But fortunately, I haven't seen that level of novelty and superiority in any patented technology so far proposed to the IETF. Most patent technology I have seen so far proposed to the IETF is either not very novel and/or not very superior and, most significant to a standarization decision, is easily replaced by non-patented technology. In the case the IETF approves a patented standard, I would hope that the IETF only does so for a mutually defensive patent, or only in the case were something is so novel and so superior as to be like the FFT to signals and systems analysis. Anything less seems like a very poor choice. So the IETF /can/ make a decision to approve a patented technology. But of course, mere procedural ability to approve a patented technology is no reason to approve a non-free patented technology that is easily replaced by non-patented technology. We should make intelligent and informed decisions. --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 Jul 28 11:04: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 7B5F93A6D95 for ; Tue, 28 Jul 2009 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 E0h9PfmWOL3v for ; Tue, 28 Jul 2009 11:04:37 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 7CAAF3A6D76 for ; Tue, 28 Jul 2009 11:04:37 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n6SI4YAs014295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Jul 2009 14:04:35 -0400 Date: Tue, 28 Jul 2009 14:04:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Jeffrey A. Williams" In-Reply-To: <4A6E48BB.E61C5F41@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Wes Beebee \(wbeebee\)" , ietf-honest@lists.iadl.org, rms@gnu.org, Nicolas Williams , tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard 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, 28 Jul 2009 18:04:38 -0000 On Mon, 27 Jul 2009, Jeffrey A. Williams wrote: > Wes and all, > > Not entirely true here. First use in commerce supersedes any > patent if the person of a product that didn't file a patent for it has > used it in commerce before another and can prove such that is Not under a first-to-file regime, which the US is changing to, and the rest of the world uses now. First-to-file will still deny patents on established prior art and non-novel inventions, but places limits. I've heard variously that any prior-art less than a year prior will be excluded from invalidating a first-to-file patent. One really does have to race to the patent office. And of course, the big companies with army of patent lawyers and camps outside the patent office will win that race most of the time. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jwkckid1@ix.netcom.com Tue Jul 28 17:06: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 A51D43A6C91 for ; Tue, 28 Jul 2009 17:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1D7iz1SxJuk for ; Tue, 28 Jul 2009 17:06:09 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 7BFFD3A67F3 for ; Tue, 28 Jul 2009 17:06:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=rOvPxRKDgZKnmkYo9x06kSbcN9arXfMubO3BWrKG+TXj+S54NtQAM6IQrdmhcYjR; 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.96.196] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MVwft-0008AP-0R; Tue, 28 Jul 2009 20:06:05 -0400 Message-ID: <4A6FACEB.14794710@ix.netcom.com> Date: Tue, 28 Jul 2009 18:59:07 -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: Dean Anderson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688295a8e382a0e41bae858f723778e0a20350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.196 Cc: "Wes Beebee \(wbeebee\)" , ietf-honest@lists.iadl.org, rms@gnu.org, Nicolas Williams , tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard 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, 29 Jul 2009 00:06:10 -0000 Dean and all, No offense Dean but I think you miss read or miss understood my previous response. I wasn't suggesting of talking about a prior filing of a patent or even a patent on a similar product or service, but the USE of a similar, even confusingly similar product or process that had or has prior USE AND was never filed for patent protection. The LAN ham act has yet to be amended as you suggest BTW, although there has been legislation that would amend the Lanham Act as you suggest, but it has little support currently. Dean Anderson wrote: > On Mon, 27 Jul 2009, Jeffrey A. Williams wrote: > > > Wes and all, > > > > Not entirely true here. First use in commerce supersedes any > > patent if the person of a product that didn't file a patent for it has > > used it in commerce before another and can prove such that is > > Not under a first-to-file regime, which the US is changing to, and the > rest of the world uses now. First-to-file will still deny patents on > established prior art and non-novel inventions, but places limits. I've > heard variously that any prior-art less than a year prior will be > excluded from invalidating a first-to-file patent. > > One really does have to race to the patent office. And of course, the > big companies with army of patent lawyers and camps outside the patent > office will win that race most of the time. > > --Dean > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 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 dean@av8.com Wed Jul 29 11:19: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 AF0003A6AAF for ; Wed, 29 Jul 2009 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuv0S-POdqx3 for ; Wed, 29 Jul 2009 11:19:47 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 5A6613A68BF for ; Wed, 29 Jul 2009 11:19: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 n6TIJi8V018476 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Jul 2009 14:19:47 -0400 Date: Wed, 29 Jul 2009 14:19:43 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Jeffrey A. Williams" In-Reply-To: <4A6FACEB.14794710@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard 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, 29 Jul 2009 18:19:48 -0000 I think I understood what you are saying. Under first-to-invent, such use establishes priority. Under first-to-file, it doesn't---or rather, its limited in how it does. As I understand it, under the first-to-file changes (which we are obligated to make under GATT treaty), First use, prior art, and actual invention, don't matter as much as they did previously. Under the new system, inventors (those who can prove they are inventors as before) are grandfathered under first-to-file. The grandfather law was passed some years ago--I can't recall offhand what it was called. Inventors (who could have previously invalidated the other patent and/or obtained their own patent under the old first-to-invent regime), are now granted the privilege to use, but not sell or license, the technology they invented, but that someone else filed a patent on first. I don't believe the Lanham act stands in the way of a change from first-to-invent to first-to-file. Already there is a range of activity that falls somewhere between misuse and anti-trust violation. But its probably worth more investigation. I think in principle, anti-trust is a argument against having patents, but at present, anti-trust law is not usually sufficient to overturn patents. Use during patent-pending period is ok, but would be prevented after the patnent is approved. I think the only thing that prior commercial use is good for is establishing proof of prior art and prior invention, and these factors are going to be limited in the near future. --Dean On Tue, 28 Jul 2009, Jeffrey A. Williams wrote: > Dean and all, > > No offense Dean but I think you miss read or miss understood my > previous response. I wasn't suggesting of talking about a prior > filing of a patent or even a patent on a similar product or service, > but the USE of a similar, even confusingly similar product or process > that had or has prior USE AND was never filed for patent protection. > The LAN ham act has yet to be amended as you suggest BTW, although > there has been legislation that would amend the Lanham Act as you > suggest, but it has little support currently. > > Dean Anderson wrote: > > > On Mon, 27 Jul 2009, Jeffrey A. Williams wrote: > > > > > Wes and all, > > > > > > Not entirely true here. First use in commerce supersedes any > > > patent if the person of a product that didn't file a patent for it has > > > used it in commerce before another and can prove such that is > > > > Not under a first-to-file regime, which the US is changing to, and the > > rest of the world uses now. First-to-file will still deny patents on > > established prior art and non-novel inventions, but places limits. I've > > heard variously that any prior-art less than a year prior will be > > excluded from invalidating a first-to-file patent. > > > > One really does have to race to the patent office. And of course, the > > big companies with army of patent lawyers and camps outside the patent > > office will win that race most of the time. > > > > --Dean > > > > -- > > Av8 Internet Prepared to pay a premium for better service? > > www.av8.net faster, more reliable, better service > > 617 344 9000 > > 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 > > _______________________________________________ > Ietf-honest mailing list > Ietf-honest@lists.iadl.org > http://lists.iadl.org/mailman/listinfo/ietf-honest > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From lrosen@rosenlaw.com Wed Jul 29 11:42: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 C4F523A70CA for ; Wed, 29 Jul 2009 11:42:12 -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 lVEOb7mM-8n4 for ; Wed, 29 Jul 2009 11:42:11 -0700 (PDT) Received: from rosenlaw.com (rosenlaw.com [192.220.47.202]) by core3.amsl.com (Postfix) with ESMTP id 91AAB3A70F5 for ; Wed, 29 Jul 2009 11:42:11 -0700 (PDT) Received: (qmail 38905 invoked by uid 12234); 29 Jul 2009 18:42:11 -0000 Received: from unknown (HELO Lawrencei) ([70.210.145.0]) (envelope-sender ) by 192.220.47.202 (qmail-ldap-1.03) with SMTP for ; 29 Jul 2009 18:42:11 -0000 From: "Lawrence Rosen" To: , "'Wes Beebee \(wbeebee\)'" References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net><20090721195028.GQ1020@Sun.COM><20090722223622.GP1020@Sun.COM> In-Reply-To: Date: Wed, 29 Jul 2009 11:41:58 -0700 Message-ID: <00cc01ca107c$439c0d10$cad42730$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQZib4LlOa+OlaTlGBR7naPZIlfgAFLglg Content-Language: en-us X-Mailman-Approved-At: Wed, 29 Jul 2009 11:44:44 -0700 Cc: ietf-honest@lists.iadl.org, tls@ietf.org, Nicolas.Williams@sun.com, ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard 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, 29 Jul 2009 18:42:13 -0000 I agree completely with Richard Stallman's responses to an earlier email. I repeat the relevant parts of that earlier exchange below. This reflects a basic policy that should be adopted by IETF. /Larry Rosen ********************* Email from RMS: If you are claiming that one additional software patent can result in fewer software patent infringement lawsuits, indeed that can sometimes be true. But lawsuits are just the tip of the iceberg of the danger of patents. When people decide not to distribute a program, or not to implement a feature, because they fear they would be sued, no lawsuit occurs, but the patent has done harm. In many cases, patents are filed long before the technology is standardized - and, if disclosed properly through the IETF process, can be weighed when determining whether to adopt a standard. IETF should use this leverage to refuse to issue a standard unless the companies in question allow it to be freely implemented and used. In some cases, the IETF may choose to adopt a patent-encumbered standard simply because it's technically superior to other options That is an example of what not to do. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Richard Stallman Sent: Monday, July 27, 2009 9:37 PM To: Wes Beebee (wbeebee) Cc: dean@av8.com; ietf-honest@lists.iadl.org; tls@ietf.org; Nicolas.Williams@sun.com; ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard From paul.hoffman@vpnc.org Wed Jul 29 12:34: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 A66DA3A6B5F; Wed, 29 Jul 2009 12:34:22 -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 up3m2ogjUzwD; Wed, 29 Jul 2009 12:34:22 -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 982D13A6E4F; Wed, 29 Jul 2009 12:34:21 -0700 (PDT) Received: from [10.20.30.158] ([77.241.97.116]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TJYDd5091243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 12:34:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090720164816.328D928C1C8@core3.amsl.com> References: <20090720164816.328D928C1C8@core3.amsl.com> Date: Wed, 29 Jul 2009 21:34:09 +0200 To: ietf@ietf.org, IETF-Announce From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard 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, 29 Jul 2009 19:34:22 -0000 At 9:48 AM -0700 7/20/09, The IESG wrote: >The IESG has received a request from the Transport Layer Security WG >(tls) to consider the following document: > >- 'Keying Material Exporters for Transport Layer Security (TLS) ' > as a Proposed Standard Given the recent discussion, I continue to support the publication of this document as a Standards Track RFC. --Paul Hoffman, Director --VPN Consortium From jwkckid1@ix.netcom.com Wed Jul 29 18:00: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 DA9F73A6B4C; Wed, 29 Jul 2009 18:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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 YSQ31PSjKzGD; Wed, 29 Jul 2009 18:00:47 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id CF9E63A6B4A; Wed, 29 Jul 2009 18:00:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mrwD5QWAOhL5Yj2m4zscde0o0pr7MkUWM7HEoQIn12X+NLoOr6dbGs/KjcPppnGC; 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.97.143] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWK0j-0006TW-TN; Wed, 29 Jul 2009 21:00:46 -0400 Message-ID: <4A710BCB.D1E45556@ix.netcom.com> Date: Wed, 29 Jul 2009 19:56:11 -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: Lawrence Rosen References: <026364d64021d6cef8b930cf16df1221.squirrel@www.trepanning.net><20090721195028.GQ1020@Sun.COM><20090722223622.GP1020@Sun.COM> <00cc01ca107c$439c0d10$cad42730$@com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688837ee7039528c3f799b4b4cdcc0bc238350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.143 Cc: "'Wes Beebee \(wbeebee\)'" , ietf@ietf.org, Nicolas.Williams@sun.com, ietf-honest@lists.iadl.org, tls@ietf.org, rms@gnu.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor(Keying MaterialExporters for Transport Layer Security (TLS))to Proposed Standard 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, 30 Jul 2009 01:00:47 -0000 Larry and all, I agree with your conclusion here Larry! Well done! But what will determine what precisely will be that standard, if any, and if not standard is determined as a result or otherwise, how will full interoperability be accomplished? Lawrence Rosen wrote: > I agree completely with Richard Stallman's responses to an earlier email. I > repeat the relevant parts of that earlier exchange below. This reflects a > basic policy that should be adopted by IETF. > /Larry Rosen > > ********************* Email from RMS: > > If you are claiming that one additional software patent can result in fewer > software patent infringement lawsuits, indeed that can sometimes be true. > But lawsuits are just the tip of the iceberg of the danger of patents. > > When people decide not to distribute a program, or not to implement a > feature, because they fear they would be sued, no lawsuit occurs, but the > patent has done harm. > > In many cases, > patents are filed long before the technology is standardized - and, if > disclosed properly through the IETF process, can be weighed when > determining whether to adopt a standard. > > IETF should use this leverage to refuse to issue a standard unless the > companies in question allow it to be freely implemented and used. > > In some cases, the IETF may > choose to adopt a patent-encumbered standard simply because it's > technically superior to other options > > That is an example of what not to do. > > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Richard Stallman > Sent: Monday, July 27, 2009 9:37 PM > To: Wes Beebee (wbeebee) > Cc: dean@av8.com; ietf-honest@lists.iadl.org; tls@ietf.org; > Nicolas.Williams@sun.com; ietf@ietf.org > Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying > MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard > > > _______________________________________________ > 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 jsalowey@cisco.com Thu Jul 30 00:54: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 679433A69A0 for ; Thu, 30 Jul 2009 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 XvayHErbKdKj for ; Thu, 30 Jul 2009 00:54:13 -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 A7A823A6E1D for ; Thu, 30 Jul 2009 00:54:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAATucEqrR7MV/2dsb2JhbAC5XYgnkBIFhBE X-IronPort-AV: E=Sophos;i="4.43,293,1246838400"; d="scan'208";a="356870783" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2009 07:54:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6U7sFN5019311 for ; Thu, 30 Jul 2009 00:54:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6U7sFHI008329 for ; Thu, 30 Jul 2009 07:54:15 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 00:54:15 -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: Thu, 30 Jul 2009 00:54:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-75 presentations Thread-Index: AcoQ6u39q1BIfvYVQFCw3Y5aJgTcjQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 30 Jul 2009 07:54:15.0412 (UTC) FILETIME=[EF260B40:01CA10EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=110; t=1248940455; x=1249804455; c=relaxed/simple; s=sjdkim1004; 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:=20IETF-75=20presentations |Sender:=20; bh=0QZTfdz2GKFNMrV2thb1dVd5J9tpM3sZwbNwV2B30bA=; b=I0eXdgKCp45LEw0jjI8h/mBYUjSnYYUo4A6AuWn5gCOO9DDPiRI2+UXS6J 7HYGAphzmeZiFSBzFt9qSGFrZ12BmmmAulQGDyrcsYZmchAncGejv0RFv3on JLWaqhOqdJsV0usWCmZBtCN5uNv8/cCMfFCLfKdDDI9u56IAIznrc=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [TLS] IETF-75 presentations 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, 30 Jul 2009 07:54:14 -0000 If you are presenting Friday and have slides, please send them to me as soon as possible. Thanks, Joe From cfinss@dial.pipex.com Thu Jul 30 07:33: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 B5BE13A700A; Thu, 30 Jul 2009 07:33:28 -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.098, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 A2ZKdsSUx7Cp; Thu, 30 Jul 2009 07:33:26 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 1489F3A6C50; Thu, 30 Jul 2009 07:33:25 -0700 (PDT) X-Trace: 237566643/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.16/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.16 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAPtLcUo+vGkQ/2dsb2JhbABEgmk8jFjCdQIHgi6BWgU X-IronPort-AV: E=Sophos;i="4.43,295,1246834800"; d="scan'208";a="237566643" X-IP-Direction: IN Received: from 1cust16.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.16]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Jul 2009 15:33:23 +0100 Message-ID: <000401ca111a$3bb01da0$0601a8c0@allison> From: "tom.petch" To: "Gerhard Muenz" , , , References: <4A6EB9BB.9040002@net.in.tum.de> Date: Thu, 30 Jul 2009 11:44:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Michael Tuexen , Daniel Mentz Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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, 30 Jul 2009 14:33:28 -0000 Gerhard Thank you for pointing this out; it had escaped me. What I had thought though was that the lack of flow control with DTLS over UDP is a problem, and that the lack of this with syslog over UDP led the syslog RFC [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as might be expected, syslog over UDP. This in turn led me to expect that syslog over DTLS over UDP would not be acceptable to the IESG, rather that syslog over DTLS over SCTP would become the RECOMMENDED transport. So; several thoughts. This is an update to the extensions RFC, RFC4366, which itself is being updated by the TLS working group (hence my addition of them to the list) and I would much rather have one extensions RFC rather than several. This is a good concept and fills a need; perhaps the TLS working group would take this on. Flow control remains an issue which I do not think that this extension addresses. Is this a security exposure? or just, like syslog over UDP, an inconvenient truth? The petch-gerhards draft allows the recipient of the unidirectional flow to initiate the DTLS 'connection', and so enables it to re-establish the connection when anything goes wrong. This would seem an alternative to consider. Tom Petch ----- Original Message ----- From: "Gerhard Muenz" To: ; Cc: "Michael Tuexen" ; "Robin Seggelmann" ; "Daniel Mentz" Sent: Tuesday, July 28, 2009 10:41 AM Subject: [Syslog] Missing dead peer detection in DTLS Hi, This mail goes to the ipfix and syslog mailing lists in order to summarize the common issues regarding DTLS. IPFIX specifies support of DTLS as mandatory for transport over UDP and SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for transport over UDP. In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we will have a first implementation of IPFIX-over-DTLS/SCTP very soon. During this implementation effort, we found that the current specification of DTLS/UDP has a severe flaw when used with unidirectional protocols (like IPFIX): The sender cannot recognize if the receiver has crashed and lost the DTLS state. We discuss this issue in a draft: http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf I've had a look at draft-feng-syslog-transport-dtls-01 and draft-petch-gerhards-syslog-transport-dtls-02. It seems that this problem has not yet been covered, although the problem should be the same for SYSLOG. As a solution, the DTLS Heartbeat Extension has been proposed very recently: http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 A feature patch for OpenSSL is available: http://sctp.fh-muenster.de/dtls-patches.html#features So, I think that we should support this standardization initiative as it solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can specify that the DTLS Heartbeat Extension MUST be implemented. Dan suggested to have a single document solving the DTLS issues regarding unidirectional protocols. I think that such a document is not needed if we have DTLS Heartbeat Extension. Regards, Gerhard Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universität München Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From tuexen@fh-muenster.de Thu Jul 30 08:24: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 60A2F28C2BD; Thu, 30 Jul 2009 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-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 xvsLWZHE1sxn; Thu, 30 Jul 2009 08:24:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5ED5D3A6B22; Thu, 30 Jul 2009 08:24:23 -0700 (PDT) Received: from [IPv6:2001:df8::16:224:36ff:feef:67d1] (unknown [IPv6:2001:df8:0:16:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 4B7141C0B4629; Thu, 30 Jul 2009 17:24:21 +0200 (CEST) From: Michael Tuexen To: "tom.petch" In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison> X-Priority: 3 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 17:24:20 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Thu, 30 Jul 2009 08:39:23 -0700 Cc: ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog@ietf.org, tls@ietf.org Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS 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, 30 Jul 2009 15:24:39 -0000 Hi Tom, a question in-line. Best regards Michael On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with =20 > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the =20= > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as =20= > might be > expected, syslog over UDP. So I think it is actually congestion control what you are looking for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? > > This in turn led me to expect that syslog over DTLS over UDP would =20 > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would =20= > become the > RECOMMENDED transport. This would mean, that * SYSLOG/TLS/TCP/IP * SYSLOG/DTLS/SCTP/IP * SYSLOG/DTLS/DCCP/IP are in principle acceptable, whereas * SYSLOG/DTLS/UDP/IP is not. You would (from the congestion control perspective) have the same classification when taking out the DTLS or TLS layer, right? > > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is =20 > being updated > by the TLS working group (hence my addition of them to the list) and =20= > I would > much rather have one extensions RFC rather than several. This is a =20= > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. > > Is this a security exposure? or just, like syslog over UDP, an =20 > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional =20= > flow to > initiate the DTLS 'connection', and so enables it to re-establish =20 > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch > > ----- Original Message ----- > From: "Gerhard Muenz" > To: ; > Cc: "Michael Tuexen" ; "Robin Seggelmann" > ; "Daniel Mentz" > Sent: Tuesday, July 28, 2009 10:41 AM > Subject: [Syslog] Missing dead peer detection in DTLS > > > Hi, > > This mail goes to the ipfix and syslog mailing lists in order to > summarize the common issues regarding DTLS. > > IPFIX specifies support of DTLS as mandatory for transport over UDP =20= > and > SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for > transport over UDP. > > In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and =20= > we > will have a first implementation of IPFIX-over-DTLS/SCTP very soon. > During this implementation effort, we found that the current > specification of DTLS/UDP has a severe flaw when used with > unidirectional protocols (like IPFIX): The sender cannot recognize if > the receiver has crashed and lost the DTLS state. > > We discuss this issue in a draft: > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 > http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf > > I've had a look at draft-feng-syslog-transport-dtls-01 and > draft-petch-gerhards-syslog-transport-dtls-02. It seems that this > problem has not yet been covered, although the problem should be the > same for SYSLOG. > > As a solution, the DTLS Heartbeat Extension has been proposed very =20 > recently: > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 > A feature patch for OpenSSL is available: > http://sctp.fh-muenster.de/dtls-patches.html#features > > So, I think that we should support this standardization initiative =20 > as it > solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can > specify that the DTLS Heartbeat Extension MUST be implemented. > > Dan suggested to have a single document solving the DTLS issues > regarding unidirectional protocols. I think that such a document is =20= > not > needed if we have DTLS Heartbeat Extension. > > Regards, > Gerhard > > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > > From bhargava.yenduri@sun.com Thu Jul 30 11:04:18 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 553443A71A6 for ; Thu, 30 Jul 2009 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 2pvNiCs6XIjr for ; Thu, 30 Jul 2009 11:04:17 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id D6F4B3A71EB for ; Thu, 30 Jul 2009 11:03:36 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6UI3cIj015630 for ; Thu, 30 Jul 2009 18:03:38 GMT Received: from [129.150.13.106] (vpn-129-150-13-106.SFBay.Sun.COM [129.150.13.106]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6UI3cau371759 for ; Thu, 30 Jul 2009 11:03:38 -0700 (PDT) Message-ID: <4A71E060.3090000@sun.com> Date: Thu, 30 Jul 2009 11:03:12 -0700 From: Krishna Yenduri User-Agent: Thunderbird 2.0.0.12 (X11/20080325) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] TLS 1.1/1.2 CLI clients 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, 30 Jul 2009 18:04:18 -0000 Hi, I am looking for any command line (non-browser) tools that support client side TLS 1.2 or TLS 1.1. Please let me know if you know of any such tool. Thanks, -Krishna From stefan@aaa-sec.com Fri Jul 31 04:46: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 3380B3A69DA for ; Fri, 31 Jul 2009 04:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQDD1aHm+M9l for ; Fri, 31 Jul 2009 04:46:30 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 0D6533A6D64 for ; Fri, 31 Jul 2009 04:46:25 -0700 (PDT) Received: (qmail 15921 invoked from network); 31 Jul 2009 11:46:24 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 31 Jul 2009 11:46:24 -0000 Received: (qmail 92766 invoked from network); 31 Jul 2009 11:46:19 -0000 Received: from dhcp-15f1.meeting.ietf.org (HELO [130.129.21.241]) (stefan@fiddler.nu@[130.129.21.241]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Jul 2009 11:46:19 -0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 31 Jul 2009 13:46:19 +0200 From: Stefan Santesson To: TLS wg Message-ID: Thread-Topic: Comments on cached info at TLS meeting Thread-Index: AcoR1ISq1JdPWHfMEE23Lw3azRBGIQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331892779_16320993" Subject: [TLS] Comments on cached info at TLS meeting 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, 31 Jul 2009 11:46:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331892779_16320993 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Recap of comments on cached info during the IETF meeting in Stockholm. Simon thought that it would be OK to send just the hash as replacement for the cached data if the client treats the hash as an index that identifies the replaced data. Doing so avoids guessing by the client. A clarification should be made in the draft. Eric made a comment on Jabber that =B3now that I see this problem suggested, this seems pretty gross from an implementation perspective. I think I'd prefer that the cache hits be returned explicitly in the extension=B2 I interpret this to mean that Eric wants the server to acknowledge exactly what data it will replace when it sends its server hello. This means that we have different opinions on the list whether the server have to know what data it will replace at server hello exchange. I=B9m personally pretty agnostic about this, but we need to agree on one approach. Other than that it was suggested that other objects could be of interest to define in the draft. We may see proposals on the list. /Stefan --B_3331892779_16320993 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Comments on cached info at TLS meeting Recap of comments on cached info during the IETF meeting in Stockholm.

Simon thought that it would be OK to send just the hash as replacement for = the cached data if the client treats the hash as an index that identifies th= e replaced data. Doing so avoids guessing by the client. A clarification sho= uld be made in the draft.

Eric made a comment on Jabber that “now that I see this problem sugge= sted, this seems pretty gross from an implementation perspective. I think I'= d prefer that the cache hits be returned explicitly in the extension”<= BR>
I interpret this to mean that Eric wants the server to acknowledge exactly = what data it will replace when it sends its server hello.
This means that we have different opinions on the list whether the server h= ave to know what data it will replace at server hello exchange.
I’m personally pretty agnostic about this, but we need to agree on on= e approach.

Other than that it was suggested that other objects could be of interest to=  define in the draft. We may see proposals on the list.

/Stefan --B_3331892779_16320993-- From william.polk@nist.gov Fri Jul 31 05:13: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 3A5023A6B51 for ; Fri, 31 Jul 2009 05:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.707 X-Spam-Level: X-Spam-Status: No, score=-6.707 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 JXZiMEftAfYt for ; Fri, 31 Jul 2009 05:13:12 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6CA2F3A694D for ; Fri, 31 Jul 2009 05:13:12 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6VCDK9Y011058 for ; Fri, 31 Jul 2009 08:13:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Fri, 31 Jul 2009 08:13:08 -0400 From: "Polk, William T." To: "tls@ietf.org" Date: Fri, 31 Jul 2009 08:13:08 -0400 Thread-Topic: TLS working group and authorization Thread-Index: AQHKEdhDvtPcLDcdsUW82wftMJQGug== Message-ID: 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Fri, 31 Jul 2009 05:13:49 -0700 Subject: [TLS] TLS working group and authorization 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, 31 Jul 2009 12:13:13 -0000 On April 15, I set the substate on draft-housley-tls-authz-extns to "Extern= al Party" with the following comment:=20 Waiting for TLS working group to decide whether they wish to take on w= ork in this space. Based on email traffic, agenda time, and the lack of new I-D submissions I = have concluded that TLS is not interested in pursuing a standards track document. Accordingly, I have ten= tatively placed the document on the=20 8-14 telechat agenda. If you wish to inform me about progress otherwise in= visible to me, please contact me before the telechat. Thanks, Tim Polk= From jwkckid1@ix.netcom.com Fri Jul 31 05:34: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 534FE3A6E2E for ; Fri, 31 Jul 2009 05:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 IOA8yMs1oZ7H for ; Fri, 31 Jul 2009 05:34:44 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 3FC123A6E71 for ; Fri, 31 Jul 2009 05:34:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=FubfEqbXy6Th8nONfT9eRhjfljmX1qN0evGNVHPwFWLjkeT6Cisc51u/dSZQ1OWj; 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.101.34] (helo=ix.netcom.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWrJZ-0000vB-NX; Fri, 31 Jul 2009 08:34:26 -0400 Message-ID: <4A72E4C1.5B36E2CB@ix.netcom.com> Date: Fri, 31 Jul 2009 05:34:10 -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: Stefan Santesson References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688a40ccb21b7dec86562734381bfd2ff10350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.101.34 Cc: TLS wg Subject: Re: [TLS] Comments on cached info at TLS meeting 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, 31 Jul 2009 12:34:45 -0000 Stefan and all, Thanks for the update. I agree that there needs to be only one approach. Stefan Santesson wrote: > Recap of comments on cached info during the IETF meeting in Stockholm. > > Simon thought that it would be OK to send just the hash as replacement > for the cached data if the client treats the hash as an index that > identifies the replaced data. Doing so avoids guessing by the client. > A clarification should be made in the draft. > > Eric made a comment on Jabber that “now that I see this problem > suggested, this seems pretty gross from an implementation perspective. > I think I'd prefer that the cache hits be returned explicitly in the > extension” > > I interpret this to mean that Eric wants the server to acknowledge > exactly what data it will replace when it sends its server hello. > This means that we have different opinions on the list whether the > server have to know what data it will replace at server hello > exchange. > I’m personally pretty agnostic about this, but we need to agree on one > approach. > > Other than that it was suggested that other objects could be of > interest to define in the draft. We may see proposals on the list. > > /Stefan > > ---------------------------------------------------------------- > _______________________________________________ > 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 simon@josefsson.org Fri Jul 31 07:00: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 742D628C28E for ; Fri, 31 Jul 2009 07:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 qPAb+Icg0vlJ for ; Fri, 31 Jul 2009 07:00:31 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5A59E3A6B6E for ; Fri, 31 Jul 2009 07:00:30 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6VE0S6H030446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2009 16:00:30 +0200 From: Simon Josefsson To: "Polk\, William T." References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090731:tls@ietf.org::AZrPqM8dhSqQWUy3:3RpB X-Hashcash: 1:22:090731:william.polk@nist.gov::0uLhEm4KATRNgIjG:BhL4 Date: Fri, 31 Jul 2009 16:00:28 +0200 In-Reply-To: (William T. Polk's message of "Fri, 31 Jul 2009 08:13:08 -0400") Message-ID: <87prbhosub.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: "tls@ietf.org" Subject: Re: [TLS] TLS working group and authorization 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, 31 Jul 2009 14:00:32 -0000 "Polk, William T." writes: > On April 15, I set the substate on draft-housley-tls-authz-extns to "External Party" with the following comment: > > Waiting for TLS working group to decide whether they wish to take on work in this space. > > Based on email traffic, agenda time, and the lack of new I-D submissions I have concluded that TLS is not > interested in pursuing a standards track document. Accordingly, I have tentatively placed the document on the > 8-14 telechat agenda. If you wish to inform me about progress otherwise invisible to me, please contact me > before the telechat. What is the intended status for the document this time? /Simon From stefan@aaa-sec.com Fri Jul 31 11:26: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 7A0323A6CE6 for ; Fri, 31 Jul 2009 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.524, 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 nNdb8x2jeefF for ; Fri, 31 Jul 2009 11:25:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 44E5F3A6CDD for ; Fri, 31 Jul 2009 11:25:58 -0700 (PDT) Received: (qmail 37344 invoked from network); 31 Jul 2009 18:26:05 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 31 Jul 2009 18:26:05 -0000 Received: (qmail 357 invoked from network); 31 Jul 2009 18:25:57 -0000 Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.97]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Jul 2009 18:25:57 -0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 31 Jul 2009 20:25:56 +0200 From: Stefan Santesson To: Simon Josefsson , "Polk, William T." Message-ID: Thread-Topic: [TLS] TLS working group and authorization Thread-Index: AcoSDFgSgy5EzXimPkOL0KbAoJShuw== In-Reply-To: <87prbhosub.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] TLS working group and authorization 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, 31 Jul 2009 18:26:00 -0000 Tim said "Experimental" at the meeting today. /Stefan On 09-07-31 4:00 PM, "Simon Josefsson" wrote: > "Polk, William T." writes: > >> On April 15, I set the substate on draft-housley-tls-authz-extns to "External >> Party" with the following comment: >> >> Waiting for TLS working group to decide whether they wish to take on >> work in this space. >> >> Based on email traffic, agenda time, and the lack of new I-D submissions I >> have concluded that TLS is not >> interested in pursuing a standards track document. Accordingly, I have >> tentatively placed the document on the >> 8-14 telechat agenda. If you wish to inform me about progress otherwise >> invisible to me, please contact me >> before the telechat. > > What is the intended status for the document this time? > > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls