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

From: Erick O <[email-masked]>
Date: Thu, 17 Sep 2009 23:31:53 -0700 (PDT)

________________________________
From: Dean Anderson <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]; Stephen Kent <[email-masked]>; [email-masked]
Sent: Wednesday, August 5, 2009 7:05:06 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

Ned and Stephen,

If you mean the recent message traffic about the 'intention to remove'
extractor from a list of patented documents, that hasn't happened so far
and an 'intention to remove' doesn't mean it isn't patented. It is
possible that Certicom can later say it was a misunderstanding and that
the official documents were correct. As evidence of their view, they
have the official documents.  As evidence of your view, you have an
unofficial and vague email message apparently contrary to the official
documents, and you will have to argue you based your decision on the
unofficial and vague message rather than the official IPR Disclosures.  
I think one cannot get to a Qualcomm v. Broadcomm finding under such
circumstances.

So, if your objection is removed once the patent threat is removed, then
you should wait until the patent threat is actually removed, which
hasn't happened yet.

As the recent discussions about destroying evidence of participation in
bluesheets shows, some people are willing to engage in deceptive
practices, which may obviously include deceiving people about their
intent to assert patent coverage.

        --Dean

On Thu, 30 Jul 2009 [email-masked] wrote:

> > I too support publication of this document as a Standards Track RFC,
> > in light of the salient message traffic of late.
> 
> +1
> 
>                 Ned
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet  Prepared to pay a premium for better service?
www.av8.net        faster, more reliable, better service
617 344 9000  

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:40:52 -0700 (PDT)

________________________________
From: Noel Chiappa <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]
Sent: Monday, July 27, 2009 9:46:52 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

    > From: Richard Stallman <[email-masked]>

    > 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: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:47:50 -0700 (PDT)

________________________________
From: Dean Anderson <[email-masked]>
To: Douglas Stebila <[email-masked]>
Cc: [email-masked]; IETF Discussion <[email-masked]>; [email-masked]; [email-masked]
Sent: Tuesday, July 21, 2009 7:35:27 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

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) '
> >  <draft-ietf-tls-extractor-06.txt> 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
> > [email-masked] mailing lists by 2009-08-10. Exceptionally,
> > comments may be sent to [email-masked] 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: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:47:22 -0700 (PDT)

________________________________
From: Douglas Stebila <[email-masked]>
To: IETF Discussion <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 21, 2009 1:32:21 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

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:

> final comments on this action.  Please send substantive comments to the