Re: [TLS] Application layer interactions and API guidance

[Ilari Liusvaara]

On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote:
> Dear all,
> We've got API guidance and application layer interactions on the TODO
> list, and both of these are important and don't show up yet. I can't
> credibly commit to taking a big stab at them, but hopefully this email
> is detailed enough that it serves as a starting point.
> 
> The problems with the application layer interaction center around
> 0-RTT and client post-authentication. 0-RTT data is replayable, and
> furthermore does not authenticate SNI or other extensions that might
> affect its interpretation at the server. I smell possible bugs where
> extension data isn't properly treated with 0-RTT vs. 1-RTT fallback:
> the current draft probably should include something like "any
> extensions which influence the interpretation of this data must be the
> same".

In composing my list of extensions to pay attention when doing 0-RTT
(SNI and ALPN), I considered matters like:

- Does this seem like it would affect 0-RTT interpretation.
- What are the TLS 1.2 rules on it?
- Is it even meaningful with PSK?
- Is it just low-level connection control?

ALPN was included because it definitely affects 0-RTT interpretation
(even against TLS 1.2 rules) and SNI because of TLS 1.2 rules (SNI
was later removed from the list).

There might be future extensions that do have an effect on 0-RTT
(some proposed extensions to Token Binding perhaps?). And it is of
course theoretically possible that TLS stack implements some extension
in a very odd way.
 
> The difference between received 0-RTT data and other data doesn't
> necessarily line up with connection state while processing, as the TLS
> stack could have transitioned to normal 1-RTT operation while 0-RTT
> data is still sitting around waiting to be processed.  This is really
> an API problem, but can also be caused by application layer choices:
> if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT,
> life gets a bit weird.

Is "life gets a bit weird" an euphemism for "there will likely be
security issues here"? :-)

Also, it is very likely that 0-RTT would need its own read API, because
it is pretty unlikely that existing API could be safely retrofitted
or even purpose-built unified API be designed that isn't just asking
for security problems via mixing 0-RTT and 1-RTT data.


It gets even more fun in DTLS, where 0-RTT packets can be reordered
after Client Finished, so more 0-RTT data arrives when the connection
has already transitioned to 1-RTT.

Perhaps the last one could be solved by requiring the library to
discard any such packets and not pass them forward.


> Post-handshake auth is an ugly one for both. It can complete
> asynchronously with respect to data exchange, which is not what the
> desired semantics usually are. Generally we want each request to have
> a single authentication context. Designing APIs to handle this is
> hard, and applications will have to be aware of how TLS authentication
> works to have rules for it. Add in the ability to stream data in both
> directions, and life gets interesting. I'm really not sure what this
> should look like.

At least you must have client and server agree on authentication
context of every given request. If they don't, vulernabilities WILL
result.

And then there have been multiple CVEs due to applications using
wrong authentication context in some situation.

(This is the reason one needs to be especially careful when combining
dynamic client certificates with HTTP/2... Basically, it can not be
done safely without coordination on application layer).

One likely wants application protocol to be able to specify part of
or the entiere request context and to extract that part in the other
end when requesting a certificate selection. This is to allow putting
part of coordination data into the request itself. However, this is not
sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at
application layer.

E.g. HTTP/2 would want to signal which stream triggered the client
certificate request, in order to enable the client to not be completely
dumb in certificate selection.

And then upon completion of the authentication (either successful or
explicitly rejected), signal the application with the new certificate
chain and the context the request had.


-Ilari

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

Re: [TLS] Industry Concerns about TLS 1.3

[Salz, Rich]

> we need a better option than TLS 1.2 that will,
> perhaps sooner than we might expect, be deprecated.

Why?

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

Re: [TLS] CertficateRequest extension encoding

[Martin Thomson]

On 24 September 2016 at 10:35, Nick Sullivan
 wrote:
> 1) Move DistinguishedName out of the structure and define it as a TLS-style
> extension. It's not a required field.
> 2) Remove SignatureScheme from structure, and instead change the behavior of
> the the "signature_algorithms" extension to include all server-supported
> SignatureSchemes in the ServerHello in descending order of preference.

This is my preference too.  I get that this means that you have to
remember more if you might support client authentication, but it
removes yet another bespoke parser and extension point.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Bill Frantz]

On 9/23/16 at 2:24 PM, bitssecur...@fsroundtable.org (BITS 
Security) wrote:


But general-purpose messaging services (and other collaboration 
services) which don’t have an explicit man-in-the-middle (and 
don’t permit server-side access to user plaintext and can’t 
be observed by other means) can’t be used in supervised 
environments. This rules out many cloud-hosted services today.


I see a train wreck coming and it looks like this:

The public internet, Google, Cloud services, Facebook, Twitter, 
etc. etc. move in the direction of improving security using 
things like PFS, because the idea of protecting human rights 
advocates in the parts of the world where people are routinely 
tortured sells well to the general public, people like me, and 
others on this list.


On the other hand, some major enterprises continue to depend on 
being able to break the security of their employees to monitor 
their networks in ways that the bad guys can easily use, as 
opposed to installing endpoint or gateway monitoring.


This train wreck results in fewer and fewer public internet 
services being available to users within these enterprises. 
Eventually, employees give up on the corporate network and start 
using their cell phones to communicate with customers, research 
investments etc., completely bypassing the regulatory required monitoring.


This scenario says it doesn't matter whether TLS 1.3 and 
successors allows RSA. If they have any PFS modes, these will be 
the only ones public internet servers will accept. If they are 
turned off in enterprise clients, they will not be able to 
connect without going through a gateway which turns them on.


My conclusion is that enterprises that depend on being able to 
decrypt traffic without involving the endpoints should start 
moving to systems that do involve the endpoints.


Cheers - Bill

---
Bill Frantz| Ham radio contesting is a| Periwinkle
(408)356-8506  | contact sport.   | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032


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

Re: [TLS] CertficateRequest extension encoding

[Nick Sullivan]

Signature algorithm support is typically per-connection, not per
certificate request. If you're doing multiple post-handshake
authentications then (2) reduces the amount of redundant data sent on
subsequent authentications. Furthermore, it opens the door for unsolicited
post-handshake authentication in future extensions to the protocol.

Clients only need to stash a copy of it if they support client
authentication, which in my opinion should be optional. Perhaps support for
post-handshake authentication should be signaled with an extension. That
way the server SignatureSchemes could be carried in that extension, rather
than overloading the "signature_algorithms" extension.




On Fri, Sep 23, 2016 at 5:56 PM David Benjamin 
wrote:

> (1) seems reasonable. I don't have strong views there. I even jokingly
> suggested it in the PR description.
>
> I do not like (2). This requires implementations stash a copy of the
> signature algorithms without known a priori whether it will be used or not.
> And it means when receiving a CertificateRequest, you have to go check that
> the extension was provided at all. I think that should stay bound to the
> CertificateRequest and as a required field.
>
> On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan 
> wrote:
>
>> David,
>>
>> If we're changing this structure of CertificateRequest, I have two
>> suggestions.
>>
>> 1) Move DistinguishedName out of the structure and define it as a
>> TLS-style extension. It's not a required field.
>> 2) Remove SignatureScheme from structure, and instead change the behavior
>> of the the "signature_algorithms" extension to include all server-supported
>> SignatureSchemes in the ServerHello in descending order of preference.
>>
>> This will result in a much more compact message structure that can easily
>> be re-purposed for post-handshake server auth and other optional extensions
>> to TLS 1.3:
>>
>>  struct {
>>  opaque certificate_request_context<1..2^8-1>;
>>  CertificateRequestExtension certificate_extensions<0..2^16-1>;
>>  } CertificateRequest;
>>
>>
>> Nick
>>
>>
>> On Thu, Sep 22, 2016 at 6:26 PM David Benjamin 
>> wrote:
>>
>>> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov 
>>> wrote:
>>>
 > But it's OID-specific how the matching works, isn't it?
 Correct, and initially we define matching for KU and EKU. These are the
 OIDs I've got the most customer requests for. I expect that we will want to
 define matching rules for other OIDs over time, in separate specs. This new
 proposal allows multiple sets of matching rules for each OID, which
 certainly increases flexibility.

 David, do you care enough to write your proposal down as a PR, so that
 we can discuss the specifics?

>>>
>>> Apologies for the delay. Been a busy few weeks. This is roughly what I
>>> was thinking:
>>> https://github.com/tlswg/tls13-spec/pull/656
>>>
>>> What do you think?
>>>
>>> Again, I don't actually care about this, so if you and others who would
>>> use this mechanism prefer it as it is, I have no qualms. This is a "pull
>>> suggestion", not a "pull request". :-)
>>>
>>> David
>>>
>>>
 Thanks,

 Andrei

 -Original Message-
 From: Anders Rundgren [mailto:anders.rundgren@gmail.com]
 Sent: Tuesday, September 6, 2016 8:36 AM
 To: Peter Gutmann ; David Benjamin <
 david...@chromium.org>; Andrei Popov ;
 Ilari Liusvaara ; tls@ietf.org
 Subject: Re: [TLS] CertficateRequest extension encoding

 On 2016-09-06 16:15, Peter Gutmann wrote:
 > David Benjamin  writes:
 >
 >> Either way I imagine our stack will just keep on ignoring it, so I
 >> don't feel about this all too strongly. But the topic came up so I
 >> thought I'd suggest this.
 >
 > I ignore it too.  Client certs are so rare, and so painful to deploy,
 > that I'm not going to make things harder on users by adding complex
 > and opaque filtering to prevent them from working.  My approach is to
 > specify as few constraints as possible, the client submits whatever
 > certificate it has, and it's then decided based on a whitelist for
 > which the server can very clearly report "not on the whitelist" when
 > it rejects it.  The design seems to be based on the idea that each
 > client has a smorgasbord of certs and the server can specify in
 > precise detail in advance which one it wants, when in reality each
 > client has approximately zero certs, and the few that do have one
 just want the one they've got to work.

 May I add some nuances here?

 Client-certificates are *extensively* used for secure box-to-box
 communication.
 Existing selection methods suffice (there's usually none on the 

Re: [TLS] CertficateRequest extension encoding

[David Benjamin]

(1) seems reasonable. I don't have strong views there. I even jokingly
suggested it in the PR description.

I do not like (2). This requires implementations stash a copy of the
signature algorithms without known a priori whether it will be used or not.
And it means when receiving a CertificateRequest, you have to go check that
the extension was provided at all. I think that should stay bound to the
CertificateRequest and as a required field.

On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan 
wrote:

David,

If we're changing this structure of CertificateRequest, I have two
suggestions.

1) Move DistinguishedName out of the structure and define it as a TLS-style
extension. It's not a required field.
2) Remove SignatureScheme from structure, and instead change the behavior
of the the "signature_algorithms" extension to include all server-supported
SignatureSchemes in the ServerHello in descending order of preference.

