Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

From: "Polk, Tim (Fed)" <[email-masked]>
Date: Mon, 10 Jul 2017 13:54:22 +0000

First, I do not see this as a “wiretapping discussion” based on my reading of 2804, although others may disagree.

Second, I believe that this discussion should go forward based on several points:

  1.  this proposal does not involve any changes to the bits on the wire specified in the TLS 1.3 document
  2.  this proposal offers significantly better security properties than current practice (central distribution of static RSA keys)
  3.  alternative solutions with significantly worse security properties are also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable solutions with appropriate security properties.  Balancing cryptographic security with other security requirements to achieve such solutions should be an acceptable path, and pursuing this work in the TLS working group gives the IETF the best opportunity to influence these solutions.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 15:16:20 +0100

Hiya,

While we're waiting on Sean/Joe... :-)

On 10/07/17 14:54, Polk, Tim (Fed) wrote:
> First, I do not see this as a “wiretapping discussion” based on my
> reading of 2804, although others may disagree.

s/may/do/

Figure 3 in the draft is absolutely clearly describing
an architecture for wiretapping TLS connections. And I
see no way in which this scheme can avoid that problem
as there is no way in which the "TLS decrypter" can be
assured to be in any particular place in any network.
(If one did try fix that, then you end up in the mctls
muck.)

> wire specified in the TLS 1.3 document 

I would assert that it substantially changes the semantics of
the bits emitted by standards-track TLS implementations. With
this, a client cannot know if it's application PDUs are being
decrypted from the middle of the network when talking to any
standards-compliant server. That basically breaks one of the
most important security properties of TLS.

> 2.  this proposal offers
> significantly better security properties than current practice
> (central distribution of static RSA keys) 

I fail to see any relevant difference in security properties
between those two, never mind a significant improvement.

> 3.  alternative solutions
> with significantly worse security properties are also feasible under
> TLS 1.3, and I would like to avoid them!

Yes. But that is not a justification to weaken security for
standards-track implementations of TLS1.3. We should not
standardise ways of doing crappy crypto would be my take.

> We should be in the business of developing pragmatic, interoperable
> solutions with appropriate security properties.  

Absolutely. This proposal, being inappropriate for the standards
track, should go visit /dev/null.

> Balancing
> cryptographic security with other security requirements to achieve
> such solutions should be an acceptable path, and pursuing this work
> in the TLS working group gives the IETF the best opportunity to
> influence these solutions.

See the raven mailing list I guess. That was specifically
discussed then.

S.

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 10 Jul 2017 17:14:44 +0200

On Mon, 2017-07-10 at 13:54 +0000, Polk, Tim (Fed) wrote:
> this proposal does not involve any changes to the bits on the wire
> specified in the TLS 1.3 document
> this proposal offers significantly better security properties than
> current practice (central distribution of static RSA keys)
> alternative solutions with significantly worse security properties
> are also feasible under TLS 1.3, and I would like to avoid them!
>  
> solutions with appropriate security properties.  Balancing

Certainly, but that doesn't need to happen on this working group, nor
protocols which implement similar solutions need to be called TLS.

regards,
Nikos

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 10 Jul 2017 15:30:48 +0000

+1 !!!

And
For the enterprise situations,  we typically own, operate and manage the involved "Facilities":
The Servers
The Applications
The Networks
The Keys
The Data
and in Many cases the clients as well

Given the above scenario,  I do not understand how this can be construed as "Wiretapping".    2804 seems to make this clear.

What Enterprises want in this space, is the ability to continue to have access to their aforementioned facilities,  to perform diagnostics, monitoring and security functions.   (i.e. continue to effectively operate and manage our networks).  Although I believe the Matt Green draft proposes a very good, viable and well thought out solution for TLS 1.3,  I suspect most of us are open to different or better solutions,  if such exists or can be conceived.
There seems to be good discussion, requirements and ideas on both sides of this issue,  albeit in sharp disagreement in many cases.      Such critical colloquy,  with significant long term impact,  should not be prematurely terminated,  IMHO.

Finally an editorial comment from those of us TRYING to get Enterprises involved at IETF.   We finally have some interest and engagement from Enterprise perspectives.     Killing discussion on this issue,  which is clearly important to Enterprises, will send the message that IETF did not really want this input or feedback.      I hope this is not the case.

From: TLS [mailto:[email-masked]] On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: [email-masked]
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

First, I do not see this as a "wiretapping discussion" based on my reading of 2804, although others may disagree.

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 10 Jul 2017 09:42:14 -0700

> protocols which implement similar solutions need to be called TLS.

I'll belabor this point: rather than thinking about what these providers
are owed, which is nothing, it is better to think about what is best for
TLS overall. Selfishly, I have a strong preference to see TLS1.3 succeed
and that within a matter of years, we no longer have to support TLS1.2 or
earlier versions.

If some networks and operators feel that they can't feasibly use TLS1.3,
they're very likely to stay on the older versions. We could consider
brinkmanship; and see who blinks first if we try to disable the older
versions anyway, but that's a gambit that often makes hostages out of
innocent users, and can end up serving to taint TLS1.3 with reliability
issues and hold back its adoption.

It's clear that there is a strong distaste here for the kind of MITM being
talked about, and many wish not to give it any kind of stamp of approval
within the standard; that that itself would also taint TLS1.3 with security
concerns. Proxies are proposed as a work-around instead, as it avoids any
changes to protocol. But this seems like cutting our noses off to spite our
faces. Proxies tend to be always-on and render plaintext much more
accessible than a tcpdump tap. Proxies are also inline, read-write, and
subject to exploit in a worse way than a tcpdump tap (which can be network
isolated). In real security terms, I absolutely buy that proxies would be
worse for overall security and all of the properties that TLS is supposed
to provide, in some environments. That would seem like a bizarre conclusion.

-- 
Colm

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Jul 2017 20:01:32 +0300

> On 10 Jul 2017, at 17:16, Stephen Farrell <[email-masked]> wrote:
> 
> 
>> 2.  this proposal offers

I can see one way in which it is worse.

With static RSA keys, you can configure the server to use only PFS ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, you need to switch to RSA ciphersuites, and that would be obvious to any client.  In fact, I think today a server would stick out if it only supported RSA ciphersuites.

There is no way to know that a server is doing what it says in the draft. It’s completely opaque to the client.

However, in both cases the server does get FS. As long as the server has not enabled RSA ciphersuites or exportable private key shares, any recorded TLS stream is safe even if the attacker later gets the private key.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Jul 2017 14:03:44 -0500

On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> With static RSA keys, you can configure the server to use only PFS
> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS,
> you need to switch to RSA ciphersuites, and that would be obvious to
> any client.  In fact, I think today a server would stick out if it
> only supported RSA ciphersuites.
> 
> There is no way to know that a server is doing what it says in the
> draft. It’s completely opaque to the client.
> 
> However, in both cases the server does get FS. As long as the server
> has not enabled RSA ciphersuites or exportable private key shares, any
> recorded TLS stream is safe even if the attacker later gets the
> private key.

Well, a client could observe reuse of server ECDHE public keys...

And servers can always share session keys with an auditing system.
There's no way a client could detect this.

I don't think we need to have the client KNOW what the server is doing
because... how the heck can the server prove it's not publishing the
client's secrets??  The server simply cannot prove that it is adhering
to any privacy policy.

Brief reuse of server ECDHE public keys is an optimization.  I _think_
it's a safe optimization, and it's safer the shorter the reuse period is
-- and correspondingly less safe the longer the reuse period.

But I would prefer that anyone wanting auditability just build that into
their implementations as a proper audit capability.  Yes, it's more
complex to later decrypt sessions, but it also doesn't mess with the
protocol in any way.

That said, I wouldn't object to the proposal if it meant to be
Informational.  I don't see how a document that describes a possible a
configuration (not protocol!) that is not relevant to the Internet
should be a Standards-Track RFC, or BCP for that matter.  Informational
will do.

Nico
--

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 10 Jul 2017 19:07:23 +0000

My $0.02: absolutely not on the Standards Track (for reasons already expressed by others), might be discussable if Informational.

--
Regards,
Uri Blumenthal

On 7/10/17, 15:03, "TLS on behalf of Nico Williams" <[email-masked] on behalf of [email-masked]> wrote:

    

    

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 20:31:57 +0100

On 10/07/17 20:07, Blumenthal, Uri - 0553 - MITLL wrote:
> My $0.02: absolutely not on the Standards Track (for reasons already
> expressed by others), might be discussable if Informational.

I haven't checked, but as far as I recall, other wiretapping
RFCs inconsistent with 2804 have all been in the ISE stream
(or predate it) and have all documented already deployed
wiretapping schemes. I think that is consistent with 2804 and
using a WG list and WG participant cycles/attention to
debate/develop wiretapping methods does go against 2804 and
ought not be done.

S.

> 
> -- Regards, Uri Blumenthal
> 
> On 7/10/17, 15:03, "TLS on behalf of Nico Williams"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>>>> 2.  this proposal offers significantly better security
>>>> properties than current practice (central distribution of
>>>> static RSA keys)
>>> 
>> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the
>> non-FS, you need to switch to RSA ciphersuites, and that would be
>> obvious to any client.  In fact, I think today a server would stick
>> out if it only supported RSA ciphersuites.
>> 
>> However, in both cases the server does get FS. As long as the
>> server has not enabled RSA ciphersuites or exportable private key
>> shares, any recorded TLS stream is safe even if the attacker later
>> gets the private key.
> 
> I don't think we need to have the client KNOW what the server is
> doing because... how the heck can the server prove it's not
> publishing the client's secrets??  The server simply cannot prove
> that it is adhering to any privacy policy.
> 
> Brief reuse of server ECDHE public keys is an optimization.  I
> _think_ it's a safe optimization, and it's safer the shorter the
> reuse period is -- and correspondingly less safe the longer the reuse
> period.
> 
> But I would prefer that anyone wanting auditability just build that
> into their implementations as a proper audit capability.  Yes, it's
> more complex to later decrypt sessions, but it also doesn't mess with
> the protocol in any way.
> 
> Informational.  I don't see how a document that describes a possible
> a configuration (not protocol!) that is not relevant to the Internet 
> should be a Standards-Track RFC, or BCP for that matter.
> Informational will do.
> 
> Nico --
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 20:37:22 +0100

> Given the above scenario,  I do not understand how this can be construed as "Wiretapping".    2804 seems to make this clear.

TLS is much more widely used that you seem to imagine.

Please see the comments to the effect that there is no
way to control to location of the wiretap/TLS-decrypter
in the protocol.

If that's not obvious, I don't know how to explain it
further.

See also text in 2804 wrt tools being used for more than
initially envisaged.

And if coercion of a server to comply with a wiretap
scheme like this stills fanciful to you, please check
out the history of lavabit - had there been a standard
wiretap API as envisaged here it's pretty certain that
would have been the device of choice in a case like that.
While it's easy enough to envisage many other abuses
that could be based on this wiretap scheme, that one is
a good match and a real one.

> Such critical colloquy,  with significant long term
> impact,  should not be prematurely terminated,  IMHO

"Premature" is nonsense, this debate has gone on too long
already.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 20:38:52 +0100

On 10/07/17 17:42, Colm MacCárthaigh wrote:
> talked about

It is not (only) "distaste," it is IETF policy as a result of
a significant debate on wiretapping.

S

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Jul 2017 13:11:21 -0700

On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <[email-masked]> wrote:

+1 !!!

And

For the enterprise situations,  we typically own, operate and manage the
involved “Facilities”:

The Servers

The Applications

The Networks

The Keys

The Data

Given the above scenario,  I do not understand how this can be construed as
“Wiretapping”.    2804 seems to make this clear.

What Enterprises want in this space, is the ability to continue to have
access to their aforementioned facilities,  to perform diagnostics,
monitoring and security functions.   (i.e. continue to effectively operate
and manage our networks).  Although I believe the Matt Green draft proposes
a very good, viable and well thought out solution for TLS 1.3,  I suspect
most of us are open to different or better solutions,  if such exists or
can be conceived.

There seems to be good discussion, requirements and ideas on both sides of
this issue,  albeit in sharp disagreement in many cases.      Such critical
colloquy,  with significant long term impact,  should not be prematurely
terminated,  IMHO.

Finally an editorial comment from those of us TRYING to get Enterprises
involved at IETF.   We finally have some interest and engagement from
Enterprise perspectives.     Killing discussion on this issue,  which is
clearly important to Enterprises, will send the message that IETF did not
really want this input or feedback.      I hope this is not the case.

One vertical is not all enterprises. Plenty of companies can trace requests
via logging systems and do not need mirroring for diagnostics.

Perhaps if we weren't faced with a last minute request to include static
ciphersuites things would be different. But the technique exists and can be
used regardless of approval. (Have you considered Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. There
are serious policy considerations here and a long agenda for this WG.
Stopping discussion is not about ignoring the problem: it's stopping a
discussion going nowhere from eating up all the bandwidth.

*From:* TLS [mailto:[email-masked]] *On Behalf Of *Polk, Tim (Fed)
*Sent:* Monday, July 10, 2017 9:54 AM
*To:* [email-masked]
*Subject:* Re: [TLS] chairs - please shutdown wiretapping discussion...

First, I do not see this as a “wiretapping discussion” based on my reading
of 2804, although others may disagree.

Second, I believe that this discussion should go forward based on several
points:

   1. this proposal does not involve any changes to the bits on the wire
   specified in the TLS 1.3 document
   2. this proposal offers significantly better security properties than
   current practice (central distribution of static RSA keys)
   3. alternative solutions with significantly worse security properties
   are also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable
solutions with appropriate security properties.  Balancing cryptographic
security with other security requirements to achieve such solutions should
be an acceptable path, and pursuing this work in the TLS working group
gives the IETF the best opportunity to influence these solutions.

The information contained in this communication is highly confidential and
is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you are
hereby notified that any viewing, copying, disclosure or distribution of
this information is prohibited. Please notify the sender, by electronic
mail or telephone, of any unintended receipt and delete the original
message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and Blue
Shield Association.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 10 Jul 2017 20:20:57 +0000

Then we read 2804 differently.     When I read 2804,  the contained discourses on what is and is not wiretapping,  clearly says to me,  that what Enterprises do within their networks,  is NOT wiretapping according to 2804 (or to me for that matter).  

We (and many others in this discussion),  have different perspectives.   Perhaps this is a contributing reason the Chairs determined it should continue.     I sincerely hope this will lead to some mutually acceptable dialogue and related solutions.  

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, July 10, 2017 3:37 PM
To: Ackermann, Michael <[email-masked]>; Polk, Tim (Fed) <[email-masked]>; [email-masked]
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

Please see the comments to the effect that there is no way to control to location of the wiretap/TLS-decrypter in the protocol.

If that's not obvious, I don't know how to explain it further.

See also text in 2804 wrt tools being used for more than initially envisaged.

And if coercion of a server to comply with a wiretap scheme like this stills fanciful to you, please check out the history of lavabit - had there been a standard wiretap API as envisaged here it's pretty certain that would have been the device of choice in a case like that.
While it's easy enough to envisage many other abuses that could be based on this wiretap scheme, that one is a good match and a real one.

> Such critical colloquy,  with significant long term impact,  should 
> not be prematurely terminated,  IMHO

"Premature" is nonsense, this debate has gone on too long already.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 22:17:36 +0100

On 10/07/17 21:20, Ackermann, Michael wrote:
> Then we read 2804 differently.     When I read 2804,  the contained
> discourses on what is and is not wiretapping,  clearly says to me,
> that what Enterprises do within their networks,  is NOT wiretapping
> according to 2804 (or to me for that matter).

You're misunderstanding what 2804 says and what the
IETF is about. 2804 says nothing about your, or my,
network at all. You are free to define middle-endian
ordering and three-valued bits if you want or to do
whatever forms of wiretapping you like in your n/w.

2804 is instead about standards track protocols as
specified by the IETF, which are used in many networks.

In the case of TLS the changes for which you are
arguing would clearly enable wiretapping in many networks
and the draft is therefore clearly inconsistent with 2804
and the standards track.

And to avoid a repeat of Russ' failed justification, many
protocols use and depend on TLS where the entity controlling
the TLS server private key materials is not the higher
layer sender or receiver, so all four points in the definition
in 2804 are fully met by your wiretapping scheme. If you want
examples, think about STMP with STARTTLS or CDNs and the web.
I'm sure there are loads of others.

Bottom line: that draft is a wiretapping draft.

At best, it ought be an ISE RFC, and even then I could see
arguments against that if what is documented has not actually
been deployed. (That last seems to me to be needed to acquire
the utility of publication described in 2804 - RFCs about
speculative schemes don't seem to me to offer any value
at all.)

S.

> 
> We (and many others in this discussion),  have different
> perspectives.   Perhaps this is a contributing reason the Chairs
> determined it should continue.     I sincerely hope this will lead to
> some mutually acceptable dialogue and related solutions.
> 
> 
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Monday, July 10, 2017 3:37
> PM To: Ackermann, Michael <[email-masked]>; Polk, Tim (Fed)
> <[email-masked]>; [email-masked] Subject: Re: [TLS] chairs -
> please shutdown wiretapping discussion...
> 
> 
> 
>> Given the above scenario,  I do not understand how this can be
>> construed as "Wiretapping".    2804 seems to make this clear.
> 
> Please see the comments to the effect that there is no way to control
> to location of the wiretap/TLS-decrypter in the protocol.
> 
> And if coercion of a server to comply with a wiretap scheme like this
> stills fanciful to you, please check out the history of lavabit - had
> there been a standard wiretap API as envisaged here it's pretty
> certain that would have been the device of choice in a case like
> that. While it's easy enough to envisage many other abuses that could
> be based on this wiretap scheme, that one is a good match and a real
> one.
> 
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any unintended
> receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue
> Cross and Blue Shield Association.
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 10 Jul 2017 21:22:12 +0000

Most Enterprises do have well developed logging collection and parsing infrastructures (e.g. Splunk, etc.).     But they are one of many tools needed to effectively manage complex corporate networks and applications.    They cannot fully replace network monitoring any more than network monitoring can replace logging, IMHO.

I do agree that it would be optimal for all perspectives and requirements to be introduced as early in the process as possible.    Hence one of the motivations for attempting to get Enterprises more active in IETF,  in general.

From: Watson Ladd [mailto:[email-masked]]
Sent: Monday, July 10, 2017 4:11 PM
To: Ackermann, Michael <[email-masked]>
Cc: Polk, Tim (Fed) <[email-masked]>; [email-masked]
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <[email-masked]<mailto:[email-masked]>> wrote:
+1 !!!

And
For the enterprise situations,  we typically own, operate and manage the involved “Facilities”:
The Servers
The Applications
The Networks
The Keys
The Data
and in Many cases the clients as well

Given the above scenario,  I do not understand how this can be construed as “Wiretapping”.    2804 seems to make this clear.

One vertical is not all enterprises. Plenty of companies can trace requests via logging systems and do not need mirroring for diagnostics.

Perhaps if we weren't faced with a last minute request to include static ciphersuites things would be different. But the technique exists and can be used regardless of approval. (Have you considered Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. There are serious policy considerations here and a long agenda for this WG. Stopping discussion is not about ignoring the problem: it's stopping a discussion going nowhere from eating up all the bandwidth.

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jul 2017 17:26:37 -0400

Stephen:

> in 2804 are fully met by your wiretapping scheme.

It is clear that you do not agree with the reasoning that I posted on Friday.  Some people do, and clearly, others do not.

So, I failed to convince you.  However, you have also failed to convince me that the proposal is wiretapping under the definition in RFC 2804, Section 3.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 22:35:21 +0100

On 10/07/17 22:26, Russ Housley wrote:
> Stephen:
> 
>> And to avoid a repeat of Russ' failed justification, many protocols
>> use and depend on TLS where the entity controlling the TLS server
>> private key materials is not the higher layer sender or receiver,
>> so all four points in the definition in 2804 are fully met by your
>> wiretapping scheme.
> 
> It is clear that you do not agree with the reasoning that I posted on
> Friday.  Some people do, and clearly, others do not.
> 
> So, I failed to convince you.  However, you have also failed to
> convince me that the proposal is wiretapping under the definition in
> RFC 2804, Section 3.

Consider SMTP/TLS. Where one MTA on the path supports this.
Say it's one operated by an anti-spam company for example.
That is clearly not the sender nor recipient.

That meets all 4 points in 2804, right?

S.

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jul 2017 18:07:23 -0400

> That meets all 4 points in 2804, right?

You are pointing to email.  Some MTAs will use SMTP over TLS, but many others do not.  It would be great if they all do, especially for the authentication.  In your response you are talking about an email system that has been using plaintext for ages, and you are trying to apply hop-by-hop a mechanism to the delivery.  Then, you are saying that the sender and receiver have confidentiality expectations that are being violated.  I do not buy it.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 23:21:11 +0100

> You are pointing to email.  Some MTAs will use SMTP over TLS, but many others do not.  It would be great if they all do, especially for the authentication.  In your response you are talking about a…

See [1].

Those show nearly 90% of mails being encrypted with
TLS now.

In many mail deployments there will be an added hop e.g.
for anti-spam (we do that here in tcd) to an outside
party.

While not 100% of mail is encrypted with TLS on all
hops, much is. (And the UTA WG are developing MTA-STS
to try improve that.)

If one of those external parties implements your
scheme then mail senders and receivers will not know and
that real TLS application meets the 2804 definition for
lots and lots and lots of emails.

Hence, 2804 applies here and the standards-track label
ought be removed.

S.

[1] https://www.google.com/transparencyreport/saferemail/

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jul 2017 18:32:22 -0400

> [1] https://www.google.com/transparencyreport/saferemail/

I'm glad that TLS is being used to protect email delivery.

I do not see how this changes the expectation discussed in RFC 2804, Section 3, Item number 3.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 23:34:07 +0100

On 10/07/17 23:32, Russ Housley wrote:
>>>>>> protocols use and depend on TLS where the entity
>>>>>> controlling the TLS server private key materials is not the
>>>>>> higher layer sender or receiver, so all four points in the
>>>>>> definition in 2804 are fully met by your wiretapping
>>>>>> scheme.
>>>>> 
>>>>> It is clear that you do not agree with the reasoning that I
>>>>> posted on Friday.  Some people do, and clearly, others do
>>>>> not.
>>>>> 
>>>>> So, I failed to convince you.  However, you have also failed
>>>>> to convince me that the proposal is wiretapping under the
>>>>> definition in RFC 2804, Section 3.
>>>> 
>>>> Consider SMTP/TLS. Where one MTA on the path supports this. Say
>>>> it's one operated by an anti-spam company for example. That is
>>>> clearly not the sender nor recipient.
>>>> 
>>> You are pointing to email.  Some MTAs will use SMTP over TLS, but
>>> many others do not.  It would be great if they all do, especially
>>> for the authentication.  In your response you are talking about
>>> an email system that has been using plaintext for ages, and you
>>> are trying to apply hop-by-hop a mechanism to the delivery.
>>> Then, you are saying that the sender and receiver have
>>> confidentiality expectations that are being violated.  I do not
>>> buy it.
>> 
>> See [1].
>> 
>> Those show nearly 90% of mails being encrypted with TLS now.
>> 
>> In many mail deployments there will be an added hop e.g. for
>> anti-spam (we do that here in tcd) to an outside party.
>> 
>> While not 100% of mail is encrypted with TLS on all hops, much is.
>> (And the UTA WG are developing MTA-STS to try improve that.)
>> 
>> If one of those external parties implements your scheme then mail
>> senders and receivers will not know and that real TLS application
>> meets the 2804 definition for lots and lots and lots of emails.
>> 
>> Hence, 2804 applies here and the standards-track label ought be
>> removed.
>> 
>> S.
>> 

Talk to our (tcd.ie) or gmail's mail admin folks. Their
expectations count too. (Or are we against enterprise
requirements or something? ;-)

S.

---

From: Eric Mill <[email-masked]>
Date: Mon, 10 Jul 2017 19:09:00 -0400

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley <[email-masked]> wrote:
> You are pointing to email.  Some MTAs will use SMTP over TLS, but many
> others do not.  It would be great if they all do, especially for the
> authentication.  In your response you are talking about an email system
> that has been using plaintext for ages, and you are trying to apply
> hop-by-hop a mechanism to the delivery.  Then, you are saying that the
> sender and receiver have confidentiality expectations that are being
> violated.  I do not buy it.
>

It seems like a weak counterargument to say that because there remain areas
where mail servers don't use TLS, that senders and receivers have no
expectation of confidentiality with email at all. Are you really saying
that if an MTA used this static-DH draft version of TLS to maintain keys to
decrypt email traffic, despite it only being "intended" for enterprise use,
that it wouldn't be wiretapping?

What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit
100% before it's suddenly wiretapping for any given MTA to surreptitiously
use the static DH version of TLS that was "intended" only for enterprise
use?

-- Eric

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 10 Jul 2017 19:12:04 -0400

> a good match and a real one.

There's a lot of insight based on the history.

If the mechanism operated at layer 3 or 4 (modify the protocol), then
the net is cast overly wide in a shared hosting arrangement. That is,
all virtual host's traffic is captured and recovered.

If it operates at layer 6 or 7 (modify the applications and/or its
libraries, like Apache or Nginx), then there is more precision in
target traffic. That is, only the target's traffic can captured and
recovered.

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Jul 2017 16:39:03 -0700

On Jul 10, 2017 4:09 PM, "Eric Mill" <[email-masked]> wrote:

I don't read RFC 2804 as applying to cases where intermediaries authorized
by a party to view information are handing it over. The MTA is authorized
by the recipient to be in the path and to look at the emails for all sorts
of reasons, and if they decide to hand over all your emails to someone else
via FTP, that's not a reason to be against FTP.

If it was to apply anything where a proxy service can be behind another
proxy would run afoul of this: they would proxy through the evesdropper. So
would reply-all, the most blatant cause of accidental evesdropping online.

Historically 2804 came out of (I think) a different situation where
signaling information related to interception was going to be included in
the protocol. Sadly it talks about sender and recipient without considering
cases where the identity is confused by subcontracting, and doesn't
distinguish cases like this which are similar to key escrow except there is
only one entity involved in the escrow.

-- Eric

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 07:02:17 -0400

> That meets all 4 points in 2804, right?

I don't buy this, Stephen.   The anti-spam company is not an eavesdropper.

What I don't understand about your approach to this draft is that it seems to me that the draft is obviously describing an exploit in TLS 1.3, for which a mitigation exists: remember keys, and refuse to communicate with an endpoint that presents a key you've seen before.

So rather than opposing the publication of the static keys draft, why not work on mitigating the attack it describes?   This attack exists whether the static keys draft is published or not.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 13:49:39 +0100

Hiya,

> I don't buy this, Stephen.   The anti-spam company is not an

This draft proposes a way for an eavesdropper who recorded
the cihphertext packets from anywhere to use a standardised
interface to get a small package of key material from the
anti-spam company (via coercion or collusion), that allows
the eavesdropper to decrypt all the TLS protected email
traffic sent via the anti-spam company. Looked at one way,
tt amounts to standardising a key exfiltration attack.

> 
> What I don't understand about your approach to this draft is that it
> seems to me that the draft is obviously describing an exploit in TLS
> 1.3, for which a mitigation exists: remember keys, and refuse to
> communicate with an endpoint that presents a key you've seen before.

The TLS server doesn't need to do things in a way that
a TLS client can detect.

> So rather than opposing the publication of the static keys draft, why
> not work on mitigating the attack it describes?   This attack exists
> whether the static keys draft is published or not.

Good/better TLS1.3 forward secrecy is being discussed as
part of the normal work in the WG. It is for sure always
possible to manage keys badly, but this draft proposes
an API to expose private key materials which is not the
same thing as bad implementation or management at all.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 09:11:40 -0400

What the draft actually says is that you can install a fixed key on the server rather than generating new keys every time, and then that fixed key can also be installed on monitoring software.   This is, I believe, the actual intended use of the proposal.

It’s also true that you can just exfiltrate every key as it’s generated, but that’s not what’s being proposed and would not, I think, suit the needs of the operators who are making this proposal.

I don’t see how you could mitigate against deliberate key exfiltration.   At some point you really are relying on the security of the endpoint.   But being able to detect repeated keys is useful for preventing pervasive monitoring: it requires the monitored either to have access to the key generation stream in realtime, or to request the key for a particular conversation.

So I think there is some value in defending against this attack.  I look forward to seeing a defense that uses perfect forward secrecy and protects against key exfiltration.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 11 Jul 2017 15:00:15 +0000

I am not certain if I speak for all Enterprise individuals involved in this discourse or not.
But I would like to endorse what Ted is saying.

As much fun as this debate has become (not),  Enterprises originally raised this issue to the TLS-WG,  to engage their considerable expertise, and to help solve what will be a huge business problem,  when TLS 1.3 is implemented.
I believe all of us Enterprise people would prefer to work with the SMEs at TLS-WG, to determine the best possible answer to this very real issue we will all face.     That is why we came to this WG.
The draft proposal is the best solution I have heard.   If there is a better approach, we all need to be open to this, as well as open to perspectives on both sides of this issue.    IMHO we want to work with the TLS-WG, not work around it, in an effort to craft the best possible solution(s),  with ALL related issues addressed.

From: TLS [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, July 11, 2017 7:02 AM
To: Stephen Farrell <[email-masked]>
Cc: Polk, Tim (Fed) <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 10, 2017, at 5:35 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
Consider SMTP/TLS. Where one MTA on the path supports this.
Say it's one operated by an anti-spam company for example.
That is clearly not the sender nor recipient.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Jul 2017 15:01:18 -0400

> a significant debate on wiretapping.

It is a policy some 17 years ago promulgated with respect to some very 
specific layer 9 threats and was pretty black and white.   In 17 years 
we've gone from workstation class systems homed to application class 
servers to smart phones and the cloud.  The SNI RFC was still three 
years out and strangely all the privacy stuff we're worried about now 
wasn't even part of the security considerations.  TOR was still a DOD 
project.  Basically, 2804 is woefully out of date with respect to the 
current state of the world.

What this discussion has shown me is that we probably a) need to take 
another look at 2804 with a view to updating it with respect to the 
IETF's general views on persistent threats of all kinds, b) need to have 
whatever revision we make of 2804 provide for the concept that the owner 
of the data is not necessarily the sender/receiver of the data and has a 
vested interest in being able to control the flow of that information or 
protect themselves against persistent system threats (e.g. masked 
attackers) implicit in protecting against persistent privacy threats, 
and c) follow the general IETF model of not reading each and every word 
in any given RFC as if it were immutable truth handed down for all 
eternity and trust that we can - if we have the discussion - find a way 
forward through consensus building not bullying.

