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

[Stephen Farrell]

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
>>> 
>> 
>> ___ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

With no hat on...

Sent from my iPhone

> On Jul 12, 2017, at 6:18 PM, Stephen Farrell  
> wrote:
> 
> 
> 
>> On 12/07/17 16:54, Kyle Rose wrote:
>> On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell >> wrote:
>> 
>>> 
>>> 
 On 12/07/17 16:27, Kyle Rose wrote:
 The telco in the POTS case isn't either endpoint. The third-party
 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.
>>> 
>> 
>> 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.
> 
> The definition in 2804 is not silly, nor did I say it was.
> 
> I said your implication that "collaboration" => "not
> wiretapping" was silly.
> 
>> This isn't wiretapping: it's *something else* potentially bad, but not all
>> surveillance is wiretapping.
> 
> Not all surveillance is wiretapping, sure, that is
> true.
> 
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 


> 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
>> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 12/07/17 16:54, Kyle Rose wrote:
> On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell > wrote:
> 
>>
>>
>> On 12/07/17 16:27, Kyle Rose wrote:
>>> The telco in the POTS case isn't either endpoint. The third-party
>>> 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.
>>
> 
> 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.

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

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

> This isn't wiretapping: it's *something else* potentially bad, but not all
> 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.


> 
> Kyle
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell  wrote:

>
>
> On 12/07/17 16:27, Kyle Rose wrote:
> > The telco in the POTS case isn't either endpoint. The third-party
> > 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell  wrote:

> > 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.
>
> That's nonsense. In the POTS case, telcos are collaborating
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon  wrote:

> On Jul 12, 2017, at 10:32 AM, Richard Barnes  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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 12, 2017, at 10:35 AM, Kyle Rose  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.)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon  wrote:

> On Jul 12, 2017, at 10:18 AM, Kyle Rose  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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Richard Barnes]

On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon  wrote:

> On Jul 12, 2017, at 10:18 AM, Kyle Rose  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.
>

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

--Richard
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 12, 2017, at 10:18 AM, Kyle Rose  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon  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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 12, 2017, at 8:24 AM, Kyle Rose  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Rose]

On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon  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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bill Frantz]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Tue, Jul 11, 2017 at 05:16:31PM -0400, Ted Lemon wrote:
> On Jul 11, 2017, at 4:58 PM, Ted Lemon  wrote:
> > On Jul 11, 2017, at 4:31 PM, Stephen Farrell  > > wrote:
> >> 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.
> > 
> > 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
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.

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



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 12 Jul 2017, at 0:21, Stephen Farrell  wrote:
> 
> 
> 
> 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.

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  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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 11 Jul 2017, at 23:54, Christian Huitema  wrote:
> 
> On 7/11/2017 1:31 PM, Stephen Farrell wrote:
> 
>> 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.
> 
> 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 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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I’d rather not deal with this whole mess.

--
Regards,
Uri 

On 7/11/2017, 16:56, "TLS on behalf of Christian Huitema"  wrote:

On 7/11/2017 1:31 PM, Stephen Farrell wrote:

> 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.

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





smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

On 7/11/2017 1:31 PM, Stephen Farrell wrote:

> 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.

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




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 11, 2017, at 3:59 PM, Stephen Farrell  wrote:
> 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.

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.

> 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.

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_.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 11, 2017, at 3:40 PM, Stephen Farrell  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. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 11/07/17 20:11, Christian Huitema wrote:
> 
> 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.

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.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael StJohns]

On 7/10/2017 3:38 PM, Stephen Farrell wrote:


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

It's clear that there is a strong distaste here for the kind of MITM being
talked about

It is not (only) "distaste," it is IETF policy as a result of
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




S



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, July 11, 2017 7:02 AM
To: Stephen Farrell <stephen.farr...@cs.tcd.ie>
Cc: Polk, Tim (Fed) <william.p...@nist.gov>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 10, 2017, at 5:35 PM, Stephen Farrell 
<stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> 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.

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.



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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Jul 10, 2017, at 5:35 PM, Stephen Farrell  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.
> 
> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 10, 2017 4:09 PM, "Eric Mill"  wrote:

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley  wrote:
>
> >> 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?
>
> 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?


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

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


> Russ
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jeffrey Walton]

On Mon, Jul 10, 2017 at 3:37 PM, Stephen Farrell
 wrote:
>
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Mill]

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley  wrote:
>
> >> 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?
>
> 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


> Russ
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 10/07/17 23:32, 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?
>>> 
>>> 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.
>> 
>> [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.
> 

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

S.

> Russ
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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?
>> 
>> 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.
> 
> [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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 10/07/17 23:07, 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?
> 
> 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.

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

> 
> Russ
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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?

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.

> 
> Russ
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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.

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

> On Jul 10, 2017, at 15:29, Stephen Farrell  wrote:
> 
> You did not respond about the Prague agenda. I continue to ask that
> you not give this bad idea more f2f time. If you do give it time,
> then I'd ask for equal time to debunk this bad idea. But better to
> have zero time.

Thanks for point this out.  We have adjusted the agenda but only to make room 
for 
draft-ietf-tls-dnssec-chain-extension and to rearrange the topics:
https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-01
Note that the time allocated for this topics includes discussion time, where I 
have no there will be a mad dash to get to the mic.

spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:watsonbl...@gmail.com]
Sent: Monday, July 10, 2017 4:11 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: Polk, Tim (Fed) <william.p...@nist.gov>; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On Jul 10, 2017 8:46 AM, "Ackermann, Michael" 
<mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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.

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:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On Behalf 
Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls@ietf.org<mailto:tls@ietf.org>
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.

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.iet

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

[Stephen Farrell]

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:stephen.farr...@cs.tcd.ie] Sent: Monday, July 10, 2017 3:37
> PM To: Ackermann, Michael <mackerm...@bcbsm.com>; Polk, Tim (Fed)
> <william.p...@nist.gov>; tls@ietf.org Subject: Re: [TLS] chairs -
> please shutdown wiretapping discussion...
> 
> 
> 
> On 10/07/17 16:30, Ackermann, Michael wrote:
>> 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.
> 
> 
> 
> 
> 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.
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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:stephen.farr...@cs.tcd.ie] 
Sent: Monday, July 10, 2017 3:37 PM
To: Ackermann, Michael <mackerm...@bcbsm.com>; Polk, Tim (Fed) 
<william.p...@nist.gov>; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On 10/07/17 16:30, Ackermann, Michael wrote:
> 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.




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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <mackerm...@bcbsm.com> 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.



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:tls-boun...@ietf.org] *On Behalf Of *Polk, Tim (Fed)
*Sent:* Monday, July 10, 2017 9:54 AM
*To:* tls@ietf.org
*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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Mon, Jul 10, 2017 at 08:29:26PM +0100, Stephen Farrell wrote:
> On 10/07/17 17:57, Sean Turner wrote:
> > After some discussion amongst the chairs, we have decided to not shut
> > down the discussion about draft-green-tls-static-dh-in-tls13.  
> 
> Ok, that's your call. But a bad call IMO.

IMO there's a trivial fix: make draft-green-tls-static-dh-in-tls13 an
individual submission targeting Informational, and allow discussion on
the TLS WG without making it a WG item (meaning, too, that no WG
milestone should refer to it).

Given that the entire text of draft-green-tls-static-dh-in-tls13 looks
like it's informational ("if you want key escrow with TLS 1.3, this is
how you might do it"), Informational looks right.

