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

[Martin Thomson]

On 23 September 2016 at 00:47, Viktor Dukhovni  wrote:
>> I see your point here. However, where would you draw the line between "I 
>> can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in 
>> a ClientHello. You can still find one cipher suite that could be ok to work 
>> with. However, how can you trust the first two bytes if you find that third 
>> byte telling you something's abnormal?
>
> The server tries that first cipher, if mutually supported, and if it
> works, it guessed right.  If the finished message from the server is
> valid, the client's handshake as seen by the server was presumably
> exactly what the client sent, so the client gets what it paid for...
>
> Servers don't have to be that forgiving, but it is a plausible approach.

Another view on this (web view):
https://annevankesteren.nl/2016/05/client-server

Why a server would tolerate rubbish and all the associated complexity,
when none of the users it cares about produce that sort of drivel is
beyond me.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Eric Rescorla]

On Thu, Sep 22, 2016 at 8:53 PM, Geoffrey Keating  wrote:

> Ryan Carboni  writes:
>
> > in the internet of things, DH is actually
> > less secure than normal public key exchange. Servers are more likely to
> > have entropy than embedded devices.
>
> I think that's backwards; in a 'normal' public key exchange, it is the
> client that generates the secret key, the server contributes no
> randomness.
>

Nit: no private randomness. It provides freshness in the form of
ServerRandom and in
TLS that's specified as random.

-Ekr


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

[Geoffrey Keating]

Ryan Carboni  writes:

> in the internet of things, DH is actually
> less secure than normal public key exchange. Servers are more likely to
> have entropy than embedded devices.

I think that's backwards; in a 'normal' public key exchange, it is the
client that generates the secret key, the server contributes no
randomness.

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

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

[Nick Sullivan]

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

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

[Brian Smith]

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

Re: [TLS] Industry Concerns about TLS 1.3

[Colm MacCárthaigh]

On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk 
wrote:

> On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh 
> wrote:
>
>> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk 
>> 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.
>>>
>>
>> I think that this may be possible for TLS1.3 0-RTT data, but not for
>> other data where an ephemeral key will be generated based also on a
>> parameter that the client chooses.
>>
>
> 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.

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

Re: [TLS] CertficateRequest extension encoding

[David Benjamin]

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] Proposed Change to Certificate message (#654)

[Nick Sullivan]

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.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Colm MacCárthaigh]

On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk 
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.
>

I think that this may be possible for TLS1.3 0-RTT data, but not for other
data where an ephemeral key will be generated based also on a parameter
that the client chooses.

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

[TLS] draft-ietf-tls-tls13-16

[Eric Rescorla]

I just uploaded draft-16.

   https://tools.ietf.org/html/draft-ietf-tls-tls13-16

The primary changes are listed below.

- New version negotiation format (*) [IMPORTANT: this got lost in the
ChangeLog]

- Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better
backwards compatibility (*)

- Move HelloRetryRequest.selected_group to an extension (*)

- Clarify the behavior of no exporter context and make it the same
  as an empty context.(*)

- New KeyUpdate format that allows for requesting/not-requesting an
  answer (*)

- New certificate_required alert (*)

- Forbid CertificateRequest with 0-RTT and PSK.

- Relax requirement to check SNI for 0-RTT.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Andrei Popov]

Hi Andrew,


?  Unfortunately, Microsoft does not allow this functionality, which is a 
problem in a TLS 1.3 only environment.
The best approach would be for Microsoft customers to make a feature request 
through their support channel.

Cheers,

Andrei

From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 1:58 PM
To: BITS Security ; tls@ietf.org; Andrei Popov 

Subject: Re: Industry Concerns about TLS 1.3


Adding Andrei Popov.


From: BITS Security 
>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; tls@ietf.org
Subject: RE: Industry Concerns about TLS 1.3

Yuhong-Thank you for the response.

Our thinking here is that enterprises who use content delivery networks will 
have the end-user session hidden from them.

The session from the end user to the edge of the content delivery network will 
be a different session than the one from the enterprise sees.  The IP's and 
ports will be different, the TCP layer activity like retransmissions will be 
different, and because of caching the application layer will be somewhat 
different.  There will be times when we need packet level data from the End 
User and TLS decryption of this packet level data for troubleshooting.

With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt 
it with the RSA private key.  With TLS 1.3 we will have to rely on the 
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.  
Unfortunately, Microsoft does not allow this functionality, which is a problem 
in a TLS 1.3 only environment.

-Andrew


From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security 
>; 
tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657


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 

Re: [TLS] Industry Concerns about TLS 1.3

[Yuhong Bao]

Adding Andrei Popov.


From: BITS Security 
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; tls@ietf.org
Subject: RE: Industry Concerns about TLS 1.3

Yuhong-Thank you for the response.

Our thinking here is that enterprises who use content delivery networks will 
have the end-user session hidden from them.

The session from the end user to the edge of the content delivery network will 
be a different session than the one from the enterprise sees.  The IP's and 
ports will be different, the TCP layer activity like retransmissions will be 
different, and because of caching the application layer will be somewhat 
different.  There will be times when we need packet level data from the End 
User and TLS decryption of this packet level data for troubleshooting.

With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt 
it with the RSA private key.  With TLS 1.3 we will have to rely on the 
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.  
Unfortunately, Microsoft does not allow this functionality, which is a problem 
in a TLS 1.3 only environment.

-Andrew


From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security ; tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657


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 

Re: [TLS] Industry Concerns about TLS 1.3

[Yoav Nir]

Hi, Andrew.

Thank you for bringing these concerns to the list. I agree with Kenny that this 
is rather late, but it’s also true that I don’t think it would change the 
outcome of the consensus in this working group.

The quest to mandate FS in TLS-using applications goes back longer than this 
effort:
 - HTTP/2 (RFC 7540) has mandated it since draft -10 from February 2014.
 - The TLS BCP (RFC 7525) has mandating a preference for FS since version -00 
or the individual submission (September 2013) and version -10 of the draft 
(February 2015) made the RSA key exchange a SHOULD NOT.

The latter is very significant, because that RFC is a bunch of recommendations 
for legacy applications.

I’m sympathetic to the argument about trouble-shooting the network, but not so 
much to the argument about keeping records.  I’ve taken the liberty of snipping 
most of your message, and interspersing my remarks with the parts where you 
shoot down proposed solutions.

> On 22 Sep 2016, at 8:19 PM, BITS Security  
> wrote:



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

That is true, but from my admittedly limited exposure to financial 
institutions, the employees there then to be given extremely locked-down 
workstations where they have practically no ability to install or uninstall 
anything. The mobile phone revolution actually helps to make this palatable, as 
employees get to do their personal business on their personal phones using the 
cellular rather than the employer’s network. 

> -  Exporting of ephemeral keys:  This solution has scalability and security 
> problems on large, busy servers where it is not possible to know ahead of 
> time which session is going to be the important one.

This seems like a strange claim to me. On the one hand, you’re storing away the 
entire (encrypted) content of the TLS session. On the other hand you can’t 
scale the storage of a few dozen bytes of keys for each of those sessions?

> -  Man-in-the-middle:  This solution adds significant latency, key management 
> complexity, and production risk at each of the needed monitoring layers.

And yet many content providers use such solutions as part of their production 
network. I’m not even talking about TLS proxy firewalls. I’m talking about 
so-called “SSL offload” gateways such as F5’s big-ip. They decrypt everything 
on the gateway and forward the requests to back-end servers. It does add 
complexity, but so does your regular monitoring hardware.

> 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 can come up with something that will do all that without giving up on 
forward secrecy, I’ll be happy to help you write a draft.

Yoav

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Yuhong-Thank you for the response.  

Our thinking here is that enterprises who use content delivery networks will 
have the end-user session hidden from them. 

The session from the end user to the edge of the content delivery network will 
be a different session than the one from the enterprise sees.  The IP's and 
ports will be different, the TCP layer activity like retransmissions will be 
different, and because of caching the application layer will be somewhat 
different.  There will be times when we need packet level data from the End 
User and TLS decryption of this packet level data for troubleshooting. 

With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt 
it with the RSA private key.  With TLS 1.3 we will have to rely on the 
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.  
Unfortunately, Microsoft does not allow this functionality, which is a problem 
in a TLS 1.3 only environment.  

-Andrew


From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com] 
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security ; tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657


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 

Re: [TLS] Industry Concerns about TLS 1.3

[Dave Garrett]

Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this 
working group, so there's no point in myself or any other contributors just 
mass-replying with a big "no" here. That said, there is one puzzling thing I'm 
curious about:

On Thursday, September 22, 2016 01:19:48 pm BITS Security wrote:
> 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.

Yes, all of these other channels are protected using TLS... which you do not 
control in any way. Also, many sites/services already prioritize FS cipher 
suites, so the deprecation of plain RSA key exchange doesn't actually affect 
the vast majority of people. (e.g. Facebook & Twitter both prefer ECDHE with 
NIST P-256) Within this very argument is already the argument that supervision 
at endpoints is required here. The security on the pipe is irrelevant. I don't 
see how you can make a point to bring this up but think keeping plain RSA KE 
suites is a useful solution.


Dave

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

Re: [TLS] Industry Concerns about TLS 1.3

[Salz, Rich]

+1 to what Kenny said.

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

[Kyle Rose]

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

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

I do not think this difficulty should be a consideration for TLS. These
capabilities can be enabled by the endpoint.

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

Re: [TLS] Industry Concerns about TLS 1.3

[Paterson, Kenny]

Hi Andrew,

My view concerning your request: no. 

Rationale: We're trying to build a more secure internet.

Meta-level comment:

You're a bit late to the party. We're metaphorically speaking at the stage of 
emptying the ash trays and hunting for the not quite empty beer cans. 

More exactly, we are at draft 15 and RSA key transport disappeared from the 
spec about a dozen drafts ago. I know the banking industry is usually a bit 
slow off the mark, but this takes the biscuit. 

Cheers,

Kenny 

> On 22 Sep 2016, at 20:27, 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.
> 
> 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 the 

Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd]

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

This can be solved by logging the entire connection contents at the
endpoint. I don't understand how you say that this is not a
replacement: it's literally the same data as you obtain decrypting the
session. This is a requirement that many of the companies involved in
the TLS 1.3 process have also, and they haven't complained about it.
Maybe I don't understand what architecture you have which makes this
impossible. If you have too much volume, then I don't see how your
network appliance doesn't have the same problem. If it's intermittent,
and you didn't log verbosely on errors, set up the endpoint to log the
next fault, and wait.

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

[TLS] Industry Concerns about TLS 1.3

[BITS Security]

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

-  Exporting of ephemeral keys:  This solution has scalability and security 
problems on large, busy servers where it is not possible to know ahead of time 
which 

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

[Viktor Dukhovni]

> On Sep 22, 2016, at 8:18 AM, Andreas Walz  
> wrote:
> 
> I see your point here. However, where would you draw the line between "I 
> can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in a 
> ClientHello. You can still find one cipher suite that could be ok to work 
> with. However, how can you trust the first two bytes if you find that third 
> byte telling you something's abnormal?

The server tries that first cipher, if mutually supported, and if it
works, it guessed right.  If the finished message from the server is
valid, the client's handshake as seen by the server was presumably
exactly what the client sent, so the client gets what it paid for...

Servers don't have to be that forgiving, but it is a plausible approach.

-- 
Viktor.

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

Re: [TLS] Signature Algorithms Extension Clarification

[Eric Rescorla]

On Thu, Sep 22, 2016 at 2:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> I need a clarification regarding the use of the signature algorithms.
>
> Reading Section 4.2.3. "Signature Algorithms" I got the impression that
> there is a new extension being defined called 
> 'supported_signature_algorithms',
> which replaces the previous 'signature_algorithm' extension.
>
> The difference between the 'signature_algorithm' extension in RFC 5246 and
> the newly defined 'supported_signature_algorithms' extension is that the
> new extension only contains the digital signature algorithm and not the
> hash function anymore.
>

> If that's indeed the intention I would prefer if the text uses the
> 'supported_signature_algorithms' rather than 'signature_algorithms'.
> (as it is done in Section 4.4.2. "Certificate Verify"). Unfortunately the
> term 'signature_algorithms' is used in many other places in the document
> itself, including the IANA consideration section that makes a reference to
> RFC 5246.
>
> Is it correct that the 'supported_signature_algorithms' extension
> replaces the 'signature_algorithm' extension from RFC 5246?
>

Yes and no :)

We've redefined the structure to be "signature and hash and curve in one
code point" but we're just
retconning the existing values and extension code point.

-Ekr


> Ciao
> Hannes
>
> ___
> 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] Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote:
> Andreas Walz  writes:
> >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
> >addresses this in the Presentation Language section:
> >
> >  "Peers which receive a message which cannot be parsed according to the
> >  syntax (e.g., have a length extending beyond the message boundary or
> >  contain an out-of-range length) MUST terminate the connection with a
> >  "decoding_error" alert."
> 
> And how many implementations are going to do this?  Consider the
> error-message litmus test I proposed earlier, reasons for failing to
> connect to (say) amazon.com:
> 
>   Error: Couldn't connect to Amazon because its certificate isn't valid.
>  
>   Error: Couldn't connect to Amazon because no suitable encryption was
>  available.
> 
>   Error: Couldn't connect to Amazon because   decoding_error alert>

"received data was malformed."

> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.

We are talking about a cryptographic protocol. Being very strict about what 
you receive is the raison d'être of the whole thing.

POODLE happened because SSL 3 in general and some TLS implementations in 
particular weren't strict.

Researchers look at protocol itself and only a handful of popular 
implementations, they won't be analysing if the TLS-as-implemented-by-ACME-
widget-7000 is secure even if it isn't strict.
-- 
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

[TLS] Signature Algorithms Extension Clarification

[Hannes Tschofenig]

Hi all,

I need a clarification regarding the use of the signature algorithms.

Reading Section 4.2.3. "Signature Algorithms" I got the impression that 
there is a new extension being defined called 
'supported_signature_algorithms', which replaces the previous 
'signature_algorithm' extension.


The difference between the 'signature_algorithm' extension in RFC 5246 
and the newly defined 'supported_signature_algorithms' extension is that 
the new extension only contains the digital signature algorithm and not 
the hash function anymore.


If that's indeed the intention I would prefer if the text uses the 
'supported_signature_algorithms' rather than 'signature_algorithms'.
(as it is done in Section 4.4.2. "Certificate Verify"). Unfortunately 
the term 'signature_algorithms' is used in many other places in the 
document itself, including the IANA consideration section that makes a 
reference to RFC 5246.


Is it correct that the 'supported_signature_algorithms' extension 
replaces the 'signature_algorithm' extension from RFC 5246?


Ciao
Hannes

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Ilari Liusvaara]

On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
> Martin Thomson  writes:
> 
> >The advantage with deploying a new protocol is that you can be strict. If, 
> >for example, all of the browsers implement TLS 1.3 and are strict, then 
> >Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
> >pretty quickly.  You might suggest that that's aspiration to the point of 
> >delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
> >didn't squash ALL of the nasty bugs, but we got most of them.
> 
> 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?

Also, code to "recover" tends to introduce security issues if used in
security protocols. Just because I don't have to deal with simple bugs
like buffer overflows leading to RCE or data races does not mean I can
do whatever I want and expect the code to have low number of security
issues. The existing stuff is way more than enough.

(Just fixed a bug where NotBefore/NotAfter of dedicated OCSP responder
certificate were not validated... Not related to recovery in any way,
but still some special code).

> The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
> Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
> else that uses HTTP as its universal substrate.  As a result there will be 
> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
> version-is.

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

> (Should I mention TLS-LTS here? :-).

Ugh...



-Ilari

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Yoav Nir]

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann  wrote:
> 
> Martin Thomson  writes:
> 
>> The advantage with deploying a new protocol is that you can be strict. If, 
>> for example, all of the browsers implement TLS 1.3 and are strict, then 
>> Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
>> pretty quickly.  You might suggest that that's aspiration to the point of 
>> delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
>> didn't squash ALL of the nasty bugs, but we got most of them.
> 
> 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.
> The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
> Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
> else that uses HTTP as its universal substrate.  As a result there will be 
> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
> version-is.

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

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

Yoav

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