This will result in a much more compact message structure that can easily
be re-purposed for post-handshake server auth and other optional extensions
to TLS 1.3:

 struct {
 opaque certificate_request_context<1..2^8-1>;
 CertificateRequestExtension certificate_extensions<0..2^16-1>;
 } CertificateRequest;


Nick


On Thu, Sep 22, 2016 at 6:26 PM David Benjamin 
wrote:

On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov 
wrote:

> But it's OID-specific how the matching works, isn't it?
Correct, and initially we define matching for KU and EKU. These are the
OIDs I've got the most customer requests for. I expect that we will want to
define matching rules for other OIDs over time, in separate specs. This new
proposal allows multiple sets of matching rules for each OID, which
certainly increases flexibility.

David, do you care enough to write your proposal down as a PR, so that we
can discuss the specifics?


Apologies for the delay. Been a busy few weeks. This is roughly what I was
thinking:
https://github.com/tlswg/tls13-spec/pull/656

What do you think?

Again, I don't actually care about this, so if you and others who would use
this mechanism prefer it as it is, I have no qualms. This is a "pull
suggestion", not a "pull request". :-)

David


Thanks,

Andrei

-Original Message-
From: Anders Rundgren [mailto:anders.rundgren@gmail.com]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann ; David Benjamin <
david...@chromium.org>; Andrei Popov ; Ilari
Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
> David Benjamin  writes:
>
>> Either way I imagine our stack will just keep on ignoring it, so I
>> don't feel about this all too strongly. But the topic came up so I
>> thought I'd suggest this.
>
> I ignore it too.  Client certs are so rare, and so painful to deploy,
> that I'm not going to make things harder on users by adding complex
> and opaque filtering to prevent them from working.  My approach is to
> specify as few constraints as possible, the client submits whatever
> certificate it has, and it's then decided based on a whitelist for
> which the server can very clearly report "not on the whitelist" when
> it rejects it.  The design seems to be based on the idea that each
> client has a smorgasbord of certs and the server can specify in
> precise detail in advance which one it wants, when in reality each
> client has approximately zero certs, and the few that do have one just
want the one they've got to work.

May I add some nuances here?

Client-certificates are *extensively* used for secure box-to-box
communication.
Existing selection methods suffice (there's usually none on the client
side).

Client-certificates for user authentication on the Web through HTTPS is a
small and diminishing activity. The decision by the browser vendors
dropping support for on-line enrollment is likely to further limit this use
case which make improvements in selection/filtering pretty uninteresting.

Client-certificates for user authentication on the Web through through
proprietary ("FIDO like") application level protocols is fairly big.  Half
of the Swedish population use such a scheme for e-government and bank
access.  It uses an ugly (and non-secure) OOB-method to make it "Web
compatible".  This use-case is (of course) not of an issue for the TLS WG
but may be of some interest for people currently using client certificates
for Web authentication.

Anders


>
> Peter.
> ___
> 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
___
TLS mailing list
TLS@ietf.org

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

[Christian Huitema]

On Friday, September 23, 2016 1:39 AM, Peter Gutmann wrote:
> Andreas Walz  writes:
>
>>However, where would you draw the line between "I can't" and "I don't want
>>to"?
> 
> It's one of those judgement-call things, I don't know if you can strictly
> define it but as a rule of thumb I'd say that if you encounter it during
> normal processing it's an I-can't problem while if you have to add
special-
> case checks to identify it and refuse to continue it's an I-don't-want-to
> problem.

Yes of course, but there is another aspect to it, the general health of the
ecosystem. Postel's rule is nice, but it removes the pressure on broken
implementations to fix their code. Pushed to the extreme, the result is a
sort of protocol drift, in which buggy variants get first tolerated, and
then accepted as de-facto standards. This tends to hinder future evolutions,
not to mention adding complexity. We often hear that "the IETF has no
protocol police," but in fact it does. Each implementation that takes a
strict view of standard compliance contributes to this policing.

-- Christian Huitema



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

Re: [TLS] CertficateRequest extension encoding

[Nick Sullivan]

David,

If we're changing this structure of CertificateRequest, I have two
suggestions.

1) Move DistinguishedName out of the structure and define it as a TLS-style
extension. It's not a required field.
2) Remove SignatureScheme from structure, and instead change the behavior
of the the "signature_algorithms" extension to include all server-supported
SignatureSchemes in the ServerHello in descending order of preference.

This will result in a much more compact message structure that can easily
be re-purposed for post-handshake server auth and other optional extensions
to TLS 1.3:

 struct {
 opaque certificate_request_context<1..2^8-1>;
 CertificateRequestExtension certificate_extensions<0..2^16-1>;
 } CertificateRequest;


Nick


On Thu, Sep 22, 2016 at 6:26 PM David Benjamin 
wrote:

> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov 
> wrote:
>
>> > But it's OID-specific how the matching works, isn't it?
>> Correct, and initially we define matching for KU and EKU. These are the
>> OIDs I've got the most customer requests for. I expect that we will want to
>> define matching rules for other OIDs over time, in separate specs. This new
>> proposal allows multiple sets of matching rules for each OID, which
>> certainly increases flexibility.
>>
>> David, do you care enough to write your proposal down as a PR, so that we
>> can discuss the specifics?
>>
>
> Apologies for the delay. Been a busy few weeks. This is roughly what I was
> thinking:
> https://github.com/tlswg/tls13-spec/pull/656
>
> What do you think?
>
> Again, I don't actually care about this, so if you and others who would
> use this mechanism prefer it as it is, I have no qualms. This is a "pull
> suggestion", not a "pull request". :-)
>
> David
>
>
>> Thanks,
>>
>> Andrei
>>
>> -Original Message-
>> From: Anders Rundgren [mailto:anders.rundgren@gmail.com]
>> Sent: Tuesday, September 6, 2016 8:36 AM
>> To: Peter Gutmann ; David Benjamin <
>> david...@chromium.org>; Andrei Popov ; Ilari
>> Liusvaara ; tls@ietf.org
>> Subject: Re: [TLS] CertficateRequest extension encoding
>>
>> On 2016-09-06 16:15, Peter Gutmann wrote:
>> > David Benjamin  writes:
>> >
>> >> Either way I imagine our stack will just keep on ignoring it, so I
>> >> don't feel about this all too strongly. But the topic came up so I
>> >> thought I'd suggest this.
>> >
>> > I ignore it too.  Client certs are so rare, and so painful to deploy,
>> > that I'm not going to make things harder on users by adding complex
>> > and opaque filtering to prevent them from working.  My approach is to
>> > specify as few constraints as possible, the client submits whatever
>> > certificate it has, and it's then decided based on a whitelist for
>> > which the server can very clearly report "not on the whitelist" when
>> > it rejects it.  The design seems to be based on the idea that each
>> > client has a smorgasbord of certs and the server can specify in
>> > precise detail in advance which one it wants, when in reality each
>> > client has approximately zero certs, and the few that do have one just
>> want the one they've got to work.
>>
>> May I add some nuances here?
>>
>> Client-certificates are *extensively* used for secure box-to-box
>> communication.
>> Existing selection methods suffice (there's usually none on the client
>> side).
>>
>> Client-certificates for user authentication on the Web through HTTPS is a
>> small and diminishing activity. The decision by the browser vendors
>> dropping support for on-line enrollment is likely to further limit this use
>> case which make improvements in selection/filtering pretty uninteresting.
>>
>> Client-certificates for user authentication on the Web through through
>> proprietary ("FIDO like") application level protocols is fairly big.  Half
>> of the Swedish population use such a scheme for e-government and bank
>> access.  It uses an ugly (and non-secure) OOB-method to make it "Web
>> compatible".  This use-case is (of course) not of an issue for the TLS WG
>> but may be of some interest for people currently using client certificates
>> for Web authentication.
>>
>> Anders
>>
>>
>> >
>> > Peter.
>> > ___
>> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Peter Bowen]

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security
 wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange
versus DH for key exchange would only seem to apply when the network
tapping system has access to the RSA key, right?  So the part of this
about monitoring the network for external chat and such doesn't really
change if the client is using TLS 1.1 or 1.3, as you still can't
decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat
under control of the monitor, so it can support TLS 1.2 as long as
needed.  TLS 1.0 came out in 1999 and is still now (in 2016) widely
deployed.  While I hope TLS 1.3 deployment is speedy, I don't forsee
browsers dropping TLS 1.2 and earlier support any time soon.

Thanks,
Peter

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

[TLS] Application layer interactions and API guidance

[Watson Ladd]

Dear all,
We've got API guidance and application layer interactions on the TODO
list, and both of these are important and don't show up yet. I can't
credibly commit to taking a big stab at them, but hopefully this email
is detailed enough that it serves as a starting point.

The problems with the application layer interaction center around
0-RTT and client post-authentication. 0-RTT data is replayable, and
furthermore does not authenticate SNI or other extensions that might
affect its interpretation at the server. I smell possible bugs where
extension data isn't properly treated with 0-RTT vs. 1-RTT fallback:
the current draft probably should include something like "any
extensions which influence the interpretation of this data must be the
same".

The difference between received 0-RTT data and other data doesn't
necessarily line up with connection state while processing, as the TLS
stack could have transitioned to normal 1-RTT operation while 0-RTT
data is still sitting around waiting to be processed.  This is really
an API problem, but can also be caused by application layer choices:
if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT,
life gets a bit weird.

API guidance is generally pretty easy, even if most implementations
have massively failed at being reasonable. I do not want to point
fingers, but someone thought having true and false values mean exactly
opposite things was a good idea in a C API at one point.

Post-handshake auth is an ugly one for both. It can complete
asynchronously with respect to data exchange, which is not what the
desired semantics usually are. Generally we want each request to have
a single authentication context. Designing APIs to handle this is
hard, and applications will have to be aware of how TLS authentication
works to have rules for it. Add in the ability to stream data in both
directions, and life gets interesting. I'm really not sure what this
should look like.