(BCP would not be appropriate, since on the cap-I Internet we would want
this deployed.  And as to intranets, we don't care.)

An I-D specifying a protocol for doing key auditing for escrow purposes
could be Standards-Track, since it could be a protocol that many need to
interop with.  But it wouldn't necessarily be a TLS WG item.  And we
might still want it to be Informational (since we can specify protocols
that way as well).

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 10/07/17 17:42, Colm MacCárthaigh wrote:
> It's clear that there is a strong distaste here for the kind of MITM being
> talked about

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

S



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 10/07/17 16:30, Ackermann, Michael wrote:
> 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.




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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"
>  wrote:
> 
> On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
>>> On 10 Jul 2017, at 17:16, Stephen Farrell
>>>  wrote:
 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.
>> 
>> 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.
> 
> 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 --
> 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 10/07/17 17:57, Sean Turner wrote:
> Stephen,
> 
> After some discussion amongst the chairs, we have decided to not shut
> down the discussion about draft-green-tls-static-dh-in-tls13.  

Ok, that's your call. But a bad call IMO.

This topic, if not the specific draft, was already the subject
of significant debate during which the use of static DH values
was raised. I think you are putting the WG participants through
repetitive calls here for no good reason. (The fact that a -01
was emitted and new authors added is not IMO a good reason.)

So I'd ask that you review the previous related threads and
consider again if the basic idea behind this hasn't already
been rejected by the WG in the recent past.

In text below I'll assume you do that but decide to have an
adoption call nonetheless (though I hope you review the mail
archive and decide to reconsider).

> We are
> not shutting down this discussion because this topic is relevant to
> the constituents on both sides of the issue in the working group and
> there is a concrete proposal to discuss. 

That seems to me to be a recipe for whack-a-mole - we have seen
these break-tls proposals over and over and handling it your way
seems like it'll encourage more of 'em.

> Now that we know the
> authors are going to ask for WG adoption, the resulting working
> group's consensus or lack of consensus on this approach will be
> useful information for other discussions that will happen in the
> broader IETF community regardless of the outcome.  

I have no idea of the process problems that that'll create if
the WG go crazy and decide to adopt this despite it conflicting
with 2804 and given all the inevitable follow up wiretapping
additions that'll be proposed for quic and pretty much everything
else, if the TLS wg are seen to "fold." Seems like a recipe for
lots of confused process lawyering to me, but hopefully that'll
not turn out to be an issue.

> Further, we intend
> for consensus on the issue to be called quickly.

I'm against it:-)

> 
> We also do not believe that this discussion is derailing the TLS1.3
> draft, we are consistently surprised by the WG’s bandwidth and the
> draft is out for a 2nd targeted WGLC.  As far as DTLS1.3, the
> specification is coming along but is not at a critical point where we
> believe this discussion will greatly detract from its development.
> 

You did not respond about the Prague agenda. I continue to ask that
you not give this bad idea more f2f time. If you do give it time,
then I'd ask for equal time to debunk this bad idea. But better to
have zero time.

S.

> J
> 
>> On Jul 8, 2017, at 05:17, Stephen Farrell
>>  wrote:
>> 
>> 
>> Sean/Joe,
>> 
>> This is a request that you, as chairs, shut down the distracting 
>> wiretapping discussion, at least until DTLS1.3 is done.
>> 
>> I have planned to spend time reading draft 21 and DTLS, but that 
>> won't happen if we keep having to fight off the latest attempts to
>> break TLS. I'd not be surprised if I weren't the only one finding
>> that distraction an irritating waste of time. Finishing TLS1.3 and
>> getting DTLS1.3 on the way surely needs to not be constantly
>> de-railed by these attempts to break TLS.
>> 
>> Therefore I'd ask that you declare this discussion closed for at 
>> least that long (i.e until DTLS1.3 is done).
>> 
>> I'd also ask that you not allocate agenda time for wiretapping in
>> Prague.
>> 
>> Thanks, S.
>> 
>> ___ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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"  wrote:

On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> > On 10 Jul 2017, at 17:16, Stephen Farrell  
wrote:
> >> 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.
> 
> 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.

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
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> > On 10 Jul 2017, at 17:16, Stephen Farrell  wrote:
> >> 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.
> 
> 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.

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
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 10 Jul 2017, at 17:16, Stephen Farrell  wrote:
> 
> 
>> 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.

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


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

Stephen,

After some discussion amongst the chairs, we have decided to not shut down the 
discussion about draft-green-tls-static-dh-in-tls13.  We are not shutting down 
this discussion because this topic is relevant to the constituents on both 
sides of the issue in the working group and there is a concrete proposal to 
discuss.  Now that we know the authors are going to ask for WG adoption, the 
resulting working group's consensus or lack of consensus on this approach will 
be useful information for other discussions that will happen in the broader 
IETF community regardless of the outcome.  Further, we intend for consensus on 
the issue to be called quickly.

We also do not believe that this discussion is derailing the TLS1.3 draft, we 
are consistently surprised by the WG’s bandwidth and the draft is out for a 2nd 
targeted WGLC.  As far as DTLS1.3, the specification is coming along but is not 
at a critical point where we believe this discussion will greatly detract from 
its development.

J

> On Jul 8, 2017, at 05:17, Stephen Farrell  wrote:
> 
> 
> Sean/Joe,
> 
> This is a request that you, as chairs, shut down the distracting
> wiretapping discussion, at least until DTLS1.3 is done.
> 
> I have planned to spend time reading draft 21 and DTLS, but that
> won't happen if we keep having to fight off the latest attempts
> to break TLS. I'd not be surprised if I weren't the only one
> finding that distraction an irritating waste of time. Finishing
> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
> constantly de-railed by these attempts to break TLS.
> 
> Therefore I'd ask that you declare this discussion closed for at
> least that long (i.e until DTLS1.3 is done).
> 
> I'd also ask that you not allocate agenda time for wiretapping
> in Prague.
> 
> Thanks,
> S.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos 
wrote:

> Certainly, but that doesn't need to happen on this working group, nor
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

+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:tls-boun...@ietf.org] On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls@ietf.org
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nikos Mavrogiannopoulos]

