Subject: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

From: Ralph Droms <[email-masked]>
Date: Mon, 2 Oct 2017 16:31:22 -0400

We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session.  The new mechanism does not depend on static handshake or session keys.  

- Ralph and Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Oct 2017 22:23:06 +0100

Sigh:-(

IMO the WG shouldn't touch this terrible proposal with a
bargepole.

And it remains outside the WG's charter I think. (It would be
a good idea if the chairs would clarify that a re-charter would
be needed were the WG to go bonkers and adopt a terrible idea
like this.)

I guess I'll need to update [1] too. I'll get back when I've
had a chance to do that but will happily accept PRs as before
and will keep an eye on the list.

For starters, though, I'd be interested answers from the authors
to two quick questions, though I suspect I can guess 'em:

1. TLS1.3 has had significant formal analysis. Did the authors
or other proponents here do any such work and if so can you send
a pointer to your results? If not, then I believe the onus is on
the folks who want to break TLS to do that work themselves if they
want to make a serious proposal and it is not ok IMO to try put
that work onto the community who have been working hard for years
to make TLS stronger.

2. Which of the hundreds of applications making use of TLS did
you analyse before proposing this? If only a handful, then same
comment wrt where the onus ought lie.

S.

[1] https://github.com/sftcd/tinfoil#latest

On 02/10/17 21:31, Ralph Droms wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Oct 2017 17:43:40 -0400

> that work onto the community who have been working hard for years

I would be willing to work with the people that did the formal analysis to show the impact of including the extension, and making changes to the extension that are indicated by that analysis.

> comment wrt where the onus ought lie.

Just like TLS 1.3 has been implemented and tested with many applications during its development, I would expect the same to happen in those environments where there is interest in making use of this extension.

Russ

---

From: Richard Barnes <[email-masked]>
Date: Mon, 2 Oct 2017 17:51:49 -0400

On Mon, Oct 2, 2017 at 5:43 PM, Russ Housley <[email-masked]> wrote:

> I would be willing to work with the people that did the formal analysis to
> show the impact of including the extension, and making changes to the
> extension that are indicated by that analysis.
>

If you're feeling enterprising, at least one model for TLS 1.3 is open
source.

https://github.com/tls13tamarin/TLS13Tamarin

I'm told that it takes a good part of an hour to run, though, so be
prepared.

--Richard

> Just like TLS 1.3 has been implemented and tested with many applications
> during its development, I would expect the same to happen in those
> environments where there is interest in making use of this extension.
>
> Russ
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Oct 2017 23:48:41 +0100

Russ,

On 02/10/17 22:43, Russ Housley wrote:
>> For starters, though, I'd be interested answers from the authors to
>> two quick questions, though I suspect I can guess 'em:
>> 
>> 1. TLS1.3 has had significant formal analysis. Did the authors or
>> other proponents here do any such work and if so can you send a
>> pointer to your results? If not, then I believe the onus is on the
>> folks who want to break TLS to do that work themselves if they want
>> to make a serious proposal and it is not ok IMO to try put that
>> work onto the community who have been working hard for years to
>> make TLS stronger.
> 
> I would be willing to work with the people that did the formal
> analysis to show the impact of including the extension, and making
> changes to the extension that are indicated by that analysis.
> 

IMO, that's not a good answer. When improving the security
properties of the protocol it may suffice. When weakening
the protocol, I strongly believe the onus is on you to have
done that work ahead of time, so that the damage you are
proposing the Internet suffers is clear and known and not
discovered years later.

>> 2. Which of the hundreds of applications making use of TLS did you
>> analyse before proposing this? If only a handful, then same comment
>> wrt where the onus ought lie.
> 
> Just like TLS 1.3 has been implemented and tested with many
> applications during its development, I would expect the same to
> happen in those environments where there is interest in making use of
> this extension.

The TLS WG has spent an awful lot of effort on (I think)
every single semantic difference between TLS1.2 and TLS1.3.
(Ortt for example.) You are now asking that everyone else
do work to figure out how your proposal damages their uses
of TLS so that this supposed use case is dealt with. I think
you and other proponents of breaking TLS need to spend that
effort yourselves. (This is because as you know there is no
way to limit the damage of your proposal to only the use-cases
that are the claimed targets for this bad idea.)

So yes, those answers are as I expected and are just as
unsurprisingly, utterly unsatisfactory.

S.

---

From: Arnaud Taddei <[email-masked]>
Date: Thu, 5 Oct 2017 10:54:12 +0200

Being new to this community, can I actually ask for the analysis of the ‘hundred’s of applications’ which lead to the evolution of TLS 1.3 the way it is today? Was it captured somewhere or shall I reconstruct this history from all the discussions in the mailing lists?

Thank you in advance

> Le 3 oct. 2017 à 00:48, Stephen Farrell <[email-masked]> a écrit :
> 
> 
> Russ,
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Oct 2017 10:12:04 +0100

On 05/10/17 09:54, Arnaud Taddei wrote:
> Being new to this community, can I actually ask for the analysis of
> the ‘hundred’s of applications’ which lead to the evolution of TLS
> 1.3 the way it is today? Was it captured somewhere or shall I
> reconstruct this history from all the discussions in the mailing
> lists?

It's more the latter. But, and it's a big but, tls1.3
is almost entirely (0rtt aside) aiming to provide the
same services as earlier versions, just to do it better,
so the need for that kind of broad survey of uses of
tls is far less. WRT 0rtt, people did, and are doing,
a bunch of work to figure out when it's (un)safe to
use that.

When it comes to breaking tls (as in this proposal),
since that'd change the security model (from an
essentially two party security protocol to an N-party
model), a lot more work would need to be done, and
has never been done, by any of the people proposing
to break tls, at least afaik.

S.

>>>> For starters, though, I'd be interested answers from the
>>>> authors to two quick questions, though I suspect I can guess
>>>> 'em:
>>>> 
>>>> or other proponents here do any such work and if so can you
>>>> send a pointer to your results? If not, then I believe the onus
>>>> is on the folks who want to break TLS to do that work
>>>> themselves if they want to make a serious proposal and it is
>>>> not ok IMO to try put that work onto the community who have
>>>> been working hard for years to make TLS stronger.
>>> 
>>> analysis to show the impact of including the extension, and
>>> making changes to the extension that are indicated by that
>>> analysis.
>>> 
>> 
>> properties of the protocol it may suffice. When weakening the
>> protocol, I strongly believe the onus is on you to have done that
>> work ahead of time, so that the damage you are proposing the
>> Internet suffers is clear and known and not discovered years
>> later.
>> 
>>> happen in those environments where there is interest in making
>>> use of this extension.
>> 
>> The TLS WG has spent an awful lot of effort on (I think) every
>> single semantic difference between TLS1.2 and TLS1.3. (Ortt for
>> example.) You are now asking that everyone else do work to figure
>> out how your proposal damages their uses of TLS so that this
>> supposed use case is dealt with. I think you and other proponents
>> of breaking TLS need to spend that effort yourselves. (This is
>> because as you know there is no way to limit the damage of your
>> proposal to only the use-cases that are the claimed targets for
>> this bad idea.)
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Arnaud Taddei <[email-masked]>
Date: Thu, 5 Oct 2017 11:14:25 +0200

I see, thank you, it seems that there is a lot of archeological work to be done. 

Ok at least I can organize my work as perhaps a good first step home work before being in a position to comment further

> Le 5 oct. 2017 à 11:12, Stephen Farrell <[email-masked]> a écrit :
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 6 Oct 2017 08:43:25 -0400

Hi Ralph, Russ,

Thanks for the update here.  I agree that this is an improvement over
draft-green-tls-static-dh-in-tls13, in particular because (1) it has a
mechanism for mutual consent and (2) it only touches the outputs of the
handshake, not the inputs.  A couple of points to consider:

Like sftcd, I would like to see some modeling to verify that this has the
expected properties.  (Unlike sftcd, I'm not sure this needs to be done at
the start vs. before it's finished.)  It seems straightforward enough that
I don't expect major issues, but it would be good to check.

It's worth noting that the approach here is all-or-nothing, in contrast to
designs like mcTLS (https://mctls.org/).  The entity to whom the keys are
exfiltrated can make modifications to the session in addition to reading
it.  I think this is probably the right trade-off of simplicity vs. solving
the problem, but maybe it's worth considering, say, a cipher suite with
AEAD plus an additional integrity check, so that you could exfil the AEAD
key and not the integrity key.  That's pretty much what we've done in the
PERC WG with draft-ietf-perc-double to allow middleboxes to make some
changes to an SRTP packet.

I don't think the spec is quite interoperably implementable in its current
state, since it's missing important details on how the wrapping is done
(what AEAD algorithm? how do you make an IV?).  This is obviously something
that can get worked out in WG, should we decide to adopt this draft.

--Richard

On Mon, Oct 2, 2017 at 4:31 PM, Ralph Droms <[email-masked]> wrote:

> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS
> extension defined in this I-D takes into account what we heard from the
> discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00
> in Prague. Specifically, it provides an opt-in capability for both the TLS
> client and server and makes it clear on the wire that visibility will be
> enabled for the session.  The new mechanism does not depend on static
> handshake or session keys.
>
> - Ralph and Russ
>
>

---

From: Nick Sullivan <[email-masked]>
Date: Mon, 09 Oct 2017 20:49:05 +0000

Ralph and Russ,

This draft addresses the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such as how Ke is
used as a symmetric key), but generally I think this approach is more
explicit and therefore less likely to unintentionally impact the broader
internet if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms <[email-masked]> wrote:

> discussion regarding TLS visibility and
> draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides
> an opt-in capability for both the TLS client and server and makes it clear
> on the wire that visibility will be enabled for the session.  The new
> mechanism does not depend on static handshake or session keys.
>
> - Ralph and Russ
>
>

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Wed, 11 Oct 2017 22:24:36 +0000

I'm a newcomer here, so I may be wrong in some aspects (I apologize in advance for that) but at least I'd like to give my opinion...

I really don't feel confortable with the approach taken in this draft. Most of the proponents of these kind of "tapping" limit their scope to datacenters, but I agree with others in that it should be treated as if it will be used on the internet as a whole (as the specification does not prevent this kind of use, and we can't know how users and hosting companies will react to this functionality being available).

It's true that with this approach the client has to opt-in but once it has opted-in, the client has no control over which third party the encryption keys are passed to. Imagine a client opts-in because he knows there is an IPS within the network and the company hosting the server asks him to (I know at least one of our clients would certainly consider this). But some time later a malicious third party manages to coerce the hosting company to provide the keys to them instead (or in addition to) the IPS. From the point of view of the client, he wouldn't notice anything different (only a change in the key identifier but could be due to key renewal)...

I think a way to solve this would be involving the client more in the visibility negotiation. For me, the client not only has to opt-in to the tapping, but should also have the possibility to unambiguosly identify the tapping third-party and accept or reject the connection accordingly. I had some naive idea for this but I was unable to accomodate it in the handshake as it is currently defined (in fact, I don't think this kind of control for the client can be provided without major changes to the handhsake protocol).

I also don't like the way security so greatly depends on SSWrapDH1 (as addressed in point 6 of Security Considerations). I expect many administrators will create long-lived keys in order to avoid the work to have to redistribute them, leaving connections open to attack during months after they take place (until SSWrapDH1 key renewal)...

Anyway, I think key life length could be addressed in later drafts, but the inability of the client to identify (and possibly reject) the tapping third party is a "no go" for me...

   Ion

________________________________
De: TLS <[email-masked]> en nombre de Nick Sullivan <[email-masked]>
Enviado: lunes, 9 de octubre de 2017 22:49
Para: Ralph Droms; [email-masked]
Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph and Russ,

There are clearly some details missing from this draft (such as how Ke is used as a symmetric key), but generally I think this approach is more explicit and therefore less likely to unintentionally impact the broader internet if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms <[email-masked]<mailto:[email-masked]>> wrote:
We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session.  The new mechanism does not depend on static handshake or session keys.

- Ralph and Russ

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

---

From: Hubert Kario <[email-masked]>
Date: Thu, 12 Oct 2017 14:57:28 +0200

On Thursday, 12 October 2017 00:24:36 CEST Ion Larranaga Azcue wrote:
> I'm a newcomer here, so I may be wrong in some aspects (I apologize in
> advance for that) but at least I'd like to give my opinion...
> 
> 
> I really don't feel confortable with the approach taken in this draft. Most
> of the proponents of these kind of "tapping" limit their scope to
> datacenters, but I agree with others in that it should be treated as if it
> will be used on the internet as a whole (as the specification does not
> prevent this kind of use, and we can't know how users and hosting companies
> will react to this functionality being available).
> 
> 
> It's true that with this approach the client has to opt-in but once it has
> opted-in, the client has no control over which third party the encryption
> keys are passed to. Imagine a client opts-in because he knows there is an
> IPS within the network and the company hosting the server asks him to (I
> know at least one of our clients would certainly consider this). But some
> time later a malicious third party manages to coerce the hosting company to
> provide the keys to them instead (or in addition to) the IPS. From the
> point of view of the client, he wouldn't notice anything different (only a
> change in the key identifier but could be due to key renewal)...
> 
> 
> I think a way to solve this would be involving the client more in the
> visibility negotiation. For me, the client not only has to opt-in to the
> tapping, but should also have the possibility to unambiguosly identify the
> tapping third-party and accept or reject the connection accordingly. I had
> some naive idea for this but I was unable to accomodate it in the handshake
> as it is currently defined (in fact, I don't think this kind of control for
> the client can be provided without major changes to the handhsake
> protocol).
> 
> 
> I also don't like the way security so greatly depends on SSWrapDH1 (as
> addressed in point 6 of Security Considerations). I expect many
> administrators will create long-lived keys in order to avoid the work to
> have to redistribute them, leaving connections open to attack during months
> after they take place (until SSWrapDH1 key renewal)...
> 
> 
> Anyway, I think key life length could be addressed in later drafts, but the
> inability of the client to identify (and possibly reject) the tapping third
> party is a "no go" for me...

