[TLS] I-D Action: draft-ietf-tls-ech-keylogfile-00.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-ech-keylogfile-00.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH)
   Authors: Yaroslav Rosomakho
Hannes Tschofenig
   Name:draft-ietf-tls-ech-keylogfile-00.txt
   Pages:   6
   Dates:   2024-10-03

Abstract:

   This document specifies an extension to the SSLKEYLOGFILE format to
   support the logging of information about Encrypted Client Hello (ECH)
   related secrets.  Two new labels are introduced, namely ECH_SECRET
   and ECH_CONFIG, which log the Hybrid Public Key Encryption (HPKE)-
   derived shared secret and the ECHConfig used for the ECH,
   respectively.

   This extension aims to facilitate debugging of TLS connections
   employing ECH.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-ech-keylogfile-00.html

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [DNSOP] Re: Re: AD review draft-ietf-tls-svcb-ech

[Arnaud Taddei]

Hi Ben, thank you for your answer but this is confirming I have a lot of 
difficulties to agree. In fact I disagree and after thorough internal 
discussions this confirms the solidity of our support to Paul Vixie’s position. 

Re-read Paul V. answers and consider the MUST NOT clauses in his emails

Inline

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 2 Oct 2024, at 16:50, Ben Schwartz  
> wrote:
> 
> Hi Arnaud,
> 
> I believe your assessment that many network administrators think they need to 
> block access to certain domains and/or disable the usage of ECH via network 
> service configuration. 
Ok

> I also believe that they are generally incorrect, since ECH does not conceal 
> any information that a firewall should believe.
Ok I am not going to redo that loop because we had it with Chris Wood and 
others and we showed that this is a gross misunderstanding of our enterprise 
environments are:
1) In practice the SNI is reliable
2) Proxies are not stupid and they check and improve the evaluation ticket in 
the proxy process before it actually takes action
3) when the SNI is not reliable this is a very good source of attackers 
information and we like this entropy as security practitioners
Again our Internet Draft on ECH deployment considerations is explicit about 
that: 2, 2.3, 2.4 and 2.5, Appendix B.3 with production data

> However, that is not the topic at hand.
I partially agree and disagree. Re-reading the whole thread my answer is 
slightly orthogonal but it provides context to Paul Vixie crucial point

> We are discussing the Security Considerations of draft-ietf-tls-svcb-ech, and 
> two points in particular:
> 
> 1. A reminder that Section 3.1 of RFC 9460 applies here.  This section 
> considers an active attacker who does not control the DNS resolver, but 
> attempts to interfere with it by forcing SERVFAIL responses, or no response 
> at all.  It does not impair the effectiveness of a filtering DNS resolver, 
> which can simply respond REFUSED to any objectionable query. 
This clause seems correct to me.

> The resolver could also rewrite the SVCB record to delete the "ech" SvcParam, 
> but this would add complexity without any benefit and would break stub DNSSEC 
> validation (hence my comment that you quoted).
Again this is EXACTLY what enterprises want to do and probably already on other 
fields and DNS software vendors too. The assumption that DNSSEC is important is 
simply irrealistic in enterprise context. That is not how the real world works 

> 2. A proposed addition to this section 
> (https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files 
> ):
> 
> > To achieve the security goals from Section 10.1 of [ECH], clients for this 
> > specification SHOULD use an authenticated and encrypted connection to a DNS 
> > resolver that they trust to preserve the confidentiality of their queries 
> > and return authentic answers.
I completely disagree for the same arguments that Paul Vixie explains very 
precisely. 

Let me extract from Paul’s reference:

"How does it work?
...
 The resolver usually checks both the domain name queries and the returned IP 
addresses against threat intelligence, and then prevents connections to known 
or suspected malicious sites. PDNS can also protect a user by redirecting the 
requesting application to a nonmalicious site or returning a response that 
indicates no IP address was found for the domain queried. In addition, many 
enterprise DNS resolvers still do not validate DNSSEC or support DoH/DoT, but 
many PDNS providers add these DNS security enhancements as well [4].
…”

You have to consider the world of security operations which was obviously 
heavily ignored so far here. 

Going the authentic path will have exactly the contrary effect. 


> The referenced section states a design goal that "An attacker cannot 
> downgrade a connection that attempts to use ECH to one that does not use 
> ECH.". 

It is really hard for me to answer that position. It is good to have a goal, 
but when in design only the end target is considered with no ‘migration’ path, 
usually (32 years of observations) it leads to the situation that doesn’t mean 
you can reach this goal in practice

> This text notes some resulting implied requirements:
> 
> 1. The client's connection to the DNS server is not vulnerable.
> 2. The DNS server is not an attacker.
> 3. The DNS server is not itself vulnerable.

Unfortunately these requirements are in practice irrealistic. In general terms 
you cannot trust the DNS resolver

> These requirements are entirely compatible with "protective DNS".  I'm happy 
> to adjust the proposed text as needed to make that clear.

No, these requi

[TLS] Re: [DNSOP] Re: Re: AD review draft-ietf-tls-svcb-ech

[Salz, Rich]

I do not think this conflict of views can be resolved. The draft is intended to 
show how it ECH should be used to preserve it’s security guarantees, and there 
are groups in the DNS community who say this prevents their normal course of 
operation, and providing the features that they provide.  I apologize in 
advance if anyone finds my wording clumsy or, worse, offensive. I was trying to 
use neutral words throughout.

I think we just acknowledge that in the security considerations and declare the 
issue closed.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org