[TLS] Encrypted SNI hangout

[Bret Jordan]

All,

Since the TLS session on Monday got canceled what would people think about 
using that time to talk about encrypted SNI?  

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Tonight's Encrypted SNI Hangout Session

[Bret Jordan]

All,

We had a great turnout tonight for the encrypted SNI hangout session.
Everyone seemed open and willing to work together to understand the
complexities that sit before us. Several interesting and important views
were expressed, and I feel that the meeting was ultimately a success. In
fact, I believe we should do more hangout sessions like this.

Take aways from the meeting:
1) We are starting to understand the problem that we are trying to solve

2) We need to ensure that any potential solution will in fact solve the
problems as we understand it and not make the problem worse

3) We need to compile a list of use cases and scenarios in a draft document
that talk about how the SNI (for good or for bad) is being used today and
what an encrypted SNI will mean for these use cases.

4) We need to make sure we get feedback and information from at least the
telco sector, large enterprise, financial sector, and the health care
sector.


I believe this information will help us better understand both sides of the
issue, shed light in to what it will mean, help us define the "why" we are
doing this, and ultimately feed and foster a better technological solution.
If you have or know of scenarios or use-cases where the SNI is being used
by network operators, system administrators, security engineers, products,
etc, please send them to me so I can start compiling them in to a draft
document.

Side question, it feels like this effort could represent a lot of work and
require a lot of dedicated cycles. Does it make sense to continue this
effort inside of the TLS WG?  If it does, will the WG give us the time,
mindshare, and cycles to focus on it (just asking the hard question)?

Once again, thanks all for attending the session tonight.

Bret

-- 

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Tonight's Encrypted SNI Hangout Session

[Bret Jordan]

What I think I am more worried about right now is jumping in to designing a
technological solution before we know and understand what is going to break
and is a solution going to actually solve the perceived problem(s) or make
them worse. Technological changes do not always make things better.

Open Questions:
1) Is encrypted SNI the best solution to address the perceived problem(s)?
2) Do we fully understand the problems we are trying to solve and
understand the best way of solving them?
3) Will this make things better or worse for the majority of use-cases?
4) Does it incur so much collateral damage that it hurts the average user?
5) If we make it client opt-in (which seems like a fundamental
requirement), does this single out the client for extra scrutiny by a well
funded threat actor or nation state?

Just some food for thought

Bret

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Tonight's Encrypted SNI Hangout Session

[Bret Jordan]

Great comments and feedback. Thank you.  

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Nov 14, 2017, at 10:43 AM, Yoav Nir  wrote:
> 
> 
> 
>> On 14 Nov 2017, at 0:00, Tom Ritter  wrote:
>> 
>> Are you also interested in collecting reports of where SNI is used to
>> censor? Or the list of network vendors that support filtering and
>> manipulating traffic based on the value?
> 
> I don’t think naming and shaming is a goal here.
> 
>> In general, the bad uses of SNI are harder to enumerate because people
>> aren't willing to come to the WG and explain how they use SNI to
>> selectively break or censor the internet for their citizens/users.
> 
> I don’t think that’s true. I used to work for a vendor of a network firewall, 
> and I can explain how this is done.  
> 
> Inspecting the ClientHello to find the SNI for filtering is a weak way to do 
> filtering. It’s also a light-weight way.  So if I want to filter Wikipedia, I 
> match SNIs to "*.wikipedia.org” and I have my filtering. Depending on how 
> many cycles I can spare, this is a cost-effective method. We have evidence 
> that it’s been used for filtering, but sophisticated users can circumvent 
> this - they can configure the browser to use TLS 1.0 and not send SNI at all.
> 
> More modern firewalls make a probing connection to the server, sending a 
> ClientHello that is almost identical to the one sent by the real client and 
> checking the returned certificate.  The names specified in that certificate 
> are used for the filtering. That information is cached so that not every real 
> ClientHello has to wait for a probing connection.  I don’t know if any vendor 
> has made this scale to filter an entire country’s browsing, but this is 
> considered to be more reliable than filtering by SNI.
> 
>> We
>> have a few confirmed cases, anecdotal evidence, and lots of evidence
>> of censors being technically applied by whatever means is available.
>> 
>> But when you pile up all the administrators who will come to the WG
>> and say "This really frustrates me and makes my job harder" you're
>> going to have a much bigger pile than the users (or even technical
>> advocates like myself) we can bring in and say "Plaintext SNI is
>> harming the Internet”.
> 
> IMO the real game-changer will be having an encrypted part to the 
> ClientHello. If all ClientHellos are different, this defeats caching.
> 
>> 
>>> Side question, it feels like this effort could represent a lot of work and
>>> require a lot of dedicated cycles. Does it make sense to continue this
>>> effort inside of the TLS WG?  If it does, will the WG give us the time,
>>> mindshare, and cycles to focus on it (just asking the hard question)?
>> 
>> In August we adopted the draft, so the answer is "Yes".
>> 
>> -tom
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Encrypted SNI

[Bret Jordan]

From a discussion on the PATIENT list found here: 
https://www.ietf.org/mail-archive/web/patient/current/msg00078.html 



From my personal perspective, we need to be careful with all of these efforts. 
It feels like the pendulum has swung so far to one side, the side of 
privacy-at-any-cost, that we are unknowingly increasing the risk to individuals 
and organizations by enabling threat actors and intrusions sets to attack 
networks and clients without any level of protection from the network. 

It also feels like a lot of these initiatives are being done without adequately 
involving and ensuring that enterprise networks and critical infrastructure can 
work with these changes. Question, do we know how these ideas and changes are 
going to impact an organizations ability to fulfill their requirements for 
regulatory compliance? 

If we continue down these paths, then I fear networks will be required to wrap 
all traffic in some other less secure protocol, outright deny some of these 
protocols, or be forced to fully proxy all traffic or take an approach that 
Google has done with their BeyondCorp design.  

The IETF work needs to do more outreach with enterprise networks and critical 
infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is not 
a holistic design. 

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



### Copied content from the PATIENT discussion 


On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
> wrote:
>>
>> Your point is one that deserves further discussion, Eric - which seems
>> likely to scale rapidly going forward.  It is key.
>>
>> So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, SNI encryption is intended to conceal the SNI, which of
> course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is that given the
> current technical state, it will not see particularly wide deployment, with
> the primary scenario being "at-risk" sites who are subject to censorship who
> either hide behind or co-tenant with sites which are not subject to
> censorship. That probably isn't going to be incredibly common right now. Of
> course, this is regrettable from the perspective of people designing these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html 


It targets the CDNs who host most of the web traffic in the US at
least.  The right place to comment on this would be the TLS list of
course, but since proposals are being posted, this is a reality and
needs to be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about the future. In March, the 
ESNI problem looked pretty intractable and then subsequently we had this idea 
about why it might be workable.

-Ekr

Best regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > >
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth referencing a relatively recent Lawfare article on the
>>> scaling litigation in the U.S. against those supporting e2e encryption
>>> services or capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>>>  
>>> 
>>>
>>> This litigation trend is also likely to increase the insurance costs of
>>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may not
>>> even be able to get insurance.  It may be fun and games to play crypto rebel
>>> in venues like the IETF where the risk exposure is minimal, but when it
>>> comes to real world consequences and costs, the equations for providers are
>>> rather different.
>>
>>
>> I think this rather overestimates the degree to which both TLS 1.3 and
>> QUIC change the equation about what a provider is able to determine from
>> traffic inspection. As a practical matter, the primary change from TLS 1.2
>> is that the provider does not get to see the server's certificate, but it
>> does see the SNI. Given that the SNI contains the identity of the server
>> that the client is connected to and that the other identities in the
>> certificate are often whatever the provider decided to co-locate on the 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

Now this WG is finally starting to talk about a solution to a real problem and 
need.  We can either address the use case and need here in the IETF, or we can 
let the solutions be done else where. I would personally prefer we take this 
work item back and solve it here in the IETF.

Finally, remember, you may not like the use case or need, but that does not 
mean the use case is not valid and needed. 

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 Dec 5, 2018, at 1:18 AM, Tony Arcieri  wrote:
> 
> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams  > wrote:
>  > I'm not a fan of systems like this, but I believe for security reasons they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
> 
> Any key escrow system will have this property.  Given the session keys
> (or a way to recover them) you can resume decrypted sessions.
> 
> Wouldn't escrowing only the client/server application traffic secrets 
> (instead of keys higher in the schedule) avoid this problem? These keys would 
> permit the one capability "visibility" appliance vendors allege to care 
> about: traffic decryption, without permitting others like session resumption.
> 
>  The most obvious escrow design requiring no changes to the clients is to
> use a static eDH key on the server-side.  The next most obvious such
> design is to have the server talk to the escrow agent.
> 
> It seems like with an out-of-band escrow agent, the traffic secrets could be 
> escrowed with no changes to TLS.
> 
> --
> Tony Arcieri
> ___
> 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] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