yes, a three-way DH with two certificates (one IPS one EE server) does seem 
like a much better approach, especially if IPS certs need to have special 
flags that make them useless for anything else and cannot be set by CAs in 
public CA programs.

> De: TLS <[email-masked]> en nombre de Nick Sullivan
> <[email-masked]> Enviado: lunes, 9 de octubre de 2017 22:49
> On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms
> <[email-masked]<mailto:[email-masked]>> wrote: We are about
> to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined
> in this I-D takes into account what we heard from the discussion regarding
> TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague.
> Specifically, it provides an opt-in capability for both the TLS client and
> server and makes it clear on the wire that visibility will be enabled for
> the session.  The new mechanism does not depend on static handshake or
> session keys.
> 
> - Ralph and Russ
> 
> 

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Oct 2017 14:16:08 +0100

(With the obvious caveat that I hate the whole
idea... :-)

> flags that make them useless for anything else and cannot be set by CAs in 

But... even if one did add names/certs for the wiretapper
or IPS or whatever then there could be more than one of
those who'd like to be able to interfere with the TLS
session, and there's no way I can see that makes sense for
the client and server to negotiate which wiretappers they
allow/like.

This is all just squaring-the-circle, TLS is meant to be
a 2-party protocol (ignoring CAs) and I don't see any way
to make TLS a multi-party protocol that works.

S.

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Oct 2017 16:21:18 -0400

Richard:

> Thanks for the update here.  I agree that this is an improvement over draft-green-tls-static-dh-in-tls13, in particular because (1) it has a mechanism for mutual consent and (2) it only touches the outputs of the handshake, not the inputs.

Thanks.

>  A couple of points to consider: 
> 
> Like sftcd, I would like to see some modeling to verify that this has the expected properties.  (Unlike sftcd, I'm not sure this needs to be done at the start vs. before it's finished.)  It seems straightforward enough that I don't expect major issues, but it would be good to check.

I agree.  I'd like to confirm that the extension has the expected properties, but I'm more willing to do that work if the TLS WG adopts the draft.  This is the order that was done for the TLS 1.3 specification.

> It's worth noting that the approach here is all-or-nothing, in contrast to designs like mcTLS (https://mctls.org/).  The entity to whom the keys are exfiltrated can make modifications to the session in addition to reading it.  I think this is probably the right trade-off of simplicity vs. solving the problem, but maybe it's worth considering, say, a cipher suite with AEAD plus an additional integrity check, so that you could exfil the AEAD key and not the integrity key.  That's pretty much what we've done in the PERC WG with draft-ietf-perc-double to allow middleboxes to make some changes to an SRTP packet.

I watched the video of the presentation, and the granularity comes at a pretty high cost.  In fact, mcTLS was designed with TLS 1.2, and the cost would be higher for TLS 1.3 because of the AEAD.  The current extension targets a more simple approach, where after client opt-in the session secrets are shared with other parties that are in the same administrative domain as the server.

> I don't think the spec is quite interoperably implementable in its current state, since it's missing important details on how the wrapping is done (what AEAD algorithm? how do you make an IV?).  This is obviously something that can get worked out in WG, should we decide to adopt this draft.

I am willing to work on adding those important details.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Oct 2017 16:23:48 -0400

Nick:

Thanks for the review.  I am willing to work on the missing details about the use of Ke.

Russ

> On Oct 9, 2017, at 4:49 PM, Nick Sullivan <[email-masked]> wrote:
> 
> Ralph and Russ,
>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 13 Oct 2017 13:05:34 +0200

> (With the obvious caveat that I hate the whole

to be clear: me too
 
> the client and server to negotiate which wiretappers they

my point is, that I may be forced to disclose contents of all my 
communications to a specific entity, so I effectively have to trust it 
(willingly or not), but that doesn't mean that I have to allow for wiretapping 
for arbitrary parties

> to make TLS a multi-party protocol that works.

1. Alice sends a share to Bob: g^a
2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab
3. Carol replies to Bob with her share added to Alice's and his: g^ac, g^bc
4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc
5. Alice calculates the shared secret g^bca
6. Bob calculates the shared secret: g^acb
7. Carol calculates the shared secret: g^abc

so it doesn't look to me like it requires a lot of chamfer to fit that square 
peg in the round hole, only the 2 and 3 need to happen out-of band.

of course, I haven't analysed how Carol would be authenticated in that 
communication (if signing just the SKS by Carol is enough, transferred in the 
encrypted extensions, with server signature of the handshake in certificate 
verify being sufficient for integrity)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Oct 2017 13:45:35 +0100

>> (With the obvious caveat that I hate the whole

IMO the more we hear of that the better

> verify being sufficient for integrity)

So the problems with that are numerous but include:

- there can be >1 carol, (and maybe all the carols also need to
  "approve" of one another), if we were crazy enough to try do
  this we'd have at least:
      - corporate outbound snooper
      - data-centre snooper (if you buy those supposed use-cases)
      - government snooper(s) in places where they don't care about
        doing that openly
  ...port 80 would suddenly be quicker than 443 again;-(
- carol is quite likely to only have a name like: 2001:db8::bad:1dea
  or your.friendly-listener.bigcdn.example.net and authenticating
  those is essentially meaningless to the endpoints in most TLS contexts
  whether or not those endpoints have humans associated with them
- the TLS endpoints can't handle the semantics of allowing in Carol(s)
  as those endpoints were designed to use TLS and not bolloxed-TLS (be
  that mcTLS or draft-rehired)

So I think this ends up as bad as the design in draft-rehired. Which
of them is more obviously bad is another question.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Oct 2017 13:59:28 +0000

I am opposed to the basic concept of injecting a third-party into the E2E TLS process.

We don’t even have a TLS 1.3 RFC yet.  We have no deployments yet.  We have no insight into whether or not there is an actual need for this.  How can we put this on-hold for, say, two years.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 13 Oct 2017 18:28:28 +0200

On Friday, 13 October 2017 14:45:35 CEST Stephen Farrell wrote:
> > so it doesn't look to me like it requires a lot of chamfer to fit that
> > square peg in the round hole, only the 2 and 3 need to happen out-of
> > band.
> > 
> > communication (if signing just the SKS by Carol is enough, transferred in
> > the encrypted extensions, with server signature of the handshake in
> > certificate verify being sufficient for integrity)
> 

true

>       - government snooper(s) in places where they don't care about

out of scope and directly against the WG agenda

>   ...port 80 would suddenly be quicker than 443 again;-(

well, that would be an argument for making the server report the encryption 
keys to the middlebox instead of this squaring of the hole

>   whether or not those endpoints have humans associated with them

not a problem, you need to trust the organisation (internal CA), not specific 
machines

>   that mcTLS or draft-rehired)

which is the entire point of it - we don't want this to be something 
clandestine or invisible to the client
 
> of them is more obviously bad is another question.

"draft-rehired"?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Oct 2017 00:30:33 +0100

Hiya,

> "draft-rehired"?

Apologies. That's how I've been verbalising/pronouncing
draft-rhrd. (*) I think it is useful to have a name that
can be pronounced, and I refuse to abuse language and talk
about this as if "visibility" was even an approximately
correct term;-)

S.

(*) I do have a weak justification:-)

        $ grep "^r.h.r.d" /usr/share/dict/words
        rehired
        $

---

From: Florian Weimer <[email-masked]>
Date: Tue, 17 Oct 2017 14:53:14 +0200

>    ...port 80 would suddenly be quicker than 443 again;-(

And any authorized eavesdropper is not allowed to be able to infer if 
they are the only ones listening in.

I don't understand why this complicated approach is needed.  Why can't 
the server provide an OOB interface to look up sessions keys, or maybe 
export them proactively?  The proposed draft needs a protocol like this 
anyway because SSWrapDH1 keys need to be distributed, and periodic key 
regeneration is needed because it is the only way to implement 
revocation of access privileges without revealing the existence of other 
authorized parties.

I don't buy the argument that there are too many session keys for 
proactive export.  Obviously, you already have sufficient capacity to 
send these keys (or an equivalent) over the wire once, so sending 
another copy or two shouldn't be a problem.

Thanks,
Florian

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Tue, 17 Oct 2017 15:46:15 +0000

> I don't understand why this complicated approach is needed.  Why can't the server provide an OOB 
> interface to look up sessions keys, or maybe export them proactively?  The proposed draft needs a 
> protocol like this anyway because SSWrapDH1 keys need to be distributed, and periodic key 
> regeneration is needed because it is the only way to implement revocation of access privileges 
> without revealing the existence of other authorized parties.

In my opinion, the proposed draft does not define a protocol because it expects that SSWrapDH1 keys will be distributed manually (I may be wrong with this, but that's what I understood as the draft does not specify any key exchange protocol between server and third-party). That's why I think that SSWrapDH1 keys will be very long-lived (administrators will hate having to manually distribute the new key in an hourly or even daily schedule), jeopardizing perfect forward secrecy for a long time.

The problem I see with a "server to third party" OOB look up or export of the keys is that the client will not be notified of this export taking place and so will lose the chance to reject surveillance...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Oct 2017 17:29:20 +0100

On 17/10/17 16:46, Ion Larranaga Azcue wrote:
> The problem I see with a "server to third party" OOB look up or
> export of the keys is that the client will not be notified of this
> export taking place and so will lose the chance to reject
> surveillance...
IIUC, with the draft-rehired proposal, the client
can in any case not be told - the TLS protocol
extensions are mere politeness and the client does
not get to know what snooper(s) are involved, nor
can the client influence the snooping keys. Once,
any infrastructure for this was deployed, I think
it'd be used without telling clients for sure. (And
we would be fully complicit in helping that happen,
if the WG adopted this stuff, because we know that
such abuses would be inevitable.)

I think this WG was correct years ago when we
passed on the DNT proposal which had the same
"just politeness" aspect - the web is not really
such a friendly place that one can depend on the
kindness of strangers. Nor are many of the many
other applications using TLS.

S.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Tue, 17 Oct 2017 18:34:32 +0000

> such abuses would be inevitable.)

Not really. The draft relies on the server sending a non-encrypted extension containing critical information (the session keys encrypted using a shared key between server and third party). The third party is expected to intercept this non-encrypted extension and decrypt it using Ke in order to obtain the session keys. Without this information the third party is unable to fully decrypt the TLS connection. 

If the extension is not sent, the client does not realize there is a third party, but the third party does not have the session keys either, and the server has to provide them in a different way (for instance, using an OOB lookup as Florian suggested). In any case, it's not the same scenario as the draft proposes (the keys are shared in a different way) and can happen with or without this draft being accepted.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Oct 2017 19:38:55 +0100

On 17/10/17 19:34, Ion Larranaga Azcue wrote:
> If the extension is not sent, the client does not realize there is a
> third party, but the third party does not have the session keys
> either, and the server has to provide them in a different way (for
> instance, using an OOB lookup as Florian suggested). In any case,
> it's not the same scenario as the draft proposes (the keys are shared
> in a different way) and can happen with or without this draft being
> accepted.
I agree.

My point is that if this draft were accepted, then the
infrastructure for the above scenario would all be in
place (the DH value for the snooper and the code to expose
session information to that snooper) and the above
scenario would be more likely to happen, more often.
IOW, by standardising draft-rehired, we'd *also* be
putting in place standard building blocks for an OOB,
client is never told mechanism.

S.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Tue, 17 Oct 2017 19:55:24 +0000

> client is never told mechanism.

I don't see it that way... For me, using the capabilities provided by this draft in order to get an OOB-only  "no client involved" mechanism is more difficult and probably less efficient than creating one from scratch...

That being said... One thing that bothers me from my last emails is that I seem to find myself on the draft-defending side of the discussion while I don't really like the draft itself due to the concerns I pointed out in my first email... I'm not fully against adding monitoring capabilities to the protocol, but I would prefer a "no-monitoring-allowed" TLS if the alternative was going with an insecure tapping mechanism.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Oct 2017 12:41:30 -0500

> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-…

This draft does not seem to have anything to address the concern that,
once a visible ClientHello extension is needed to enable wiretapping,
certain parties (e.g., national border firewalls) would reject/drop
*all* ClientHellos not containing that extension, thereby extorting all
clients into "opting in" to the wiretapping and effectively rendering
the "opt-in" requirement useless for those clients.

As a more general comment, I think that this concern is so squarely at
odds with the concern that the client must be able to opt-in to the
wiretapping [and, optionally, be guaranteed by the key schedule to know
when wiretapping is happening] that I do not see any potential for a
workable solution.

-Ben

P.S. I agree with Rich; can we try to defer these conversations until
after 1.3 is actually published?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 14:07:12 +0100

Hiya,

> after 1.3 is actually published?

FWIW, I also think it'd be a good plan if the chairs
did that. I'm happy to oppose these ideas any time,
but later is better than now, given this would further
distract us from 1.3.

S.

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 13:55:25 +0000

Ben,

In the scenario you outlined below, it seems the third party has significant control over the communications of the clients (e.g. national border firewall). In addition, based on your description, it seems they are intent on ensuring that not communications occur unless they can view the communications. In addition, they must be able to coerce the server owner into providing the key (because the proposed method requires opt-in by both the client and the server). This is a significant amount of control that the third party wields. 

In this scenario, wouldn't the state firewall simply require all clients to trust their CA so that they can reverse proxy all communications--since they will likely not only be interested in one server's communications but many? It seems important to keep in mind that each server that a third party wants to listen in on must agree to enable it (opt-in). It would seem that a state run firewall is unlikely to get that agreement from a broad number of servers of interest. And, as you point out, each client will know they're being forced to agree that the third party can listen in on communications (if they choose to continue to communicate with the server). In countries where it is possible to challenge such coercion in a court of law, the client will know they are being forced and can challenge that (or more likely the industry can provide pressure). This method seems to protect against someone like the NSA secretly coercing a server owner into opting in without the knowledge of the client (and the broader community). 

I guess the basic question I'm asking is that if a third party is so powerful that they can do what you describe, aren't they going to force an even more effective method (trusting their CA so that they can terminate the connection as a middle man) on clients so that they don't have to coerce every server?

Thanks,

Paul

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Wednesday, October 18, 2017 13:42
To: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-…

This draft does not seem to have anything to address the concern that, once a visible ClientHello extension is needed to enable wiretapping, certain parties (e.g., national border firewalls) would reject/drop
*all* ClientHellos not containing that extension, thereby extorting all clients into "opting in" to the wiretapping and effectively rendering the "opt-in" requirement useless for those clients.

As a more general comment, I think that this concern is so squarely at odds with the concern that the client must be able to opt-in to the wiretapping [and, optionally, be guaranteed by the key schedule to know when wiretapping is happening] that I do not see any potential for a workable solution.

-Ben

P.S. I agree with Rich; can we try to defer these conversations until after 1.3 is actually published?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 14:15:19 +0000

➢     I guess the basic question I'm asking is that if a third party is so powerful that they can do what you describe, aren't they going to force an even more effective method (trusting their CA so that they can terminate the connection as a middle man) on clients so that they don't have to coerce every server?
    
The stated goal of this work (and its predecessor) is to allow enterprises to capture traffic for later debugging and analysis.  The client could be coming in via the generic public Internet, with a stock browser.

Your question points out a danger of this mechanism: it becomes all too easy to “escape” and enable nationwide wiretapping.

Make sense?

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 14:16:50 +0000

> From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, October 19, 2017 09:07
> To: Benjamin Kaduk <[email-masked]>; [email-masked]
> FWIW, I also think it'd be a good plan if the chairs did that. I'm happy to
> oppose these ideas any time, but later is better than now, given this would
> further distract us from 1.3.

I don't think this is a good plan.

---

From: "Paul Turner" <[email-masked]>
Date: Thu, 19 Oct 2017 10:18:21 -0400

> From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
> Sent: Thursday, October 19, 2017 10:15
> To: Paul Turner <[email-masked]>; Kaduk, Ben
> <[email-masked]>; [email-masked]
> ➢     I guess the basic question I'm asking is that if a third party is so powerful
> that they can do what you describe, aren't they going to force an even more
> effective method (trusting their CA so that they can terminate the connection
> as a middle man) on clients so that they don't have to coerce every server?
> 
> The stated goal of this work (and its predecessor) is to allow enterprises to
> capture traffic for later debugging and analysis.  The client could be coming in
> via the generic public Internet, with a stock browser.
> 
> Your question points out a danger of this mechanism: it becomes all too easy
> to “escape” and enable nationwide wiretapping.
> 
> Make sense?
> 
Can you explain how nationwide wiretapping is going to be easy with this plan? Again, EVERY server owner will need to opt-in.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 14:22:14 +0000

>     Can you explain how nationwide wiretapping is going to be easy with this plan? Again, EVERY server owner will need to opt-in.
   
I didn’t say easy, I said ‘easier’

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 14:23:03 +0000

> From: Salz, Rich [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 10:22
> To: Paul Turner <[email-masked]>; Paul Turner
> <[email-masked]>; Kaduk, Ben <[email-masked]>;
> [email-masked]
> >     Can you explain how nationwide wiretapping is going to be easy with this
> plan? Again, EVERY server owner will need to opt-in.
> 
Can you explain how it is easier?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 14:26:29 +0000

There’s no way to limit it to the use-case it was putatively intended for.  We now have a signaling mechanism that says “allow interception.”  Firewalls can drop connections where the client doesn’t send that extension. Therefore they can force only tappable TLS traffic. This makes the job easier.

I take it you want to see this draft adopted?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 15:37:07 +0100

> I don't think this is a good plan.

Why exactly? What here is so urgent that it needs
to be haggled over before TLS1.3 is done?

TLS1.3 is the major work item for which this WG is
chartered, and breaking TLS is something that is
outside this WG's charter entirely.

I think you'd need a very good argument that any WG
ought prioritise out-of-scope work at the expense
of the main goal of the WG.

S.

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 14:37:47 +0000

> 
> There’s no way to limit it to the use-case it was putatively intended for.  We
> now have a signaling mechanism that says “allow interception.”  Firewalls can
> drop connections where the client doesn’t send that extension. Therefore they
> can force only tappable TLS traffic. This makes the job easier.
> 

Can you please be more specific about the scenario(s) you're describing? 1) Is this for communication between servers within the nation state's boundaries and do they have complete control over the owners of those servers (totalitarian state). 2) Is this for communication between servers within the nation state's boundaries and do they not have complete control over the owners of those servers (an apparently democratic state). 3) Is this for communication between servers outside the nation state's boundaries and do not they not have complete control over the owners of those servers (international scenario). And, based on the scenario, how is the third party going to coerce the server vendors into cooperating (for 1, that seems clear, but then they have complete access to all communications anyways)? I'm not just asking these questions to be difficult. I would like to better understand the scenario in which a client and server can be coerced so that it is possible to judge "easier" against the alternatives.

> I take it you want to see this draft adopted?

Yes but I'm also keeping my mind open to understand all of perspectives to see if something would change my opinion.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 14:47:58 +0000

With this extension, any middlebox anywhere can drop traffic that is not tappable.  Regardless of who controls the clients and servers, we are now enabling entities to block traffic unless you acquiesce. For example, an inflight wifi could use this.  Maybe, ultimately, many/most of the servers that the passengers connect to will not support it, but some might.

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 15:06:37 +0000

> 
> With this extension, any middlebox anywhere can drop traffic that is not
> tappable.  Regardless of who controls the clients and servers, we are now
> enabling entities to block traffic unless you acquiesce. For example, an inflight
> wifi could use this.  Maybe, ultimately, many/most of the servers that the
> passengers connect to will not support it, but some might.
> 

Can't any middlebox block traffic today if the client doesn't agree to trust its CA? If a middlebox drops traffic because the extension was not included, there will be no indication to the client that it was dropped because they didn't include the extension. If the middlebox does display a page back to the client saying "You have to turn on TLS-Visibility so that we can we can look at traffic for a server that we have control over but don't want to get the data from this directly.", how is that different than "You have to trust our CA in order to communicate with this server so we can route you through our reverse proxy. Please download our CA root from the following location and install it."?

The second seems much easier in terms of scenarios 2 and 3 from my previous message.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 15:16:17 +0000

They can already block traffic based on IP address.  That’s single-point blocking.  Being able to block based on the client’s willingness to let their traffic be interception is a whole additional class and it also indicates that the client is willing to let their traffic be intercepted.  The two things are very very very different.

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 15:19:58 +0000

> 
> They can already block traffic based on IP address.  That’s single-point
> blocking.  Being able to block based on the client’s willingness to let their
> traffic be interception is a whole additional class and it also indicates that the
> client is willing to let their traffic be intercepted.  The two things are very very
> very different.
> 

Can you explain the comparison that I brought up regarding trusting the CA? That is related to " the client’s willingness to let their traffic be intercepted".

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 15:35:16 +0000

➢     Can you explain the comparison that I brought up regarding trusting the CA? That is related to " the client’s willingness to let their traffic be intercepted".

Subverting one CA cuts across a large scale of Internet traffic and might be noticed or can be routed around.  Certificate transparency helps prevent a single CA from being coerced into misissuance.  With this extension, someone doesn’t have to coerce a CA or force victims to trust a new CA.  Instead they have to gain the cooperation of the origin(s) they are interested in.  Further, if you mix in a coerced/force-trusted CA, you don’t even need the origin’s cooperation.

---

From: Paul Turner <[email-masked]>
Date: Thu, 19 Oct 2017 17:07:21 +0000

> 
> Subverting one CA cuts across a large scale of Internet traffic and might be
> noticed or can be routed around.  

With respect to "be noticed", forcing clients to opt-in seems like it would clearly be noticed. My understanding was that you were saying that the middlebox could block traffic. That seems in conflict with your statement that they can be "routed around". 

>Certificate transparency helps prevent a
> single CA from being coerced into misissuance.  

It seems like a middlebox that is able to deny traffic (has that level of power, would simply use their own CA and force trust of that)

>With this extension, someone
> doesn’t have to coerce a CA or force victims to trust a new CA.  Instead they
> have to gain the cooperation of the origin(s) they are interested in.  

Gaining the cooperation of the servers (origins) seems relevant. If they get the cooperation of the servers, they can simply get the data directly from them. But, again, they also have to get the cooperation of the clients. 

If a middlebox has sufficient power to block traffic, force clients into opting in, and coerce servers into opting in, it seems like they have sufficient alternative options that are of equivalent effort ("ease").

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 19 Oct 2017 17:12:11 +0000

If those middleboxes already have sufficient alternative options, why do we spend time discussing this draft? Why do we need to add yet another alternative for them?

Regards,
Uri

Sent from my iPhone

> On Oct 19, 2017, at 13:08, Paul Turner <[email-masked]> wrote:
> 
> 
> 
>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Oct 2017 13:15:02 -0400

> If those middleboxes already have sufficient alternative options, why do we spend time discussing this draft? Why do we need to add yet another alternative for them?

Indeed, if this proposal were equivalent to CA forcing, then the solution to the problem this proposal purports to solve would be CA forcing. The reason this proposal is preferred is that it's easier and less apparently invasive than CA forcing.  Making less good crypto have an obviously less good UI is a good thing.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Oct 2017 17:26:55 +0000

We disagree.

Being able to block traffic is much less effort than pretending to be another identity.

---

From: Darin Pettis <[email-masked]>
Date: Thu, 19 Oct 2017 22:30:10 +0000

> Being able to block traffic is much less effort than pretending to be

First I want to thank the TLS WG for all their assistance and conversation
around finding the right methodology for continued visibility.

The question has been raised: "Why address visibility now?"   The answer is
that it is critical that the visibility capability is retained.  It is
available today through the RSA key exchange algorithm.  We understand that
the issue was raised late and have fallen on the preverbal sword for being
late to the party but the issue is real.  That is where the "rhrd" draft
has come from.  A way to retain that visibility capability but with a newer
and more secure protocol.

We need to protect and troubleshoot data that is within each of our
companies.   As encryption becomes more prevalent, it becomes more and more
critical to see that data.

The amount of people currently voicing concern is likely small for two
reasons.  One is that everything is public and many of the "lurkers" are
hesitant to voice their concerns.  The second reason is that so many don't
know that visibility will be an issue.  They will either discover this as
they migrate to TLS 1.3 or as they start to encrypt within their data
center.  There is work to rapidly raise that awareness through roundtables,
conferences and other venues.

It is very positive that the WG has made a number of great recommendations
that have led to this solution.   That is the intention.  We would
appreciate the WG now adopting the extension so that it can be ushered
through the process.   This continued visibility can continue to be
available as we all have expectations that our data is safeguarded and that
websites are available to us quickly.   Thank you for your valued
assistance!

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Oct 2017 15:37:19 -0700

On 10/19/2017 3:30 PM, Darin Pettis wrote:

> reasons.  One is that everything is public and many of the "lurkers"
> are hesitant to voice their concerns.  The second reason is that so
> many don't know that visibility will be an issue.  They will either
> discover this as they migrate to TLS 1.3 or as they start to encrypt
> within their data center.  There is work to rapidly raise that
> awareness through roundtables, conferences and other venues.

Might it be because many of these enterprises and data centers do not in
fact see encryption as a problem? Maybe they have found ways to manage
their applications and servers without breaking TLS...

-- 
Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Oct 2017 20:06:19 -0500

On 10/19/2017 05:30 PM, Darin Pettis wrote:
>
> The question has been raised: "Why address visibility now?"   The
> answer is that it is critical that the visibility capability is
> retained.  It is available today through the RSA key exchange
> algorithm.  We understand that the issue was raised late and have
> fallen on the preverbal sword for being late to the party but the
> issue is real.  That is where the "rhrd" draft has come from.  A way
> to retain that visibility capability but with a newer and more secure
> protocol. 
>

But the "rhrd" draft does not require any changes to the core TLS 1.3
protocol, and in fact I have heard several key participants say that any
"visibility" changes must not require changes to the core protocol.  If
the "visibility" work will be done via extensions, then there is no
ordering requirement for their specification with respect to the core
work, there is only an ordering requirement between them and adoption of
TLS 1.3 in enterprises.  Do you want to argue that a year timescale is
too slow for enterprise adoption of TLS 1.3?  If not, I continue to not
see a reason to address "visibility" now.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2017 11:48:32 +0100

I agree with Christian and Ben's points. I'd also add:

On 19/10/17 23:30, Darin Pettis wrote:
> available today through the RSA key exchange algorithm. 

That yet again ignores the fact that TLS1.2 will continue to
be available, which utterly undermines your argument that we
need to disrupt the work on TLS1.3 with this divisive debate

S

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Oct 2017 13:44:04 +0000

*   The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol.

You achieve your needs right now by sharing the origin’s RSA key with your debugging agents.  You can achieve the same needs in TLS 1.3 by keeping that architecture, although more information must be shared.  This preserves the architecture and becomes “just” implementation.  This has been brought up before.

The first draft showed how to do this purely on the server side.  Some members of the WG rose up and wanted explicit opt-in. The new draft does that.  In retrospect, it turns out that opt-in is worse, mainly that there is no way to guarantee that this does not “escape” onto the public Internet. This makes sense, if you require opt-in from the client, then it is not surprising that, other entities besides the two parties engaged in the TLS protocol could, well, *require* clients to opt-in.  As I and others have tried to show in email exchangers with Paul, this is a fundamental change to the nature of how TLS is used.

Finally, as has also been mentioned, nobody is preventing you from keeping your servers at TLS 1.2 or earlier.  TLS 1.2 was defined by RFC 5246 in 2008. A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will happen any faster?

You have not made your case.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2017 14:54:00 +0100

Minor clarification...

On 20/10/17 14:44, Salz, Rich wrote:
>  Some members of the WG rose up and wanted explicit opt-in

I don't think "wanted" is quite right. Some
WG participants (e.g. me) wanted nothing like
this to ever be done in the IETF. Others did
comment that the lack of client opt-in was a
bad aspect of draft-green, but I'm not sure
that anyone clearly said "I do want draft-green
snooping, but with client opt-in."

S.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Oct 2017 10:08:44 -0400

On Oct 20, 2017, at 9:54 AM, Stephen Farrell <[email-masked]> wrote:
> Others did

I can say for myself that there was a really strong hard sell on the notion of doing this in Prague.   Not being sufficiently paranoid, my general sympathy for people facing hard problems led me to consider what they were proposing, but each time they came up with something, someone with more paranoia fu than I have pointed out a hole in it.   During that period there were several periods when I was reluctantly willing to consider some less-bad version of draft-green.   This is a long way from "want," and even a pretty long way from "support."

My personal feeling having been peeled off the herd and hard-sold like this is that there is some really powerful motivated reasoning going on here, and that the working group should just stop entertaining this process.   Weakening TLS is not the right way to approach the problem that has been described here.

I hasten to add that I don't think the people doing the hard sell are bad people, or that they didn't have good reason for trying to do it.   My point is simply that we've been collectively sucked close to a black hole here, and we need to take a step back from it.   In the same sense that LEOs who want key escrow have good reason for wanting it and are not bad people for wanting it, so too with the people pushing this proposal.   But like key escrow, this proposal is not beneficial for end-users or for security as a whole.

In order for it to make sense to go forward with this proposal, two things would have to be true that I don't think are true.   First, we would have to agree that user security is not a primary goal.   And second, we would have to agree that overall network security is not a primary goal.   Discussing the details of how much security we are willing to give up, what attack surfaces that we could remove we are willing to leave in, only makes sense if we are willing to drop those two primary goals.

Watching this conversation has been a really good learning experience for me, so I don't regret it, but I think we should stop.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 20 Oct 2017 14:14:21 +0000

+1 to Rich.

--

Regards,

Uri Blumenthal

From: TLS <[email-masked]> on behalf of Rich Salz <[email-masked]>
Date: Friday, October 20, 2017 at 09:59
To: Darin Pettis <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ø  The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 20 Oct 2017 16:00:01 +0000

Expressly reacting to the viability of continuing to use TLS1.2 forever.

As a network person,  this sounds a little like suggesting that if we feel there are operational  shortcomings in IPv6,  then we should just plan to stay with IPv4, forever.
And that approach may even be viable for the short term or in isolated situations.
But for the longer term using TLS1.2 is likely to have the following issues for Enterprises:

  *   Industry groups will force us to use newer versions
  *   Policy standards will evolve in similar fashions.
  *   Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in.
  *   Software Products and Applications will attempt to remain current and will eventually sunset support for older protocol versions
  *   Business Partners or Government agency customers may require TLS1.3.
  *   Internal Security Teams may require TLS1.3, at some point in the future.    And they should!    And why should we NOT want  and be able to utilize TLS 1.3 with it’s updated and enhanced capabilities.  We DO WANT THIS!   We just still need to run our networks and businesses and are badly wanting to work with the Working Group to assure our use cases can be accommodated, if at all possible.
  *   And thinking further ahead,  what would be the extended proposed strategy,  when TLS 1.4 (or whatever comes next),  is finalized.        Adopting such a “Stay with the old product forever”  would seem to be tantamount to hoping that TLS 1.3 (and 1.4, etc.),  never get deployed.   For VERY Security focused industries,  such as healthcare and finance,  this is directly opposite of what we want, need and support.   We need security protocols to continue to evolve, improve and become as effective as possible,  but they need to move forward with the understanding  that operational perspectives are important as well.

From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, October 20, 2017 9:44 AM
To: Darin Pettis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2017 17:14:22 +0100

> Expressly reacting to the viability of continuing to use TLS1.2 forever.

Sorry, that's just misquoting.

Rich asked "why do the WG need to debate this now"
Darin said "we must, because we need snooping..."
I said "no, you can use TLS1.2 and debate this after
TLS1.3 is done."

That is nothing like saying "use TLS1.2 forever."

Please don't misquote like that.

S

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Oct 2017 16:23:50 +0000

*   Expressly reacting to the viability of continuing to use TLS1.2 forever.

Nobody has said that, you are arguing a strawman.

None of those even require TLS 1.2 yet, and it is a decade old.  Do you think any of them will jump from 1.1 to 1.3?  What timetable do you think that will happen?  A decade?  Five years?

Again, what timetable do you think that will happen?

“May.”  Do you have any indication that this is a requirement?  Government tends to work either far in advance (like NIST post-quantum crypto) or to track industry.

Your use-cases can be accommodated.  You just need to spend some more money on server-side runtimes and key management.  Instead, you propose to force all clients into a weaker security posture.  I am sorry to be harsh, but as I explained in email messages yesterday, if you force clients to indicate that they are willing to have traffic be intercepted, then any middlebox can categorize, and deny or subvert, such traffic.  Again, don’t think of just national-scale adversaries, but your ISP or IP-in-airplane provider.

The proposal fundamentally changes the way TLS works.  And with the posted use-cases, it seems completely obvious to me that it *weakens* the protection afforded to the general population.

I believe I know why people want this now. They are worried that if TLS 1.3 goes out without something like this, then the market (standard widely available browsers) will not implement it. Let me assure you that this isn’t an issue. The extension would *never ever* make it to the MUST state, and the browsers would be unlikely to ever implement it anyway.

I have an alternate strategy proposal.  Configure your servers to only use TLS 1.2 or earlier, probably for at least five years. During that time, modify the server-side and analysis tools to record and use the extra key material you’ll need for TLS 1.3.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 20 Oct 2017 16:41:04 +0000

So it sounds like we are in agreement that continuing to use TLS 1.2 is not a viable long term  alternative.  

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Friday, October 20, 2017 12:14 PM
To: Ackermann, Michael <[email-masked]>; Salz, Rich <[email-masked]>; Darin Pettis <[email-masked]>; [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

S

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Oct 2017 16:57:19 +0000

Long-term is a subjective term, and using it can lead to misunderstandings.

Based on current and previous actions around SSL and TLS versions, you can use TLS 1.2 for at least five, likely at least 10, years.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 20 Oct 2017 17:51:19 +0000

These mandates/requirements are typically motivated by the realization that TLS Vn is more secure than TLS Vn-x.
One of the important reasons TLS 1.3 may be more secure than TLS 1.2 and below is that it does not offer non-PFS options.
Then deploying a weakened configuration of TLS 1.3 (without PFS) would not meet the intent of those future mandates/requirements.
Then do we gain anything by standardizing a weakened configuration of TLS 1.3?

Cheers,

Andrei

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Oct 2017 11:22:42 -0700

On Fri, Oct 20, 2017 at 6:44 AM, Salz, Rich <[email-masked]> wrote:

>
>    - A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the
>    actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will
>    happen any faster?
>
> It's worse than that. PCI-DSS presently only requires TLS 1.0. The
deadline to switch to 1.1 or higher is 30 June 2018:

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Oct 2017 21:27:25 +0300

> is not a viable long term  alternative.  

If one looks at long time horizon...

TLS 1.2 will very probably remain viable until quantum computers come
and demolish its security, unfortunately.

Yes, quantum computers will demolish TLS 1.3 as it is currently, but
adding PQC into 1.3 is much easier than adding it into 1.2. With TLS
1.3, the biggest problems is choosing the PQC algorithm, not
integrating it, whereas TLS 1.2 requires would require very nontrivial
integration work too.

Oh, and come quantum computers, you will find that PQC schemes are much
less well-behaved than the pre-quantum schemes in use. Thus many tricks
that worked no longer work. So you would be better just adapting,
because come QC, you don't have choice but to, potentially very
quickly.

Also, with regards to support, I would be much more concerned about
software dropping support of, or regulations mandating disabling of,
RSA key exchange than TLS 1.2 as whole. There are already TLS libraries
that lack RSA key exchange, despite the fact it is MTI. Furthermore,
that sort of thing is much more feasible on server side, as client
support for ECDH (or at least DH-2k) is just about universal.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Oct 2017 15:16:26 -0400

> On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
>> The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol. 
>> 
> 
> But the "rhrd" draft does not require any changes to the core TLS 1.3 protocol, and in fact I have heard several key participants say that any "visibility" changes must not require changes to the core protocol.  If the "visibility" work will be done via extensions, then there is no ordering requirement for their specification with respect to the core work, there is only an ordering requirement between them and adoption of TLS 1.3 in enterprises.  Do you want to argue that a year timescale is too slow for enterprise adoption of TLS 1.3?  If not, I continue to not see a reason to address "visibility" now.

Ben:

I do not see the visibility extension taking any resources away from the completion of TLS 1.3, so I do not see any reason to make it wait.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Oct 2017 14:21:38 -0500

On 10/20/2017 02:16 PM, Russ Housley wrote:
>
>
> Ben:
>
> I do not see the visibility extension taking any resources away from
> the completion of TLS 1.3, so I do not see any reason to make it wait.
>

At risk of sounding overly self-important, there are a couple of old
emails sitting in my inbox waiting to get translated into pull requests
against the spec.  The time I am spending on this thread is time that I
am not able to spend improving the TLS 1.3 document.

-Ben

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Oct 2017 15:02:12 -0700

> and demolish its security, unfortunately.

As someone who has spent a lot of time working on compliance for payments
systems, I have an open question to the "visibility" advocates:

Can you provide a *specific citation* as to where you will be *required* to
use TLS 1.3 any time in, say, the next decade?

This is absolutely not the case for PCI-DSS.

To my knowledge any requirement of this nature simply doesn't exist. I
could be wrong but... citation needed.

If there is no pressing reason for legacy systems which are dependent on
"visibility"/self-MitM capability because their observability story is so
poor and they can't use endpoint agents to solve the same problems, what is
the case for trying to add MitM mechanisms now?

The answer is simple: stay on TLS 1.2 (or earlier) until you can improve
your observability story, or *specific* requirements which *mandate* use of
TLS 1.3 actually manifest. From previous experience: such mandates will not
be a fire drill, but will be years in the making, and repeatedly delayed
due to "industry" requirements / shortcomings.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Sun, 22 Oct 2017 12:58:55 -0400

Agreed; this conversation is not going to get anything to a real WG 
consensus without causing people to flee the WG. The hard sell just 
makes people more and more skeptical that this is really well 
intentioned. Please, let's just let this mess die. As Rich Salz has 
stated previously, we should just recommend those unwilling to change 
their ways immediately to stay on TLS 1.2 for a few years whilst they 
transition to something less horrible that can work with TLS 1.3. And, 
that less horrible thing need not suck up a billion more posts here.

Dave

On 10/20/2017 10:08 AM, Ted Lemon wrote:
> On Oct 20, 2017, at 9:54 AM, Stephen Farrell <[email-masked]
> <mailto:[email-masked]>> wrote:
> I can say for myself that there was a really strong hard sell on the
> notion of doing this in Prague.   Not being sufficiently paranoid, my
> general sympathy for people facing hard problems led me to consider what
> they were proposing, but each time they came up with something, someone
> with more paranoia fu than I have pointed out a hole in it.   During
> that period there were several periods when I was reluctantly willing to
> consider some less-bad version of draft-green.   This is a long way from
> "want," and even a pretty long way from "support."
>
> My personal feeling having been peeled off the herd and hard-sold like
> this is that there is some really powerful motivated reasoning going on
> here, and that the working group should just stop entertaining this
> process.   Weakening TLS is not the right way to approach the problem
> that has been described here.
>
> I hasten to add that I don't think the people doing the hard sell are
> bad people, or that they didn't have good reason for trying to do it.
> My point is simply that we've been collectively sucked close to a black
> hole here, and we need to take a step back from it.   In the same sense
> that LEOs who want key escrow have good reason for wanting it and are
> not bad people for wanting it, so too with the people pushing this
> proposal.   But like key escrow, this proposal is not beneficial for
> end-users or for security as a whole.
>
> In order for it to make sense to go forward with this proposal, two
> things would have to be true that I don't think are true.   First, we
> would have to agree that user security is not a primary goal.   And
> second, we would have to agree that overall network security is not a
> primary goal.   Discussing the details of how much security we are
> willing to give up, what attack surfaces that we could remove we are
> willing to leave in, only makes sense if we are willing to drop those
> two primary goals.
>
> Watching this conversation has been a really good learning experience
> for me, so I don't regret it, but I think we should stop.

---

From: Russ Housley <[email-masked]>
Date: Sun, 22 Oct 2017 13:54:01 -0400

Tony:
> 
> Can you provide a *specific citation* as to where you will be *required* to use TLS 1.3 any time in, say, the next decade?
> 
No one is requiring TLS 1.3 that I know about.  However, there are places that require visibility into TLS.  I will let one of the people that works in a regulated industry offer pointers to the documents.

Russ

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 22 Oct 2017 18:31:12 +0000

IMHO, get the TLS-1.3 standard out first, then start mucking with it.

There's nothing yet to make "visibility" into. ;-)

And in any case I'm against weakening the protocol, since there are other ways to accomplish the perlustrator's mission.

Regards,
Uri

Sent from my iPhone

> On Oct 22, 2017, at 13:54, Russ Housley <[email-masked]> wrote:
> 
> Tony:
>>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 Oct 2017 14:40:43 -0400

> No one is requiring TLS 1.3 that I know about.  However, there are places that require visibility into TLS.  I will let one of the people that works in a regulated industry offer pointers to the do…

What they require is visibility into contents of the flow that they are using encryption to protect.   Right now, the protocol they are using is TLS 1.1 or TLS 1.2.   The right thing for them to do if they continue to need this visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE, or some protocol that is designed for this use case, not to take a protocol designed specifically for securing flows from on-path eavesdropping and create a mode where it is easier to wiretap.

There is no reason other than momentum for them to switch to TLS 1.3 when it doesn't address their use case.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Oct 2017 15:24:52 -0400

Sent from my iPhone

> On Oct 22, 2017, at 2:40 PM, Ted Lemon <[email-masked]> wrote:
> 

With no hat, I agree.
https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward

Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Oct 2017 15:38:07 -0400

Sent from my iPhone

> On Oct 22, 2017, at 3:24 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
> 

I should note that I have not read the new draft yet.  These threads keep me busy.

---

From: Steve Fenter <[email-masked]>
Date: Sun, 22 Oct 2017 15:48:36 -0500

The main problem with not addressing the TLS visibility issue now is that no one knows when a vulnerability will be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, particularly in today's security environment. I've also learned that getting a solution in place through the IETF is a multi-year process, and then vendor adoption time has to be added on top of that.  Enterprises don't want to be caught in a position where a vulnerability is forcing us to upgrade, and we are starting at ground zero on a multi-year process to restore TLS visibility. We have to get out in front of this problem so we're not caught unprepared.

Sent from my iPad

> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" <[email-masked]> wrote:
> 
> 
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 22 Oct 2017 21:15:43 +0000

First they have to go through this vulnerability search dance with TLS-1.1 and achieve a reasonably complete move to TLS-1.2.

Regards,
Uri

Sent from my iPhone

> On Oct 22, 2017, at 16:49, Steve Fenter <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 Oct 2017 17:17:31 -0400

On Oct 22, 2017, at 4:48 PM, Steve Fenter <[email-masked]> wrote:
> The main problem with not addressing the TLS visibility issue now is that no one knows when a vulnerability will be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, particularly in today's security environment.

Implicit in this assertion is the claim that these organizations could switch quickly to TLS 1.3, but in fact we know that it's been very difficult for them to make the switch from 1.1 to 1.2, and in many cases they haven't done it.   So this isn't really at all persuasive.   But even if it were persuasive, it still wouldn't be a good argument.  TLS is a complicated protocol that does far more than is required for the use case we are talking about.   It would be better to use a simpler protocol with a smaller attack surface.

So why not get started on that now, instead of trying to weaken TLS 1.3?

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Oct 2017 23:26:32 +0100

On 22/10/17 21:48, Steve Fenter wrote:
> The main problem with not addressing the TLS visibility issue now is
> that no one knows when a vulnerability will be discovered in TLS 1.2
> that forces enterprises to upgrade to TLS 1.3. We've had guarantees
> that TLS 1.2 and the RSA key exchange are going to be fine for 5 to
> 10 years, but nobody knows that, particularly in today's security
> environment. I've also learned that getting a solution in place
> through the IETF is a multi-year process, and then vendor adoption
> time has to be added on top of that.  Enterprises don't want to be
> caught in a position where a vulnerability is forcing us to upgrade,
> and we are starting at ground zero on a multi-year process to restore
> TLS visibility. We have to get out in front of this problem so we're
> not caught unprepared.

Wait. What?

One of your arguments for needing snooping is that you
claim a lack of competence in debugging applications that
use TLS.

So to solve that, you propose we introduce a rarely used,
sporadically supported method of leaking keys to third
parties. IOW, you add what's called a vulnerability and
do so in a complex manner in code paths that'll hardly
ever be used (according to the proponents, they'll only
be used in the "proper" places, or at least, none of you
have so far ever acknowledged the falsity of that "proper"
places magical thinking).

Rarely used complex code for leaking keys... hmm, now
what is that likely to lead to? Oh yes, bugs.

But now you claim that a well tested protocol with fairly
mature implementations (TLS1.2) might have bugs that cause
you to need to add your additional complex key-leaking
vulnerability feature which'll magically have no bugs?

I think you can fairly claim a worst argument of the year
prize for that one;-)

S.

PS: Your claim about "guarantees" is just false afaics. I
saw no such thing on the list. Please desist from inventing
statements that were not made, or point me at where someone
said something that is even remotely possible to confuse
with such a guarantee. (Combining risible argument and false
claims really isn't wise.)

>> So it sounds like we are in agreement that continuing to use TLS
>> 1.2 is not a viable long term  alternative.
>> 
>> 
>> Based on current and previous actions around SSL and TLS versions,
>> you can use TLS 1.2 for at least five, likely at least 10, years.
>> 
>> 
>>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 22 Oct 2017 23:16:52 +0000

I am willing to bet that his point was not at all that Enterprises could switch quickly,  as you say in your response.
We do not do ANYTHING quickly.

I believe his point was that because we do not move quickly,  we need to prepare as much in advance as possible, and assure that the base protocols we know we will be using in the future,  do not put us in the position of having to do things that are generally not possible,  such as make significant application or protocol changes.

And out of curiosity,  what is the simpler protocol you are recommending?    I say out of curiosity because switching to a whole different protocol is not likely to be feasible from any perspective for large enterprises and the complex, multi-tier protocols that are prevalent.

From: TLS [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Sunday, October 22, 2017 5:18 PM
To: Steve Fenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 22, 2017, at 4:48 PM, Steve Fenter <[email-masked]<mailto:[email-masked]>> wrote:
The main problem with not addressing the TLS visibility issue now is that no one knows when a vulnerability will be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, particularly in today's security environment.

---

From: Steve Fenter <[email-masked]>
Date: Sun, 22 Oct 2017 18:26:38 -0500

I know of a number of large enterprises in verticals including financial, health care, retail, and government, across multiple countries, who are using packet payload inspection within their data centers.  Most of these enterprises are reluctant to step forward in a public forum and reveal their internal network structure and their internal security and monitoring practices. This gives the false impression that out of band decryption of TLS is not a big deal. It is in fact mission critical to a significant number of large enterprises.

I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is trying to architect and engineer solutions without knowing the complete set of requirements, at least on the enterprise side.  This results in sub-optimal design decisions (from an enterprise perspective), which in this case will break mission critical enterprise monitoring and troubleshooting systems.

We've already experienced what a rollout of TLS 1.3 will be like, at more than one enterprise, when certain vendors decided to move Diffie Hellman ciphers to the top of their priority list on a code upgrade. This caused severity one outages of critical monitoring systems.  This means that critical applications depend on these monitoring systems, and if the monitoring system is down the application is completely down. This is not the outcome we want when TLS 1.3 is rolled out, but it is what we are headed for. Enterprise monitoring should be tested as part of the operational TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should not be approved if enterprise monitoring breaks.

The only other option being presented to enterprises is that we continue to run on a TLS spec that is nine years old, and then continue running it until it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standard, but say that enterprises cannot upgrade to it.

> On Oct 19, 2017, at 5:37 PM, Christian Huitema <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 Oct 2017 19:35:54 -0400

> I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is…

The reason we don't have that is that designing secure protocols in secret isn't a trustworthy approach.   Of course, you can always get together privately.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 Oct 2017 19:43:51 -0400

> And out of curiosity,  what is the simpler protocol you are recommending?    I say out of curiosity because switching to a whole different protocol is not likely to be feasible from any perspective…

Perhaps you should read the article that Kathleen shared earlier today?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Oct 2017 00:50:14 +0100

Hi Ted,

On 23/10/17 00:35, Ted Lemon wrote:
>> I have been saying to anyone who will listen that the IETF needs a
>> private forum for enterprises, to enable them to come forward and
>> discuss their real requirements. Without this input the IETF is
>> trying to architect and engineer solutions without knowing the
>> complete set of requirements, at least on the enterprise side.
>> This results in sub-optimal design decisions (from an enterprise
>> perspective), which in this case will break mission critical
>> enterprise monitoring and troubleshooting systems.
> 
> The reason we don't have that is that designing secure protocols in
> secret isn't a trustworthy approach.   Of course, you can always get
> together privately.

Well, to be fair, that ask - for (literally!) secret handshakes
does explain one part of this debacle that has puzzled me so far.
We've seen the following interactions:

snooping-proponents: "we need snooping, because <foo>"
others: "that has all sorts of bad side-effects, e.g. A,B,C..."
...
...silence from snooping proponents...

The ask for secrecy I think demonstrates that the silence in
response to explanations of derived demonstrable damage is not
due to a lack of understanding, but must be down to caring
only about one's own "constituency" and not at all about the
Internet more broadly.

I think I now understand some of this better (but deplore it
more), but am left more puzzled as to the what it was that
inspired draft-rehired authors.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 22 Oct 2017 23:54:57 +0000

➢ I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is trying to architect and engineer solutions without knowing the complete set of requirements, at least on the enterprise side.

Sorry, no.  We don’t work that way.  Never have, and never will.  Everything must be done in public.  That’s really just non-negotiable.  Without that input, then yes, the IETF protocols will “just” be for the public Internet.  I’m sure many will accept that.

➢     The only other option being presented to enterprises is that we continue to run on a TLS spec that is nine years old, and then continue running it until it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standard, but say that enterprises cannot upgrade to it.
    
Yes it makes sense, for two reasons.  First, “enterprises,” as represented by those who claim to need this visibility, haven’t even moved up to requiring TLS 1.2.  It was because of enterprise push-back that PCI DSS was delayed, and that was only TLS 1.1!  Second, “enterprise” is a small part of the Internet.

So you need TLS 1.3, with this security-weakening feature, so that in case someone finds a break in TLS 1.1, or TLS 1.2, you can rapidly upgrade to TLS 1.3.  The phrase that comes to mind is “are you --- kidding me?”

Enterprise monitoring, as has been repeatedly said here, *does not have to break.*  Keep your architecture and have the server’s that you control within your enterprise share all the keys with the logging system.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Oct 2017 02:30:05 +0000

Salz, Rich <[email-masked]> writes:

>None of those even require TLS 1.2 yet, and it is a decade old.  Do you think
>any of them will jump from 1.1 to 1.3?  What timetable do you think that will
>happen?  A decade?  Five years?

>From working with a lot of SCADA/embedded/IoT vendors, they hope to migrate
from TLS 1.0 to 1.2 within the next 5-10 years (note the "hope to ..." rather
than "have a fixed roadmap to ...", it's sort of a general brownian motion).
None of them, that I know of, have ever mentioned TLS 1.3.  In the same way
that HTTP/2 effectively forked HTTP, so I'm expecting TLS 1.3 to fork TLS.

>Again, what timetable do you think that will happen?

In SCADA, embedded, etc, I would say "never".  I know that predicting the
future is always risky :-), but if I had to put money on "1-2 years", "2-5
years", "5-10 years", or "beyond ten years", I'd put it on the latter, which
in effect means "never".

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Oct 2017 06:58:52 +0300

> On 22 Oct 2017, at 21:40, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 22, 2017, at 1:54 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> What they require is visibility into contents of the flow that they are using encryption to protect.   Right now, the protocol they are using is TLS 1.1 or TLS 1.2.   The right thing for them to do if they continue to need this visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,

Right, and shamelessly plugging my working group, I2NSF has recently adopted a draft ([1]) that is aimed at enabling and automating the deployment of IKE/IPsec in the datacenter.

> or some protocol that is designed for this use case, not to take a protocol designed specifically for securing flows from on-path eavesdropping and create a mode where it is easier to wiretap.
> 

[1] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 14:35:40 +0000

I have.
I was only asking what your opinion was, based on that statement in your reply.

From: Ted Lemon [mailto:[email-masked]]
Sent: Sunday, October 22, 2017 7:44 PM
To: Ackermann, Michael <[email-masked]>
Cc: Steve Fenter <[email-masked]>; [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 22, 2017, at 7:16 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:
And out of curiosity,  what is the simpler protocol you are recommending?    I say out of curiosity because switching to a whole different protocol is not likely to be feasible from any perspective for large enterprises and the complex, multi-tier protocols that are prevalent.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 11:40:51 -0400

> I was only asking what your opinion was, based on that statement in your reply. 

With respect, Michael, I gave my opinion in the message to which Kathleen replied, so your assertion that you have been reading these messages doesn't seem to be reflected in the dialog we are having.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Oct 2017 10:14:46 -0600

> I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is…

The IETF doesn't run private forums behind closed doors. You'd need to
do that kind of work elsewhere (these large enterprises could, of
course, start their own industry forum, where they could work in ways
that the IETF doesn't).

> We've already experienced what a rollout of TLS 1.3 will be like, at more than one enterprise, when certain vendors decided to move Diffie Hellman ciphers to the top of their priority list on a code upgrade. This caused severity one outages of critical monitoring systems. 

It sounds as if different internal teams might not have been
communicating well about the rollout of those new cipher suites.
Operational issues in large enterprises are not a problem that requires
protocol work.

>  This means that critical applications depend on these monitoring systems, and if the monitoring system is down the application is completely down. This is not the outcome we want when TLS 1.3 is rolled out, but it is what we are headed for. Enterprise monitoring should be tested as part of the operational TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should not be approved if enterprise monitoring breaks.

Operational testing is always good, but very strong arguments need to be
made for the latter claim. Among other things, you're adding a new
requirement to the Internet Standards Process, which would necessitate
IETF consensus on changes to RFC 2026!

> The only other option being presented to enterprises is that we continue to run on a TLS spec that is nine years old, and then continue running it until it is 14 to 19 years old. It makes no sense…

There are many options, some of which Kathleen outlined in her blog
post. It's not helpful to say there is just one option when we haven't
fully explored either the problem space or the solution space. And by
"we" I mean especially those who are claiming the need for TLS visibility.

Peter

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 16:22:24 +0000

I am merely trying to understand if there are any constructive suggestions amongst all these discussions, that we should consider.

Your comment was
"It would be better to use a simpler protocol,"

My question back to you was WHAT SIMPLIER PROTOCOL?

If  your answer to my question,  is to refer to Kathleen's document,  then she discusses a few things.   If I have to guess which one of those you may be referring to,  I will guess IPSEC?
Is this correct?   Are you suggesting we should convert to IPSEC?

If that was stated in any previous correspondence,  I did not see it.

Sent: Monday, October 23, 2017 11:41 AM

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:
I was only asking what your opinion was, based on that statement in your reply.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Oct 2017 12:25:32 -0400

> What they require is visibility into contents of the flow that they are using encryption to protect.   Right now, the protocol they are using is TLS 1.1 or TLS 1.2.   The right thing for them to do…

Is there running code that demonstrates the IPsec+IKE can be deployed and operated at scale in the sort of environment the enterprise network tips have described to us?

> or some protocol that is designed for this use case, not to take a protocol designed specifically for securing flows from on-path eavesdropping and create a mode where it is easier to wiretap.

...assuming the necessary lead time and support from vendors to implement another protocol.

> There is no reason other than momentum for them to switch to TLS 1.3 when it doesn't address their use case.

But TLS 1.3 addresses *part* of the use case, as it does provide better security and it represents an incremental change to the current deployment and operation practices.  

- Ralph

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Oct 2017 16:26:33 +0000

*   I am merely trying to understand if there are any constructive suggestions amongst all these discussions, that we should consider.

Yes.  To repeat myself, here are two:

  1.  Continue to use your existing schemes. You won’t have to change to TLS 1.3 for years.
  2.  Modify your servers and logging infrastructure to report-out the PFS keys and use them

Do you need me to post links to my messages?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Oct 2017 16:28:39 +0000

*   Is there running code that demonstrates the IPsec+IKE can be deployed and operated at scale in the sort of environment the enterprise network tips have described to us?

IBM has supported full-scale IPsec/IKE deployment on System/z for a very long time, and it also has an interesting way of sharing/escrowing TLS session keys with Cisco boxes.

So if we can assume that many of these large enterprises have a mainframe, then they have the proofpoints behind their own firewall.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 12:35:19 -0400

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 12:38:12 -0400

> Is there running code that demonstrates the IPsec+IKE can be deployed and operated at scale in the sort of environment the enterprise network tips have described to us?

Is there running code that demonstrates that draft-rhrd-tls-tls13-visibility-00 can be deployed and operated at scale?   :)

In fact, when I went looking at the state of the art for IKE/IPsec after our conversation in Prague, I was pleasantly surprised at how usable it is.   I don't know if it currently scales up as you suggest, but it certainly can in principle.   This is why I'm suggesting that resources be spent doing that, rather than in limiting the ability of TLS 1.3 to address its use case, which is a different use case.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 16:39:05 +0000

Thanks Rich
I have seen these suggestions previously.
But as numerous messages on this chain, from various people have discussed, neither  of those suggestions are viable from an Enterprise Architecture planning perspective.

  1.  If staying with TLS 1.2 indefinitely was considered acceptable,  would we even be having these discussions?
  2.  Modifying Server,  application and logging infrastructure is a huge, expensive proposition,  that executive management would not be receptive to at all.   Not to mention the logistics to follow if they were.

From: Salz, Rich [mailto:[email-masked]]
Sent: Monday, October 23, 2017 12:27 PM
To: Ackermann, Michael <[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

---

From: Hubert Kario <[email-masked]>
Date: Mon, 23 Oct 2017 18:43:25 +0200

On Thursday, 19 October 2017 19:12:11 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> If those middleboxes already have sufficient alternative options, why do we
> spend time discussing this draft? Why do we need to add yet another
> alternative for them?

so that they benefit from standardisation, network effects and be fiscally 
responsible!

</devils advocate>
 
> > 
> > 
> > With respect to "be noticed", forcing clients to opt-in seems like it
> > would clearly be noticed. My understanding was that you were saying that
> > the middlebox could block traffic. That seems in conflict with your
> > statement that they can be "routed around". 
 
> > It seems like a middlebox that is able to deny traffic (has that level of
> > power, would simply use their own CA and force trust of that)
 
> >> doesn’t have to coerce a CA or force victims to trust a new CA.  Instead
> >> they have to gain the cooperation of the origin(s) they are interested
> >> in.>
> > 
> > Gaining the cooperation of the servers (origins) seems relevant. If they
> > get the cooperation of the servers, they can simply get the data directly
> > from them. But, again, they also have to get the cooperation of the
> > clients. 
 
> > If a middlebox has sufficient power to block traffic, force clients into
> > opting in, and coerce servers into opting in, it seems like they have
> > sufficient alternative options that are of equivalent effort ("ease").

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 12:43:46 -0400

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael <[email-masked]> wrote:
> If staying with TLS 1.2 indefinitely was considered acceptable,  would we even be having these discussions? 

This is a vacuous argument.   Nobody has provided any evidence of any kind that "enterprise" installations relying on TLS 1.2 would ever switch to TLS 1.3, much less that they would do so in any kind of hurry.   You demonstrate why with your very next bullet point:
> Modifying Server,  application and logging infrastructure is a huge, expensive proposition,  that executive management would not be receptive to at all.   Not to mention the logistics to follow if they were.  

If indeed that unmovable mountain, executive management, must be moved in the case of switching to TLS 1.3 or in the case of switching to something else, it seems obvious to me that it is better to switch to something else.

Can you give me a clear technical reason why that is not preferable?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Oct 2017 16:44:07 +0000

DAMMIT.  Stop saying indefinitely.

What percentage of hosts within your enterprise use TLS 1.2 as the preferred protocol?

  1.  Modifying Server,  application and logging infrastructure is a huge, expensive proposition,  that executive management would not be receptive to at all.   Not to mention the logistics to follow if they were.

And this is probably the main point behind all this.  Folks want to make the entire Internet less secure (I’ve explained why) so that they can save time and money.

But even if that were not the issue, do you think this draft won’t require custom work?

---

From: Dave Garrett <[email-masked]>
Date: Mon, 23 Oct 2017 13:17:18 -0400

On 10/23/2017 12:39 PM, Ackermann, Michael wrote:
>  2. Modifying Server,  application and logging infrastructure is a huge,
>     expensive proposition,  that executive management would not be
>     receptive to at all.   Not to mention the logistics to follow if
>     they were.

I'd just like to have everyone stop and focus on this, right here. This 
is the crux of everything. It takes effort and resources to upgrade your 
systems, and you don't want to do it. Tough; this is not the TLS WG's 
problem. The job here is to design the most secure protocol possible, 
and weakening things significantly to accommodate legacy methods is not 
a realistic option. Organizations will *always* have to expend effort 
and resources to upgrade to better systems. If that can be reduced 
without affecting security, great, but if not, then you're just going to 
have to accept it. People should not be here arguing against technical 
improvements; they should be with their managers explaining the simple 
reality of the situation. Yeah, I know it's hard to explain to executive 
management that they are not in control here, but they aren't.

I count at least 400+ messages on this list on this one topic. The 
answer is still "no". You're not getting a cheap drop-in replacement for 
your existing insecure use of static RSA keys out of this WG. Fixing 
devil's advocate qualms like whether or not clients have to send an 
extension is not enough to get even a rough consensus. Nontrivial, but 
very much viable, effort and resources will be required to upgrade.

https://en.wikipedia.org/wiki/Technical_debt

Dave

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 17:30:47 +0000

The WHY you ask is in the answer.
It is a huge proposition requiring change to virtually every platform and application.    Not to mention all the management,  monitoring and security platforms.
It would be very expensive and time consuming.
And when they ask why this is necessary,  it is because the new version of the existing protocol is not backwards compatible,  which is something we have come to expect.

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, October 23, 2017 12:44 PM
To: Ackermann, Michael <[email-masked]>
Cc: Salz, Rich <[email-masked]>; [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:

  1.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Oct 2017 17:33:54 +0000

*   It is a huge proposition requiring change to virtually every platform and application.    Not to mention all the management,  monitoring and security platforms.

Do you expect that this draft will require no changes to all your management, monitoring, and security platforms?

  *   And when they ask why this is necessary,  it is because the new version of the existing protocol is not backwards compatible,  which is something we have come to expect.

You have years to set the right expectation.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 13:45:14 -0400

> And when they ask why this is necessary,  it is because the new version of the existing protocol is not backwards compatible,  which is something we have come to expect. 

I really tried to have sympathy for you about this in Prague.   I know what it's like to get unreasonable pushes from management (not based on recent experience, fortunately).   But this exact form of reasoning is why we're suffering from attacks on the internet like the Mirai botnet and the Reaper botnet, the Equifax hack, et cetera.

You have come to a group of people who take these issues extremely seriously and asked them to bless you in going forward to create another problem of the same magnitude.   I know you don't think that's what you're asking, but that really is what you are asking.   It might not be on your network—maybe you will operate this technology securely.   But you are asking us to create an attack surface, and it will be used.

When you make requests like this, what you are really doing is pushing off costs your management doesn't want to pay on the users of the Internet as a whole.   130 million Americans are now doomed for life to suffer from attacks on their credit because of this kind of thinking.

Stop asking us to take security less seriously, and start taking it more seriously.   You work for BCBS: you are responsible for protecting the privacy of a similar number of Americans.   I know this is hard, but it's time to stop imagining that you can lay costs off on us and start planning how you are going to migrate to a more secure architecture.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Oct 2017 18:54:15 +0100

On 23/10/17 18:30, Ackermann, Michael wrote:
> It is a huge proposition requiring change to virtually every platform
> and application.    Not to mention all the management,  monitoring
> and security platforms. It would be very expensive and time
> consuming. And when they ask why this is necessary,  it is because
> the new version of the existing protocol is not backwards compatible,
> which is something we have come to expect.
All of these cost (*) arguments were raised in the draft-green
iteration of this nonsense. None of them are any different when
draft-green is replaced with draft-rehired.

The arguments did not convince before, and will not convince now.

They did not garner rough consensus before and I'm pretty happy
from list discussion that they don't seem to be doing so now.

Why do you insist on wasting the time of the WG? That seems
disruptive to me.

For the chairs:
- Various people have asked you to call a halt here.
- I do so again.
- Pretty-please even :-)

It seems clear this latest version of the same old bad idea
is going nowhere but /dev/null, as is proper. Please do declare
the discussion done.

S.

(*) The arguments here are of course all about moving the
cost to someone else, they are not about reducing costs. The
proponents of moving the cost elsewhere of course never seem
to admit that.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 23 Oct 2017 18:08:17 +0000

For the chairs: I second Stephen’s request. Enough is enough.
--
Regards,
Uri Blumenthal

On 10/23/17, 13:54, "TLS on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:
    
             On 23/10/17 18:30, Ackermann, Michael wrote: …

    
    For the chairs:
    - *Various people have asked you to call a halt here*.
    - *I do so again*.
    - Pretty-please even :-)

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 18:12:04 +0000

To suggest that I or my industry does not take security seriously, is inaccurate and immaterial to this discussion.

I would put the comment  that anyone or any industry is attempting to lay costs for anything off on IETF,  in the same unfortunate bucket.

These types of subjectively negative statements are not at all constructive, germane nor worthy of response.

Sent: Monday, October 23, 2017 1:45 PM

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Oct 2017 18:29:27 +0000

*   I would put the comment  that anyone or any industry is attempting to lay costs for anything off on IETF,  in the same unfortunate bucket.

Do I misunderstand what you meant by this comment?
                It is a huge proposition requiring change to virtually every platform and application.    Not to mention all the management,  monitoring and security platforms. It would be very expensive and time consuming.

Or this one?

Or this one?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Oct 2017 14:38:29 -0400

> To suggest that I or my industry does not take security seriously, is inaccurate and immaterial to this discussion. 

I'm sure you take security seriously.   What I'm saying is that you have tunnel vision about it, because you are caught between a rock (the IETF) and a hard place (management that won't listen).
 
> I would put the comment  that anyone or any industry is attempting to lay costs for anything off on IETF,  in the same unfortunate bucket. 

By "we" I mean users of the Internet, not the IETF.  The IETF doesn't have deep pockets.
 
> These types of subjectively negative statements are not at all constructive, germane nor worthy of response.

That's fine.   We would all like for this conversation to end.   My "subjectively negative statements" were just explaining to you why you aren't making any headway in the working group in trying to get the outcome you seek.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 18:42:13 +0000

But as stated in several previous Emails, the fact that TLS 1.2 is still available,  does not mean that we won't  have applications, business units or other entities that require TLS 1.3 and we will need to manage, monitor and secure these, as well as older versions.

---

From: Adam Caudill <[email-masked]>
Date: Mon, 23 Oct 2017 19:11:58 +0000

To be honest, I’m rather surprised that this group continues to spend time
on this. I’m of the opinion that the chairs should step in and put this
discussion on hold until the work on TLS 1.3 is complete. This, and any
document of the same goal, are eating up time and energy that should be
directed to completing the work this group was chartered to do. There’s no
indication that there will be any consensus on moving forward with any such
document in this group, and I don’t think that will change any time soon.

Those advocating for some standardized method of subverting the security
properties of TLS have been offered numerous options in good faith, and
continue to reject them all. I’m aware of extremely large enterprises that
in fact require TLS 1.2 with PFS, as they made the investment in addressing
this issue early on, and do so effectively. This can be solved without
changes to the protocol or a standardized “backdoor” - and is being done
today by at least some enterprises.

I understand that this complicates the work that some do, and will mean
additional engineering or spending to deal with it, when they eventually
move to TLS 1.3; that said, I don’t think their decision to take the easy
route in traffic inspection and ignore the evolution of 1.3 till the last
moment should lead to adding new risk to every other TLS user, especially
those that invested in long term solutions that deal with these changes.

I’m of the opinion that this discussion is no longer productive; there’s no
indication that there will be consensus on this or similar documents, good
faith efforts have been made to offer alternatives - in multiple
discussions, it’s distracting from the work of completing 1.3. To me, the
most logical thing to do is move on, finish the work on 1.3, and then
reevaluate (not that I expect consensus to emerge then either).

-- 

--*Adam Caudill*
http://adamcaudill.com

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 23 Oct 2017 14:42:55 -0700

> today by at least some enterprises.

Having worked (and presently working) for more than one company of this
nature, in the payments business no less, I would like to restate that it's
incredibly disingenuous to cite the need for self-MitM capability as an
"industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find
the field divided between those who have invested in a real observability
story, and those who think passive network traffic collection is the only
way to debug their systems. I think if you were to even take a straw poll
of the best approaches monitoring/observability among actual industry
practitioners, passive network traffic collection would rank close to the
bottom of the list.

I would go as far as to say that if you are among those requesting this
misfeature, you are doing a terrible job securing your infrastructure, and
should look into modern observability techniques as an alternative to
debugging by concentrating network traffic dumps into a single point of
compromise which represents a huge security liability. Yes, switching to a
new approach to observability is a huge investment that will take time, but
so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM
misfeature and could be actively harmed by it, and while a self-MitM
capability may be standard operating practice for some, it is not true for
all, and identifying those who want the self-MitM capability as "industry"
is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF
is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the
rest of us less secure at the request of those who are running insecure
infrastructures and apparently intend on keeping things that way.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 22:09:34 +0000

This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern.

No one I am aware of is pushing for a MitM capability to address this.   In fact it was one of the alternative solutions for which many implementation issues were cited at the Prague meeting and on this list.    But I would like to ask,  what is the solution that your company and others that you reference,  have solved this problem by implementing?

From: TLS [mailto:[email-masked]] On Behalf Of Tony Arcieri
Sent: Monday, October 23, 2017 5:43 PM
To: Adam Caudill <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <[email-masked]<mailto:[email-masked]>> wrote:
Those advocating for some standardized method of subverting the security properties of TLS have been offered numerous options in good faith, and continue to reject them all. I’m aware of extremely large enterprises that in fact require TLS 1.2 with PFS, as they made the investment in addressing this issue early on, and do so effectively. This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find the field divided between those who have invested in a real observability story, and those who think passive network traffic collection is the only way to debug their systems. I think if you were to even take a straw poll of the best approaches monitoring/observability among actual industry practitioners, passive network traffic collection would rank close to the bottom of the list.

I would go as far as to say that if you are among those requesting this misfeature, you are doing a terrible job securing your infrastructure, and should look into modern observability techniques as an alternative to debugging by concentrating network traffic dumps into a single point of compromise which represents a huge security liability. Yes, switching to a new approach to observability is a huge investment that will take time, but so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM misfeature and could be actively harmed by it, and while a self-MitM capability may be standard operating practice for some, it is not true for all, and identifying those who want the self-MitM capability as "industry" is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the rest of us less secure at the request of those who are running insecure infrastructures and apparently intend on keeping things that way.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Oct 2017 17:30:37 -0500

>  But as stated in several previous Emails, the fact that TLS 1.2 is still available,  does not mean that we won't  have applications, business units or other entities that require TLS 1.3 and we wi…

This seems sufficiently hypothetical so as to be non-actionable.

That is, I assume that any sufficiently large enterprise must have some
sort of architecture review process before a new system is deployed (and
if one does not, it seems highly unlikely to be secure).  There would
need to be some resolution of the conflict between those parties
"requiring" monitorability and those parties "requiring" TLS 1.3 before
such a system could get approved and approach deployment, so I feel
obligated to insert "require" into scare quotes and attribute no real
meaning to the statement.

As was stated previously, this is a case of being stuck between a rock
and a hard place.  While it is reasonable to investigate changing both
of the rock and the hard place, it seems unwise to presume that it is
one or the other specifically that must change.  You assert in a
different message that it would be very expensive and time consuming to
change "virtually every platform and application, not to mention all the
management, monitoring, and security platforms" (e.g., the "hard
place"), and I do not disagree.  It would also be expensive and time
consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the
way(s) being proposed; unfortunately, the error bars on this cost
estimate are necessarily quite large so as to take into account the risk
of catastrophic breakdown of the security of the Internet.   It seems
pretty clear that various parties involved in this conversation are
applying different metric functions to weight these various costs, which
makes it hard to see a path that would appease everyone.

In that same "different message" you also mention that you have come to
expect backwards compatibility, but can you really expect backwards
compatibility without limit?  Does Windows 10 run MS-DOS executables? 
Can a Kerberos principal who last set their password using Kerberos 4
expect to interoperate in a modern Kerberos 5 deployment?  Can you still
log into a shell server via telnet?  There are many arguments in support
of backwards compatibility, but they are not universal, and history
provides plenty of precedent for security eventually overriding
backwards compatibility.  So where would you put the boundary on the
backwards compatibility for static RSA in TLS or equivalent
non-forward-secrecy mechanisms?  Would you propose infinite
compatibility in this space with no bound?  Ten years from now?  When a
quantum computer can quickly factor 2048-bit RSA keys?  There are no
doubt folks here would claim that the writing has been on the wall for
five years or more that static RSA was out and forward secrecy was on
the way in, and that now is the right time to draw the line and drop the
backwards compatibility.    In fact, there is already presumed WG
consensus for that position, so a strong argument indeed would be needed
to shift the boundary from now.  I won't say that no such argument can
exist, but I don't think we've seen it yet.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Oct 2017 17:33:18 -0500

On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> No one I am aware of is pushing for a MitM capability to address
> this.   In fact it was one of the alternative solutions for which many
> implementation issues were cited at the Prague meeting and on this
> list.    But I would like to ask,  what is the solution that your
> company and others that you reference,  have solved this problem by
> implementing?   

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic
and modify plaintext for the affected connections?

-Ben

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 23 Oct 2017 15:40:44 -0700

On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk <[email-masked]> wrote:
>  There are no doubt folks here would claim that the writing has been on the wall for

I don't have too strong an interest in this thread, it's not going
anywhere, and I don't mind that. But I do want to chime in and point
out that forward secrecy is not completely on the way in. With STEK
based 0-RTT, it sounds like many implementors are happy to see user's
requests, cookies, passwords and other secret tokens protected only by
symmetric keys that are widely shared across many machines and
geographic boundaries, with no defined key schedule, usage
requirements or forward secrecy. Clearly, the consensus has been
willing to accept that trade-off, and there is definite wiggle room.

-- 
Colm

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 23 Oct 2017 23:31:00 +0000

NO
The objective is to be passively observe, out of band and not to be a MitM or modify/inject text.    Just as we all do today.  

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Monday, October 23, 2017 6:33 PM
To: Ackermann, Michael <[email-masked]>; Tony Arcieri <[email-masked]>; Adam Caudill <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> No one I am aware of is pushing for a MitM capability to address this.   
> In fact it was one of the alternative solutions for which many 

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic and modify plaintext for the affected connections?

-Ben

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 24 Oct 2017 01:58:56 +0000

Who cares about the objective? People are asking about the result.

Regards,
Uri

Sent from my iPhone

> On Oct 23, 2017, at 19:32, Ackermann, Michael <[email-masked]> wrote:
> 
> NO

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 24 Oct 2017 02:47:01 +0000

On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael <[email-masked]>
wrote:

> NO
> The objective is to be passively observe, out of band and not to be a MitM
> or modify/inject text.    Just as we all do today.

You seem to be confused as to the difference between an active vs passive
MitM. Using the term “MitM” for a passive network observer, particularly
one which can decrypt traffic, is perfectly apt.

Tony Arcieri

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Tue, 24 Oct 2017 07:31:43 +0000

Even if YOUR objective is to passively observe, you have to admit that this mechanism allows OTHER PEOPLE using it to modify the encrypted data, and we should always consider the worst-case scenario.

In fact, my opinion a couple of weeks ago was that we had to find some way to provide visibility for TLS 1.3, but after reading other people's comments on this thread, I think there are lots of solutions to provide visibility of the encrypted data within internal networks. And if the transition requires work and money... Well, security always does.

I side with the people that think we should close this topic and move on (I am even wondering if it was a good idea to send this mail and thus fuel the discussion). I'm eager to see a final specification of TLS 1.3 and I'm currently frustrated with being unable to see the light at the end of the tunnel while we are just going round and round the same discussion...

> -----Mensaje original-----
> De: TLS [mailto:[email-masked]] En nombre de Ackermann, Michael
> Enviado el: martes, 24 de octubre de 2017 1:31
> Para: Benjamin Kaduk <[email-masked]>; Tony Arcieri
> <[email-masked]>; Adam Caudill <[email-masked]>
> CC: [email-masked]
> The objective is to be passively observe, out of band and not to be a MitM or
> modify/inject text.    Just as we all do today.
> 
> To: Ackermann, Michael <[email-masked]>; Tony Arcieri
> <[email-masked]>; Adam Caudill <[email-masked]>
> Cc: [email-masked]
> SSWrapDH1 private key has the cryptographic capability to inject traffic and
> modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly confidential and is
> intended solely for the use of the individual(s) to whom this communication
> is directed. If you are not the intended recipient, you are hereby notified
> that any viewing, copying, disclosure or distribution of this information is
> prohibited. Please notify the sender, by electronic mail or telephone, of any
> unintended receipt and delete the original message without making any
> copies.
> 
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2017 09:38:46 +0100

Sean/Joe, this is addressed to you...

On 24/10/17 00:31, Ackermann, Michael wrote:
> NO The objective is to be passively observe, out of band and not to
> be a MitM or modify/inject text.    Just as we all do today.

So from the above we see that some of the proponents of
breaking TLS demonstrate a breathtaking ignorance of what
they are espousing. After 18 months of this WG dealing
with the "I want my static RSA" pony, I personally think
we are justified in demanding more from those who've been
actively engaged for some time in trying to break TLS and
therefore we ought consider postings such as the above,
or ones containing blatantly false/exaggerated statements
(e.g. about "guarantees" or "using TLS1.2 forever") as
being merely disruptive.

So in addition to asking you as chairs to close down this
discussion, I would also ask that you contact the folks
being disruptive like that and try to educate them as to
how to behave in IETF discussions and also let them know
about the IETF's processes for dealing with disruptive
postings.

Thanks,
S.

PS: Your (chairs') silence on the repeated requests to
close down this discussion is quite puzzling to me.

> 
> -----Original Message----- From: Benjamin Kaduk
> [mailto:[email-masked]] Sent: Monday, October 23, 2017 6:33 PM To:
> Ackermann, Michael <[email-masked]>; Tony Arcieri
> <[email-masked]>; Adam Caudill <[email-masked]> Cc:
> [email-masked] Subject: Re: [TLS] Publication of
> draft-rhrd-tls-tls13-visibility-00
> 
>> this. In fact it was one of the alternative solutions for which
>> many implementation issues were cited at the Prague meeting and on
>> this list.    But I would like to ask,  what is the solution that
>> your company and others that you reference,  have solved this
>> problem by implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of
> the SSWrapDH1 private key has the cryptographic capability to inject
> traffic and modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any unintended
> receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue
> Cross and Blue Shield Association.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 24 Oct 2017 13:57:07 +0200

On Tuesday, 24 October 2017 00:40:44 CEST Colm MacCárthaigh wrote:
> >  There are no doubt folks here would claim that the writing has been on
> >  the wall for> 

which part of the HTTP 0-RTT usage policy does say that that is acceptable?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 13:30:22 +0000

➢     The objective is to be passively observe, out of band and not to be a MitM or modify/inject text.    Just as we all do today.  
    
That might be the objective, but isn’t Ben correct?  If a third-party has the session keys, what prevents them from doing that?  Good behavior?  Or is there some technical means (unclear to me) to actually prevent it?

As I used to read in the comics of my youth, https://www.urbandictionary.com/define.php?term=good%20lord%21%20choke  I am glad that this conversation thread kept going, like a zombie it keeps rising.  We know have enough knowledge to definitively put a stake through its heart, forever.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Oct 2017 09:22:29 -0600

> close down this discussion is quite puzzling to me.

Section 2 of RFC 7282 is relevant here: "rough consensus is achieved
when all issues are addressed, but not necessarily accommodated". Issues
have been raised (albeit some of them seemingly not well informed about
best industry practices, technical alternatives, practical implications,
or IETF processes), and those issues have been considered, weighed,
addressed, and (IMHO) found to be "in the rough".

+1 to Stephen's request.

Peter

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 24 Oct 2017 16:41:56 +0000

Our proposals are for spanned/tapped, passive traffic.    You seem to be talking about modifying the actual  live data stream.  
And MitM is also outside of what we want to do but would seem to be more feasible in that scernario.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Oct 2017 16:45:40 +0000

➢ Our proposals are for spanned/tapped, passive traffic.    You seem to be talking about modifying the 
➢ actual  live data stream.  

Yes I am.

➢     And MitM is also outside of what we want to do but would seem to be more feasible in that scernario.  

I think that is a grudging admission that it does, but please be explicit.  Does your proposal enable an attacker (such as a gateway on an airplane or any other middlebox between the endpoints) to modify the stream?  Ideally your answer – or, better yet, from one of the I-D authors – is yes, no, or I don’t know.

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 24 Oct 2017 09:49:32 -0700

Dear TLS WG,

The chairs have been following the recent vigorous discussion on
draft-rhrd-tls-tls13-visibility and we'd like to say a few words about
process and how we intend to move forward.

First, we would like to clarify that this discussion isn't delaying TLS
1.3. We've been holding final publication to resolve some middlebox issues
as described in a recent message from ekr

https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 and
expect to discuss this in Singapore. No one and we mean no one should delay
submitting a PR related to TLS1.3 or any other WG draft because of this
discussion. You’ll note that others have recently, you should follow suit.

In Prague, we had a discussion of draft-green and there was neither
consensus to work in this area nor to decline to work in this area.  In
addition to the comments that we should simply decline all such work, the
authors received technical comments about their approach and draft-rhrd
seems to be an attempt to address some of those comments.  As is normal
IETF practice, we will be giving this topic agenda time in Singapore to see
if a consensus emerges one way or the other.

Absolutely no decisions will be made about adoption prior to that time, nor
prior to a formal call for adoption. In particular, decisions will not be
made based on the volume of messages to the mailing list.  It is
unnecessary and unproductive to repeat points you have already made just
because someone responds to you. You will not be missing out on the chance
to make your argument.

Finally, we would like to remind WG members to keep their messages
professional and civil. We have noted a number of recent messages that do
not conform to those standards and we will be reaching out to people
personally to address those instances.

J&S

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2017 18:01:19 +0100

Joe,

On 24/10/17 17:49, Joseph Salowey wrote:
> As is normal

I would ask that you, as chairs, reconsider that. While I
do have strong opinions, the list traffic seems to me to
have been extremely clear on this draft and on this overall
topic. Personally, given recent traffic, and the clear lack
of consensus to even discuss the basic proposition of snooping,
I can't see agenda time for this as being other that a waste
of time. (Again.)

S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Oct 2017 15:31:17 -0400

On Oct 24, 2017, at 12:49 PM, Joseph Salowey <[email-masked]> wrote:
> First, we would like to clarify that this discussion isn't delaying TLS 1.3. We've been holding final publication to resolve some middlebox issues as described in a recent message from ekr
> https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 <https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0> and expect to discuss this in Singapore. No one and we mean no one should delay submitting a PR related to TLS1.3 or any other WG draft because of this discussion. You’ll note that others have recently, you should follow suit.

Perhaps not.   I don't feel qualified to judge.   But it's delaying other work, because people who could be doing useful work in the IETF are engaging on this topic instead.   No discussion is without cost, so there is value in cutting off useless discussion, and it is very much your job to do so.   E.g., this was about a half hour of my time, and I have a bunch of other things to do before the draft submission cutoff that I didn't do so that I could respond to this.

> In Prague, we had a discussion of draft-green and there was neither consensus to work in this area nor to decline to work in this area.  In addition to the comments that we should simply decline all such work, the authors received technical comments about their approach and draft-rhrd seems to be an attempt to address some of those comments.  As is normal IETF practice, we will be giving this topic agenda time in Singapore to see if a consensus emerges one way or the other.

The problem with this is that technical comments about a bad idea just improve the bad idea.   The discussion we have been trying to have with the proponents of this idea is the question of whether or not it is a bad idea, not about the technical details.   I say this as someone who has proposed lots of bad ideas in the past.   When I propose a bad idea, and for example Dave Oran points out something obvious that I missed (true story), my response to this is to reconsider what I've proposed to do and to see if there is a better way to solve the problem, not to continue pushing for the idea that has been shown to be a bad idea.

Our objection here, which I third or fourth, is that this discussion has not progressed that way.   This is clearly a bad idea.   Maybe you don't agree.   But we've said why it's clearly a bad idea, and that is something that could have been discussed.   But none of the proponents of this idea have made any attempt to address the substantive objections that have been raised about the idea itself.

So it's not really fair to say that progress is being made.   Progress is being made on refining the bad idea, but no progress has been made in discussing ways to solve the problem that aren't a bad idea.   To be clear, I and several others have proposed ways of solving this problem that are not bad ideas.   These have been rejected on non-technical grounds.

> Absolutely no decisions will be made about adoption prior to that time, nor prior to a formal call for adoption. In particular, decisions will not be made based on the volume of messages to the mailing list.  It is unnecessary and unproductive to repeat points you have already made just because someone responds to you. You will not be missing out on the chance to make your argument.

This feels like the Overton window shifting due to a false equivalence.   The issue here is not that we feel that we will miss out on the chance to make our arguments.   It's that we've been making them, and they've been explicitly ignored.

> Finally, we would like to remind WG members to keep their messages professional and civil. We have noted a number of recent messages that do not conform to those standards and we will be reaching out to people personally to address those instances.

I believe that I have been personally chastized by another participant for responding in a way that was held by that participant to be uncivil/unprofessional.   If you agree with that assessment, please communicate with me to that effect privately (or publicly, if you prefer, but this conversation has really gone on for too long).

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2017 20:58:14 +0100

On 24/10/17 20:31, Ted Lemon wrote:
> But it's delaying other work, because people who could be doing
> useful work in the IETF are engaging on this topic instead.
I'm not sure of the extent to which my work in the IETF is
useful or not, but it is certainly the case that these
repeated proposals have consumed the cycles I have for that
work. As both Ted and Ben have said this I know I'm not
alone in that, and the volume of mail on the topic alone
shows that others are spending valuable time rebutting the
ongoing break-TLS show.

Whether or not any of us would have contributed to TLS1.3 or
DTLS1.3 being done sooner or better instead is another question,
but the real linkage to TLS1.3 here is that if any of these
bad ideas did achieve more that forcing us to oppose them, and
the WG went mad and adopted any of it, then that would surely
and fully muck up TLS1.3 and DTLS1.3, both in terms of timing
and I believe in terms of utility. (Who'd want a new TLS version
that's designed as broken?)

S.

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 25 Oct 2017 19:34:41 +0000

I didn't want to stick my foot in this, but here we are.

The goal for an inspection service to be able to take a recording of the
network and a key (or corpus of keys) and be able to decrypt any TLS
connection to a server within that network.

There are multiple ways of getting these keys.
1) use TLS 1.2 with RSA -> one single key
2) use TLS 1.3 with DH key derived from seed -> one single key (similar to
draft-green)
3) use any version of TLS and export the session keys -> corpus of keys
equal to number of connections

The fundamental assumption of this draft is that that 3) is not feasible
for all enterprises because rearchitecting their systems for a multi-key
escrow is either too costly or that the requirement for TLS 1.3 will come
too soon. Ted Lemon had some convincing arguments earlier about why
enterprises should see this coming and invest in migrating to a model
closer to 3), which will always be possible in a system that uses symmetric
cryptography for encryption. Newer companies like the one mentioned by Tony
Arcieri have managed to architect their systems this way, so it’s not
impossible. Still, it’s usually cheaper to adapt an existing system rather
than re-architect your network (and buy more gear). As long as 2) is
possible, the moving to a model based on 3) is going to be a hard sell.

