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

2017-07-21 Thread Ted Lemon 
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 <mackerm...@bcbsm.com>
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.
>
>
>
> Attempting to address specific applications or implementations would seem
> only add confusion IMHO.
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter <t...@ritter.vg>
> *Cc:* IETF TLS <tls@ietf.org>
> *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 <t...@ritter.vg> wrote:
>
> On 20 July 2017 at 01:53, Yoav Nir <ynir.i...@gmail.com> wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley <hous...@vigilsec.com> 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.
> >
> >
> > 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 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
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-20 Thread Tom Ritter 
On 20 July 2017 at 10:29, Paul Turner  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.

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

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

2017-07-20 Thread Paul Turner 




-Original Message-
From: Tom Ritter [mailto:t...@ritter.vg]
Sent: Thursday, July 20, 2017 11:20
To: Paul Turner <ptur...@equio.com>
Cc: Yoav Nir <ynir.i...@gmail.com>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?



On 20 July 2017 at 10:07, Paul Turner 
<ptur...@equio.com<mailto:ptur...@equio.com>> 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."



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.

(US-centric view if that isn't apparent.)



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

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

2017-07-20 Thread Stephen Farrell 


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



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

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

2017-07-20 Thread Paul Turner 




-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 10:58
To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com>
Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?







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?



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.














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

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

2017-07-20 Thread Tom Ritter 
On 20 July 2017 at 10:07, Paul Turner  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

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

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

2017-07-20 Thread Paul Turner 
 

 

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tom Ritter
Sent: Thursday, July 20, 2017 10:44
To: Yoav Nir <ynir.i...@gmail.com>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?

 

On 20 July 2017 at 01:53, Yoav Nir < <mailto:ynir.i...@gmail.com> 
ynir.i...@gmail.com> wrote:

> 

> On 20 Jul 2017, at 8:01, Russ Housley < <mailto:hous...@vigilsec.com> 
> hous...@vigilsec.com> 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.

> 

> 

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

 

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:TLS@ietf.org> TLS@ietf.org

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

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

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

2017-07-20 Thread Stephen Farrell 


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.









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

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

2017-07-20 Thread Paul Turner 
Thanks for your response.  Response to one of your comments below.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 09:45
To: Paul Turner <paul.tur...@venafi.com>; tls@ietf.org
Subject: Re: [TLS] Is there a way forward after today's hum?


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 <paul.tur...@venafi.com<mailto:paul.tur...@venafi.com>>
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; tls@ietf.org<mailto:tls@ietf.org>
Subject: RE: [TLS] Is there a way forward after today's hum?



From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org<mailto:tls@ietf.org>
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:





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



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



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 wou

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

2017-07-20 Thread Paul Turner 




-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, July 20, 2017 09:29
To: Russ Housley <hous...@vigilsec.com>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?



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





Russ Housley wrote:

>

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



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.



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



-Martin



___

TLS mailing list

TLS@ietf.org<mailto:TLS@ietf.org>

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

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

2017-07-20 Thread Ted Lemon 
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  wrote:

> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  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.
> >
> >
> > 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 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-20 Thread Tom Ritter 
On 20 July 2017 at 01:53, Yoav Nir  wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley  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.
>
>
> 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 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

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

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

2017-07-20 Thread Paul Turner 




-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 08:22
To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com>
Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?





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.



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.






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

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

2017-07-20 Thread Jeffrey Walton 
On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton  wrote:
>...
> 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).

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

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

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

2017-07-20 Thread Robin Wilton 
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 <paul.tur...@venafi.com>
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; tls@ietf.org
Subject: RE: [TLS] Is there a way forward after today's hum?



From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org
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:





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



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

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

2017-07-20 Thread Robin Wilton 




From: Russ Housley <hous...@vigilsec.com>
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 
<wil...@isoc.org<mailto:wil...@isoc.org>> wrote:

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


Robin:

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

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


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

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

2017-07-20 Thread Martin Rex 
I'm sorry, Russ, but I think this would be seriously deceiving.


Russ Housley wrote:
> 
> 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.

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

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

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

2017-07-20 Thread Stephen Farrell 

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.





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

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

2017-07-20 Thread Ted Lemon 
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 <ptur...@equio.com> wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:51
> *To:* Paul Turner <paul.tur...@venafi.com>
> *Cc:* Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> 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 <paul.tur...@venafi.com>
> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner <paul.tur...@venafi.com>
> *Cc:* Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
> *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" <paul.tur...@venafi.com> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *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:
>
>
> --
>
> 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

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

2017-07-20 Thread Paul Turner 




-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 07:54
To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com>
Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?







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?



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



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.


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

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

2017-07-20 Thread Paul Turner 
 

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:51
To: Paul Turner <paul.tur...@venafi.com>
Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?

 

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 <paul.tur...@venafi.com 
<mailto:paul.tur...@venafi.com> > wrote:

 

 

From: TLS [mailto:tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> ] On 
Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:25
To: Paul Turner <paul.tur...@venafi.com <mailto:paul.tur...@venafi.com> >
Cc: Robin Wilton <wil...@isoc.org <mailto:wil...@isoc.org> >; <tls@ietf.org 
<mailto:tls@ietf.org> > <tls@ietf.org <mailto:tls@ietf.org> >
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" <paul.tur...@venafi.com 
<mailto:paul.tur...@venafi.com> > wrote:

 

 

From: TLS [mailto:tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> ] On 
Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org <mailto:tls@ietf.org> 
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:

 


  _  

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  

 

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 the

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

2017-07-20 Thread Stephen Farrell 


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.



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

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

2017-07-20 Thread Ted Lemon 
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 <paul.tur...@venafi.com> wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner <paul.tur...@venafi.com>
> *Cc:* Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
> *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" <paul.tur...@venafi.com> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *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:
>
>
> --
>
> 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
>
>
>
> 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 T

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

2017-07-20 Thread Paul Turner 


From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:25
To: Paul Turner <paul.tur...@venafi.com>
Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org>
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" 
<paul.tur...@venafi.com<mailto:paul.tur...@venafi.com>> wrote:


From: TLS [mailto:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On Behalf 
Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org<mailto:tls@ietf.org>
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:





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



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 Rus

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

2017-07-20 Thread Russ Housley 

> On Jul 20, 2017, at 5:57 AM, Robin Wilton  wrote:
> 
> 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  


Robin:

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

Russ


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

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

2017-07-20 Thread Ted Lemon 
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" <paul.tur...@venafi.com> wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *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:
>
>
> --
>
> 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
>
>
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-20 Thread Paul Turner 


From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org
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:





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



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

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

2017-07-20 Thread Yoav Nir 

> On 20 Jul 2017, at 8:01, Russ Housley  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.
> 

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 
 if that is OK and change the allow-wiretap setting to True”)





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

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

2017-07-20 Thread Ted Lemon 
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"  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
>
>
> On Jul 19, 2017, at 1:14 PM, Ted Lemon  wrote:
>
> Provably involved, or involved setting an evil bit?
>
> On Wed, Jul 19, 2017 at 7:10 PM, 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 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-20 Thread Russ Housley 
The agenda included:

- Data Center use of Static DH (30 min)
 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 .

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

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

2017-07-20 Thread Russ Housley 
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  wrote:
> 
> Provably involved, or involved setting an evil bit?
> 
> On Wed, Jul 19, 2017 at 7:10 PM, 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 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-19 Thread Stephen Farrell 


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



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

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

2017-07-19 Thread Ted Lemon 
Provably involved, or involved setting an evil bit?

On Wed, Jul 19, 2017 at 7:10 PM, 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 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls