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

From: Russ Housley <[email-masked]>
Date: Wed, 19 Jul 2017 13:10:56 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 19:14:46 +0200

Provably involved, or involved setting an evil bit?

On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <[email-masked]> wrote:

> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 18:27:15 +0100

On 19/07/17 18:10, Russ Housley wrote:
> 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 would almost certainly be opposed. There are enough generic
reasons to not break tls to go around for us all.

S.

> 
> 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 _______________________________________________ TLS mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 19 Jul 2017 12:29:09 -0700

Can you provide more context for those of us not in the room? What was the
hum in reference to?

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jul 2017 02:01:03 -0400

Ted, if we use a new extension, then the server cannot include it unless the client offered it first.  I am thinking of an approach where the server would include information needed by the decryptor in the response.  So, if the client did not offer the extension, it would be a TLS protocol violation for the server to include it.

Russ

> On Jul 19, 2017, at 1:14 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

---

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

The agenda included:

- Data Center use of Static DH (30 min)
 https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ <https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/>

- National Cybersecurity Center of Excellence (NCCOE) project for
 visibility within the datacenter with TLS 1.3 (10min)
 aka implementing draft-green-tls-static-dh-in-tls13

- Discussion about the previous topic (40min)

At the start of the Discussion portion of the agenda, Stephen Farrell talked about https://github.com/sftcd/tinfoil <https://github.com/sftcd/tinfoil>.

At the end of the Discussion, the chairs asked for a hum about working on visibility in the datacenter, and the room was evenly split.

Russ

> On Jul 19, 2017, at 3:29 PM, Ryan Hamilton <[email-masked]> wrote:
> 
> Can you provide more context for those of us not in the room? What was the hum in reference to?
> 
> On Wed, Jul 19, 2017 at 10:10 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

---

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

I think that's okay, since this is only for use in applications where both
parties are in on the deal. But the problem with the static ecdh proposal
is the the server is not compelled to reveal that it is doing it.

On Jul 20, 2017 8:01 AM, "Russ Housley" <[email-masked]> wrote:

> Ted, if we use a new extension, then the server cannot include it unless
> the client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, if
> the client did not offer the extension, it would be a TLS protocol
> violation for the server to include it.
>
> Russ
>
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Jul 2017 08:53:33 +0200

> On 20 Jul 2017, at 8:01, Russ Housley <[email-masked]> wrote:
> 

So we also add an alert called “key-export-needed” in case the client does not include it.

That way a browser (as an example) can show the user why the connection was broken (“server requires wiretapping to be enabled. Go to about:config <about:config> if that is OK and change the allow-wiretap setting to True”)

---

From: [email-masked] (Martin Rex)
Date: Thu, 20 Jul 2017 15:29:20 +0200 (CEST)

I'm sorry, Russ, but I think this would be seriously deceiving.

Russ Housley wrote:
> both the client and the server, would the working group adopt it, work
> on it, and publish it as an RFC?
> 
> 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.

Any party observing the handshake (read: a monitoring middlebox) would
see whether client proposed the extension and server confirmed the extension
in the clear part of the TLS handshake, and that very same monitoring
middlebox very very very probably would kill/prevent all TLS handshakes
without that extension being confirmed by the server from completing...

... at which point this is no longer a "rare and occasional voluntary
opt-in for debugging broken apps" but rather a policy enforcment known
as "coercion".

I am violently opposed to standardizing enfored wire-tapping for TLS.

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Thu, 20 Jul 2017 09:43:41 -0500

On 20 July 2017 at 01:53, Yoav Nir <[email-masked]> wrote:
> Ted, if we use a new extension, then the server cannot include it unless the
> client offered it first.  I am thinking of an approach where the server
> the client did not offer the extension, it would be a TLS protocol violation
> for the server to include it.
>
>
> That way a browser (as an example) can show the user why the connection was
> broken (“server requires wiretapping to be enabled. Go to about:config if
> that is OK and change the allow-wiretap setting to True”)

I previously expressed that I could support the extension mechanism -
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breaking
crypto) to achieve them. I've looked at more than one 'end to end'
encrypted messenger that tosses in the 'third end' of key escrow.

But to suggest such a mechanism might ever be implemented in a web
browser throws my hackles up. The discussion has always been about
datacenter - the people concerned say "We don't want your datacenter
stuff in our protocol and the proponents say "No really, we only care
about the datacenter."

The concerns around some future government-mandated key escrow is very
real and very concerning.

-tom

---

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

The problem is that one of the applications for web browsers is as a
replacement for 3270s (the first web browser).   That use case is said to
require this functionality.

On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter <[email-masked]> wrote:

> the
> > So we also add an alert called “key-export-needed” in case the client
> does
> > not include it.
> >

---

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

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, July 20, 2017 09:29
To: Russ Housley <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

Russ Housley wrote:

> party observing the handshake could see the extension was included or not.

Any party observing the handshake (read: a monitoring middlebox) would see whether client proposed the extension and server confirmed the extension in the clear part of the TLS handshake, and that very same monitoring middlebox very very very probably would kill/prevent all TLS handshakes without that extension being confirmed by the server from completing...

Just to make sure I understand the scenario: The nation state has contacted the TLS server owner and convinced/coerced them to provide contents of communications. They've decided that instead of using options 1, 2, or 3 in my earlier message (I can resend if that would help), they tell the TLS server owner that they would like them to use the extension method. If a client attempted to connect without including the extension, they would kill the connection. That seems like it protects the client from being eavesdropped, and they could discern that someone is attempting to listen. Can you expand on how this would be deceiving?

... at which point this is no longer a "rare and occasional voluntary opt-in for debugging broken apps" but rather a policy enforcment known as "coercion".

It seems a middlebox owner who is both powerful and intent enough to pursue this would instead compel the TLS server owner to use options 1, 2, or 3.

-Martin

TLS mailing list

[email-masked]<mailto:[email-masked]>

---

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

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Tom Ritter
Sent: Thursday, July 20, 2017 10:44
To: Yoav Nir <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

On 20 July 2017 at 01:53, Yoav Nir < <mailto:[email-masked]> [email-masked]> wrote:

> On 20 Jul 2017, at 8:01, Russ Housley < <mailto:[email-masked]> [email-masked]> wrote:

> Ted, if we use a new extension, then the server cannot include it 

> unless the client offered it first.  I am thinking of an approach 

> where the server would include information needed by the decryptor in 

> the response.  So, if the client did not offer the extension, it would 

> be a TLS protocol violation for the server to include it.

> does not include it.

> That way a browser (as an example) can show the user why the 

> connection was broken (“server requires wiretapping to be enabled. Go 

> to about:config if that is OK and change the allow-wiretap setting to 

> True”)

I previously expressed that I could support the extension mechanism - I'm sympathetic to regulatory requirements and unhappy with, although understanding of, what has become the 'standard mechanism' (breaking

But to suggest such a mechanism might ever be implemented in a web browser throws my hackles up. The discussion has always been about datacenter - the people concerned say "We don't want your datacenter stuff in our protocol and the proponents say "No really, we only care about the datacenter."

The concerns around some future government-mandated key escrow is very real and very concerning.

It seems like that problem exists today with TLS 1.3. If a government is powerful enough to mandate key escrow, wouldn’t they also be power enough to mandate implementing static DH with TLS 1.3 (so that they key escrow is possible). In addition, based on this level of influence, couldn’t they alternatively require TLS server owners to provide them unencrypted data. 

-tom

TLS mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/tls> https://www.ietf.org/mailman/listinfo/tls

---

From: Tom Ritter <[email-masked]>
Date: Thu, 20 Jul 2017 10:19:51 -0500

On 20 July 2017 at 10:07, Paul Turner <[email-masked]> wrote:
> It seems like that problem exists today with TLS 1.3. If a government is
> powerful enough to mandate key escrow, wouldn’t they also be power enough to
> mandate implementing static DH with TLS 1.3 (so that they key escrow is
> possible). In addition, based on this level of influence, couldn’t they
> alternatively require TLS server owners to provide them unencrypted data.

Anything's possible, but it there's a difference between:

"I demand you implement a new mechanism to securely ship me crypto
keys or plaintext, do something for which there is no standard
mechanism or agreement."

and

"If you flip this existing setting right here in OpenSSL, and stick
this public key right here, it will automatically satisfy our
requirements."