On Mon, 2017-07-10 at 13: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.
>  
> Second, I believe that this discussion should go forward based on
> several points:
> 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!
>  
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.)

> 
> 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 

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 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Polk, Tim (Fed)]

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.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

Message received.  Expect a response in a couple of hours.

spt

> On Jul 8, 2017, at 05:17, Stephen Farrell  wrote:
> 
> 
> Sean/Joe,
> 
> This is a request that you, as chairs, shut down the distracting
> wiretapping discussion, at least until DTLS1.3 is done.
> 
> I have planned to spend time reading draft 21 and DTLS, but that
> won't happen if we keep having to fight off the latest attempts
> to break TLS. I'd not be surprised if I weren't the only one
> finding that distraction an irritating waste of time. Finishing
> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
> constantly de-railed by these attempts to break TLS.
> 
> Therefore I'd ask that you declare this discussion closed for at
> least that long (i.e until DTLS1.3 is done).
> 
> I'd also ask that you not allocate agenda time for wiretapping
> in Prague.
> 
> Thanks,
> S.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 09/07/17 07:23, Colm MacCárthaigh wrote:
> Dismissing concerns with trivial and shallow analysis can serve to diminish
> the success of TLS1.3, because the users don't need to adopt it, and can
> end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX
> environments".

Over the last ~ year and a half, since these folks have
started openly bemoaning the lack of rsa key transport
in tls1.3, I'd guess there've been a few hundred messages
on the list on that topic alone. That is not dismissal,
that's having had more than a fair hearing. As you note,
it is entirely ok that they do not get what they want at
the end of that IMO extremely over-extended process.

Again, I would ask that the chairs chime in as to whether
they would like to see this distraction/discussion be
continued or stopped.

S.




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dan Brown]

I agree with Stephen: this ID and all its detailed discussion should move over 
to the Intranet ETF and/or the Internet Subverting TF (wherever such a TF may 
be).‎ TLS 1.3 is already a big change.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Stephen Farrell
Sent: Saturday, July 8, 2017 5:17 AM
To: tls chair
Cc: tls@ietf.org
Subject: [TLS] chairs - please shutdown wiretapping discussion...


Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sat, Jul 8, 2017 at 6:04 PM, Eric Mill  wrote:

>
> Stating that proxies are not viable for enterprise organizations due to
> the scale and complexity of their network environments is subjective,
> generally not well-detailed, and much more open to skepticism.
>
> The burden on the proposers should be to address this skepticism, and to
> justify to the working group why enterprises that are large enough and
> well-funded enough to have such vast and complex networks cannot invest in
> upgrading those networks to an approach that doesn't rely on directly
> weakening their own connection security and potentially the security of
> others' through the unintended consequences of formalizing this RFC.
>

TLS1.3 isn't a debate, or a legal argument. It's an actual thing in the
world that we'd like to see succeed and be as pervasive as possible. The
folks reporting saying it won't work are doing us a favor, they don't owe
us anything.

So when those users show up saying "This won't work for me", it is better
to have a very open mind and make every attempt to understand them. If
their explanations are not clear, then burrow further. Be charitable and
lean as heavily towards why they may be right, search for good reasoning in
/their/ favor, and state it as well as it can possibly be presented. Only
on those terms try to tackle it with alternatives.

If the presenters are wrong, and the skepticism is merited, that approach
will still work. But if they happen to be right, it makes the alternatives
or adaptations more clear, or the necessity for them more obvious.
Dismissing concerns with trivial and shallow analysis can serve to diminish
the success of TLS1.3, because the users don't need to adopt it, and can
end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX
environments".

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Mill]

On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner <paul.tur...@venafi.com> wrote:
>
> The Internet Draft describes the use of static (EC)DHE for traffic
> entirely inside enterprise networks and intends to clearly state that it
> should not be used for "information passed across the Internet". If we have
> not been clear enough on that in the document, please tell us how we can be
> more clear. Assuming that the document is clear on this point, it would not
> then apply to "wiretapping" as defined in RFC 2804 (as Russ mentioned in an
> earlier email).
>

The IETF's position as expressed in 2804 is on technologies that
"facilitate" wiretapping. What the RFC says the protocol is "intended for"
in layer 8 isn't as relevant as how the technology could easily be used,
once standardized.

The burden on the proposers should be to demonstrate that the technology
can *only* be used in the manner of its stated intent, even if the humans
involved were all hostile, or compelled to be hostile.

