Subject: Re: [TLS] Is there a way forward after today's hum?

From: Robin Wilton <[email-masked]>
Date: Thu, 20 Jul 2017 09:57:59 +0000

Apologies for not replying "in thread" on this occasion, for noob reasons... but here's the specific comment from Russ that I wanted to respond to:

________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I wish the chairs had asked a second question.  If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking.

If a specification were available that used an extension that involved both the client and the server, would the working group adopt it, work on it, and publish it as an RFC?

I was listening very carefully to the comments made by people in line.  Clearly some people would hum for "no" to the above question, but it sounded like many felt that this would be a significant difference.  It would ensure that both server and client explicitly opt-in, and any party observing the handshake could see the extension was included or not.

Russ

====

Stephen Farrell articulated a concern with that approach - namely, that if we are relying on a setting that is meant to ensure both parties must be aware that static DH is in use, then a bad actor would find ways to suppress that notification. In your proposal, Russ, the notification mechanism would take the form of an extension... so I think we would need to understand what the failsafe is, for instance if that extension is disabled, or not present, in a given deployment of TLS.

There's an implicit assumption about the threat model, too, which I just want to call out. The assumption is that a bad actor would suppress the notification so that the client is not aware that static DH is in use. For completeness, should we also consider whether there are attacks in which it's the *server* whose notification is suppressed? (I can't think of such an attack, off the top of my head, but then, that's probably why I'm not a hacker. ;^, )

Best wishes,

Robin

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 11:03:53 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: [email-masked]
Subject: Re: [TLS] Is there a way forward after today's hum?

Russ

====

Best wishes,

Robin

Robin,

With respect to your threat concerns, can you be more clear about the threats you're considering? Here are a few things that come to mind:

  1.  TLS Server has all of the decrypted data and can provide that to a third party (whether compelled or otherwise) without any indication to the TLS client. This seems true TLS 1.3 today.
  2.  TLS Server has their ephemeral DH keys and session keys and can provide them to a third party without any indication to the TLS client. This seems true with TLS 1.3 today.
  3.  TLS Server can create a TLS server implementation that uses static DH keys and provide them to a third party. The client can use methods to detect this (though there are measures and countermeasures here). This is true seems TLS 1.3 today.
  4.  TLS Client has all of the decrypted data and can provide that to a third party (whether compelled or otherwise) without any indication to the TLS server. This seems true in TLS 1.3 today.
  5.  TLS Client has their ephemeral DH keys and session keys and can provide them to a third party without any indication to the TLS server. This seems true with TLS 1.3 today.

I believe Russ was outlining a method where an extension would be added to TLS 1.3 that would provide for delivery of a decryption key to a third party during the handshake (correct me if I got that wrong, Russ). Because it would be during the handshake, it would seem to be visible to the TLS  Client-in fact, the client would have to include the extension to begin with. If the TLS client saw the extension and did not consent, it could abort the connection. If the TLS Server were attempting to provide access to the exchanged data to a third party, it would seem they could use 1, 2, or 3 above and not have to go to the trouble of attempting to subvert the mechanism that Russ proposes (and others have previously proposed).

Can you clarify?

Paul

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 13:25:27 +0200

Paul, it would be trivial to normal that exchange to conceal from the
client that a static key is being used. No software mods required on either
end: just in the middle.

On Jul 20, 2017 1:04 PM, "Paul Turner" <[email-masked]> wrote:

>
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* [email-masked]
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> ------------------------------
>
> Stephen Farrell articulated a concern with that approach - namely, that if
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. For
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of such
> an attack, off the top of my head, but then, that's probably why I'm not a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you’re considering? Here are a few things that come to mind:
>
>
>
>    1. TLS Server has all of the decrypted data and can provide that to a
>    third party (whether compelled or otherwise) without any indication to the
>    TLS client. This seems true TLS 1.3 today.
>    2. TLS Server has their ephemeral DH keys and session keys and can
>    provide them to a third party without any indication to the TLS client.
>    This seems true with TLS 1.3 today.
>    3. TLS Server can create a TLS server implementation that uses static
>    DH keys and provide them to a third party. The client can use methods to
>    detect this (though there are measures and countermeasures here). This is
>    true seems TLS 1.3 today.
>    4. TLS Client has all of the decrypted data and can provide that to a
>    third party (whether compelled or otherwise) without any indication to the
>    TLS server. This seems true in TLS 1.3 today.
>    5. TLS Client has their ephemeral DH keys and session keys and can
>    provide them to a third party without any indication to the TLS server.
>    This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added to
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Because
> it would be during the handshake, it would seem to be visible to the TLS
> Client—in fact, the client would have to include the extension to begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jul 2017 07:35:28 -0400

> On Jul 20, 2017, at 5:57 AM, Robin Wilton <[email-masked]> wrote:
> 

Robin:

I belive that such tampering would be detected by the finished message processing and the handshake would fail.

Russ

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 11:44:34 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:25
To: Paul Turner <[email-masked]>
Cc: Robin Wilton <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

Paul, it would be trivial to normal that exchange to conceal from the client that a static key is being used. No software mods required on either end: just in the middle.

Thanks, Ted. Can you expand on this?

Also, can you also put it in the context of a threat model as Robin suggested? I’ve suggested some things below but may not have it right. Why would the attacker take this approach versus some of the readily available methods?

Paul

On Jul 20, 2017 1:04 PM, "Paul Turner" <[email-masked]<mailto:[email-masked]>> wrote:

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

Russ

====

Best wishes,

Robin

Robin,

With respect to your threat concerns, can you be more clear about the threats you’re considering? Here are a few things that come to mind:

I believe Russ was outlining a method where an extension would be added to TLS 1.3 that would provide for delivery of a decryption key to a third party during the handshake (correct me if I got that wrong, Russ). Because it would be during the handshake, it would seem to be visible to the TLS  Client—in fact, the client would have to include the extension to begin with. If the TLS client saw the extension and did not consent, it could abort the connection. If the TLS Server were attempting to provide access to the exchanged data to a third party, it would seem they could use 1, 2, or 3 above and not have to go to the trouble of attempting to subvert the mechanism that Russ proposes (and others have previously proposed).

Can you clarify?

Paul

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 13:51:16 +0200

Paul, the reason to use the MiTM approach rather than simply hacking the
endpoint the attacker controls is that it may be much more convenient to be
running out-of-the-box software on the endpoint.   The MiTM isn't an
attacker from the perspective of the controlled endpoint; it is simply a
convenient way to conceal what is being done.

Having thought about it some more, as Russ points out, it might be too
expensive to be worth doing, because you'd have to hack the whole stream.
It would not, for example, be a useful passive attack, obviously.

That said, suppose this extension were added to everyone's TLS libraries.
Now the number of lines of code I'd have to #ifdef out to avoid setting the
evil bit would be much less than if it weren't.

On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner <[email-masked]> wrote:

>
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner <[email-masked]>
> *Cc:* Robin Wilton <[email-masked]>; <[email-masked]> <[email-masked]>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I’ve suggested some things below but may not have it right. Why
> would the attacker take this approach versus some of the readily available
> methods?
>
>
>
> Paul
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Jul 2017 12:53:45 +0100

On 20/07/17 12:44, Paul Turner wrote:
> 
> I believe Russ was outlining a method where an extension would be
> added to TLS 1.3 that would provide for delivery of a decryption key
> to a third party during the handshake (correct me if I got that
> wrong, Russ). Because it would be during the handshake, it would seem
> to be visible to the TLS  Client—in fact, the client would have to
> include the extension to begin with. If the TLS client saw the
> extension and did not consent, it could abort the connection. If the
> TLS Server were attempting to provide access to the exchanged data to
> a third party, it would seem they could use 1, 2, or 3 above and not
> have to go to the trouble of attempting to subvert the mechanism that
> Russ proposes (and others have previously proposed).
Yeah, good try, but *which* third party?

The kind of (IMO) intractable questions that Would arise
include whether or not enterprise clients only want their
own snoopers to snoop and not everyone else's? And then
the naming issues become intractable. And of course in
many applications (e.g. SMTP) there's still >1 TLS session
in the mail e2e path. And in the web there can be >1 box
between the browser and content site. Yoav already brought
up another one about about:config, and, and, and...

In the end, this'd be another failed proposal is my bet.
I volunteer to help in the engineering of that if needed;-)