I recall one of the arguments that Apple made against the FBI was that
they were asking them to do something novel that required significant
amounts of work, testing, had never been done before, etc. IANAL but I
think this is standard argument to show the request is unreasonable
and overly burdensome. Removing that argument concerns me.
(US-centric view if that isn't apparent.)

-tom

---

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

-----Original Message-----
From: Tom Ritter [mailto:[email-masked]]
Sent: Thursday, July 20, 2017 11:20
To: Paul Turner <[email-masked]>
Cc: Yoav Nir <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

On 20 July 2017 at 10:07, Paul Turner <[email-masked]<mailto:[email-masked]>> wrote:

> It seems like that problem exists today with TLS 1.3. If a government

> is powerful enough to mandate key escrow, wouldn’t they also be power

> enough to mandate implementing static DH with TLS 1.3 (so that they

> key escrow is possible). In addition, based on this level of

> influence, couldn’t they alternatively require TLS server owners to provide them unencrypted data.

"I demand you implement a new mechanism to securely ship me crypto keys or plaintext, do something for which there is no standard mechanism or agreement."

and

"If you flip this existing setting right here in OpenSSL, and stick this public key right here, it will automatically satisfy our requirements."

Thanks for this clarification. I agree that anything is possible in both directions. Russ opened this discussion by asking about an alternative to static DH. In this model, I’ve assumed the client would need to explicitly opt-in by including an extension in its ClientHello. There are obviously details to work out but if it were possible to provide a method like that, it seems like it would thwart the second option. Would it?

I recall one of the arguments that Apple made against the FBI was that they were asking them to do something novel that required significant amounts of work, testing, had never been done before, etc. IANAL but I think this is standard argument to show the request is unreasonable and overly burdensome. Removing that argument concerns me.

-tom

---

From: Tom Ritter <[email-masked]>
Date: Thu, 20 Jul 2017 10:44:58 -0500

On 20 July 2017 at 10:29, Paul Turner <[email-masked]> wrote:
> Thanks for this clarification. I agree that anything is possible in both
> directions. Russ opened this discussion by asking about an alternative to
> static DH. In this model, I’ve assumed the client would need to explicitly
> opt-in by including an extension in its ClientHello. There are obviously
> details to work out but if it were possible to provide a method like that,
> it seems like it would thwart the second option. Would it?

Not when the target of the request is Facebook for their Messenger
App. Or Google for the Gmail app, or Hangouts. Or Skype.

What percentage of TLS protected communication takes place between a
client and server developed by the same company? All of that is
immediately at risk.

What about 360 Browser (one of the popular Chinese-made web browsers)?
Hell, they _still_ aren't validating SSL certificates!![0] The dynamic
for them (both technical and political) is quite different than for
what we tend to think of as 'browsers'.

I get the impression you're assuming that 'the' (for nebulous values
of 'the') government isn't going to ask a web browser to support the
mechanism, and they would only go to the webservers. But because it's
an offer/accept mechanism, there's an argument that goes "Hey
Browser-Maker make all of your installs _offer_ to encrypt to our
escrow key, and if the server doesn't accept it, don't." "Hey
US-Company, make all of your web servers support escrowing to our key
if the client offers to. If the client doesn't offer, don't."

The more I think about standardizing such a mechanism the more nervous
I get we will be building something that is too likely to be used,
even if not expansively, against the ideals we have espoused in 2804
and elsewhere.

-tom

[0] Yea. Really. It was this case a little bit ago for 99% of sites on
the web and I'll make you a bet it's still the case today.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 21 Jul 2017 10:00:34 +0000

Ted
You may be aware that most enterprises have been migrating away from 3270 for 20 years or more.  Very little still exists.      What little does exist is usually implemented via tn3270.   In the browser scenario you describe I would expect the Server side to be a tn3270 server,  but you will have to fill in the details of the use case you are describing,  to be sure.

I hope the above helps,  but my real question is why would this be special or even relevant to the TLS1.3 discussion.

Attempting to address specific applications or implementations would seem only add confusion IMHO.

Thanks

Mike

From: TLS [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 10:48 AM
To: Tom Ritter <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] Is there a way forward after today's hum?

The problem is that one of the applications for web browsers is as a replacement for 3270s (the first web browser).   That use case is said to require this functionality.

On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter <[email-masked]<mailto:[email-masked]>> wrote:
On 20 July 2017 at 01:53, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
>

-tom

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: Ted Lemon <[email-masked]>
Date: Fri, 21 Jul 2017 12:15:18 +0200

As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once.   The
reason the 3270 is no longer widely used is because it's been replaced by
web browsers.

Mentioning that in passing probably made my message less clear; the point
is that the 3270<->mainframe model of operation comes with very different
assumptions than the web browser<->service provider model, and one of the
problems you have is that what you are doing is really the former and not
the latter.

On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael <[email-masked]>
wrote:

> Ted
>
> You may be aware that most enterprises have been migrating away from 3270
> for 20 years or more.  Very little still exists.      What little does
> exist is usually implemented via tn3270.   In the browser scenario you
> describe I would expect the Server side to be a tn3270 server,  but you
> will have to fill in the details of the use case you are describing,  to be
> sure.
>
>
>
> I hope the above helps,  but my real question is why would this be special
> or even relevant to the TLS1.3 discussion.
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter <[email-masked]>
> *Cc:* IETF TLS <[email-masked]>
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> 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.
>