You have stated that there are alternatives by using proxies but enterprise
> organizations have stated this is not viable due to the complexity and
> scale of their network environments.


Not all statements are created equal. Stating that proxies can technically
fulfill this function is objective, and can be backed up in clear technical
detail.

Stating that proxies are not viable for enterprise organizations due to the
scale and complexity of their network environments is subjective, generally
not well-detailed, and much more open to skepticism.

The burden on the proposers should be to address this skepticism, and to
justify to the working group why enterprises that are large enough and
well-funded enough to have such vast and complex networks cannot invest in
upgrading those networks to an approach that doesn't rely on directly
weakening their own connection security and potentially the security of
others' through the unintended consequences of formalizing this RFC.


> Our collective objective is to increase the security of the Internet at
> large. As such, we have proposed this RFC in order to ensure that TLS 1.3
> is adopted as broadly as possible inside of enterprises, which is an
> important step in increasing security.


So is increasing the use of forward secret connections within enterprise
network environments. Why should the TLS WG accept the argument that legacy
approaches to monitoring enterprise networks are worth risking the
weakening of the product of years of hard work?

-- Eric


-Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
> Sent: Saturday, July 8, 2017 10:33
> To: Yaron Sheffer <yaronf.i...@gmail.com>; tls chair <
> tls-cha...@tools.ietf.org>
> Cc: tls@ietf.org
> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
>
>
>
> On 08/07/17 15:27, Yaron Sheffer wrote:
> > Hi Stephen,
> >
> > Like you, I am very unhappy with this draft, and would not support its
> > adoption as a WG draft. However I think that open discussion is in
> > general good, and that the best venue for discussion of this draft is
> > this mailing list. Even if some of this discussion devolves into
> > generic "are we pro or against wiretapping" questions.
>
> FWIW I believe that we have had that discussion about breaking tls over
> and over on this and other lists. I see no value in doing it yet again,
> even if the proximate cause is a new variation of the "here's a way to
> break tls" class of drafts. (Someday we should find someone who'd document
> all the broken break-tls ideas that have been rightly rejected over the
> years.)
>
> >
> > I don't think this is a significant distraction that could derail
> > (D)TLS, moreover, you will recall that in Chicago several new drafts
> > were adopted to the working group. So the WG does feel that TLS is in
> > good enough shape that we can spend some bandwidth on other things.
>
> Maybe I'm more easily distracted, at least by this topic;-)
>
> Anyway, I'm fine that it's for the chairs to figure that out.
>
> S.
>
>
> > Thanks,
> >
> > Yaron
> >
> >
> > On 08/07/17 12:17, Stephen Farrell wrote:
> >> Sean/Joe,
> >>
> >> This is a request that you, as chairs, shut down the distracting
> >> wiretapping discussion, at least until DTLS1.3 is done.
> >>
> >> I have planned to spend time reading draft 21 and DTLS, but that
> >> won't happen if we keep having to fight off the latest attempts to
> >> break TLS. I'd not be surprised if I weren't the only one finding
> >> that distraction an irritati

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

[Tony Arcieri]

On Sat, Jul 8, 2017 at 11:17 AM Russ Housley  wrote:

> I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not
> enable MitM.  The server does not share the signing private key, so no
> other party can perform a valid handshake.
>

This method allows a middlebox to recover the plaintext of a TLS session.
While I took issue with Stephen's attempts to shut down conversations this
line of inquiry, I have a much, much stronger objection to downplay the
fact that this is still a self-inflicted MitM attack.

Let me be very clear: full plaintext recovery by a passive middlebox
absolutely is "MitM". Just because it does not allow full impersonation of
the server does not make it MitM. It is MitM, and we should be very clear
it is MitM.

Further, the server is choosing to use a (EC)DH key that was generated by
> the key manager, so it is quite different than the mandatory key escrow used
> in the Clipper Chip.
>

It enables the same ends: recovery of session plaintexts, and as I stated
on other threads I would personally prefer a more explicit key escrow
mechanism implemented as a TLS extension, which to some degree would
actually look a bit more like LEAP.

> --
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

Tony:

I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not enable 
MitM.  The server does not share the signing private key, so no other party can 
perform a valid handshake.  Further, the server is choosing to use a (EC)DH key 
that was generated by the key manager, so it is quite different than the 
mandatory key escrow used in the Clipper Chip.

Russ