Given that enterprises would rather be standards-compliant, this draft is a
way to prevent enterprises from just going ahead and implementing 2), and
instead implement something that has similar benefits (a single master key
that can decrypt multiple connections), but with additional safeguards for
the user:
-the ability to opt out
-visibility into the fact that their connection is part of a pool of
connections protected by a single key

You can do neither with 2). This is a win. To Rich’s argument that network
domains will force browsers to implement this by blocking connections that
don’t advertise this support, I disagree. There are no passive firewalls
that I know of that drop TLS connections that don’t support escrow (in the
sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow).
Shouldn’t these be blocked by the GFW if someone is forcing RSA escrow?

On that note, so what if some browsers opt in? Servers need to also opt-in
to setting visibility keys. These will be visible by the browser, and
visible by network watchdogs. Visibility is good in the situation where
both parties want to be honest, and a dishonest escrow mechanism is
possible. Furthermore, large services that are internet-facing that see
this extension existence can simply disconnect when it's presented,
applying back-pressure in the event of this "escaping" the datacenter.

Until TLS is redesigned so that a single key escrow is not possible,
datacenter operators will choose to do 2). For the next version of TLS, we
should strive to eliminate a the ability for a server to escrow a single
key. I posit that this should be a fundamental design principle for TLS
going forward: *cross-connection secrecy*. Forward secrecy with respect to
the long term certificate key is something that has been addressed in TLS
1.3. Forward secrecy with respect to other keys, like the session ticket
key or other keys that can be generated centrally, are things that need to
be looked at more closely for TLS 1.4 (or whatever’s next).

This draft is an optional extension that allows a client and server to
agree that a single key held by the server should be able to decrypt the
data of multiple connections. I don’t think it’s something that belongs on
the Internet as a whole, but understood it as a lesser of two evils with
respect to the options people have.

To summarize:
- TLS 1.3 allows single-key escrow with no client opt-in by design (because
of ephemeral DH)
- This is something that requires fundamental changes to TLS to fix, but
should be looked into
- Enterprises should look into moving to a model where session keys are
exported to prepare for this eventuality
- draft-rhrd allows clients to opt-in to an extension-based escrow system
that doesn’t abuse the core protocol and it enables network watchdogs to
observe
- having such a system on the internet is a bad idea because it reduces the
security of multiple connections down to a single piece of data
- on the other hand using draft-rhrd is safer than allowing organizations
to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
non-forward-secret cipher suites

Nick

On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich <[email-masked]> wrote:

> There’s no way to limit it to the use-case it was putatively intended
> for.  We now have a signaling mechanism that says “allow interception.”
> Firewalls can drop connections where the client doesn’t send that
> extension. Therefore they can force only tappable TLS traffic. This makes
> the job easier.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Oct 2017 16:03:38 -0400

On Oct 25, 2017, at 3:34 PM, Nick Sullivan <[email-masked]> wrote:
> Forward secrecy with respect to other keys, like the session ticket key or other keys that can be generated centrally, are things that need to be looked at more closely for TLS 1.4 (or whatever’s next).