I think we should be more open minded and look at the needs from a 360 degree 
deployment perspective. The real power of the IETF is in looking at all the 
needs and requirements and designing solutions for them.

We should flesh this out. It seems like several people on this list so far have 
proposed options that might work. If we spent half as much time looking for a 
solution as we have trying to prevent a solution, we would probably be done by 
now. 

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 Dec 5, 2018, at 6:12 PM, Stephen Farrell  wrote:
> 
> 
> 
> On 05/12/2018 08:08, Bret Jordan wrote:
>> Now this WG is finally starting to talk about a solution to a real
>> problem and need.  We can either address the use case and need here
>> in the IETF, or we can let the solutions be done else where. I would
>> personally prefer we take this work item back and solve it here in
>> the IETF.
> 
> #include 
> 
> I would hope the WG not revisit this topic and see no new
> facts to justify distracting the WG again. Forum shopping
> is not new - rubber-stamping by ETSI or ANSI was explicitly
> proposed as a putative reason to adopt draft-green and that
> did not result in consensus to work on this topic despite
> the significant effort put in by proponents. I'm also happy
> to say that I see no evidence that the WG would reach a
> different conclusion as to lack of consensus.
> 
> FWIW, I view this discussion as being analogous to scratching
> an itchy scab - despite our knowing it is unproductive to do
> so, some IETF participants apparently can't resist poking at
> the wound:-(
> 
> S.
> 
>> 
>> Finally, remember, you may not like the use case or need, but that
>> does not mean the use case is not valid and needed.
>> 
>> 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 Dec 5, 2018, at 1:18 AM, Tony Arcieri 
>>> wrote:
>>> 
>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams >> <mailto:n...@cryptonector.com>> wrote:
>>>> I'm not a fan of systems like this, but I believe for security
>>>> reasons they should be designed in such a way that only the
>>>> confidentiality of traffic is impacted, and a "visibility" system
>>>> isn't able to leverage the decrypted traffic to resume decrypted
>>>> sessions and thereby impersonate clients.
>>> 
>>> Any key escrow system will have this property.  Given the session
>>> keys (or a way to recover them) you can resume decrypted sessions.
>>> 
>>> Wouldn't escrowing only the client/server application traffic
>>> secrets (instead of keys higher in the schedule) avoid this
>>> problem? These keys would permit the one capability "visibility"
>>> appliance vendors allege to care about: traffic decryption, without
>>> permitting others like session resumption.
>>> 
>>> The most obvious escrow design requiring no changes to the clients
>>> is to use a static eDH key on the server-side.  The next most
>>> obvious such design is to have the server talk to the escrow
>>> agent.
>>> 
>>> It seems like with an out-of-band escrow agent, the traffic secrets
>>> could be escrowed with no changes to TLS.
>>> 
>>> -- Tony Arcieri ___ 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
>> 
> <0x5AB2FAF17B172BEA.asc>

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

Comments inline 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Dec 5, 2018, at 7:33 PM, Stephen Farrell  wrote:
> 
> 
> 
>> On 05/12/2018 10:22, Bret Jordan wrote:
>> I think we should be more open minded and look at the needs from a
>> 360 degree deployment perspective. 
> 
> I think we should avoid marketing speak.

This is not marketing speak. This is understanding how these solutions need to 
be deployed end to end in all of their scenarios from consumer, to small 
business, to enterprise, to service provider, to content provider, to telco, 
etc.  


> 
>> The real power of the IETF is in
>> looking at all the needs and requirements and designing solutions for
>> them.
> 
> The IETF is sometimes at it's best when it says "no." This
> is one of those cases.


I disagree.



>> We should flesh this out. It seems like several people on this list
>> so far have proposed options that might work. If we spent half as
>> much time looking for a solution as we have trying to prevent a
>> solution, we would probably be done by now.
> 
> All of the above was done, at length, and we got a result.
> The TLS WG had no consensus to work on this topic.

Or it could be said the TLS WG had no consensus to not work on it.  When there 
is a tie who wins? It seems like working on a solution that works for the 
larger community is the right solution.  The use case and need is a valid 
requirement.

Bret 



> S.
> 
> 
>> 
>> 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 Dec 5, 2018, at 6:12 PM, Stephen Farrell
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On 05/12/2018 08:08, Bret Jordan wrote:
>>>> Now this WG is finally starting to talk about a solution to a
>>>> real problem and need.  We can either address the use case and
>>>> need here in the IETF, or we can let the solutions be done else
>>>> where. I would personally prefer we take this work item back and
>>>> solve it here in the IETF.
>>> 
>>> #include 
>>> 
>>> I would hope the WG not revisit this topic and see no new facts to
>>> justify distracting the WG again. Forum shopping is not new -
>>> rubber-stamping by ETSI or ANSI was explicitly proposed as a
>>> putative reason to adopt draft-green and that did not result in
>>> consensus to work on this topic despite the significant effort put
>>> in by proponents. I'm also happy to say that I see no evidence that
>>> the WG would reach a different conclusion as to lack of consensus.
>>> 
>>> FWIW, I view this discussion as being analogous to scratching an
>>> itchy scab - despite our knowing it is unproductive to do so, some
>>> IETF participants apparently can't resist poking at the wound:-(
>>> 
>>> S.
>>> 
>>>> 
>>>> Finally, remember, you may not like the use case or need, but
>>>> that does not mean the use case is not valid and needed.
>>>> 
>>>> 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 Dec 5, 2018, at 1:18 AM, Tony Arcieri  
>>>>> wrote:
>>>>> 
>>>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams
>>>>> mailto:n...@cryptonector.com>> wrote:
>>>>>> I'm not a fan of systems like this, but I believe for
>>>>>> security reasons they should be designed in such a way that
>>>>>> only the confidentiality of traffic is impacted, and a
>>>>>> "visibility" system isn't able to leverage the decrypted
>>>>>> traffic to resume decrypted sessions and thereby impersonate
>>>>>> clients.
>>>>> 
>>>>> Any key escrow system will have this property.  Given the
>>>>> session keys (or a way to recover them) you can resume
>>>>> decrypted sessions.
>>>>> 
>>>>> Wouldn't escrowing only the client/server application traffic 
>>>>> secrets (instead of keys higher in the schedule) avoid this 
>>>>> problem? These keys would permit the one capability
>>>>> "visibility" appli

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

[Bret Jordan]

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)  
> 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
> 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] TLS Impact on Network Security draft updated

[Bret Jordan]

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
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 23, 2019, at 4:51 PM, Sean Turner  wrote:
> 
> 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  wrote:
>> 
>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
>>  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.
>> 
>> 
>> 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.
>> ___
>> 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] TLS Impact on Network Security draft updated

[Bret Jordan]

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


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 23, 2019, at 6:46 PM, Filippo Valsorda  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.).
> 
> Is there precedent for publishing such a document as an RFC?
> 
> ___
> 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] TLS Impact on Network Security draft updated

[Bret Jordan]

As a professional organization and part of due diligence, we need to try and 
understand the risks and ramifications on the deployments of our solutions. 
This means, understanding exactly how the market uses and needs to use the 
solutions we create. When we remove or change some technology, we should try 
hard to provide a work around. If a work around is not possible, we need to 
cleanly document how these changes are going to impact the market so it can 
prepare. This is the responsible and prudent thing to do in a professional 
organization like the IETF. 

The draft that Nancy and others have worked on is a great start to documenting 
how these new solutions are going to impact organizational networks. Regardless 
of whether you like the use-cases or regulations that some organizations have, 
they are valid and our new solutions are going to impact them. 

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 23, 2019, at 7:44 PM, Dennis Jackson  
> wrote:
> 
> RFC 791  is nearly 40 years old.
> RFC 4074 lists 5 forms of deviations from RFC 1034 and explains 
> the correct behavior. 
> RFC 7021 describes a series of objective tests of RFC 6333 and 
> the results. 
> 
> 
> The above RFCs describe objective test results and how they 
> relate to earlier RFCs. In contrast, this document offers a 
> speculative and subjective discussion of possible future impact.
> 
> 
> I do not believe there is any precedent supporting publication.
> 
> 
> Best,
> Dennis

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