> On Jul 8, 2017, at 11:39 AM, Tony Arcieri  wrote:
> 
> I was one of the people arguing my hardest against the BITS Security proposal 
> to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 
> 1.3 had already moved forward on what I would call a more modern protocol 
> design of the sort I believe payments companies should embrace to improve 
> their security.
> 
> That said, if people do want to MitM themselves, I would rather there be a 
> single, easily detectable and very explicit way of doing so, as opposed to 
> sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to 
> have a clear answer for these users, less they continue to make (bad) 
> arguments that there is something fundamentally wrong with the design of TLS 
> 1.3 that makes it incompatible with "industry requirements".
> 
> Clearly there are echoes of the scary protocols of yesteryear, i.e. 
> Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the 
> image header you will discover he is quite familiar with these things, and my 
> personal presumption would be he is not displaying this image to show his 
> undying love of the Clipper chip, although perhaps he's an especially crafty 
> and duplicitous NSA sleeper agent.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 8 Jul 2017, at 18:39, Tony Arcieri  wrote:
> 
> I was one of the people arguing my hardest against the BITS Security proposal 
> to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 
> 1.3 had already moved forward on what I would call a more modern protocol 
> design of the sort I believe payments companies should embrace to improve 
> their security.
> 
> That said, if people do want to MitM themselves, I would rather there be a 
> single, easily detectable and very explicit way of doing so, as opposed to 
> sketchy, incompatible, ad hoc mechanisms.

But all the MITM solutions, whether proxies or static DH are not easily 
detectable. Client-side proxies - the kind deployed by enterprises - are 
visible to clients (by the CA signing the proxy certificates) but not to the 
servers. This is implemented on the server, but is invisible to the client.  
Even if the client rapid-fires several handshakes to see if the public key does 
not change, this is indistinguishable from the optimization of using the same 
key-pair for several seconds (without saving the private key).

> Furthermore, it would be nice to have a clear answer for these users, less 
> they continue to make (bad) arguments that there is something fundamentally 
> wrong with the design of TLS 1.3 that makes it incompatible with "industry 
> requirements".
> 
> Clearly there are echoes of the scary protocols of yesteryear, i.e. 
> Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the 
> image header you will discover he is quite familiar with these things, and my 
> personal presumption would be he is not displaying this image to show his 
> undying love of the Clipper chip, although perhaps he's an especially crafty 
> and duplicitous NSA sleeper agent.

It’s not about the reputations or motivations of the impressive list of 
authors. It’s about having the capability built into widely used products and 
libraries.

Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA 
certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose further that 
your server is using the ever popular Apache/modssl/openssl stack.

If you want to disable forward secrecy you have to either replace the 
certificate with an RSA certificate and move to all static RSA ciphersuites, or 
you need to replace your stack with something that does what this draft 
describes.

With this draft widely implemented it’s just a matter of turning the capability 
on.

We can’t really stop people implementing it, It’s not detectable by the client 
and an implementation would seem to be fully compliant with TLS 1.3.  And I 
don’t know how to implement this in such a way that it would work for “good” 
purposes but not for “bad” purposes, however one defines good and bad here.


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 08/07/17 16:31, Paul Turner wrote:
> Stephen,
> 
> You have referenced RFC 2804, which states the following in section
> 3:
> 
> "For the purposes of this memo, the following definition of
> wiretapping is used: 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"

The draft matches 2804 for many uses of TLS. E.g. anyone with
a hosted web service without access to the underlying http server
config. That's millions of people I believe. I do not believe
that is fixable.

> 
> The Internet Draft describes the use of static (EC)DHE for traffic
> entirely inside enterprise networks 

No it doesn't. There is no definition of enterprise network
not any mechanism for constraining deployment to such. Nor
can there be, other than pretense and pixie-dust.

> and intends to clearly state that
> it should not be used for "information passed across the Internet".

Yes, you may intend to say something like that but it's nonsense.
TLS is used in far too many contexts for that to be a reasonable
approach.

> If we have not been clear enough on that in the document, please tell
> us how we can be more clear. 

Remove the "standards track" header and go elsewhere is IMO
the only sensible outcome. It is not possible, nor useful,
to attempt to fix the draft as-is.

> Assuming that the document is clear on
> this point, it would not then apply to "wiretapping" as defined in
> RFC 2804 (as Russ mentioned in an earlier email).

Yes, you are both incorrect there.

> 
> It would appear then that your concern is that an organization (or
> person) will disregard these two documents and use static (EC)DHE
> keys for their Internet connections. Is that correct?
> 
> Assuming that is correct, here are two considerations:
> 
> 1. Why would an organization that wants to deliberately share the

Coercion. Eg. a NSL in the US.

The proposed method is nice and simple for the web site and
from the point of a wiretapper puts the packet capture burden
nicely where it's wanted in the middle of the network.

