Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

Erick O <> Fri, 18 September 2009 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4793D3A68F4 for <>; Fri, 18 Sep 2009 07:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZT6s2I69iiuZ for <>; Fri, 18 Sep 2009 07:52:44 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id A61153A67CC for <>; Fri, 18 Sep 2009 07:52:43 -0700 (PDT)
Received: (qmail 34890 invoked by uid 60001); 18 Sep 2009 14:46:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1253285218; bh=V5aS1hmW4i8nq1GFFkmK6AccH32Grgpe5QPHzWPuOV8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oYbapFfN3zQcBLLSIskcLI8Dg4uGHjMDyCZsqRs1doWmpfqvhkmSE+g3iyL7Yw7CPx+0lMFsn8t3Qbdsg1RYASGdt4NmeOVJFrfLuJte0asWclIfXSNGDNYGSTfeX6Yg7E0CJz2tZSd7KjQbcIZ8qF5pmhaIdc9M51ZKqeFH6zc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FCUK+1FP/eVkhnWzaJdMgPAX7UY3i7qfAsSFdmNnLLt8IoJ8tq95zxMjxl/91J2g1TwnJY8byBzPfDZSH0tTmpG+HeAMn2oB0IDZGNi7DwiqFKD/eNM1xXcz/gf/LePiXY5KoR6xd/lcoMYCPKPrknTdCSgSNKoLmmdmC3OFlz8=;
Message-ID: <>
X-YMail-OSG: gU8gVGkVM1l6r7oqqEZQ8_k52uJbBdRRlRWWf1.RjUlmqnwDi375cScjOcQXSXyN7G5CHaDAHy1vj7sm.iQB24bStAI6YY2faqnMZo5.6l7Kj21uENOrQRMDWzqrkDCJ.v9T6VJeS_ouW2KHhKTG743_X8WPRlFw0.pCXgDDqM7V9e_TEMhw91FmA9DPxcjW6nH6TJMoBGHrqlSMIVB2.up304ClpAcL.5aBIHfiCwMpnps9vg--
Received: from [] by via HTTP; Fri, 18 Sep 2009 07:46:57 PDT
X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2
References: <> <> <20090721195028.GQ1020@Sun.COM> <>
Date: Fri, 18 Sep 2009 07:46:57 -0700 (PDT)
From: Erick O <>
To: "Jeffrey A. Williams" <>, Nicolas Williams <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-609979027-1253285217=:33483"
Cc:, Todd Glassy <>,,,
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard
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, 18 Sep 2009 14:52:44 -0000

From: Jeffrey A. Williams <>
To: Nicolas Williams <>
Cc: Todd Glassy <>et>;;;;
Sent: Tuesday, July 21, 2009 4:41:39 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

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


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
My Phone: 214-244-4827

TLS mailing list