Hi Éric, see further thoughts on ECH below.
On 7/13/22 12:12 PM, Peter Saint-Andre wrote:
On 7/12/22 1:50 AM, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: No Objection
<snip/>
### Section 3.7 ESNI as a SHOULD ?
Shouldn't ESNI be a normative "SHOULD" ? Or is the non-normative text
"just" to
avoid forming a cluster with ESNI draft ? Which would be sad...
There is always debate about references to works in progress. It's not
clear that a protocol still being hashed out in a WG (even a protocol as
important as ESNI) can be reasonably considered a best current practice,
given that it's far from stable. Eventually, we assume that the IETF
will publish rfc7525ter to replace rfc7525bis, at which time that BCP
will include updated recommendations (including, I'd expect, ESNI and
various other things that are developed between now and then).
The implication of your original comment is that the authors are trying
to avoid a cluster and push this document through without a normative
reference to the ECH I-D being worked on in the TLS WG.
This is not what we're trying to do. Although personally I think that
ECH is consistent with RFC 3365, there are questions and concerns about
ECH that need to be worked out, the protocol needs to be finalized,
implementations need to be written or finished, administrators of
various TLS-based systems need figure out how to deploy it properly,
etc. For these reasons, I think it is simply too early to recommend ECH
as a best *current* practice. Hopefully it will be so when this BCP is
updated again a few years from now.
Nevertheless and in light of the above considerations, I grant that the
current text might be too strong:
Implementers are strongly encouraged to support TLS
Encrypted Client Hello once [I-D.ietf-tls-esni] has been
standardized.
Something like this might be more accurate:
At the time of writing, a technology for encrypting the SNI
(called Encrypted Client Hello) is being worked on in the TLS
Working Group [I-D.ietf-tls-esni]. Once that method has been
standardized and widely implemented, it will likely be appropriate
to recommend or mandate its usage in a future version of this
BCP.
I'd also suggest changing "this information leak is closed by use of TLS
Encrypted Client Hello" to "this information leak will be closed by use
of TLS Encrypted Client Hello once that method has been standardized".
I've incorporated the foregoing suggestions into a PR:
https://github.com/yaronf/I-D/pull/463
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