> content of TLS encrypted Internet communications with a third party
> go to the trouble of implementing static (EC)DHE keys? Since they are
> an end point in the communications, they have all of the information
> (decrypted) and can share it with the third party without any need
> for static (EC)DHE keys (as I believe Watson pointed out).
> 
> 2. There is nothing in the TLS 1.3 protocol today that would prevent
> someone from implementing static (EC)DHE keys, even if this document
> is not published as an RFC.  If published, this RFC would make it
> clear that must not be done with TLS 1.3.

I would prefer that we impose more strict requirements on
the use of non-static public DH values and forget about this
draft entirely.

I will strongly object to every attempt to do this on the
standards-track with the IETF.

> 
> You have stated that there are alternatives by using proxies but
> enterprise organizations have stated this is not viable due to the> 
> complexity and scale of their network environments.

And others disagreed with that and don't find any problems
with dropping rsa key transport. Assertions that this is
necessary are therefore false. It clearly is not needed for
lots of deployments.

> Our collective
> objective is to increase the security of the Internet at large. 

If so, you are going about it wrong - there BITS-related efforts
all seem to me to be in the direction of weakening security.

S.

> As
> such, we have proposed this RFC in order to ensure that TLS 1.3 is
> adopted as broadly as possible inside of enterprises, which is an
> important step in increasing security.
> 
> Consequently, we would ask that this discussion not be shut down as
> you request.
> 
> Paul
> 
> -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On
> Behalf Of Stephen Farrell Sent: Saturday, July 8, 2017 10:33 To:
> Yaron Sheffer <yaronf.i...@gmail.com>; tls chair
> <tls-cha...@tools.ietf.org> Cc: tls@ietf.org Subject: Re: [TLS]
> chairs - please shutdown wiretapping discussion...
> 
> 
> 
> On 08/07/17 15:27, Yaron Sheffer wrote:
>> Hi Stephen,
>> 
>> Like you, I am very unhappy with this draft, and would not support
>> its adoption as a WG draft. However I think that open discussion is
>> in general good, and that the best venue for discussion of this
>> draft is this mailing list. Even if some of this discussion
>> devolves into generic "are we pro or against wiretapping"
>> questions.
> 
> FWIW I believe that we have had that discussion about breaking tls
> over and over on this and other lists. I see no value in doi

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

[Tony Arcieri]

On Sat, Jul 8, 2017 at 8:44 AM, Stephen Farrell 
wrote:

> On 08/07/17 16:39, Tony Arcieri wrote:
> > Clearly there are echoes of the scary protocols of yesteryear, i.e.
> > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check
> the
> > image header you will discover he is quite familiar with these things,
> and
> > my personal presumption would be he is not displaying this image to show
> > his undying love of the Clipper chip, although perhaps he's an especially
> > crafty and duplicitous NSA sleeper agent.
> >
>
> Reputations are irrelevant to how we evaluate this, though
> I guess can be affected by the drafts one co-authors.
>
> The relevant draft is proposing a wiretapping API for TLS.
>
> That's inconsistent with RFC2804 no matter who proposes it.


Perhaps you should respond to the other two paragraphs in my message?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 08/07/17 16:39, Tony Arcieri wrote:
> Clearly there are echoes of the scary protocols of yesteryear, i.e.
> Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the
> image header you will discover he is quite familiar with these things, and
> my personal presumption would be he is not displaying this image to show
> his undying love of the Clipper chip, although perhaps he's an especially
> crafty and duplicitous NSA sleeper agent.
> 

Reputations are irrelevant to how we evaluate this, though
I guess can be affected by the drafts one co-authors.

The relevant draft is proposing a wiretapping API for TLS.

That's inconsistent with RFC2804 no matter who proposes it.

S.




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

I was one of the people arguing my hardest against the BITS Security
proposal to continue to (ab)use RSA static keys to allow passive MitM, even
though TLS 1.3 had already moved forward on what I would call a more modern
protocol design of the sort I believe payments companies should embrace to
improve their security.

That said, if people do want to MitM themselves, I would rather there be a
single, easily detectable and very explicit way of doing so, as opposed to
sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to
have a clear answer for these users, less they continue to make (bad)
arguments that there is something fundamentally wrong with the design of
TLS 1.3 that makes it incompatible with "industry requirements".

Clearly there are echoes of the scary protocols of yesteryear, i.e.
Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the
image header you will discover he is quite familiar with these things, and
my personal presumption would be he is not displaying this image to show
his undying love of the Clipper chip, although perhaps he's an especially
crafty and duplicitous NSA sleeper agent.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paul Turner]