That's not to doubt or deride the folks posing illformed
requirements but because squaring circles is just not a
good plan.

S.

---

From: "Paul Turner" <[email-masked]>
Date: Thu, 20 Jul 2017 07:58:04 -0400

Sent: Thursday, July 20, 2017 07:51

Paul, the reason to use the MiTM approach rather than simply hacking the endpoint the attacker controls is that it may be much more convenient to be running out-of-the-box software on the endpoint.   The MiTM isn't an attacker from the perspective of the controlled endpoint; it is simply a convenient way to conceal what is being done.

To make sure I understand your reference to MiTM, is that different than the third party in #2 and #3 below?

Having thought about it some more, as Russ points out, it might be too expensive to be worth doing, because you'd have to hack the whole stream.   It would not, for example, be a useful passive attack, obviously.

That said, suppose this extension were added to everyone's TLS libraries.   Now the number of lines of code I'd have to #ifdef out to avoid setting the evil bit would be much less than if it weren't.

On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner <[email-masked] <mailto:[email-masked]> > wrote:

From: TLS [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:25
To: Paul Turner <[email-masked] <mailto:[email-masked]> >
Cc: Robin Wilton <[email-masked] <mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]> > <[email-masked] <mailto:[email-masked]> >
Subject: Re: [TLS] Is there a way forward after today's hum?