Later, Mike

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Jul 2017 12:11:09 -0700

> I don’t see how you could mitigate against deliberate key exfiltration.   At some point you really are relying on the security of the endpoint.   But being able to detect repeated keys is useful fo…
To paraphrase what Ted says using my own words, the use of static (EC)DH
shares is an attack against the integrity of the TLS 1.3 protocol. I
think this attack should be documented in the TLS spec, probably in
Appendix E since the attack compromises security properties of the
protocol, or maybe in Appendix C if we want to outline the
implementation issues. Some text like:

For various reasons, some implementations may be tempted to use static
(EC) DH private key. Using such keys lowers the security guarantees of
TLS 1.3. Adversaries that get access to the static (EC) DH private key
can now get access to the content of the communication. Adversaries that
acquire the key in real-time can compromise the confidentiality of the
conversation. Adversaries that acquire the key later can use it to
access the content of recorded sessions, thus breaking the forward
secrecy promise of the protocol. TLS 1.3 clients should detect the use
of static (EC)DH keys by corresponding servers, and should treat servers
using such keys as compromised. Clients can perform this detection by
comparing keys proposed by servers at different time, or by cooperating
with other clients to compare the keys proposed to them by servers.

-- Christian Huitema

-- 
Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 20:31:32 +0100

On 11/07/17 20:01, Michael StJohns wrote:
> Basically, 2804 is woefully out of date with respect to the current
> state of the world.

As I said before I do think the authors of this draft should
indeed have said that it needs to obsolete 2804 as that is
required for them to get the standards track status that they
requested in the draft header.

I also think that's going about things arseways - if 2804 needs
to be updated, that should happen first.

And for the current discussion, if the WG consensus is (as it
ought be) to not adopt this draft based on 2804, then there is
an IETF-level (and not TLS WG level!) question as to how to
handle drafts that are inconsistent with 2804 - ISTM that 2804
only envisages those being sent to the ISE and not being IETF
work items at all, otherwise the IETF would indeed be developing
wiretapping specifications which is clearly and obviously not
what 2804 says. And that matches my recollection of the debate
at the time, but I've not gone back to the raven archive to
check. (And 2804 pre-dating RFC streams won't help there I'm
sure in terms of clarity.)

So I'd also object to this WG attempting a supposed "compromise"
of pursuing an informational RFC as a work item. Doing do would
create an almost certainly huge but repeated debate on this
aspect during such a WG process and during IETF last call. That
specific question could maybe be figured out via an IESG note,
and might not need a full-on 2804bis debate, not sure.

No doubt such a debate would be a non-trivial undertaking, but
if we could reach a new consensus on a 2804bis that strengthened
Internet security and privacy, that would be a good thing. (I'm
not sure if folks would really be up for that though.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 20:40:57 +0100

> with other clients to compare the keys proposed to them by servers.

I generally like the idea of such text but I'm not at all
sure client detection is really feasible in the general
case. It'd seem possible for a server to hold a rather long
list of re-used static DH values and unlikely for normal
clients to detect those. And it also seems like an arms race
too, e.g. if a special zmap-like survey was used to detect
this kind of bad crypto. Still worth testing for no doubt,
(it'd make for a nice academic publication) but I'm not sure
detection could be sufficiently probable that we could make
the statement above.

Speaking of text changes though, if this wiretapping scheme
were to be adopted in any sense, there would be a load of
tweaks to text in tls1.3 needed as a result - starting with
the abstract to -21 for example as we could no longer say
that TLS is "designed to prevent eavesdropping" without a
highly embarrassing qualifier. (Hence my request to not have
this discussion until after DTLS1.3 is done - and chairs if
you're reading this please do reconsider.)

Sigh,
S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 15:48:26 -0400

On Jul 11, 2017, at 3:40 PM, Stephen Farrell <[email-masked]> wrote:
> It'd seem possible for a server to hold a rather long
> clients to detect those.

Bearing in mind that the current proposal is intended to perpetuate a well-established use model so as to avoid having to re-tool, I don’t think this is a real concern. In practice I expect that the number of keys used in such a system will be small because the operational burden of making it large will be enough to motivate re-tooling. 

So in practice I would expect a client to be able to cache enough keys to notice this attack, if the user were motivated, or the client vendor considered this to be a credible threat worth addressing.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 20:59:41 +0100

On 11/07/17 20:48, Ted Lemon wrote:
>> It'd seem possible for a server to hold a rather long list of
>> re-used static DH values and unlikely for normal clients to detect
>> those.
> 
> Bearing in mind that the current proposal is intended to perpetuate a
> well-established use model so as to avoid having to re-tool, I don’t
> think this is a real concern. In practice I expect that the number of
> keys used in such a system will be small because the operational
> burden of making it large will be enough to motivate re-tooling.
> 
> So in practice I would expect a client to be able to cache enough
> keys to notice this attack, if the user were motivated, or the client
> vendor considered this to be a credible threat worth addressing.

I can't see that happening. Once the first example.com is called
out for using this, others will make their list longer or take
other approaches, e.g. use one exfiltrated private value as a
seed for others via some proprietary mechanism.

Actually, that calls out another reason to not standardise or
further develop this - any such standard is either undetectable
or leads to deployments deviating from the standard to become less
detectable - both undesirable outcomes. That latter case also
destroys the "but we should scrutinise it" argument IMO as the
"it" will change to be undetectable and not the "it" that was
ostensibly scrutinised.

S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 16:03:53 -0400

On Jul 11, 2017, at 3:59 PM, Stephen Farrell <[email-masked]> wrote:
> I can't see that happening. Once the first example.com <http://example.com/> is called

Ah, you mean the first time the attack happens in the wild.   Sure, I can see that, but that gains the attacker no real advantage over just exfiltrating all the keys.   Once you make the number of keys large enough to be hard to detect, you have a really big key management problem.   Might as well just make it a logging problem.   So we've forced them to do the thing that makes pervasive monitoring hard and point monitoring easy.   I call that a win.

Note that if we took a distributed approach to discovering key reuse, it would be almost impossible for any large site to conceal.

> "it" will change to be undetectable and not the "it" that was

I'm not arguing in favor of standardizing this.   I think it's an attack, and there is a countermeasure which is worth documenting, and possibly worth deploying.   If the working group does a CFA on the draft, I will argue against adoption.   I like Christian's approach—document this in an appendix, _as an attack_.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 21:31:23 +0100

On 11/07/17 21:03, Ted Lemon wrote:
> Ah, you mean the first time the attack happens in the wild.  

Well, the first time it's detected in the wild.

> Sure, I
> can see that, but that gains the attacker no real advantage over just
> exfiltrating all the keys.   

I agree. I think one can actually generalise here and argue
that there's no value in new standards for bad crypto, only
in standards for current BCP crypto. (On the basis that if
it's crap crypto there's too much damage potential in the
homogeneous environment created by a successful standard.)

> Once you make the number of keys large
> enough to be hard to detect, you have a really big key management
> problem.   

Not necessarily. I'd bet folks would invent proprietary
ways of avoiding detection, that deviate from the "standard"
and that perhaps make crypto worse all around. Say by deriving
secrets from some function f(exfiltrated-secret, time, count)
for a small counter or some such and having the decryptor of
the wiretapped packets hunt a bit for the right key.

> Might as well just make it a logging problem.   So we've
> forced them to do the thing that makes pervasive monitoring hard and
> point monitoring easy.   I call that a win.
> 
> Note that if we took a distributed approach to discovering key reuse,
> it would be almost impossible for any large site to conceal.

I would bet there are ways to hide from that.

Cheers,
S.

PS: There are also genuine performance reasons why the same
DH public might be re-used in some cases, so there would be
false positives in a survey to consider as well.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Jul 2017 13:54:40 -0700

> false positives in a survey to consider as well.

Well, yes. The classic argument is performance. Saving the cost of
exponentiation, computing G^X once for many session instead of once per
session. But you reap most of the benefits of that optimization with a
fairly small number of repetitions. Performance alone is not a good
reason to use the key over extended period, not to share the exact same
key between all servers in a farm. The fact is that wide reuse of the
same (EC)DH private key does compromise the security of TLS -- including
an obvious issue with forward secrecy.

I get your argument that this can turn into a cat and mouse game.
Clients detect a bad behavior, misbehaving servers adapt by tweaking the
behavior to avoid detection, clients get smarter, etc. On the other
hand, documenting the attack clearly marks this key reuse as not
desirable and not supported. The public statement provides an argument
to developers to "just say no" when asked to add the wiretap "feature".
Detection by clients also provides a clear signal to enterprises that
they should really find another way to solve their problem.

In any case, I just submitted PR #1049
(https://github.com/tlswg/tls13-spec/pull/1049).

-- 
Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 16:58:18 -0400

On Jul 11, 2017, at 4:31 PM, Stephen Farrell <[email-masked]> wrote:
> I'd bet folks would invent proprietary

Hm, well, but that would be catnip for security researchers, particularly if it weakened the key.   But yeah, you're right, that does make detecting the attack possibly impractical aside from as a large research project.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 11 Jul 2017 20:58:56 +0000

I’d rather not deal with this whole mess.

--
Regards,
Uri 

On 7/11/2017, 16:56, "TLS on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -- 
    Christian Huitema

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Jul 2017 00:10:47 +0300

> On 11 Jul 2017, at 23:54, Christian Huitema <[email-masked]> wrote:
> 

I don’t think the number of times (within reason) a key is used matters that much. It only matters whether or not it is exportable. If a server implementations generates a fresh key for every session and then stores it in a database that maps public key to private key, then that database can trivially be used to decrypt all traffic. Conversely, an implementation could generate a key in memory and use it until reboot and as long as it’s not exported, nothing happens.

I once implemented an ECDHE TLS server with an in-memory key that was rotated every 10 seconds. Since it was never written to disk (or even paged out) this practice did not compromise forward secrecy.

The draft also recommends rotating the keys, but I guess that would be far less often than once every 10 seconds. But that is not the crucial difference. The crucial difference is that these keys get exported.

Note, however, that the reason RSA ciphersuites were deprecated is that we are afraid that a stolen or coerced private key will compromise past sessions. If the session between us is recorded today and someone steals or demands my private key tomorrow, than they can decrypt our conversation from today.

This is not the case in (EC)DHE  ciphersuites in TLS 1.2 or 1.3. Any session that happens before this mechanism is turned on, is safe. Sessions can only be compromised after the server has enabled this feature, which is equivalent to handing over the RSA private key in RSA ciphersuites. That is not the forward secrecy issue that we wanted to solve by removing RSA ciphersuites.  If one of the parties to a conversation cooperates with the wiretap, this isn’t an attack.

Yoav

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 17:16:31 -0400

On Jul 11, 2017, at 4:58 PM, Ted Lemon <[email-masked]> wrote:
> On Jul 11, 2017, at 4:31 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:

On second thought, this suffers from the same problem as the many-static-keys problem: there are too many moving parts.   This requires all clocks on all servers and interceptors to be in perfect sync, not just close, or else potentially halves the performance during clock skew  overlap periods.   It requires every server and interceptor to implement the same algorithm.   And you still have to distribute the information from which the key is derived.

So again, yes, you can do this particular mitigation strategy.   But it's expensive, and so nobody's going to do it if they have a better choice.   It's cheaper to just re-tool to support TLS 1.3.   As long as the solution isn't standard, it's only going to appeal to a _very_ limited audience, if there's any audience for it at all.   E.g., consider trying to deploy something like this on a country-wide scale.   You're just going to exfiltrate every key instead—it's cheaper.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 22:21:15 +0100

On 11/07/17 22:10, Yoav Nir wrote:
> If one of the parties to a conversation cooperates with the wiretap,
> this isn’t an attack.
Lemme try on this one again from a different angle.

In classic telephony wiretaps the carrier does the
tap. There are similar situations with TLS...

In hosted platforms (e.g. wordpress.com and many
others) where the senders and receivers (or publishers
& readers) have read and write access via PHP code
and not via a shell, and cannot therefore control web
or TLS configuration, the platform would be doing a
wiretap if it turned this on, whilst colluding with
or being coerced by some other entity that collects
and later decrypts the ciphertext and packets.

Are we agreed that that use-case is wiretapping via
this mechanism?

There are many millions of people who use such
constrained hosted environments.

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Jul 2017 01:09:02 +0300

> On 12 Jul 2017, at 0:21, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Wordpress.com <http://wordpress.com/> is a party to the session. It has access to the plaintext and could deliver it to whatever third party whenever they wanted. This draft may be an optimization, but the plaintext was always theirs to give.

I might be deluding myself that I’m sending this email to you over TLS. In fact I’m only uploading it to gmail.com <http://gmail.com/> who will forward it to TCD’s server. Both servers will have access to the plaintext. Both servers can send it to a third party, or share session keys or share ECDHE private keys.

Whether one party to a conversation (phone or IP) has the right to share private contents with a third party is a legal matter that varies from country to country and from state to state. I only claim that this draft does not change the fact that is true for PFS suites in TLS 1.x and for all suites in TLS 1.3, that it’s impossible to decrypt a recorded session without cooperation from either party, and that cooperation has to start *before*  the session is recorded.

That is not the case for POTS wiretap or for the RSA key exchange.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 23:14:55 +0100

On 11/07/17 23:09, Yoav Nir wrote:
> Whether one party to a conversation (phone or IP) has the right to
> share private contents with a third party is a legal matter that
> varies from country to country and from state to state. I only claim
> that this draft does not change the fact that is true for PFS suites
> in TLS 1.x and for all suites in TLS 1.3, that it’s impossible to
> decrypt a recorded session without cooperation from either party, and
> that cooperation has to start *before*  the session is recorded.

But hang on, in this example wordpress.com are the equivalent
of the POTS carrier - why is it a wiretap in the POTS case and
not in the HTTP/TLS case? That makes no sense. Neither are a
callee/caller just the same as when my vanity domain is used
to transfer information between you and I via some wordpress
plug-in I've installed.

I do agree with the "*before*" statement and about optimisation
but an optimised-X is still an X.

S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Jul 2017 18:27:16 -0500

On Tue, Jul 11, 2017 at 05:16:31PM -0400, Ted Lemon wrote:
> > Hm, well, but that would be catnip for security researchers,
> > particularly if it weakened the key.   But yeah, you're right, that
> > does make detecting the attack possibly impractical aside from as a
> > large research project.
> 
> On second thought, this suffers from the same problem as the
> many-static-keys problem: there are too many moving parts.   This
> requires all clocks on all servers and interceptors to be in perfect
> sync, not just close, or else potentially halves the performance
> during clock skew  overlap periods.   It requires every server and
> interceptor to implement the same algorithm.   And you still have to
> distribute the information from which the key is derived.

If TLS 1.3 still has server nonces (does it?) then those could be used
to provide enough information to reconstruct the server's ECDH key given
access to a base secret (per-host secret, say)...  Alternatively could
one use some extension to signal such information?  After all, if one
wishes to decrypt past sessions, presumably one is recording them, so if
the transcript gives you the bits you need...

Or one could also just construct a protocol by which to quickly log
{transcript_hash, session_key} encrypted to the log sink.

Or {transcript_hash, counter/nonce for ECDH keygen} -- this doesn't need
to be encrypted, which simplifies key management for the escrow system,
though it also makes past sessions vulnerable to host compromises.

If synchronous, reliable escrow is not required then one could
immediately send a UDP datagram to the sink and use background
retransmission as needed if one wants reliable escrow.  One could even
just syslog the darned thing.  If reliable escrow is required then hold
the connection until the sink ACKs the escrow message.

This is a very simple design for session key escrow.  It requires a sink
and storage, granted, but that's pretty cheap nowadays, you almost
certainly have such sinks, and, besides, if you're interested in
decrypting sessions after the fact then you're recording entire sessions
anyways, so storage-wise a session key escrow system is no big deal.

Note that such a system would be completely undetectable from a client's
point of view.  It's a server-side CALEA-like "port" enabling
eavesdropping by authorized parties.  One could not prove that the
server does not do this without access to the server.

Such an escrow-via-logging approach works no matter what TLS 1.3 looks
like on the wire.  More than that, it works for all client-server
protocols for that matter: SSHv2, Kerberos, SCRAM, whatever.  All you
have to do is specify what goes into the transcript hash for each
protocol, and what bits to include for key escrow.  Universal session
key escrow.  What's an intranet not to like, right?

The best thing about such a scheme is that it completely sidesteps all
this entire "it's wiretapping" "no it's not" "yes it is" "nuh uh" ...
thread.  One might want to standardize a key escrow logging protocol --
why not?  Maybe not at the IETF, or maybe in a WG just for that purpose.
I don't have a problem with that.

I also don't have a problem with draft-green-tls-static-dh-in-tls13
provided that it be published as an Informational RFC.  After all, it
documents a method that a) doesn't change TLS on the wire, and which b)
clients have a hard time deciding when to refuse to talk to a server
that appears to implement it.  Sure, it breaks the spirit of TLS 1.3,
but that was always possible, with or without an RFC.

I might not even have a problem with draft-green-tls-static-dh-in-tls13
as a Standards-Track RFC.  Not publishing doesn't prevent implementation
reuse of ECDH keys, and publishing doesn't cause reuse of ECDH keys to
be required.  My only objection to publishing on the Standards-Track is
that Informational seems much more appropriate given that the
contents... is purely informative, lacking even a reference to RFC2119,
much less normative RFC2119 keywords.

Too much ado about nothing.  The best solution here is for the authors
to acknowledge the informative/non-normative nature of their I-D and
take it to the ISE as an FYI.  Done.

Nico
--

---

From: Bill Frantz <[email-masked]>
Date: Tue, 11 Jul 2017 17:42:47 -0700

I must admit that I mostly agree with Stephan that this kind of 
thing should not exist. However, it exists now, and the chairs 
have decided we should at least discuss it.

I think there are many ways to meet the "requirements" of 
network monitoring and protocol debugging, and some are worse 
than others. Leading the world in the direction of the least 
damaging ones seems to be the bese way to deal with a bad situation.

The major threats I see include:

   Coerced use by oppressive governments.

   Use outside the immediate private network

   Use by an ISP on its customers

   Use without both ends being aware that it is in use.

I think coerced use is by oppressive governments is an obvious 
bad and I hope I have working group agreement on this point.

Limiting the protocol to the immediate private network will 
prevent 3rd parties from activating it to spy on the enterprise. 
One possible way to enforce this limitation is to require 
compliant implementations to limit broadcast of decryption 
information to the IP addresses on the local subnet.

I would be nice to be able to keep an ISP from spying on its 
customers as part of its "private network". However, I don't see 
how to differentiate an ISP's network from a enterprise network.

If it is not technically possible to use the protocol without 
both ends being aware that it is in use, then user interfaces 
can reflect its use. One result would be that enterprise users 
would be continually warned that their messages aren't private.

Any technical fixes we build into the protocol that prevent 
these actions are a positive improvement.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | If you want total security, go to prison. 
There you're
408-356-8506       | fed, clothed, given medical care and so on. 
The only
www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower

---

From: Timothy Jackson <[email-masked]>
Date: Wed, 12 Jul 2017 08:53:09 +0000

Bill,

I agree that we need to find the "least bad" option, if for no other reason than to prove there is no acceptable solution. If I may, I'd like to suggest another possible way to get to "least bad".

Perhaps our goal should not be to prevent servers collaborating with the monitoring, which we can't actually do anyway, but rather to ensure both sides to know when this is happening. This will give clients the opportunity to decide whether or not to allow it. A few people have started down this path on this thread.

One can imagine a few ways to approach this (these are examples to get people thinking and admittedly aren't fully baked, so be nice ;-) )
1. Define a new ciphersuite(s) explicitly for this purpose. Call it TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256_MON(itor) or whatever. This would make it obvious what's happening and the client can choose to enable or disable such cipher suites. Browser/OS vendors might let users/admins enable these cipher suites for local network connections and disable them for connections to the wider internet.
2. Include something in the server's certificate (a new X509 extension or the static ECDH key perhaps?) as a signal to the client that the server is enabling monitoring. Again, this can be allowed for connections within an organization but potentially blocked for connections to external networks.
3. Use a 3-party handshake. As I recall, there are three party versions of RSA and DH (Joux, 2000) and at least progress on making 3-party ECDH work based on Ben Lynn's work. (I haven't checked to see what the latest status on this is.) This probably becomes an extension and possibly some newly defined cipher suites as well.

There may be any number of other solutions, this isn't meant to be an exhaustive list, just get people thinking. Because this request is so specialized (monitoring inside an enterprise), it seems reasonable to me that the solution can be non-generalizable to the internet at large. In fact, that's probably a desired trait. Therefore, the use of custom ciphersuites, extensions or the like may be viable, since both ends of the connection are ostensibly under the control of the enterprise. (I'm sure BITS et al will speak up if they disagree.)

Cheers,

Tim
--
Tim Jackson
Senior Product Security Architect

________________________________

From: "Bill Frantz" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 11, 2017 at 5:43:03 PM
To: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | If you want total security, go to prison.
There you're
408-356-8506       | fed, clothed, given medical care and so on.
The only
www.pwpconsult.com<http://www.pwpconsult.com> | thing lacking is freedom. - Dwight D. Eisenhower

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 08:24:24 -0400

On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon <[email-masked]> wrote:

> It’s also true that you can just exfiltrate every key as it’s generated,
> but that’s not what’s being proposed and would not, I think, suit the needs
> of the operators who are making this proposal.
>
> I don’t see how you could mitigate against deliberate key exfiltration.
>  At some point you really are relying on the security of the endpoint.
>  But being able to detect repeated keys is useful for preventing pervasive
> monitoring: it requires the monitored either to have access to the key
> generation stream in realtime, or to request the key for a particular
> conversation.
>

Much of this conversation seems to conflate wiretapping with collaboration.
2804 has a clear definition of wiretapping:

q( Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
      the third party

   3. When the normal expectation of the sender is that the transmitted
      information will only be seen by the recipient parties or parties
      obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
      of the first party, either because he is of interest, or because
      the second party's reception is of interest. )

This proposal (and related proposals involving encrypting session keys to
inspection boxes, either in-band or OOB) violates condition 2 because one
endpoint would have to intentionally take action to deliver the session key
or private DH share to the third party. If one endpoint is feeding
cryptographic material to a third party (the only way that information gets
out to the third party, vulnerabilities notwithstanding), they are
collaborating, not enabling wiretapping.

(I'd argue the inspection box also fails to be a third party, as it is part
of the infrastructure of one endpoint, but that's largely irrelevant to the
question of whether this is wiretapping once we've determined the delivery
of keys is not a secret.)

I think this issue of static DH being an attack (maybe; not taking a
position) is something of a red herring, because shipping individual
session keys to a third party like a government doesn't add any substantive
hurdle beyond shipping them a single static DH share. That said, I agree
that an infrastructure for detecting the loss of forward secrecy, perhaps
in a CT-like manner, may make sense to protect against unintentional key
compromise or compromise of one endpoint: the problems that forward secrecy
is intended to address, which specifically do *not* include collaboration.

Kyle

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 08:57:51 -0400

On Jul 12, 2017, at 8:24 AM, Kyle Rose <[email-masked]> wrote:
> Much of this conversation seems to conflate wiretapping with collaboration. 2804 has a clear definition of wiretapping:

The problem is that in modern times we can't assume that collaboration is consensual, so the rules in RFC2804 aren't as applicable as they were.   There's no way to have the consensual collaboration use case without enabling the non-consensual use case.   Anything we do that makes it easier to enable the non-consensual use case is a bad idea.   So in my mind RFC 7258 is more applicable here than RFC 2804.

The problem with arguing this on the basis of whether or not there is a non-wiretapping operational use case for this is that there is a legitimate non-wiretapping operational use case here.   As I understand it, the motivation for doing this is to be able to avoid deploying different pieces of DPI hardware differently in data centers.   That's a legitimate motivation.   The problem is that (IMHO) it's not a good enough reason to standardize this.

I would much rather see people who have this operational use case continue to use TLS 1.2 until the custom DPI hardware that they are depending on is sufficiently obsolete that they are going to remove it anyway; at that point they can retool and switch to TLS 1.3 without needing support for static keys.   The advantage of this is that simply using TLS 1.2 signals to the client that the privacy protections of TLS 1.3 are not available, so you get the consensual aspect that Tim was arguing for without having to modify TLS 1.3.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 10:18:47 -0400

On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon <[email-masked]> wrote:

> The problem is that in modern times we can't assume that collaboration is
> consensual, so the rules in RFC2804 aren't as applicable as they were.
>

Until someone comes up with a technical countermeasure for involuntary
collusion, the solution space is entirely political. This isn't nuclear
science, in which it was conceivable in the 1940's that consensus among the
entire community of nuclear physicists could have crippled the development
of the bomb: the IETF neither discussing nor publishing a document
describing a mechanism for session key sharing does not imply that a
government hell-bent on pervasive surveillance will be unable to force
something down the throats of site admins, because even the
not-entirely-broken ways of doing this are pretty obvious extensions to the
protocol.

We need to dispel the myth that mere inaction on our part will on its own
prevent implementation of these mechanisms, if for no other reason but to
redirect energy to the political arena where the pervasive monitoring
battles *are* actually fought.

> There's no way to have the consensual collaboration use case without
> enabling the non-consensual use case.   Anything we do that makes it easier
> to enable the non-consensual use case is a bad idea.   So in my mind RFC
> 7258 is more applicable here than RFC 2804.
>

No contest.

> The problem with arguing this on the basis of whether or not there is a
> non-wiretapping operational use case for this is that there *is* a
> legitimate non-wiretapping operational use case here.   As I understand it,
> the motivation for doing this is to be able to avoid deploying different
> pieces of DPI hardware differently in data centers.   That's a legitimate
> motivation.   The problem is that (IMHO) it's not a good enough reason to
> standardize this.
>
> I would much rather see people who have this operational use case continue
> to use TLS 1.2 until the custom DPI hardware that they are depending on is
> sufficiently obsolete that they are going to remove it anyway; at that
> point they can retool and switch to TLS 1.3 without needing support for
> static keys.   The advantage of this is that simply using TLS 1.2 signals
> to the client that the privacy protections of TLS 1.3 are not available, so
> you get the consensual aspect that Tim was arguing for without having to
> modify TLS 1.3.
>

Absolutely. Your recommendation (among others') is precisely why I am
opposed to censoring this (or any) discussion. We're not the protocol
police: while there is simply no way for us to prevent implementors from
doing misguided things, we can provide alternatives and recommendations
along with justifications for those judgments. But I see this discussion as
mostly limited to improving the practical security of actual users, not as
part of some larger war against wiretapping or pervasive surveillance. This
isn't that battle, and this is not where that battle will be fought if
governments decide they want those things.

Kyle

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 10:22:16 -0400

On Jul 12, 2017, at 10:18 AM, Kyle Rose <[email-masked]> wrote:
> We need to dispel the myth that mere inaction on our part will on its own prevent implementation of these mechanisms, if for no other reason but to redirect energy to the political arena where the pervasive monitoring battles *are* actually fought.

Inaction on our part will prevent the code from going into the common distributions.   That's not worthless.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Jul 2017 10:32:15 -0400

> distributions.   That's not worthless.

Oh, come on.  You've never seen code in a library that implements something
that's not in an IETF RFC?

--Richard

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 10:35:34 -0400

> distributions.   That's not worthless.

Which will have zero impact on pervasive surveillance until some government
decides they want to use this mechanism or something like it and mandates
that it be implemented universally within their borders. Then it will
appear in short order, even if the government has to hire their own code
monkeys to do it, at which point it will continue to have zero impact on
pervasive surveillance.

Again, I'm not recommending any TLS distribution implement this, only that
we stop fooling ourselves into believing that refusing to standardize a
mechanism like this will prevent one from being implemented when someone
decides they want it.

This is fundamentally different from the question of standardizing
potentially privacy-violating protocol extensions that need to survive
end-to-end on the internet to be useful to the third party: this entire
functionality can be implemented at a single endpoint without anyone else's
permission or custom interop.

Kyle

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 10:38:54 -0400

On Jul 12, 2017, at 10:32 AM, Richard Barnes <[email-masked]> wrote:
> Oh, come on.  You've never seen code in a library that implements something that's not in an IETF RFC?  

Of course I have.   I think that putting a warning in the TLS 1.3 spec as Christian suggested will mean that the code won't appear in places where there isn't a strong use case for it.   It may well appear in places where there is a strong use case, but anything open source is going to face a stiff headwind in terms of implementing this, and that's what I'm suggesting we encourage.   If it doesn't show up in openssl, gnutls or boringssl, it's a much smaller problem.   We can't actually stop it happening—I'm just arguing for not making it convenient.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 10:41:32 -0400

On Jul 12, 2017, at 10:35 AM, Kyle Rose <[email-masked]> wrote:
> Which will have zero impact on pervasive surveillance until some government decides they want to use this mechanism or something like it and mandates that it be implemented universally within their borders. Then it will appear in short order, even if the government has to hire their own code monkeys to do it, at which point it will continue to have zero impact on pervasive surveillance.

Right, and then there will have to be a public debate.   I expect that exactly what you describe will happen or be attempted in various jurisdictions.   That's okay.   Requiring this stuff to be done publicly is better than it happening in secret.

(Is this conversation still really useful?   I don't think I'm saying anything you don't already know, so I don't know why you made this point.)

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 10:45:18 -0400

On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon <[email-masked]> wrote:

> Of course I have.   I think that putting a warning in the TLS 1.3 spec as
> Christian suggested will mean that the code won't appear in places where
> there isn't a strong use case for it.   It may well appear in places where
> there is a strong use case, but anything open source is going to face a
> stiff headwind in terms of implementing this, and that's what I'm
> suggesting we encourage.   If it doesn't show up in openssl, gnutls or
> boringssl, it's a much smaller problem.   We can't actually stop it
> happening—I'm just arguing for not making it convenient.
>

Knowing the people involved in at least some of those projects, there is
very little chance of that happening. Beyond that lies political action,
which is definitely not what the TLS WG mailing list should be used for.

To your last email, I agree that we've mostly beaten this to death. I'm
happy to let the conversation move elsewhere.

Kyle

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Jul 2017 18:08:31 +0300

> an obvious issue with forward secrecy.

Yes, the cost saturates very rapidly as the number of reuses increases.
Even 100 reuses gets one within ~1% of asymptotic limit (half load).

> (https://github.com/tlswg/tls13-spec/pull/1049).

I didn't see this document the attack on integerity (full MITM attack)
of the connection if attacker has aquired the DH share before the
connection.

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jul 2017 16:18:23 +0100

On 12/07/17 13:24, Kyle Rose wrote:
> or private DH share to the third party.

I agree if there are only two parties, i.e. some deployments
of schemes like this wiretapping scheme, do not meet the
definition of wiretapping in 2804.

> If one endpoint is feeding

That's nonsense. In the POTS case, telcos are collaborating
with their local LEAs and that is wiretapping. Claiming that
no deployment of this scheme (e.g. the SMTP or wordpress.com
type ones already described on the list) meets the 2804
definition is just silly.

S.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 11:27:09 -0400

On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell <[email-masked]

> with their local LEAs and that is wiretapping.

The telco in the POTS case isn't either endpoint. The third-party
surveillance is unknown to those endpoints. Therefore: wiretapping.

Kyle

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jul 2017 16:28:59 +0100

> surveillance is unknown to those endpoints. Therefore: wiretapping.

Same in the wordpress.com or smtp/tls cases already
described on list. Therefore: wiretapping.

My point was that "collaborating" does not mean not
wiretapping. Saying otherwise is what'd be silly.

S.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 12 Jul 2017 11:54:30 -0400

On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell <[email-masked]

> wiretapping. Saying otherwise is what'd be silly.

And yet that's what 2804, what you have repeatedly cited, explicitly
states. I'm going to go with the definition given there, "silly" or not.
This isn't wiretapping: it's *something else* potentially bad, but not all
surveillance is wiretapping.

Kyle

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jul 2017 17:18:48 +0100

> states. I'm going to go with the definition given there, "silly" or not.

The definition in 2804 is not silly, nor did I say it was.

I said your implication that "collaboration" => "not
wiretapping" was silly.

> surveillance is wiretapping.

Not all surveillance is wiretapping, sure, that is
true.

What is also true is that the draft being discussed
is entirely clearly usable for wiretapping in some
applications that use TLS according to the definition
in 2804.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 12 Jul 2017 22:01:18 +0200

With no hat on...

Sent from my iPhone

> On Jul 12, 2017, at 6:18 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
The difference with the WordPress & SMTP examples is that you know content will sit in plaintext on the servers, whereas with POTS, you need to wiretap to get the voice content. You only expect the log that the call transpired to exist with the service provider.

I'm still in a mode of listening to arguments,  but wanted to point this out in case better examples emerged.

Thanks,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jul 2017 21:16:07 +0100

On 12/07/17 21:01, Kathleen Moriarty wrote:
> With no hat on...
> 
> The difference with the WordPress & SMTP examples is that you know
> content will sit in plaintext on the servers, whereas with POTS, you
> need to wiretap to get the voice content. You only expect the log
> that the call transpired to exist with the service provider.

Sure POTS != the web or smtp, though 2804 specifically calls
out pen-traces as being covered, so we're not only dealing with
bulk call content.

But in any case the precise mechanisms used to get the pen-trace
equivalent or the bulk content to the wiretapper as cleartext isn't
really significant  - whether that be via a carload of tapes, a fat
pipe from the MTA or wordpress.com-like site to the wiretapper, or
via a few KB-per-DH-private if the wiretapper already has the bulk
ciphertext in hand. The crucial thing here is that the leak of the
DH private values is needed to enable that ciphertext to be rendered
as plain, and this proposed mechanism is how that part of the wiretap
service would be enabled, and that's why these examples fit the
2804 definition.

Put another way - it doesn't matter if a traditional POTs wiretap
is done via a conference call setup (frequently done) or by actually
recording to a tape device as was done in the past. And just the
same, it doesn't matter that the mail or web content is also
available as plaintext to the leaker of the DH private value. All
of those can be used to provide a wiretap service as per the 2804
definitions. (In fact a wiretap based on leaking DH private values
would be much more efficient for an entity that already has the
capability to capture packets are lots of places on the Internet,
but that's not that important in terms of whether the 2804 term
is right or not.)

Does that help?

Cheers,
S.

> 
> I'm still in a mode of listening to arguments,  but wanted to point
> this out in case better examples emerged.
> 
> Thanks, Kathleen
> 
> 
>> What is also true is that the draft being discussed is entirely
>> clearly usable for wiretapping in some applications that use TLS
>> according to the definition in 2804.
>> 
>> S.
>> 
>> 
>>> 
>>> Kyle
>>> 
>>