Stephen,

You have referenced RFC 2804, which states the following in section 3:

"For the purposes of this memo, the following definition of wiretapping is 
used: 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"

The Internet Draft describes the use of static (EC)DHE for traffic entirely 
inside enterprise networks and intends to clearly state that it should not be 
used for "information passed across the Internet". If we have not been clear 
enough on that in the document, please tell us how we can be more clear. 
Assuming that the document is clear on this point, it would not then apply to 
"wiretapping" as defined in RFC 2804 (as Russ mentioned in an earlier email).

It would appear then that your concern is that an organization (or person) will 
disregard these two documents and use static (EC)DHE keys for their Internet 
connections. Is that correct?

Assuming that is correct, here are two considerations:

1. Why would an organization that wants to deliberately share the content of 
TLS encrypted Internet communications with a third party go to the trouble of 
implementing static (EC)DHE keys? Since they are an end point in the 
communications, they have all of the information (decrypted) and can share it 
with the third party without any need for static (EC)DHE keys (as I believe 
Watson pointed out). 

2. There is nothing in the TLS 1.3 protocol today that would prevent someone 
from implementing static (EC)DHE keys, even if this document is not published 
as an RFC.  If published, this RFC would make it clear that must not be done 
with TLS 1.3.

You have stated that there are alternatives by using proxies but enterprise 
organizations have stated this is not viable due to the complexity and scale of 
their network environments. Our collective objective is to increase the 
security of the Internet at large. As such, we have proposed this RFC in order 
to ensure that TLS 1.3 is adopted as broadly as possible inside of enterprises, 
which is an important step in increasing security. 

Consequently, we would ask that this discussion not be shut down as you request.

Paul

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Saturday, July 8, 2017 10:33
To: Yaron Sheffer <yaronf.i...@gmail.com>; tls chair <tls-cha...@tools.ietf.org>
Cc: tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On 08/07/17 15:27, Yaron Sheffer wrote:
> Hi Stephen,
> 
> Like you, I am very unhappy with this draft, and would not support its 
> adoption as a WG draft. However I think that open discussion is in 
> general good, and that the best venue for discussion of this draft is 
> this mailing list. Even if some of this discussion devolves into 
> generic "are we pro or against wiretapping" questions.

FWIW I believe that we have had that discussion about breaking tls over and 
over on this and other lists. I see no value in doing it yet again, even if the 
proximate cause is a new variation of the "here's a way to break tls" class of 
drafts. (Someday we should find someone who'd document all the broken break-tls 
ideas that have been rightly rejected over the years.)

> 
> I don't think this is a significant distraction that could derail 
> (D)TLS, moreover, you will recall that in Chicago several new drafts 
> were adopted to the working group. So the WG does feel that TLS is in 
> good enough shape that we can spend some bandwidth on other things.

Maybe I'm more easily distracted, at least by this topic;-)

Anyway, I'm fine that it's for the chairs to figure that out.

S.


> Thanks,
> 
> Yaron
> 
> 
> On 08/07/17 12:17, Stephen Farrell wrote:
>> Sean/Joe,
>>
>> This is a request that you, as chairs, shut down the distracting 
>> wiretapping discussion, at least until DTLS1.3 is done.
>>
>> I have planned to spend time reading draft 21 and DTLS, but that 
>> won't happen if we keep having to fight off the latest attempts to 
>> break TLS. I'd not be surprised if I weren't the only one finding 
>> that distraction an irritating waste of time. Finishing
>> TLS1.3 and getting DTLS1.3 on the way surely needs to not be 
>> constantly de-railed by these attempts to break TLS.
>>
>> Therefore I'd ask that you declare this discussion closed for at 
>> least that long (i.e until DTLS1.3 is done).
>>
>> I'd also ask that you not allocate agenda time for wiretapping in 
>> Prague.
>>
>> Thanks,
>> S.
>>
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yaron Sheffer]

Hi Stephen,

Like you, I am very unhappy with this draft, and would not support its 
adoption as a WG draft. However I think that open discussion is in 
general good, and that the best venue for discussion of this draft is 
this mailing list. Even if some of this discussion devolves into generic 
"are we pro or against wiretapping" questions.


I don't think this is a significant distraction that could derail 
(D)TLS, moreover, you will recall that in Chicago several new drafts 
were adopted to the working group. So the WG does feel that TLS is in 
good enough shape that we can spend some bandwidth on other things.


Thanks,

Yaron


On 08/07/17 12:17, Stephen Farrell wrote:

Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls