Subject: [TLS] TLS Impact on Network Security draft updated

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 21 Jul 2019 13:51:32 +0000

Hi,
Thanks to all the feedback provided, we have updated the https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
draft.  At this point, we believe the draft is stable and would like to request its publication as an informational draft.

Warm regards,
    Nancy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jul 2019 05:28:55 -0700

Nancy,

Not sure what you're asking for here. This doesn't appear to be a WG
document, so that question would be prior to asking for publication in the
WG. Or are you planning to ask the AD to sponsor it and this is just an FYI
to the WG?

-Ekr

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>
>
>
> Warm regards,
>
>     Nancy
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 11:07:14 -0400

Nancy,

I support this work and think this draft should be published. This is a yet another good write up on some of the requirements that are needed for operational security. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
> Hi,
> Thanks to all the feedback provided, we have updated the https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04 <https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Jul 2019 11:35:49 -0700

This draft contains substantial omissions in section 3.

Nothing in TLS 1.3 prevents scanning for servers and examining the
certificates they present. Nothing in TLS 1.3 prevents using reverse
proxies to provide WAF functionality. PCI-DSS compliance is not at odds
with deploying TLS 1.3. In fact the citation to A2 is to a sun-setting of
all pre TLS 1.2 versions for point of sale terminals. I really don't see
where the conflict exists since all ciphers in 1.3 are secure.

The absence of these solutions means the draft overstates the impact of the
increased protection TLS 1.3 provides. It's disappointing to see sustained
and persistent opposition to encryption and privacy despite multiple RFCs
saying that yes we should encrypt all the things.

On Tue, Jul 23, 2019, 8:08 AM Bret Jordan <[email-masked]> wrote:

> Nancy,
>
> I support this work and think this draft should be published. This is a
> yet another good write up on some of the requirements that are needed for
> operational security.
>
> Thanks,
> Bret

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 23 Jul 2019 13:05:03 -0700

> request its publication as an informational draft.

I read this draft as the latest attempt in a disinformation campaign by
manufacturers and users of middleboxes that passively decrypt TLS
connections to politicize and reframe the argument around what is, at its
core, a fundamentally insecure practice which is incompatible with
technically sound and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel
words, and other deceptive language to argue your points.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the
subtext is quite clearly the much narrower subfield of middlebox TLS
decryption. By using such a grandiose title which is deceptively hiding the
true subject matter, you are implying that middleboxes are the sum total of
network security.

The draft begins "Enterprises [...] need to defend their information
systems from attacks originating from both inside and outside their
networks." I am co-owner of a company which heavily leverages firewalls for
layer 3/4 network security in conjunction with TLS. We care deeply about
network security, and believe that our network is *more secure*
specifically because we *don't* perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and
as an enterprise TLS user who cares deeply about network security, I do not
identify whatsoever with the claims this draft is making about the needs of
enterprise TLS users as a whole. In as much as what it describes to
"network security", it is but one niche consideration within a vastly
broader field, and one which is increasingly controversial.

I will point out, since you appear to work at Cisco, that your company
works on approaches to network security (e.g. malware detection) which
avoid decrypting TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

There is an entire world of network IDS systems beyond middleboxes which
passively decrypt TLS.

It is factually inaccurate for this draft to be described as "TLS 1.3
Impact on Network-Based Security". If you are going to write a draft about
the impact of TLS 1.3 on middleboxes for passive TLS decryption, please
call a spade a spade and don't try to hide your true intentions under a
bunch of weasel words and overly broad claims that make it sound like
middlebox-related TLS decryption problems are the end of network security
as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that
attempts by middlebox-using enterprise TLS users to weaken TLS in order to
retain compatibility with their traffic decryption appliances is a threat
to the security of our enterprise TLS deployments.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jul 2019 16:14:44 -0400

> draft.  At this point, we believe the draft is stable and would like to request its publication as an informational draft.

I found the language of the draft (especially the introduction)
somewhat turgid and repetitive to the point of significantly
detracting from readability.  I think the draft needs substantial
editing for simplicity and clarity.

As to specific technical issues, I don't understand the point being
made in Section 2.2.2 about client key shares and resumption:

   In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
   which can be negotiated as part of an initial handshake and then used
   in a subsequent handshake to perform resumption using the PSK.  TLS
   1.3 states that the client SHOULD include a "key_share" extension to
   enable the server to decline resumption and fall back to a full
   handshake, however it is not an absolute requirement.

   Example scenarios that are impacted by this are middleboxes that were
   not part of the initial handshake, and hence do not know the PSK.  If
   the client does not include the "key_share" extension, the middlebox
   cannot force a fallback to the full handshake.  If the middlebox
   policy requires it to inspect the session, it will have to fail the
   connection instead.

[ AFAIK, even with PSK-based resumption, and even when the client's
  initial key share was not acceptable to server, the server can still
  perform a full handshake after HRR.  An MiTM middle-box can replace
  the server's HRR with its own, and then decline the client's PSK
  and perform a full handshake. ]

I also found the malicious server argument in section 2.2.1 somewhat
unconvincing, since malicious servers have lots of (previously)
innocuous domains to choose from, or can present self-signed
certificates for any SNI of their choice.

The impact of TLS 1.3 is largely limited to making it more difficult
to whitelist "known good" servers from MiTM inspection.  With TLS
1.3 a middle box that wants to be sure to MiTM sessions to "bad"
servers, must also MiTM sessions to "good" servers (in order to
determine that they're really "known good"), because authenticating
a "good" server is no longer possible without MiTM interception.
Blacklists of "known bad" are easily bypassed even with TLS 1.2.

Middleboxes that are limited to closing TCP connections for the
"known bad", are not particularly effective with TLS 1.2, and will
be increasingly less so as attacks become more sophisticated.  A
middlebox that wants to detect the bad must do MiTM interception,
and with TLS 1.3 will need to intercept *all* traffic, even the
previously "known good", once the "known good" peer deploys TLS 1.3.

Yes, optimizing out interception of the "authenticated known good"
is no longer possible.

-- 
	Viktor.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 23 Jul 2019 16:51:16 -0400

On 7/23/19 2:35 PM, Watson Ladd wrote:
> certificates they present.
Agreed, however there is no guarantee that the server will present the 
same certificate and other TLS parameters as it will for a particular 
client connection
> Nothing in TLS 1.3 prevents using reverse proxies to provide WAF 
> functionality.
Agreed however you need to terminate the TLS 1.3 connection at that WAF
> PCI-DSS compliance is not at odds with deploying TLS 1.3. In fact the 
> citation to A2 is to a sun-setting of all pre TLS 1.2 versions for 
> point of sale terminals. I really don't see where the conflict exists 
> since all ciphers in 1.3 are secure.
>
I'll defer to one of my co-authors on this one.
> The absence of these solutions means the draft overstates the impact 
> of the increased protection TLS 1.3 provides. It's disappointing to 
> see sustained and persistent opposition to encryption and privacy 
> despite multiple RFCs saying that yes we should encrypt all the things.
>
The draft is submitted with the intent of informing the community about 
impacts as we see them. The authors welcome discussion and constructive 
feedback and we will be happy to update and improve the draft 
accordingly when such information is provided and consensus forms around 
it. Specific text suggestions will be even better.

Thanks

-- Flemming
>
> On Tue, Jul 23, 2019, 8:08 AM Bret Jordan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Nancy,
>
>     I support this work and think this draft should be published. This
>     is a yet another good write up on some of the requirements that
>     are needed for operational security.
>
>     Thanks,
>     Bret
>>     On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing)
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>     Thanks to all the feedback provided, we have updated
>>     thehttps://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>>     draft.  At this point, we believe the draft is stable and would
>>     like to request its publication as an informational draft.
>>     Warm regards,
>>         Nancy

---

From: Sean Turner <[email-masked]>
Date: Tue, 23 Jul 2019 16:51:50 -0400

Tony,

While you may have concerns or otherwise disagree with the contents of this draft, let’s please keep discussion on this list, on all issues, polite and professional.

spt
(as co-chair)

> On Jul 23, 2019, at 16:05, Tony Arcieri <[email-masked]> wrote:
> 
> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <ncamwing@cisco..com> wrote:
> Hi,
> 
> I read this draft as the latest attempt in a disinformation campaign by manufacturers and users of middleboxes that passively decrypt TLS connections to politicize and reframe the argument around what is, at its core, a fundamentally insecure practice which is incompatible with technically sound and highly desirable protocol improvements to TLS.
> 
> I implore you stop using overly broad terminology, euphemisms, weasel words, and other deceptive language to argue your points.
> 
> This draft is titled "TLS 1.3 Impact on Network-Based Security", but the subtext is quite clearly the much narrower subfield of middlebox TLS decryption. By using such a grandiose title which is deceptively hiding the true subject matter, you are implying that middleboxes are the sum total of network security.
> 
> The draft begins "Enterprises [...] need to defend their information systems from attacks originating from both inside and outside their networks." I am co-owner of a company which heavily leverages firewalls for layer 3/4 network security in conjunction with TLS. We care deeply about network security, and believe that our network is *more secure* specifically because we *don't* perform middlebox interception of TLS.
> 
> I consider our company to be in the category of enterprise TLS users, and as an enterprise TLS user who cares deeply about network security, I do not identify whatsoever with the claims this draft is making about the needs of enterprise TLS users as a whole. In as much as what it describes to "network security", it is but one niche consideration within a vastly broader field, and one which is increasingly controversial.
> 
> I will point out, since you appear to work at Cisco, that your company works on approaches to network security (e.g. malware detection) which avoid decrypting TLS:
> 
> There is an entire world of network IDS systems beyond middleboxes which passively decrypt TLS.
> 
> It is factually inaccurate for this draft to be described as "TLS 1.3 Impact on Network-Based Security". If you are going to write a draft about the impact of TLS 1.3 on middleboxes for passive TLS decryption, please call a spade a spade and don't try to hide your true intentions under a bunch of weasel words and overly broad claims that make it sound like middlebox-related TLS decryption problems are the end of network security as we know it.
> 
> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that attempts by middlebox-using enterprise TLS users to weaken TLS in order to retain compatibility with their traffic decryption appliances is a threat to the security of our enterprise TLS deployments.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 23 Jul 2019 16:57:08 -0400

On 7/23/19 4:05 PM, Tony Arcieri wrote:
> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
> <ncamwing@cisco..com <mailto:[email-masked]>> wrote:
>
>     Hi,
>
> I read this draft as the latest attempt in a disinformation campaign 
> by manufacturers and users of middleboxes that passively decrypt TLS 
> connections to politicize and reframe the argument around what is, at 
> its core, a fundamentally insecure practice which is incompatible with 
I am not a mind-reader, so I will refrain from attributing malice to 
your choice of words - I would appreciate it if you would extend the 
same courtesy.

> This draft is titled "TLS 1.3 Impact on Network-Based Security", but 
> the subtext is quite clearly the much narrower subfield of middlebox 
> TLS decryption. By using such a grandiose title which is deceptively 
> hiding the true subject matter, you are implying that middleboxes are 
> the sum total of network security.
No such implication is intended - we will look for a more accurate 
document title.
> networks." I am co-owner of a company which heavily leverages 
> firewalls for layer 3/4 network security in conjunction with TLS. We 
> care deeply about network security, and believe that our network is 
> *more secure* specifically because we *don't* perform middlebox 
> interception of TLS.
>
> I consider our company to be in the category of enterprise TLS users, 
> and as an enterprise TLS user who cares deeply about network security, 
> I do not identify whatsoever with the claims this draft is making 
> about the needs of enterprise TLS users as a whole. In as much as what 
> it describes to "network security", it is but one niche consideration 
> within a vastly broader field, and one which is increasingly 
> controversial.
>
It is indeed controversial, and different enterprises have different 
views on these. I know this because I regularly interact with a number 
of these across different industries.

> https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
I am quite familiar with this. Please note that it does not provide a 
full replacement for all existing capabilities

> which passively decrypt TLS.
Are you saying that it is possible to passively decrypt TLS 1.3 sessions 
without being a MITM (or otherwise sharing keying material) ?

> Impact on Network-Based Security". If you are going to write a draft 
> about the impact of TLS 1.3 on middleboxes for passive TLS decryption, 
> please call a spade a spade and don't try to hide your true intentions 
> under a bunch of weasel words and overly broad claims that make it 
> sound like middlebox-related TLS decryption problems are the end of 
> network security as we know it.
>
> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel 
> that attempts by middlebox-using enterprise TLS users to weaken TLS in 
> order to retain compatibility with their traffic decryption appliances 
> is a threat to the security of our enterprise TLS deployments.
Please see my earlier comments on this.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 23 Jul 2019 17:04:17 -0400

> editing for simplicity and clarity.
If you have any specific text suggestions, please let us know.
>    and perform a full handshake. ]

We will take another look at this part.
> certificates for any SNI of their choice.
It all depends on what you are willing to accept. I still see a 
difference with TLS 1.3 here.

> Yes, optimizing out interception of the "authenticated known good"
Ok - thanks for the feedback.

-- Flemming

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Jul 2019 21:05:17 +0000

What does it say that RFC 8404 doesn’t?

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Jul 2019 14:09:41 -0700

> same certificate and other TLS parameters as it will for a particular

True but for 99% (WAG) of setups this is driven by SNI and ciphersuite
which you see in the clear.

> Agreed however you need to terminate the TLS 1.3 connection at that WAF

That doesn't sound like a big difficulty especially given the WAF was
intercepting and decrypting before. What is the gain here? It's also more
secure: there is fun with headers that doesnt work if the WAF normalizes.

> citation to A2 is to a sun-setting of all pre TLS 1.2 versions for point of
> sale terminals. I really don't see where the conflict exists since all
> ciphers in 1.3 are secure.
>
> The absence of these solutions means the draft overstates the impact of
> the increased protection TLS 1.3 provides. It's disappointing to see
> sustained and persistent opposition to encryption and privacy despite
> multiple RFCs saying that yes we should encrypt all the things.
>
> feedback and we will be happy to update and improve the draft accordingly
> when such information is provided and consensus forms around it. Specific
> text suggestions will be even better.
>

I seem to remember a discussion during the last call of TLS 1.3 where these
issues were raised. I think at minimum pointing out that this only affects
some networks with some choices of how to do things and that other
techniques (like reverse proxies) can achieve the same ends is necessary if
the goal is actually to help operators cope with TLS 1.3.

> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 17:52:21 -0400

Thanks Sean.  

It is critical that we understand and discuss all sides of an issue and address all use cases that market has. Beating people down and trying to attack people or their use cases is not something we should be doing in formal standards, especially here at the IETF.

Thanks,
Bret

> On Jul 23, 2019, at 4:51 PM, Sean Turner <[email-masked]> wrote:
> 
> Tony,
>

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Tue, 23 Jul 2019 21:55:39 +0000

+1, neutrality is appreciated, thank you Sean

Collecting expressed views should prevail in a neutral way, there is no reason why inappropriate behaviour should be tolerated and let the impression that the loudest voice is prevailing

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 23 Jul 2019 21:55:50 +0000

+1

From: TLS <[email-masked]> On Behalf Of Bret Jordan
Sent: Tuesday, July 23, 2019 5:52 PM
To: Sean Turner <[email-masked]>
Cc: Tony Arcieri <[email-masked]>; [email-masked]
Subject: Re: [TLS] TLS Impact on Network Security draft updated

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust the content.

Thanks Sean.

Thanks,
Bret

On Jul 23, 2019, at 4:51 PM, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:

Tony,

spt
(as co-chair)

On Jul 23, 2019, at 16:05, Tony Arcieri <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <ncamwing@cisco..com<mailto:ncamwing@cisco..com>> wrote:
Hi,

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that attempts by middlebox-using enterprise TLS users to weaken TLS in order to retain compatibility with their traffic decryption appliances is a threat to the security of our enterprise TLS deployments.
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

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

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Jul 2019 15:11:57 -0700

Document: draft-camwinget-tls-use-cases-05.txt

I have some technical comments on the current draft.

S 2.2.1.
   Note that even _if_ the SNI is provided by the client, there is no
   guarantee that the actual server responding is the one indicated in
   the SNI from the client.  SNI alone, without comparison of the server
   certificate, does not provide reliable information about the server
   that the client attempts to reach.  Where a client has been
   compromised by malware and connects to a command and control server,
   but presents an innocuous SNI to bypass protective filters, it is
   undetectable under TLS 1.3.

This actually applies to TLS 1.2 as well, because nothing requires
that a nonconformant client use the key supplied in the server certificate
(for instance, it might just just encrypt with a fixed key or tunnel
a key exchange in the TLS handshake somehow). This cannot be detected
by a passive observer.

S 2.2.2.
I don't understand the point of this section. TLS 1.3 resumption PSK
and TLS 1.2 resumption (with tickets, for instance) are largely
isomorphic. In both cases, the client can decline resumption, but that
is true in 1.2 as well (though there's no formal way to do it in 1.2).
As a practical matter, there's no real chance that a standard client
will not let you fall back to a full handshake.

In earlier versions of this document, it didn't recognize this point
and so this section (while misleading) made some sense, but at this
point I would just remove it.

S 2.2.3.
I don't get what this section is trying to say. Previous TLS versions
included anti-downgrade mechanisms, so you could never silently
downgrade versions. The TLS 1.3 anti-downgrade mechanisms are
designed to be stronger than TLS 1.2, but they don't fundamentally
change this situation.

S 2.2.4.
Yes, ESNI causes you problems, but if you are a selective MITM proxy,
you should just disable ESNI on clients using the same mechanisms
that you use to add your own trust anchor.

-Ekr

---

From: "Filippo Valsorda" <[email-masked]>
Date: Wed, 24 Jul 2019 00:46:43 +0200

Before any technical or wording feedback, I am confused as to the nature of this document. It does not seem to specify any protocol change or mechanism, and it does not even focus on solutions to move the web further.

Instead, it looks like a well edited blog post, presenting the perspective of one segment of the industry. (The perspective seems to also lack consensus, but I believe even that is secondary.) Note how as of draft-camwinget-tls-use-cases-05 there are no IANA considerations, no security considerations, and no occurrences of any of the BCP 14 key words (MUST, SHOULD, etc.).

Is there precedent for publishing such a document as an RFC?

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 18:56:47 -0400

Informational documents do not (usually) have normative statements.  If they had normative language, they would be standards track document. 

Thanks,
Bret

> On Jul 23, 2019, at 6:46 PM, Filippo Valsorda <[email-masked]> wrote:
>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Jul 2019 15:58:06 -0700

On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda <[email-masked]>
wrote:

> Before any technical or wording feedback, I am confused as to the nature
> of this document. It does not seem to specify any protocol change or
> mechanism, and it does not even focus on solutions to move the web further.
>
> Instead, it looks like a well edited blog post, presenting the perspective
> of one segment of the industry. (The perspective seems to also lack
> consensus, but I believe even that is secondary.) Note how as of
> draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> security considerations, and no occurrences of any of the BCP 14 key words
> (MUST, SHOULD, etc.).
>

I was going to say RFC 691 but no, it recommends changes to the protocol
(as well as being quite amusing). RFC 4074 comes close describing bad
behavior without an explicit plea to stop doing it, but has a security
considerations section. RFC 7021 describes the impact of a particular
networking technique on applications.

So there is precedent.

Sincerely,
Watson

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 24 Jul 2019 03:17:37 +0000

This should not be dismissed as small segments of industries.    This represents ubiquitous use cases at all large organizations in Insurance, Health Care, Banking, Automotive and many others.
We as the IETF should not lightly dismiss such significant numbers and volume, even (or especially),  if the answers are not easy ones.    Do we really want related solutions to be developed elsewhere?

From: TLS <[email-masked]> On Behalf Of Watson Ladd
Sent: Tuesday, July 23, 2019 6:58 PM
To: Filippo Valsorda <[email-masked]>
Cc: TLS List <[email-masked]>
Subject: Re: [TLS] TLS Impact on Network Security draft updated

On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda <[email-masked]<mailto:[email-masked]>> wrote:
Before any technical or wording feedback, I am confused as to the nature of this document. It does not seem to specify any protocol change or mechanism, and it does not even focus on solutions to move the web further.

I was going to say RFC 691 but no, it recommends changes to the protocol (as well as being quite amusing). RFC 4074 comes close describing bad behavior without an explicit plea to stop doing it, but has a security considerations section. RFC 7021 describes the impact of a particular networking technique on applications.

So there is precedent.

Sincerely,
Watson

---

From: Joseph Birr-Pixton <[email-masked]>
Date: Wed, 24 Jul 2019 07:51:42 +0100

Hello,

I would like to suggest that this draft is expanded to cover the use cases
of governments, such as those recently seen in Kazakhstan. This will
ideally leave the reader with a fuller impression of the risks inherent in
the technology being described here.

- section 1: add a sentence to the introduction, eg. "Governments may wish
to intercept their citizen's traffic for the purpose of identifying and
combating political dissent."
- section 4: add subsection "09 - Suppression of Dissent" covering this use
case of the technology.

Thanks,
Joe

---

From: Hubert Kario <[email-masked]>
Date: Wed, 24 Jul 2019 14:30:19 +0200

On Wednesday, 24 July 2019 05:17:37 CEST Ackermann, Michael wrote:
> This should not be dismissed as small segments of industries.    This
> represents ubiquitous use cases at all large organizations in Insurance,
> Health Care, Banking, Automotive and many others.

Not "all" and not "ubiquitous", the word you're looking for is "some". As it 
was pointed out many times already on this mailing list.

> We as the IETF should
> not lightly dismiss such significant numbers and volume, even (or
> especially),  if the answers are not easy ones. 

Also, the people that are pushing against the IETF consens should not lightly 
dismiss it, even (or especially), if the answers are not the ones that they 
would like to hear.

> 
> On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda
> <[email-masked]<mailto:[email-masked]>> wrote:
> Before any
> technical or wording feedback, I am confused as to the nature of this
> document. It does not seem to specify any protocol change or mechanism, and
> it does not even focus on solutions to move the web further. 
 
> I was going to say RFC 691 but no, it recommends changes to the protocol (as
> well as being quite amusing). RFC 4074 comes close describing bad behavior
> without an explicit plea to stop doing it, but has a security
 
> So there is precedent.
> 
> Sincerely,
> Watson
> 
> 
> 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.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Jul 2019 13:11:28 +0000

*   This should not be dismissed as small segments of industries.    This represents ubiquitous use cases at all large organizations in Insurance, Health Care, Banking, Automotive and many others.

All generalization are false, including the claim that these are ubiquitous uses at all large organizations in the named industries.  I know counterfactuals.

---

From: Sean Turner <[email-masked]>
Date: Sat, 27 Jul 2019 09:27:42 -0400

As draft-camwinget-tls-use-cases is not going to be considered within the TLS WG, we need to move the discussions off of the TLS list.  After consultation with our AD, we are going to ask that further discussion be directed to the authors either directly to the authors or through the draft’s authors alias [email-masked].

spt