Sincerely,
Watson

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

Re: [TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan]

Thanks for the suggestions. I've restructured my PR to include an array of
SingleCertificate objects in the Certificate structure.

Ilari: I agree that the post-hanshake auth mechanism as currently described
is a bit lacking, but I'd like to sort this out first.

Victor: For cached_info, OCSP responses are relatively long-lived and the
server should know whether or not a cached OCSP is close to expiration, so
cached_info is still useful, but I agree that this makes it less useful.


On Fri, Sep 23, 2016 at 2:53 PM Victor Vasiliev  wrote:

> The version where each certificate gets its own extension sounds like a
> step in the right direction.
>
> One concern I have is the way this would interact with cached_info
> extension.  Currently, it allows the entire Certificate message to be
> cached -- which just meant the entire chain in 1.2.  With the suggested
> change, this makes less sense: while you still want to cache SCTs, this
> might be much less desirable for OCSP responses.
>
> On Fri, Sep 23, 2016 at 3:49 PM, Eric Rescorla  wrote:
>
>> This seems like a reasonable direction.
>>
>> -Ekr
>>
>>
>> On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <
>> nicholas.sulli...@gmail.com> wrote:
>>
>>> This suggestion makes sense to me.
>>>
>>> Both the SCT and OCSP v2 extension allow for multiple objects in order
>>> to cover multiple certificates in a chain, but your suggestion makes the
>>> grouping much more explicit and obviates the need for OCSPv2. I'd
>>> definitely consider a modification like this.
>>>
>>> Nick
>>>
>>> On Thu, Sep 22, 2016 at 7:17 PM Brian Smith 
>>> wrote:
>>>
 Nick Sullivan  wrote:

> PR: https://github.com/tlswg/tls13-spec/pull/654
>

> This change adds a set of extensions to the Certificate message. With
> this change, the Certificate message can now hold all extension messages
> that are certificate-specific (rather than connection-specific). This
> change also resolves the anomaly of OCSP messages appearing before
> certificates in the handshake.
>

 There are two ways that such a thing could be done. How your proposal
 suggests:

 opaque ASN1Cert<1..2^24-1>;
 struct {
 opaque certificate_request_context<0..2^8-1>;
 ASN1Cert certificate_list<0..2^24-1>;
 Extension extensions<0..2^16-1>;
 } Certificate;

 or:

 opaque ASN1CertData<1..2^24-1>;
 struct {
 ASN1CertData cert_data;
 Extension extensions<0..2^16-1>;
 }

 struct {
 opaque certificate_request_context<0..2^8-1>;
 ASN1Cert certificate_list<0..2^24-1>;
 } Certificate;

 I think you are right that the SCT and the OCSP response are
 per-certificate. In particular, they are not per-certificate-chain, so to
 me the latter form, where each certificate in the chain gets its own
 extension list, makes more sense to me. Would you consider changing the
 proposal to the second form?

 Cheers,
 Brian
 --
 https://briansmith.org/


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

Re: [TLS] Industry Concerns about TLS 1.3

[Adam Caudill]

Andrew,

You are requesting a major design change at the last minute, to restore a 
problematic feature that was removed due to its negative security impact. You 
should understand from the beginning that this is an extreme request. Moreso, 
you should understand that others in your industry have no problem complying 
with US and international regulations, while using PFS cipher suites.

I am personally aware of two of the largest financial organizations in the US 
that actually require PFS suites for all internal and external applications, 
and use endpoint security applications to handle this issue. It may not be as 
convenient as what you are doing now, but it is a problem that has already been 
solved, and solved effectively.

Before claiming that the IETF is eliminating your choice, you may want to take 
a closer look at how those your industry have already dealt with this. There 
are effective solutions that have already been mentioned, that don’t involve 
reducing the security of every TLS user around the globe.

Personally, I agree completely with Kenny’s response - the answer is simply no. 
It’s too large of a change, it has too large of a security impact, and there 
are established solutions to address your issues.

--
Adam Caudill
a...@adamcaudill.com
http://adamcaudill.com/


> On Sep 23, 2016, at 5:34 PM, BITS Security  
> wrote:
> 
>> you can keep using TLS1.2 in your internal network, can't you?
> 
> There are both public and private sector regulators arcing towards being more 
> prescriptive in this area.  It is possible, if not likely, in the not too 
> distant future that my member companies will not have the choice to 
> "downgrade" to "obsolete" TLS versions.
> 
> Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS 
> 1.2.  That's a signal that may prove difficult to divert in this rapidly 
> evolving threat and regulatory environment.
> 
> - Andrew
> 


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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

On Fri, Sep 23, 2016 at 5:34 PM, BITS Security
 wrote:
>> you can keep using TLS1.2 in your internal network, can't you?
>
> There are both public and private sector regulators arcing towards being more 
> prescriptive in this area.  It is possible, if not likely, in the not too 
> distant future that my member companies will not have the choice to 
> "downgrade" to "obsolete" TLS versions.

Its not the first time C has worked against security.

Password complexity and rotation policies come to mind; they cause the
security in the system to drop as users are forced to comply.

Would a KMIP/KeyServer help? Hosts can ask the key server server for
its random key or seed material, and then use them key derivation and
for protocol execution. I built a proof of concept interception proxy
to do it a few years ago to help understand the intersection a service
like CipherCloud with C

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> you can keep using TLS1.2 in your internal network, can't you?

There are both public and private sector regulators arcing towards being more 
prescriptive in this area.  It is possible, if not likely, in the not too 
distant future that my member companies will not have the choice to "downgrade" 
to "obsolete" TLS versions.  

Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS 
1.2.  That's a signal that may prove difficult to divert in this rapidly 
evolving threat and regulatory environment.

- Andrew 



From: Xiaoyin Liu [mailto:xiaoyi...@outlook.com] 
Sent: Friday, September 23, 2016 5:00 PM
To: BITS Security ; Salz, Rich 
; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,
 
I don't understand why your "choice is being removed", because you can keep 
using TLS1.2 in your internal network, can't you?
 
Best,
Xiaoyin
 
From: BITS Security
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
 
Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.  

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.  

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.  

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn't amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
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

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

Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd]

On Fri, Sep 23, 2016 at 12:31 PM, BITS Security
 wrote:
>> What exactly is the problem you are concerned with? As I've pointed out 
>> previously one can still log the contents of TLS protected
>> connections: you do this at the client, or with an intercepting proxy.
>> What information does this not get you that you need on the network?
>
> For enterprises using Content Delivery Networks, the TLS session from the 
> browser ends at the edge server in the Content Delivery Network.  The session 
> that the enterprise sees is completely different: different IP's and ports, 
> different TLS session, different application layer content because of 
> caching, different network behavior (like packet drops and retransmissions).  
> If some infrastructure component in the data center is causing a problem, a 
> trace on the browser side is blind to that.  An additional problem is that 
> Microsoft does not allow logging of ephemeral keys in their browser.
>
> Likewise endpoint logging in the data center often does not provide adequate 
> data to isolate the fault domain and/or the root cause of a problem.  Logs 
> tell you that an event happened but not why it happened or which 
> infrastructure component was the cause of the problem. For example, a log may 
> indicate that a call was made that either didn't get answered or received a 
> slow answer, but there could be ten infrastructure components between the 
> server that made the call and the destination server that is supposed to 
> answer.

I think you are confused about endpoints. Either these middleboxes
terminate a TLS connection or they do not. If they do, you can log the
application layer traffic at that box in and out. If they do not, then
IP level captures tell you what they are doing.  That some of these
endpoints are middleboxes from the standpoint of a higher layer of the
stack doesn't change that they are endpoints from the TLS layer's
perspective. I don't see what the barrier is.

>
> From the time a packet enters a data center, it is travelling through 
> routers, switches, firewalls, load balancers, web servers, app servers, 
> middleware servers, and possibly hitting a mainframe, all TLS encrypted for 
> many enterprises.  Frequently, source and destination IP's are NAT'ed 
> multiple times, so there is no visible relationship between the packet that 
> enters the data center and the same call at deeper layers of the 
> infrastructure.  Any one of these infrastructure nodes could be the cause of 
> a problem.  The way to isolate the fault domain of a problem is to take a 
> packet trace at each tier of the application infrastructure and look at the 
> application layer data in a decrypted trace in order to find the transaction 
> that is failing.

I do not want to be the person who has to figure out which SQL query
came from which HTTP request. Much easier to have the webserver tell
me (and maybe even add standard headers to permit RPC tracebacks).
Even better is it can track only those ensuing requests that
ultimately result in a failure.

>
> Large enterprises have built up robust out-of-band packet capture 
> infrastructures in order to provide better network and application layer 
> visibility than what logs provide.  Packet brokers and sniffers can handle 10 
> Gbits/sec. line rate or more of traffic, including write to disk at 20 
> Gbits/sec. or more.  This is needed because when IP's are NAT'ed, you have to 
> trace everything in and out of a particular server and then decrypt in order 
> to find the transaction of interest.  Some endpoints and/or infrastructure 
> components have packet capture capability, but most are not robust enough to 
> handle this kind of packet capture load in a busy production environment.

You do not need to capture every exchange, just the interesting ones.
What this sounds like is an environment where you have deployed dozens
of boxes with fast stripes on the side, with no real ability to ensure
that they are able to properly log, or administrative insight into
what black magic they might be doing, and have tried to make up with
it with dirty, labor-intensive hacks.

>
> There can be twenty or more layers to a large application, all TLS encrypted, 
> that need to be inspected for troubleshooting, and replacing this with MITM 
> infrastructure is not scalable.  Likewise, there can be hundreds of physical 
> network taps feeding security monitoring tools like IDS/IPS, malware 
> detection, and fraud monitoring.  Threats are coming not just from the 
> Internet, but also from internal or 3rd party machines that have been 
> compromised and then start reconnaissance from a wide variety of locations.  
> Large enterprises also have complex virtual environments which can be running 
> TLS between VM's.  There is no scalable way to intercept VM to VM TLS that 
> never leaves the virtual server.

The word scalable has a meaning. MITM scales linearly.
> --Andrew
>
>
> -Original 

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> Let's get specific about how this works: if an employee of a regulated
> institution is logging into a TLS protected social media website, how
> do you decrypt the connection without using a MITM device on the
> network? I'm sure with large enough checks collaboration application
> providers will be happy to implement whatever you need in the way of
> logging at the server. 

The issue here is not just collaboration applications; it’s also point-to-point 
messaging protocols.   
  
Some vendors have created p2p messaging services to meet supervision 
requirements, and these have an explicit man-in-the-middle.   
  
But general-purpose messaging services (and other collaboration services) which 
don’t have an explicit man-in-the-middle (and don’t permit server-side access 
to user plaintext and can’t be observed by other means) can’t be used in 
supervised environments. This rules out many cloud-hosted services today. 
  
In the future, even enterprise-hosted versions of messaging services probably 
won’t be usable in supervised environments if there’s no way for the enterprise 
to access traffic except on the destination endpoint.   


> And firing isn't enough of a threat to get people to behave when it
> comes to circumventing monitoring? 

The issue isn’t getting people to behave, or punishing them when they don’t; 
it’s demonstrating that the business has met its legal obligation to create a 
record of communications that can be accessed in case of an investigation.  An 
employee who circumvents controls can be fired, but that does not absolve the 
business of liability for failing to create a legally required record of the 
content of that employee’s communications.

- Andrew



-Original Message-
From: Watson Ladd [mailto:watsonbl...@gmail.com] 
Sent: Thursday, September 22, 2016 3:06 PM
To: BITS Security 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security  
wrote:
> To:  IETF TLS 1.3 Working Group Members
>
> My name is Andrew Kennedy and I work at BITS, the technology policy division 
> of the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
> organization represents approximately 100 of the top 150 US-based financial 
> services companies including banks, insurance, consumer finance, and asset 
> management firms.
>
> I manage the Technology Cybersecurity Program, a CISO-driven forum to 
> investigate emerging technologies; integrate capabilities into member 
> operations; and advocate member, sector, cross-sector, and private-public 
> collaboration.
>
> While I am aware and on the whole supportive of the significant contributions 
> to internet security this important working group has made in the last few 
> years I recently learned of a proposed change that would affect many of my 
> organization's member institutions:  the deprecation of RSA key exchange.

You've "recently learned" about a change that was proposed several
*years* ago, starting in the earliest drafts of TLS 1.3. This change is being 
made due to substantial security issues with encryption based key exchanges: 
while we could redesign the exchange to repair these issues, the risk of key 
compromise resulting in decryption of old data is real.

>
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
> problems for financial institutions, almost all of whom are running TLS 
> internally and have significant, security-critical investments in out-of-band 
> TLS decryption.
>
> Like many enterprises, financial institutions depend upon the ability to 
> decrypt TLS traffic to implement data loss protection, intrusion detection 
> and prevention, malware detection, packet capture and analysis, and DDoS 
> mitigation.  Unlike some other businesses, financial institutions also rely 
> upon TLS traffic decryption to implement fraud monitoring and surveillance of 
> supervised employees.  The products which support these capabilities will 
> need to be replaced or substantially redesigned at significant cost and loss 
> of scalability to continue to support the functionality financial 
> institutions and their regulators require.
>
> The impact on supervision will be particularly severe.  Financial 
> institutions are required by law to store communications of certain employees 
> (including broker/dealers) in a form that ensures that they can be retrieved 
> and read in case an investigation into improper behavior is initiated.  The 
> regulations which require retention of supervised employee communications 
> initially focused on physical and electronic mail, but now extend to many 
> other forms of communication including instant message, social media, and 
> collaboration applications.  All of these communications channels are 
> protected using TLS.

Let's get specific about how this works: if an employee of a regulated 
institution is logging into a TLS 

Re: [TLS] Industry Concerns about TLS 1.3

[Stephen Farrell]

Andrew,

On 23/09/16 21:31, BITS Security wrote:
> We do however want to raise our concern (and hopefully your
> awareness) of what appears to be an unintended consequence of the
> move to PFS-only choices.

I don't believe I've heard anything in this discussion so far
that wasn't well-known and discussed when the WG decided to
remove static RSA key transport a couple of years ago but I've
not gone back and checked the list archive and meeting minutes.

Given what you say above, am I right in assuming that you
yourself went back and reviewed those in order to reach the
conclusion that these are unintended consequences and not just
the result of a well-considered analysis? If so, can you say
exactly what was not considered before? If not, then maybe
you could consult the archive and minutes, as that's the usual
expectation in the IETF.

S.




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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

It's possible to run TLS 1.3 and PFS through the Content Delivery Network and 
into the enterprise data center, and then have a load balancer or other proxy 
terminate TLS.  This gives us the option of running a different protocol in the 
data center, but we need a better option than TLS 1.2 that will, perhaps sooner 
than we might expect, be deprecated.  

-Andrew 

-Original Message-
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
Sent: Friday, September 23, 2016 3:52 PM
To: BITS Security ; Watson Ladd 
; Ackermann, Michael 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

You are implicitly suggesting to remove perfect-forward-secrecy as soon as a 
TLS flow is created by the CDN. However these packets will still be traveling 
over the public Internet and/or "private" (leased, not really
private) MPLS VPNs, where we KNOW that government agencies are eavesdropping 
and recording network flows to keep for years ahead. In other words, even when 
the TLS flow enters "your" network, you and your customer are still at risk 
from pervasive monitoring.

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

Re: [TLS] CertficateRequest extension encoding

[Andrei Popov]

With this change, we can define multiple matching rules for the same extension 
OID, which might be useful. Looks good to me.

Cheers,

Andrei

From: David Benjamin [mailto:david...@chromium.org]
Sent: Thursday, September 22, 2016 6:26 PM
To: Andrei Popov ; Anders Rundgren 
; Peter Gutmann ; 
Ilari Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding

On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov 
> wrote:
> But it's OID-specific how the matching works, isn't it?
Correct, and initially we define matching for KU and EKU. These are the OIDs 
I've got the most customer requests for. I expect that we will want to define 
matching rules for other OIDs over time, in separate specs. This new proposal 
allows multiple sets of matching rules for each OID, which certainly increases 
flexibility.

David, do you care enough to write your proposal down as a PR, so that we can 
discuss the specifics?

Apologies for the delay. Been a busy few weeks. This is roughly what I was 
thinking:
https://github.com/tlswg/tls13-spec/pull/656

What do you think?

Again, I don't actually care about this, so if you and others who would use 
this mechanism prefer it as it is, I have no qualms. This is a "pull 
suggestion", not a "pull request". :-)

David

Thanks,

Andrei

-Original Message-
From: Anders Rundgren 
[mailto:anders.rundgren@gmail.com]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann 
>; David Benjamin 
>; Andrei Popov 
>; Ilari 
Liusvaara >; 
tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
> David Benjamin > writes:
>
>> Either way I imagine our stack will just keep on ignoring it, so I
>> don't feel about this all too strongly. But the topic came up so I
>> thought I'd suggest this.
>
> I ignore it too.  Client certs are so rare, and so painful to deploy,
> that I'm not going to make things harder on users by adding complex
> and opaque filtering to prevent them from working.  My approach is to
> specify as few constraints as possible, the client submits whatever
> certificate it has, and it's then decided based on a whitelist for
> which the server can very clearly report "not on the whitelist" when
> it rejects it.  The design seems to be based on the idea that each
> client has a smorgasbord of certs and the server can specify in
> precise detail in advance which one it wants, when in reality each
> client has approximately zero certs, and the few that do have one just want 
> the one they've got to work.

May I add some nuances here?

Client-certificates are *extensively* used for secure box-to-box communication.
Existing selection methods suffice (there's usually none on the client side).

Client-certificates for user authentication on the Web through HTTPS is a small 
and diminishing activity. The decision by the browser vendors dropping support 
for on-line enrollment is likely to further limit this use case which make 
improvements in selection/filtering pretty uninteresting.

Client-certificates for user authentication on the Web through through 
proprietary ("FIDO like") application level protocols is fairly big.  Half of 
the Swedish population use such a scheme for e-government and bank access.  It 
uses an ugly (and non-secure) OOB-method to make it "Web compatible".  This 
use-case is (of course) not of an issue for the TLS WG but may be of some 
interest for people currently using client certificates for Web authentication.

Anders


>
> Peter.
> ___
> 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] Industry Concerns about TLS 1.3

[Xiaoyin Liu]

Andrew,



I don’t understand why your “choice is being removed”, because you can keep 
using TLS1.2 in your internal network, can’t you?



Best,

Xiaoyin



From: BITS Security
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich; 
nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3



Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements.

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Salz, Rich]

> What is happening from our perspective is choice is being removed and an
> adequate replacement has (seemingly) not been identified.

So far I've seen two alternatives mentioned.  Monitor at the endpoint, and use 
TLS 1.2.  (You already have the PFS issue with TLS 1.1 and beyond).

Not everything the IETF does will drop seamlessly into all enterprise 
deployments.  But hey, at least you're not running SNA networks any more :)
--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


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

Re: [TLS] Industry Concerns about TLS 1.3

[Eric Rescorla]

Andrew,

What would probably be most helpful here would be if you tried to describe
what you think your requirements are in some sort of protocol-neutral
fashion.

-Ekr


On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <
bitssecur...@fsroundtable.org> wrote:

> Rich (et al.) -- I understand where you are coming from but I will poke a
> little bit at this portrayal.
>
> We are not here hat-in-hand asking for a return to RSA key exchange to the
> proposed standard.  We do however want to raise our concern (and hopefully
> your awareness) of what appears to be an unintended consequence of the move
> to PFS-only choices.
>
> What is happening from our perspective is choice is being removed and an
> adequate replacement has (seemingly) not been identified.  This lack of
> choice may not affect everyone and every use-case but it will predictably
> affect large, complex, highly regulated enterprises in a serious manner.
> This is a classic case of security requirement being in conflict with a
> different security requirement.
>
> IETF protocols are run extensively both on the public Internet and within
> private enterprises.  Any decisions made by the TLS Working Group will
> affect both environments, and the needs and requirements of both
> environments should be considered.
>
> -Andrew
>
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
> Sent: Friday, September 23, 2016 3:08 PM
> To: nalini.elk...@insidethestack.com
> Cc: tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
>
> > It would be very interesting to get the network diagnostic and
> operations people (rather than the architects) of the above companies
> involved in this conversation.
>
> Nothing has ever stopped them.  Never. Participation is as simple as
> joining a mailing list.  The IETF has been doing SSL and TLS for nearly 20
> years.  It is not a secret.  It was incumbent on them to reach out and get
> involved.
>
> > Why don't we listen to each other?   I know at IETF, I often hear that
> we don't get enough operators to comment and give feedback.  Well, here you
> have some.  It may be that these companies have problems that are different
> from Google's (just as an example).
>
> Don't try to equate "listen to each other" with "meet my requirement."
> The message has been stated, very clearly, from individuals, WG members,
> through document editors and WG chairs and up to Security Directors:
> static RSA is not coming back to TLS 1.3 .  Since before the last IETF this
> was the message, consistently.  So perhaps you should answer the question
> first -- why aren't *you* listening? :)
>
> PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to
> prevent PFS in their existing deployment?  Why won't additional controls to
> prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So
> far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to
> move to TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs
> in TLS 1.3 too.
>
> Look, pretty much the entire world is being spied on by national-scale
> adversaries who are recording all traffic for eventual decryption and
> correlation.  *Almost everyone* is having their traffic surveilled. The
> problems of debugging a set of enterprise apps doesn’t amount to a hill of
> beans in that world. It just doesn't. Same for a particular industry's
> regulatory requirements.
>
> > Isn't our goal to have the best standards possible?   Any organism
> (including the IETF), needs feedback to thrive.
>
> Oxygen, coke, and cookies too.
>
> --
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz __
> _
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Yoav Nir]

> On 23 Sep 2016, at 10:08 PM, Salz, Rich  wrote:
> 
> 
> Look, pretty much the entire world is being spied on by national-scale 
> adversaries who are recording all traffic for eventual decryption and 
> correlation.  *Almost everyone* is having their traffic surveilled. The 
> problems of debugging a set of enterprise apps doesn’t amount to a hill of 
> beans in that world. It just doesn't. Same for a particular industry's 
> regulatory requirements. 

+1

And if almost everyone is having the traffic surveilled, you can bet that the 
financial industry in every country is definitely being surveilled. Probably by 
multiple agencies from multiple countries.

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.  

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.  

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.  

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
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] Industry Concerns about TLS 1.3

[Ilari Liusvaara]

On Thu, Sep 22, 2016 at 05:19:48PM +, BITS Security wrote:
> To:  IETF TLS 1.3 Working Group Members
>
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in
> out-of-band TLS decryption. 

It is not merely deprecated, the whole TLS 1.3 design assumes DH-like
key exchange, which RSA key exchange isn't. It has been this way from
the earliest designs, which were over 2 years ago.

If you are thinking you can have static RSA key exchange in TLS 1.3, you
are just plain wasting your time. There will not be static RSA in TLS
1.3. No matter how much "inconvience" you claim that causes.



Also, security protocol design is hard enough without backdoors. Try to
add those and everything will just come apart. In way that lets the "bad
guys" (however you define those) to waltz in.


-Ilari

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

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

I work in the payments industry, but I am not speaking on behalf of my
employer.

I would like to note that if the approaches outlined in the "BITS Security"
post are the preferred ones for the companies they represent, those
companies have made a huge strategic blunder and should correct those
strategic blunders rather than requiring last-minute major design overhauls
to TLS 1.3 which would weaken its security.

+1000 Kenny Patterson's comments.

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <
bitssecur...@fsroundtable.org> wrote:

> -  End point monitoring: This technique does not replace the pervasive
> network visibility that private enterprises will lose without the RSA key
> exchange.  Ensuring that every endpoint has a monitoring agent installed
> and functioning at all times is vastly more complex than ensuring that a
> network traffic inspection appliance is present and functioning.  In the
> case of monitoring of supervised employee communications, moving the
> monitoring function to the endpoint raises new security concerns focusing
> on deliberate circumvention - because in the supervision use case the
> threat vector is the possessor of the endpoint.
>

I strongly disagree. Endpoint security is paramount, and some sort of
network MitM system is absolutely not a replacement for endpoint agents. I
would highly suggest deploying agents on your endpoints. If you don't have
endpoint security, all is lost. I would suggest performing multiple
security checks regularly on all endpoints throughout your enterprise.

Modern endpoint agents can work at a level much higher than TLS network
packets (i.e. total memory inspection with kernel-level agents). MitMing
traffic in lieu of deploying an endpoint agent only provides monitoring of
"compliant" packet streams, which are unlikely to be used by either
attackers or insider threats. I'm not saying it's bad to run NIDS or a
rolling packet capture system, these are both great, but again, neither are
a replacement for an endpoint agent.

Until the critical concerns surrounding enterprise security, employee
> supervision, and network troubleshooting are addressed as effectively as
> internet MITM and surveillance threats have been, we, on behalf of our
> members, are asking the TLS 1.3 Working Group to delay Last Call until a
> workable and scalable solution is identified and vetted, and ultimately
> adopted into the standard by the TLS 1.3 Working Group.


If you're relying on MitMing S2S traffic for debugging a payment stack, it
sounds like your payment stack is opaque to you, which is not only a
concern for security, but the general reliable operation of your payment
stack as a whole. As a general recommendation, I would suggest building out
debugging facilities for your payment stack so you know it actually works,
and don't have to lean on crutches like MitMing traffic for debugging
purposes.

While such a crutch may in the short-term make debugging appear easier, it
also assists a patient attacker with internal network access who is
passively capturing traffic before attempting to obtain a decryption key
which would expose payment credentials e.g. cardholder info/PANs, ACH
account numbers, etc.

tl;dr: your suggestions would harm the security of more "forward thinking"
payments companies. Again, my personal opinion, not that of my employer.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Yaron Sheffer]

What exactly is the problem you are concerned with? As I've pointed
out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting
proxy. What information does this not get you that you need on the
network?


For enterprises using Content Delivery Networks, the TLS session from
the browser ends at the edge server in the Content Delivery Network.
The session that the enterprise sees is completely different:
different IP's and ports, different TLS session, different
application layer content because of caching, different network
behavior (like packet drops and retransmissions).  If some
infrastructure component in the data center is causing a problem, a
trace on the browser side is blind to that.  An additional problem is
that Microsoft does not allow logging of ephemeral keys in their
browser.


[...]

From the time a packet enters a data center, it is travelling
through routers, switches, firewalls, load balancers, web servers,
app servers, middleware servers, and possibly hitting a mainframe,
all TLS encrypted for many enterprises.  Frequently, source and
destination IP's are NAT'ed multiple times, so there is no visible
relationship between the packet that enters the data center and the
same call at deeper layers of the infrastructure.  Any one of these
infrastructure nodes could be the cause of a problem.  The way to
isolate the fault domain of a problem is to take a packet trace at
each tier of the application infrastructure and look at the
application layer data in a decrypted trace in order to find the
transaction that is failing.




You are implicitly suggesting to remove perfect-forward-secrecy as soon 
as a TLS flow is created by the CDN. However these packets will still be 
traveling over the public Internet and/or "private" (leased, not really 
private) MPLS VPNs, where we KNOW that government agencies are 
eavesdropping and recording network flows to keep for years ahead. In 
other words, even when the TLS flow enters "your" network, you and your 
customer are still at risk from pervasive monitoring.


Thanks,
Yaron

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

Re: [TLS] Proposed Change to Certificate message (#654)

[Eric Rescorla]

This seems like a reasonable direction.

-Ekr


On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan 
wrote:

> This suggestion makes sense to me.
>
> Both the SCT and OCSP v2 extension allow for multiple objects in order to
> cover multiple certificates in a chain, but your suggestion makes the
> grouping much more explicit and obviates the need for OCSPv2. I'd
> definitely consider a modification like this.
>
> Nick
>
> On Thu, Sep 22, 2016 at 7:17 PM Brian Smith  wrote:
>
>> Nick Sullivan  wrote:
>>
>>> PR: https://github.com/tlswg/tls13-spec/pull/654
>>>
>>
>>> This change adds a set of extensions to the Certificate message. With
>>> this change, the Certificate message can now hold all extension messages
>>> that are certificate-specific (rather than connection-specific). This
>>> change also resolves the anomaly of OCSP messages appearing before
>>> certificates in the handshake.
>>>
>>
>> There are two ways that such a thing could be done. How your proposal
>> suggests:
>>
>> opaque ASN1Cert<1..2^24-1>;
>> struct {
>> opaque certificate_request_context<0..2^8-1>;
>> ASN1Cert certificate_list<0..2^24-1>;
>> Extension extensions<0..2^16-1>;
>> } Certificate;
>>
>> or:
>>
>> opaque ASN1CertData<1..2^24-1>;
>> struct {
>> ASN1CertData cert_data;
>> Extension extensions<0..2^16-1>;
>> }
>>
>> struct {
>> opaque certificate_request_context<0..2^8-1>;
>> ASN1Cert certificate_list<0..2^24-1>;
>> } Certificate;
>>
>> I think you are right that the SCT and the OCSP response are
>> per-certificate. In particular, they are not per-certificate-chain, so to
>> me the latter form, where each certificate in the chain gets its own
>> extension list, makes more sense to me. Would you consider changing the
>> proposal to the second form?
>>
>> Cheers,
>> Brian
>> --
>> https://briansmith.org/
>>
>>
> ___
> 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] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

On Fri, Sep 23, 2016 at 12:42:09AM +, Nick Sullivan wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/654
> 
> Hello,
> 
> I'd like to propose a small to the Certificate message format to allow for
> future extensibility of the protocol.
> 
> This change adds a set of extensions to the Certificate message. With this
> change, the Certificate message can now hold all extension messages that
> are certificate-specific (rather than connection-specific). This change
> also resolves the anomaly of OCSP messages appearing before certificates in
> the handshake.
> 
> Reasoning:
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
> and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
> per-connection metadata. By putting these responses in the
> EncryptedExtensions, you limit these extensions to being shown once per
> connection. This restricts future protocol extensions from using multiple
> Certificate messages to support multiple certificates on the same
> connection. An example of this is the post-handshake authentication
> proposal (
> https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
> which currently requires a modified post-handshake Certificate message.
> This proposed change would simplify the post-handshake auth proposal
> significantly and generally make more sense as more certificate-specific
> extensions are created.

Also, this would presumably solve the user_mapping problem without
introducing a new handshake message. Basically, there is extension
user_mapping, that wants to send some certificate-associated auxillary
data from client to server. Currnently, there is no place to put such
data.

And yeah, with post-handshake auth, it looks like one would want a lot
more flexibility than currently exists.


BTW: I would rather dump the current post-handshake auth for such
extension proposal. The current post-handshake authentication is just
plain annoying to implement in contexts where the client has no
intention of ever supporting it.

And the current post-handshake auth mechanism seems to be insufficient
for real-world uses too...

I recently got an idea of implementing freezing session state into
octet stream and being able to thaw such. I quickly discovered I
can't implement that without either having freezable hashes (which I
don't have available) or just saying screw it with post-handshake auth
and never responding to the requests, even to reject them.



-Ilari

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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

> Look, pretty much the entire world is being spied on by national-scale 
> adversaries who are recording all traffic for eventual decryption and 
> correlation.  *Almost everyone* is having their traffic surveilled. The 
> problems of debugging a set of enterprise apps doesn’t amount to a hill of 
> beans in that world. It just doesn't. Same for a particular industry's 
> regulatory requirements.
>

+1, this and what follows is why its important to me.

Years ago I worked with a Vietnamese fellow named Say Ok. We had a
shared locker room, and I noticed Say had six or eight scars on his
chest and abdomen, so I asked what they were. They were the scars from
the bullet holes when the North Vietnamese tried to murder him because
he wanted a democracy and better life for his children.

I can't even talk about some of the obscene things I know are going on
in some US DoD programs. I'm hoping/waiting for Glenn Greenwald, Laura
Poitras and Ewen MacAskill to break those stories.

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> What exactly is the problem you are concerned with? As I've pointed out 
> previously one can still log the contents of TLS protected
> connections: you do this at the client, or with an intercepting proxy.
> What information does this not get you that you need on the network?

For enterprises using Content Delivery Networks, the TLS session from the 
browser ends at the edge server in the Content Delivery Network.  The session 
that the enterprise sees is completely different: different IP's and ports, 
different TLS session, different application layer content because of caching, 
different network behavior (like packet drops and retransmissions).  If some 
infrastructure component in the data center is causing a problem, a trace on 
the browser side is blind to that.  An additional problem is that Microsoft 
does not allow logging of ephemeral keys in their browser. 

Likewise endpoint logging in the data center often does not provide adequate 
data to isolate the fault domain and/or the root cause of a problem.  Logs tell 
you that an event happened but not why it happened or which infrastructure 
component was the cause of the problem. For example, a log may indicate that a 
call was made that either didn't get answered or received a slow answer, but 
there could be ten infrastructure components between the server that made the 
call and the destination server that is supposed to answer.   

>From the time a packet enters a data center, it is travelling through routers, 
>switches, firewalls, load balancers, web servers, app servers, middleware 
>servers, and possibly hitting a mainframe, all TLS encrypted for many 
>enterprises.  Frequently, source and destination IP's are NAT'ed multiple 
>times, so there is no visible relationship between the packet that enters the 
>data center and the same call at deeper layers of the infrastructure.  Any one 
>of these infrastructure nodes could be the cause of a problem.  The way to 
>isolate the fault domain of a problem is to take a packet trace at each tier 
>of the application infrastructure and look at the application layer data in a 
>decrypted trace in order to find the transaction that is failing. 

Large enterprises have built up robust out-of-band packet capture 
infrastructures in order to provide better network and application layer 
visibility than what logs provide.  Packet brokers and sniffers can handle 10 
Gbits/sec. line rate or more of traffic, including write to disk at 20 
Gbits/sec. or more.  This is needed because when IP's are NAT'ed, you have to 
trace everything in and out of a particular server and then decrypt in order to 
find the transaction of interest.  Some endpoints and/or infrastructure 
components have packet capture capability, but most are not robust enough to 
handle this kind of packet capture load in a busy production environment. 

There can be twenty or more layers to a large application, all TLS encrypted, 
that need to be inspected for troubleshooting, and replacing this with MITM 
infrastructure is not scalable.  Likewise, there can be hundreds of physical 
network taps feeding security monitoring tools like IDS/IPS, malware detection, 
and fraud monitoring.  Threats are coming not just from the Internet, but also 
from internal or 3rd party machines that have been compromised and then start 
reconnaissance from a wide variety of locations.  Large enterprises also have 
complex virtual environments which can be running TLS between VM's.  There is 
no scalable way to intercept VM to VM TLS that never leaves the virtual server.

--Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Watson Ladd
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael  
wrote:
>  I am not sure I understand what your reply means?
>
> Is it that we should create or even allow an environment to develop,  where 
> all providers of service cannot  provide effective diagnostics and support?   
> And then see the constituents of these industries collapse together. And 
> only then realize we have an issue?
> I hope I am  not understanding correctly. IETF is supposed to be looking 
> ahead to provide better answers and circumvent predictable problems.Not 
> ignoring,  waiting and then reacting to negative situations that can and 
> should be avoided.

What exactly is the problem you are concerned with? As I've pointed out 
previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

>
> What I am saying,  in relation to your "Delivering a stable product"  comment 
> is that over time various industries have learned what it takes to "Deliver a 
> stable product".We did not want to 

Re: [TLS] Industry Concerns about TLS 1.3

[Salz, Rich]

> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Eric Rescorla]

A few observations:

+ TLS 1.3 is designed around the assumption that we are doing DH-style
  key establishment. There are good reasons for this, both in terms of
  protocol simplicity and in terms of establishing a baseline of
  strong modes (PFS, compatibility with standard uses of EC,
  etc.). Re-adding a key transport mode like TLS 1.2 static RSA would
  be extremely disruptive, even if it weren't being raised so late in
  the process. It's certainly not just a matter of changing some
  RFC 2119 language forbidding static RSA.

+ As several people have observed, there are several potential ways to
  build an equivalent capability that's compatible with TLS 1.3 as it
  currently is designed (see for instance Hugo Krawczyk's email [0])
  They would of course require a different interface between the
  monitoring appliance and the server (i.e., you would need to export
  a different kind of key and use it somewhat differently on the
  monitoring system), but it's not significantly less efficient.

-Ekr

[0] As well as his caveat about analysis being needed here.


On Fri, Sep 23, 2016 at 9:49 AM, Ackermann, Michael 
wrote:

> Without re stating the original message from the bank coalition,  which
> states this better than I could,   the client and MITM solutions are not
> practical in many situations.Also they do not provide the scope, depth
> or detail that is utilized with today's solutions.
>
> -Original Message-
> From: Watson Ladd [mailto:watsonbl...@gmail.com]
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael 
> Cc: noloa...@gmail.com; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael 
> wrote:
> >  I am not sure I understand what your reply means?
> >
> > Is it that we should create or even allow an environment to develop,
> where all providers of service cannot  provide effective diagnostics and
> support?   And then see the constituents of these industries collapse
> together. And only then realize we have an issue?
> > I hope I am  not understanding correctly. IETF is supposed to be
> looking ahead to provide better answers and circumvent predictable
> problems.Not ignoring,  waiting and then reacting to negative
> situations that can and should be avoided.
>
> What exactly is the problem you are concerned with? As I've pointed out
> previously one can still log the contents of TLS protected
> connections: you do this at the client, or with an intercepting proxy.
> What information does this not get you that you need on the network?
>
> >
> > What I am saying,  in relation to your "Delivering a stable product"
> comment is that over time various industries have learned what it takes to
> "Deliver a stable product".We did not want to invest millions in these
> debugging networks.   But  we learned the hard way,  that it was necessary.
> > I am not a member of the banking coalition that started this subject,
> nor of the banking industry at all,  but I certainly understand their
> perspective and am concerned about  the same unmanageable future they
> described.
>
> Do  Akami, Cloudlflare and Google magically not have these problems?
> >
> > Thanks
> >
> > Mike
> >
> >
> >
> > -Original Message-
> > From: Jeffrey Walton [mailto:noloa...@gmail.com]
> > Sent: Friday, September 23, 2016 10:55 AM
> > To: Ackermann, Michael 
> > Cc: BITS Security ; tls@ietf.org
> > Subject: Re: [TLS] Industry Concerns about TLS 1.3
> >
> > On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <
> mackerm...@bcbsm.com> wrote:
> >> From the perspective an Enterprise that runs these applications and has
> invested HEAVILY in the debugging networks.
> >>
> >> The reason we are debugging these networks is so that "The 5-6 order of
> magnitude of folks using them"  will have good service.   If they do not,
> they will consider competitors and/or generate a litany service calls or
> complaints.I.E. When these "Folks"  are slow or not working
> they are just as unhappy as we are.
> >>
> >
> > Isn't that the market operating as expected? Those who deliver a stable
> product at a competitive price are rewarded, while those who fail to
> deliver or deliver at an unreasonable cost are not? (Some hand waiving).
> >
> > If all providers failed to deliver or delivered an inferior product,
> then it might indicate a major course correction is needed. But I don't
> think that's the case here.
> >
> > Jeff
> >
> >
> > 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 

Re: [TLS] Industry Concerns about TLS 1.3

[Ackermann, Michael]

Without re stating the original message from the bank coalition,  which states 
this better than I could,   the client and MITM solutions are not practical in 
many situations.Also they do not provide the scope, depth or detail that is 
utilized with today's solutions.   

-Original Message-
From: Watson Ladd [mailto:watsonbl...@gmail.com] 
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael 
Cc: noloa...@gmail.com; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael  
wrote:
>  I am not sure I understand what your reply means?
>
> Is it that we should create or even allow an environment to develop,  where 
> all providers of service cannot  provide effective diagnostics and support?   
> And then see the constituents of these industries collapse together. And 
> only then realize we have an issue?
> I hope I am  not understanding correctly. IETF is supposed to be looking 
> ahead to provide better answers and circumvent predictable problems.Not 
> ignoring,  waiting and then reacting to negative situations that can and 
> should be avoided.

What exactly is the problem you are concerned with? As I've pointed out 
previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

>
> What I am saying,  in relation to your "Delivering a stable product"  comment 
> is that over time various industries have learned what it takes to "Deliver a 
> stable product".We did not want to invest millions in these debugging 
> networks.   But  we learned the hard way,  that it was necessary.
> I am not a member of the banking coalition that started this subject,  nor of 
> the banking industry at all,  but I certainly understand their perspective 
> and am concerned about  the same unmanageable future they described.

Do  Akami, Cloudlflare and Google magically not have these problems?
>
> Thanks
>
> Mike
>
>
>
> -Original Message-
> From: Jeffrey Walton [mailto:noloa...@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael 
> Cc: BITS Security ; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael  
> wrote:
>> From the perspective an Enterprise that runs these applications and has 
>> invested HEAVILY in the debugging networks.
>>
>> The reason we are debugging these networks is so that "The 5-6 order of 
>> magnitude of folks using them"  will have good service.   If they do not,  
>> they will consider competitors and/or generate a litany service calls or 
>> complaints.I.E. When these "Folks"  are slow or not working they 
>> are just as unhappy as we are.
>>
>
> Isn't that the market operating as expected? Those who deliver a stable 
> product at a competitive price are rewarded, while those who fail to deliver 
> or deliver at an unreasonable cost are not? (Some hand waiving).
>
> If all providers failed to deliver or delivered an inferior product, then it 
> might indicate a major course correction is needed. But I don't think that's 
> the case here.
>
> Jeff
>
>
> 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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.


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

Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd]

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael
 wrote:
>  I am not sure I understand what your reply means?
>
> Is it that we should create or even allow an environment to develop,  where 
> all providers of service cannot  provide effective diagnostics and support?   
> And then see the constituents of these industries collapse together. And 
> only then realize we have an issue?
> I hope I am  not understanding correctly. IETF is supposed to be looking 
> ahead to provide better answers and circumvent predictable problems.Not 
> ignoring,  waiting and then reacting to negative situations that can and 
> should be avoided.

What exactly is the problem you are concerned with? As I've pointed
out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

>
> What I am saying,  in relation to your "Delivering a stable product"  comment 
> is that over time various industries have learned what it takes to "Deliver a 
> stable product".We did not want to invest millions in these debugging 
> networks.   But  we learned the hard way,  that it was necessary.
> I am not a member of the banking coalition that started this subject,  nor of 
> the banking industry at all,  but I certainly understand their perspective 
> and am concerned about  the same unmanageable future they described.

Do  Akami, Cloudlflare and Google magically not have these problems?
>
> Thanks
>
> Mike
>
>
>
> -Original Message-
> From: Jeffrey Walton [mailto:noloa...@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael 
> Cc: BITS Security ; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael  
> wrote:
>> From the perspective an Enterprise that runs these applications and has 
>> invested HEAVILY in the debugging networks.
>>
>> The reason we are debugging these networks is so that "The 5-6 order of 
>> magnitude of folks using them"  will have good service.   If they do not,  
>> they will consider competitors and/or generate a litany service calls or 
>> complaints.I.E. When these "Folks"  are slow or not working they 
>> are just as unhappy as we are.
>>
>
> Isn't that the market operating as expected? Those who deliver a stable 
> product at a competitive price are rewarded, while those who fail to deliver 
> or deliver at an unreasonable cost are not? (Some hand waiving).
>
> If all providers failed to deliver or delivered an inferior product, then it 
> might indicate a major course correction is needed. But I don't think that's 
> the case here.
>
> Jeff
>
>
> 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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Dan Brown]

Weaker crypto to stop insider attacks, is that the request? (And practice?) 
Doesn’t that increase the risk of larger (but perhaps rarer) further insider 
attacks?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

If the problem is the use of forward secrecy then there is a simple solution, 
don't use it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael
 wrote:
> From the perspective an Enterprise that runs these applications and has 
> invested HEAVILY in the debugging networks.
>
> The reason we are debugging these networks is so that "The 5-6 order of 
> magnitude of folks using them"  will have good service.   If they do not,  
> they will consider competitors and/or generate a litany service calls or 
> complaints.I.E. When these "Folks"  are slow or not working they 
> are just as unhappy as we are.
>

Isn't that the market operating as expected? Those who deliver a
stable product at a competitive price are rewarded, while those who
fail to deliver or deliver at an unreasonable cost are not? (Some hand
waiving).

If all providers failed to deliver or delivered an inferior product,
then it might indicate a major course correction is needed. But I
don't think that's the case here.

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[Ackermann, Michael]

>From the perspective an Enterprise that runs these applications and has 
>invested HEAVILY in the debugging networks.

The reason we are debugging these networks is so that "The 5-6 order of 
magnitude of folks using them"  will have good service.   If they do not,  they 
will consider competitors and/or generate a litany service calls or complaints. 
   I.E. When these "Folks"  are slow or not working they are just as 
unhappy as we are.  

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, September 23, 2016 4:06 AM
To: Yuhong Bao ; BITS Security 
; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3



On 22/09/16 19:36, Yuhong Bao wrote:
> This also reminds me of 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

Yuk. Prioritising the needs of those debugging networks over the maybe 5-6 
orders of magnitude more folks using them is ass-backwards IMO. That result 
looks to me like a very bad decision if I'm following it correctly.

S.

> 
> 
> From: TLS  on behalf of BITS Security 
> 
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> To:  IETF TLS 1.3 Working Group Members
> 
> My name is Andrew Kennedy and I work at BITS, the technology policy division 
> of the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
> organization represents approximately 100 of the top 150 US-based financial 
> services companies including banks, insurance, consumer finance, and asset 
> management firms.
> 
> I manage the Technology Cybersecurity Program, a CISO-driven forum to 
> investigate emerging technologies; integrate capabilities into member 
> operations; and advocate member, sector, cross-sector, and private-public 
> collaboration.
> 
> While I am aware and on the whole supportive of the significant contributions 
> to internet security this important working group has made in the last few 
> years I recently learned of a proposed change that would affect many of my 
> organization's member institutions:  the deprecation of RSA key exchange.
> 
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
> problems for financial institutions, almost all of whom are running TLS 
> internally and have significant, security-critical investments in out-of-band 
> TLS decryption.
> 
> Like many enterprises, financial institutions depend upon the ability to 
> decrypt TLS traffic to implement data loss protection, intrusion detection 
> and prevention, malware detection, packet capture and analysis, and DDoS 
> mitigation.  Unlike some other businesses, financial institutions also rely 
> upon TLS traffic decryption to implement fraud monitoring and surveillance of 
> supervised employees.  The products which support these capabilities will 
> need to be replaced or substantially redesigned at significant cost and loss 
> of scalability to continue to support the functionality financial 
> institutions and their regulators require.
> 
> The impact on supervision will be particularly severe.  Financial 
> institutions are required by law to store communications of certain employees 
> (including broker/dealers) in a form that ensures that they can be retrieved 
> and read in case an investigation into improper behavior is initiated.  The 
> regulations which require retention of supervised employee communications 
> initially focused on physical and electronic mail, but now extend to many 
> other forms of communication including instant message, social media, and 
> collaboration applications.  All of these communications channels are 
> protected using TLS.
> 
> The impact on network diagnostics and troubleshooting will also be serious.  
> TLS decryption of network packet traces is required when troubleshooting 
> difficult problems in order to follow a transaction through multiple layers 
> of infrastructure and isolate the fault domain.   The pervasive visibility 
> offered by out-of-band TLS decryption can't be replaced by MITM 
> infrastructure or by endpoint diagnostics.  The result of losing this TLS 
> visibility will be unacceptable outage times as support groups resort to 
> guesswork on difficult problems.
> 
> Although TLS 1.3 has been designed to meet the evolving security needs of the 
> Internet, it is vital to recognize that TLS is also being run extensively 
> inside the firewall by private enterprises, particularly those that are 
> heavily regulated.  Furthermore, as more applications move off of the desktop 
> and into web browsers and mobile applications, dependence on TLS is 
> increasing.
> 
> Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS 
> 1.2 by major browser vendors, or changes to regulatory standards will force 
> these 

Re: [TLS] Industry Concerns about TLS 1.3

[nalini.elkins]

On 22/09/16 19:36, Yuhong Bao wrote:
> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

>Yuk. Prioritising the needs of those debugging networks
>over the maybe 5-6 orders of magnitude more folks using
>them is ass-backwards IMO. That result looks to me like
>a very bad decision if I'm following it correctly.
Brings to mind the story about the people who were so concerned about having 
the engine stolen out of the car that they bolted the hood shut so you could 
never get in.   So, of course, if there was any maintenance to be done to the 
engine, if was impossible.
I wonder if there is some need for balancing of requirements.
Nalini

> 
> 
> From: TLS  on behalf of BITS Security 
> 
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> To:  IETF TLS 1.3 Working Group Members
> 
> My name is Andrew Kennedy and I work at BITS, the technology policy division 
> of the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
> organization represents approximately 100 of the top 150 US-based financial 
> services companies including banks, insurance, consumer finance, and asset 
> management firms.
> 
> I manage the Technology Cybersecurity Program, a CISO-driven forum to 
> investigate emerging technologies; integrate capabilities into member 
> operations; and advocate member, sector, cross-sector, and private-public 
> collaboration.
> 
> While I am aware and on the whole supportive of the significant contributions 
> to internet security this important working group has made in the last few 
> years I recently learned of a proposed change that would affect many of my 
> organization's member institutions:  the deprecation of RSA key exchange.
> 
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
> problems for financial institutions, almost all of whom are running TLS 
> internally and have significant, security-critical investments in out-of-band 
> TLS decryption.
> 
> Like many enterprises, financial institutions depend upon the ability to 
> decrypt TLS traffic to implement data loss protection, intrusion detection 
> and prevention, malware detection, packet capture and analysis, and DDoS 
> mitigation.  Unlike some other businesses, financial institutions also rely 
> upon TLS traffic decryption to implement fraud monitoring and surveillance of 
> supervised employees.  The products which support these capabilities will 
> need to be replaced or substantially redesigned at significant cost and loss 
> of scalability to continue to support the functionality financial 
> institutions and their regulators require.
> 
> The impact on supervision will be particularly severe.  Financial 
> institutions are required by law to store communications of certain employees 
> (including broker/dealers) in a form that ensures that they can be retrieved 
> and read in case an investigation into improper behavior is initiated.  The 
> regulations which require retention of supervised employee communications 
> initially focused on physical and electronic mail, but now extend to many 
> other forms of communication including instant message, social media, and 
> collaboration applications.  All of these communications channels are 
> protected using TLS.
> 
> The impact on network diagnostics and troubleshooting will also be serious.  
> TLS decryption of network packet traces is required when troubleshooting 
> difficult problems in order to follow a transaction through multiple layers 
> of infrastructure and isolate the fault domain.  The pervasive visibility 
> offered by out-of-band TLS decryption can't be replaced by MITM 
> infrastructure or by endpoint diagnostics.  The result of losing this TLS 
> visibility will be unacceptable outage times as support groups resort to 
> guesswork on difficult problems.
> 
> Although TLS 1.3 has been designed to meet the evolving security needs of the 
> Internet, it is vital to recognize that TLS is also being run extensively 
> inside the firewall by private enterprises, particularly those that are 
> heavily regulated.  Furthermore, as more applications move off of the desktop 
> and into web browsers and mobile applications, dependence on TLS is 
> increasing.
> 
> Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS 
> 1.2 by major browser vendors, or changes to regulatory standards will force 
> these enterprises - including financial institutions - to upgrade to TLS 1.3. 
>  It is vital to financial institutions and to their customers and regulators 
> that these institutions be able to maintain both security and regulatory 
> compliance during and after the transition from TLS 1.2 to TLS 1.3.
> 
> At the current time viable TLS 1.3-compliant solutions to problems like DLP, 
> NIDS/NIPS, PCAP, DDoS mitigation, malware 

Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]

[Hubert Kario]

On Friday, 23 September 2016 11:59:31 CEST Stephen Farrell wrote:
> On 23/09/16 11:46, Nikos Mavrogiannopoulos wrote:
> > On Fri, 2016-09-23 at 09:05 +0100, Stephen Farrell wrote:
> >> On 22/09/16 19:36, Yuhong Bao wrote:
> >>> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?i
> >>> d=1188657
> >> 
> >> Yuk. Prioritising the needs of those debugging networks
> >> over the maybe 5-6 orders of magnitude more folks using
> >> them is ass-backwards IMO. That result looks to me like
> >> a very bad decision if I'm following it correctly.
> > 
> > That's a very different concern than the one asked by BITS security,
> > and is IMO a very valid one. Running any protocol under TLS wouldn't
> > mean that debugging is very hard or impossible for the one running the
> > protocol. Administrators debug and trace protocols every day to figure
> > out failures (that's why we have advanced tools like wireshark). Making
> > it hard for them to use these tools isn't increasing security; it is
> > only making their life harder.
> 
> Sure. But their/our lives sometimes should be a bit harder
> to make things safer for the vast bulk of people using the
> networks/applications we're developing. As with everything,
> there's a balance needed. In this case, I think the wrong
> decision was reached.

those secret keys are on the client machines and they will stay on client 
machines

making it hard to extract master key from process memory is just security 
through obscurity, not something that will stop a determined attacker

*cough*LD_PRELOAD*cough*
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Friday, 23 September 2016 08:38:44 CEST Peter Gutmann wrote:
> Andreas Walz  writes:
> >However, where would you draw the line between "I can't" and "I don't want
> >to"?
> 
> It's one of those judgement-call things, I don't know if you can strictly
> define it but as a rule of thumb I'd say that if you encounter it during
> normal processing it's an I-can't problem while if you have to add special-
> case checks to identify it and refuse to continue it's an I-don't-want-to
> problem.

So it comes down how the code just happens to be written? I don't think that's 
a good approach for security critical code... 

I mean if you do a

while not is_empty(buffer):
   c_id = get_two_bytes_with_overflow_check(buffer)
   list_of_cipher_ids.append(c_id)

you won't need to do additional checks to see if the length is even or not.

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Andreas Walz  writes:

>However, where would you draw the line between "I can't" and "I don't want
>to"?

It's one of those judgement-call things, I don't know if you can strictly
define it but as a rule of thumb I'd say that if you encounter it during
normal processing it's an I-can't problem while if you have to add special-
case checks to identify it and refuse to continue it's an I-don't-want-to
problem.

Using again the example of "Couldn't connect to Amazon because no suitable
encryption was available", if the server or client accidentally memset()s the
cipher suite block to 0xDEADBEEF then you've run into an I-can't-continue
problem, while if the length fields don't quite match up (the MUST NOT that
was cited at the start of this thread), something that you wouldn't even
notice unless you added special-case code to check for it, then it's an I-
don't-want-to-continue problem.

Peter.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Ilari Liusvaara  writes:
>On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
>> It also means you're going to be in for a rude shock when you encounter the
>> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
>
>That did not check for interop with any mainstream TLS library?

Mainstream TLS 1.3 libraries?  Since the spec is still subject to weekly
changes, I doubt there's anything to interop test with.  

(It's actually a bit of a rhetorical question, since I've seen little to no
evidence that embedded/SCADA/etc has any intention of throwing away their
existing investment and starting again with 1.3 or 2.0 or whatever it'll be
called, I doubt there'll be much to non-interop with.

>Also, code to "recover" tends to introduce security issues if used in
>security protocols. 

This isn't "code to recover", it's just normal code.  If anything, it's adding
additional code to check for problems that aren't really problems that'll lead
to security issues.

>Well, the problem you encounter first with HTTP/2 is that it really dislikes
>unencrypted operation. Which impiles you pretty much need encryption. Which
>impiles you pretty much need the WebPKI certificate model... Which tends to
>be poor match for anything except named servers on the internet, which tends
>not be suitable for IoT stuff...

Yup.  The HTTP/2 folks' response to this at the time was "let them eat 1.1",
pretty much guaranteeing a fork of the HTTP protocol, with two different
versions being maintained in perpetuity.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Yoav Nir  writes:

>But if at some point all websites use HTTP-whatever-the-current-version-is
>then maybe browsers can remove support for HTTP/1.1 and then your
>embedded/SCADA/IoT devices won’t give us that rude shock.

Since HTTP/2 pretty much guarantees that SCADA/IoT/etc will keep using HTTP
1.1 forever, browsers are going to have to keep supporting both versions
forever.  Either that or there'll be custom forks of browsers sold as "SCADA
administration clients" or something similar.

>I honestly don’t think that having two protocols for these two radically
>different use cases is a bad outcome.

Neither do I.  The problem is that we're supposed to pretend that HTTP 1.1
will go away and everything will only talk HTTP/2, rather than accepting that
both will be with us for a long time, if not forever.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Stephen Farrell]

On 22/09/16 19:36, Yuhong Bao wrote:
> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

Yuk. Prioritising the needs of those debugging networks
over the maybe 5-6 orders of magnitude more folks using
them is ass-backwards IMO. That result looks to me like
a very bad decision if I'm following it correctly.

S.

> 
> 
> From: TLS  on behalf of BITS Security 
> 
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> To:  IETF TLS 1.3 Working Group Members
> 
> My name is Andrew Kennedy and I work at BITS, the technology policy division 
> of the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
> organization represents approximately 100 of the top 150 US-based financial 
> services companies including banks, insurance, consumer finance, and asset 
> management firms.
> 
> I manage the Technology Cybersecurity Program, a CISO-driven forum to 
> investigate emerging technologies; integrate capabilities into member 
> operations; and advocate member, sector, cross-sector, and private-public 
> collaboration.
> 
> While I am aware and on the whole supportive of the significant contributions 
> to internet security this important working group has made in the last few 
> years I recently learned of a proposed change that would affect many of my 
> organization's member institutions:  the deprecation of RSA key exchange.
> 
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
> problems for financial institutions, almost all of whom are running TLS 
> internally and have significant, security-critical investments in out-of-band 
> TLS decryption.
> 
> Like many enterprises, financial institutions depend upon the ability to 
> decrypt TLS traffic to implement data loss protection, intrusion detection 
> and prevention, malware detection, packet capture and analysis, and DDoS 
> mitigation.  Unlike some other businesses, financial institutions also rely 
> upon TLS traffic decryption to implement fraud monitoring and surveillance of 
> supervised employees.  The products which support these capabilities will 
> need to be replaced or substantially redesigned at significant cost and loss 
> of scalability to continue to support the functionality financial 
> institutions and their regulators require.
> 
> The impact on supervision will be particularly severe.  Financial 
> institutions are required by law to store communications of certain employees 
> (including broker/dealers) in a form that ensures that they can be retrieved 
> and read in case an investigation into improper behavior is initiated.  The 
> regulations which require retention of supervised employee communications 
> initially focused on physical and electronic mail, but now extend to many 
> other forms of communication including instant message, social media, and 
> collaboration applications.  All of these communications channels are 
> protected using TLS.
> 
> The impact on network diagnostics and troubleshooting will also be serious.  
> TLS decryption of network packet traces is required when troubleshooting 
> difficult problems in order to follow a transaction through multiple layers 
> of infrastructure and isolate the fault domain.   The pervasive visibility 
> offered by out-of-band TLS decryption can't be replaced by MITM 
> infrastructure or by endpoint diagnostics.  The result of losing this TLS 
> visibility will be unacceptable outage times as support groups resort to 
> guesswork on difficult problems.
> 
> Although TLS 1.3 has been designed to meet the evolving security needs of the 
> Internet, it is vital to recognize that TLS is also being run extensively 
> inside the firewall by private enterprises, particularly those that are 
> heavily regulated.  Furthermore, as more applications move off of the desktop 
> and into web browsers and mobile applications, dependence on TLS is 
> increasing.
> 
> Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS 
> 1.2 by major browser vendors, or changes to regulatory standards will force 
> these enterprises - including financial institutions - to upgrade to TLS 1.3. 
>  It is vital to financial institutions and to their customers and regulators 
> that these institutions be able to maintain both security and regulatory 
> compliance during and after the transition from TLS 1.2 to TLS 1.3.
> 
> At the current time viable TLS 1.3-compliant solutions to problems like DLP, 
> NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and monitoring of 
> regulated employee communications appear to be immature or nonexistent.  
> There are serious cost, scalability, and security concerns with all of the 
> currently proposed alternatives to the existing out-of-band TLS decryption 
> architecture:
> 
> -  End point monitoring: This technique does not replace 

Re: [TLS] Industry Concerns about TLS 1.3

[Thijs van Dijk]

On 23 September 2016 at 04:04, Colm MacCárthaigh  wrote:

> If the problem is the use of forward secrecy then there is a simple
 solution, don't use it.
 That is, you can, as a server, have a fixed key_share for which the
 secret exponent becomes the private key exactly as in the RSA case. It does
 require some careful analysis, though.

>>>
>> The key_share contributed by the client is indeed ephemeral and it
>> replaces the random key chosen by the client in the RSA-based scheme.
>>
>
> Yep, you're right, now I get it. I also now wonder if clients should make
> a best effort of detecting duplicate parameters and rejecting them.
>

Regular clients, no.
But this would be a useful addition to debugging / scanning suites (e.g.
Qualys), or browser extensions for the security conscious (e.g. CertPatrol).

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