Unless I am very much mistaken, it is literally impossible to prevent a server from escrowing a key so that the contents of the communication can be decrypted.

> - having such a system on the internet is a bad idea because it reduces the security of multiple connections down to a single piece of data
> - on the other hand using draft-rhrd is safer than allowing organizations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret cipher suites

There's no question of allowing or not allowing—that's outside of IETF's sphere of influence.   But the case has been (to me convincingly) made that making it possible for an eavesdropper on the conversation to easily tell whether a client is willing to accept key escrow makes things worse, from a security perspective.

The main sense in which it makes things worse is that such a feature might be added to standard libraries, and thus be available at low cost, and thus might become easy to impose as a regulatory requirement.

This is why I have been advocating for simply not using TLS for this use case.   There exist solutions to this problem that do not require breaking TLS 1.3, that are standard, and that are already allowed for PCI compliance.   It's better for everyone if these two domains are kept separate, and I haven't yet heard a good argument for not doing so.

> The fundamental assumption of this draft is that that 3) is not feasible for all enterprises because rearchitecting their systems for a multi-key escrow is either too costly or that the requirement for TLS 1.3 will come too soon. Ted Lemon had some convincing arguments earlier about why enterprises should see this coming and invest in migrating to a model closer to 3),

To be clear, I actually don't think that per-session key escrow is feasible in the use case that we are talking about here.   From a security perspective I think it's a pretty good idea, because it allows for things like rate-limiting the number of connections that can be monitored, but from a practical perspective, arranging to have the keys available in a timely manner during debugging seems to me not to be tractable, since the number of keys involved would be substantial, and the timing would be quite exact; indeed, if the debugging process requires debugging all active streams in order to find an ID in the stream that is actually sought, I think it would be almost impossible, and certainly ludicrously expensive.

What I've been arguing for is to switch away from TLS for this use case.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 22:32:24 +0100

Thank you Nick.

On 25/10/17 20:34, Nick Sullivan wrote:
> to setting visibility keys.

It is good to see the discussion move on from the proponents'
seeming inability to envisage that anything bad could possibly
happen here;-)

I believe you are right that if we standardise this, it is
reasonably likely to end up in some browser. (I've no idea
how to estimate that probability, so we're all guessing
really.)

As you might expect, I disagree with your analysis as to the
consequences if browsers did support this.

Just as one example, I read today of reports that some people
have been arrested/accused partly on the basis that they downloaded
some software [1] so it is sadly far too easy to imagine that
some regime somewhere would arrest people for having a browser
that does not support this "standard" feature. Note, I'm not
saying I accept all details of the story in [1] as such things
are often badly reported, but I do assert that such issues are
ones we ought be seriously considering.

For me, us defining a feature like this that could be mandated,
for wiretapping, or the absence of which could get folks into
that kind of trouble, is just not something we ought be risking,
regardless of our inability to estimate the probabilities
involved.

S.

[1]
https://www.theguardian.com/world/2017/oct/25/amnesty-turkish-chair-taner-kilic-on-trial-over-failed-coup