Paul

On Jul 20, 2017 1:04 PM, "Paul Turner" <[email-masked] <mailto:[email-masked]> > wrote:

From: TLS [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [TLS] Is there a way forward after today's hum?

  _____  

 
 
Russ

====

Best wishes,

Robin  

Robin,

Can you clarify?

Paul

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

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 12:04:16 +0000

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 07:54
To: Paul Turner <[email-masked]>; Ted Lemon <[email-masked]>
Cc: Robin Wilton <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 12:44, Paul Turner wrote:

> to a third party during the handshake (correct me if I got that wrong,

> Russ). Because it would be during the handshake, it would seem to be

> visible to the TLS  Client—in fact, the client would have to include

> the extension to begin with. If the TLS client saw the extension and

> did not consent, it could abort the connection. If the TLS Server were

> attempting to provide access to the exchanged data to a third party,

> it would seem they could use 1, 2, or 3 above and not have to go to

> the trouble of attempting to subvert the mechanism that Russ proposes

> (and others have previously proposed).

Let’s use the oppressive government institution that I believe you’ve mentioned (pardon me if I got that wrong) with a connection over the Internet in this case. Can you reply in that context? I’m truly interested in understanding. It wasn’t a “try”.

The kind of (IMO) intractable questions that Would arise include whether or not enterprise clients only want their own snoopers to snoop and not everyone else's? And then the naming issues become intractable. And of course in many applications (e.g. SMTP) there's still >1 TLS session in the mail e2e path. And in the web there can be >1 box between the browser and content site. Yoav already brought up another one about about:config, and, and, and...

That's not to doubt or deride the folks posing illformed requirements but because squaring circles is just not a good plan.

S.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 14:05:51 +0200

It's a variant of (3).

What your threat models do not take into account is how these attacks
relate to the problem they are proposed to solve.   The reason we're even
having this discussion is because some data center operators feel that
having ephemeral keys is too onerous, and that they would like the IETF to
weaken TLS 1.3 to no longer require this.

So if you just consider this problem in the abstract as a serious of
potential threat models, you're somewhat missing the point.   From my
perspective, the problem here is that to address this use case, we are
being asked to make a change to TLS which will make every existing
implementation of TLS that conforms to the change weaker.

It is certainly true that TLS 1.3 isn't resistant to the threats you've
described; that's not the point.   The point is that TLS 1.3 makes each of
these threats substantially more expensive to pull off, with more moving
parts and more people with a need to know.   It does not make the attacks
impossible, or even impossible to do in secret.  It makes them harder, and
harder to do in secret.

On Thu, Jul 20, 2017 at 1:58 PM, Paul Turner <[email-masked]> wrote:

> *Sent:* Thursday, July 20, 2017 07:51
>   Now the number of lines of code I'd have to #ifdef out to avoid setting
> the evil bit would be much less than if it weren't.
>
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Jul 2017 13:21:44 +0100

Hiya,

On 20/07/17 13:04, Paul Turner wrote:
> Let’s use the oppressive government institution that I believe you’ve
> mentioned (pardon me if I got that wrong) with a connection over the
> Internet in this case. 

Sorry, I'm not sure what you mean there, but guessing, yes,
there can be multiple nation state actors who would try to
compel use of this mitm, and for a proposal in this space
that also causes intractable problems when a connection is
supposed to be mitm'd by more than one of those, or one is
not clear which is the appropriate nation state attacker
to appease.

> Can you reply in that context? I’m truly
> interested in understanding. It wasn’t a “try”.
Hopefully the above helps, but it may also help to say that
the appropriate context I'd consider for TLS is essentially
all the applications of TLS and all the deployments that'd
eventually be updated with whatever proposal is on the table.
(Prior to getting it off the table when it's shown to be
a bad plan:-)

Cheers,
S.

---

From: Robin Wilton <[email-masked]>
Date: Thu, 20 Jul 2017 13:35:41 +0000

________________________________
From: Russ Housley <[email-masked]>
Sent: Thursday, July 20, 2017 12:35 PM
To: Robin Wilton
Cc: IETF TLS
Subject: Re: [TLS] Is there a way forward after today's hum?

On Jul 20, 2017, at 5:57 AM, Robin Wilton <[email-masked]<mailto:[email-masked]>> wrote:

Russ

====

Best wishes,
Robin

Robin:

Russ

Thanks, Russ;

If I am analysing this correctly, there are two "tampering events" involved here.

The first is: has someone tampered at the protocol/notification level to prevent the client from being notified that static DH is in use?

The second is: when the client decrypts traffic using whatever has resulted from the key exchange protocol, can it tell whether the DH key that was used is a static one or not?

I don't know enough about your proposed extension to judge whether it's reasonable to assume that the finished message processing would detect either of those or not (but I freely admit, that's my lack of knowledge).

Yrs.,
Robin

---

From: Robin Wilton <[email-masked]>
Date: Thu, 20 Jul 2017 13:45:25 +0000

Hi Paul - thanks for this; two comments inline.

I'm an Outlook Webmail n00b, so just in case "nesting" doesn't work, I have marked them with @@@.

________________________________
From: Paul Turner <[email-masked]>
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; [email-masked]
Subject: RE: [TLS] Is there a way forward after today's hum?

Russ

====

Best wishes,

Robin

Robin,

@@@I'll have to give these proper thought when I have more bandwidth - so, I'm not ignoring these good questions/scenarios!

I believe Russ was outlining a method where an extension would be added to TLS 1.3 that would provide for delivery of a decryption key to a third party during the handshake (correct me if I got that wrong, Russ).

@@@This seems somewhat different to static DH... are we now talking about an alternative, more along key escrow lines?  Apologies if I missed something earlier from Russ; I'll go back down the thread and see.

Because it would be during the handshake, it would seem to be visible to the TLS  Client—in fact, the client would have to include the extension to begin with. If the TLS client saw the extension and did not consent, it could abort the connection. If the TLS Server were attempting to provide access to the exchanged data to a third party, it would seem they could use 1, 2, or 3 above and not have to go to the trouble of attempting to subvert the mechanism that Russ proposes (and others have previously proposed).

Can you clarify?

Paul

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 20 Jul 2017 10:11:16 -0400

On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton <[email-masked]> wrote:
>...
> The first is: has someone tampered at the protocol/notification level to
> prevent the client from being notified that static DH is in use?
>
> The second is: when the client decrypts traffic using whatever has resulted
> from the key exchange protocol, can it tell whether the DH key that was used
> is a static one or not?
>
> I don't know enough about your proposed extension to judge whether it's
> reasonable to assume that the finished message processing would detect
> either of those or not (but I freely admit, that's my lack of knowledge).

In my mind's eye, and stepping back to 10,000 feet, the security
engineering problem you are witnessing is:

   * The security community has advised "DH for perfect forward secrecy"
   * RSA key transport was deprecated because it does not provide PFS
   * The proposal does an end-around, and it breaks
expectations/security properties

The security community created the "reasonable expectation" of PFS
when using Diffie-Hellman. A typical developer who follows best
practices will expect it. It was pounded into heir heads. Cf.,
https://www.imperialviolet.org/2013/12/03/forwardsecretforjournalists.html
and https://www.imperialviolet.org/2013/06/27/botchingpfs.html.

The typical developer will not be able to make the distinction between
Diffie-Hellman Ephemeral and Static Diffie-Hellman modulo key vaulting
so traffic can be decrypted later. In the typical developer's eyes,
they have been told to do something because it has certain security
properties but it no longer holds.

The signalling indicates the loss of the security property typical
developers and users have come to expect.

Jeff

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 14:40:54 +0000

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 08:22
To: Paul Turner <[email-masked]>; Ted Lemon <[email-masked]>
Cc: Robin Wilton <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

Hiya,

> Internet in this case.

Sorry, I'm not sure what you mean there, but guessing, yes, there can be multiple nation state actors who would try to compel use of this mitm, and for a proposal in this space that also causes intractable problems when a connection is supposed to be mitm'd by more than one of those, or one is not clear which is the appropriate nation state attacker to appease.

I’m assuming that you’re referring to multiple nations being between the TLS client and server. If a TLS client is set to not include the extension, it seems the TLS client would simply close the connection. It seems the client could choose whether it wanted to appease the nation states. Did I misunderstand?

> Can you reply in that context? I’m truly interested in understanding.

> It wasn’t a “try”.

Hopefully the above helps, but it may also help to say that the appropriate context I'd consider for TLS is essentially all the applications of TLS and all the deployments that'd eventually be updated with whatever proposal is on the table.

Agreed.  It is critical to consider all of the possible use cases.

(Prior to getting it off the table when it's shown to be a bad plan:-)

Cheers,

S.

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 14:55:11 +0000

Thanks for your response.  Response to one of your comments below.

From: TLS [mailto:[email-masked]] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 09:45
To: Paul Turner <[email-masked]>; [email-masked]
Subject: Re: [TLS] Is there a way forward after today's hum?

________________________________
From: Paul Turner <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; [email-masked]<mailto:[email-masked]>
Subject: RE: [TLS] Is there a way forward after today's hum?

Russ

====

Best wishes,

Robin

Robin,

I was assuming to Russ' comment above "an extension that involved both the client and the server", which is a different approach than static DH. I may have misunderstood his message.

Because it would be during the handshake, it would seem to be visible to the TLS  Client-in fact, the client would have to include the extension to begin with. If the TLS client saw the extension and did not consent, it could abort the connection. If the TLS Server were attempting to provide access to the exchanged data to a third party, it would seem they could use 1, 2, or 3 above and not have to go to the trouble of attempting to subvert the mechanism that Russ proposes (and others have previously proposed).

Can you clarify?

Paul

---

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

On 20/07/17 15:40, Paul Turner wrote:
> I’m assuming that you’re referring to multiple nations being between
> the TLS client and server. If a TLS client is set to not include the
> extension, it seems the TLS client would simply close the connection.
> It seems the client could choose whether it wanted to appease the
> nation states. 

Through how many nations states did this email travel between you
and I? Mail is maybe worse than the web, but that's just with our
current deployments but who knows when they'll migrate a 5G VM for
a web server close to my base station?

I'd assert there's no way TLS clients in general could know when
to set or unset the "please wiretap me" evil bit in a ClientHello,
regardless of how complex a configuration is used.

Cheers,
S.

---

From: Paul Turner <[email-masked]>
Date: Thu, 20 Jul 2017 15:23:19 +0000

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 10:58
To: Paul Turner <[email-masked]>; Ted Lemon <[email-masked]>
Cc: Robin Wilton <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

> nation states.

Through how many nations states did this email travel between you and I? Mail is maybe worse than the web, but that's just with our current deployments but who knows when they'll migrate a 5G VM for a web server close to my base station?

Can you clarify on the scenario a bit? Is one or more of the MTAs in the nation state (that wants to listen)? If so, it seems the nation state can get to the data with options 1, 2,  or 3 in my earlier message (options that are available with TLS 1.3 today). They don’t have to attempt to circumvent the method Russ eluded to at the beginning of this thread.

I'd assert there's no way TLS clients in general could know when to set or unset the "please wiretap me" evil bit in a ClientHello, regardless of how complex a configuration is used.

It seems like the guidance would be for all TLS clients to NOT include the extension by default. Anyone who wanted to enable it on their TLS client would have to explicitly turn it on through configuration. Since the client wouldn’t include the extension and the server would know that the client would abort the connection if it included the extension in return (a violation of TLS 1.3), the server would simply proceed in killing the connection itself. It doesn’t seem like there would be the need for complex configuration decisions to be made by TLS client users who have no intention of enabling it. Is that correct?

Cheers,

S.

---

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

On 20/07/17 16:23, Paul Turner wrote:
>> I'd assert there's no way TLS clients in general could know when to
>> set or unset the "please wiretap me" evil bit in a ClientHello,
> It seems like the guidance would be for all TLS clients to NOT
> include the extension by default. Anyone who wanted to enable it on
> their TLS client would have to explicitly turn it on through
> configuration. Since the client wouldn’t include the extension and
> the server would know that the client would abort the connection if
> it included the extension in return (a violation of TLS 1.3), the
> server would simply proceed in killing the connection itself. It
> doesn’t seem like there would be the need for complex configuration
> decisions to be made by TLS client users who have no intention of
> enabling it. Is that correct?
No. What's correct is never even defining this at all.

If you think there's some other correct state of affairs I will
read the I-D you write describing that. (And then debunk it:-)

S.