Hi Med,
I have provided a number of responses below, but my primary concern is
the resolution of your DISCUSS position. There seem to be two
remaining points in your DISCUSS:
1. Whether the citation to ECH-in-DNS should be normative.
2. The request for some discussion of how ECH Configs are
"bound to a server".
WRT to the first point, as I said in my initial message the only
at scale mechanism for deployment of ECH that we have is via DNS,
and that's what this specification presumes in S 4.1.
This document defines the ECH configuration's format, but
delegates DNS publication details to [RFC9460]. See [ECH-IN-DNS]
for specifics about how ECH configurations are advertised in HTTPS
records. Other delivery mechanisms are also possible. For
example, the client may have the ECH configuration preconfigured.
Preconfiguration is not a scalable mechanism. For this reason, I
believe that a normative reference is appropriate, and that this is
well within the WG's discretion. Perhaps more to the point, this
objection does not seem to fit within the IESG DISCUSS criteria (the
criteria contemplate the opposite case of an informative reference
which should be normative, but that is entirely different), so I do
not believe that this objection should be the basis of a continuing
DISCUSS.
This leaves us with the second point about how ECH Configs are bound
to a server. I'm not quite sure what you're asking for here. As
indicated below, ECH Configs have to be treated somewhat differently
depending on how they are learned: for instance the retry_configs are
only intended for use within a given set of attempted connections
whereas configs learned via DNS have a lifetime dictated by the DNS
behaviors (as in ECH-in-DNS):
The retry configurations are meant to be used for retried
connections. Further use of retry configurations could yield a
tracking vector. In settings where the client will otherwise already
let the server track the client, e.g., because the client will send
cookies to the server in parallel connections, using the retry
configurations for these parallel connections does not introduce a
new tracking vector.
Similarly, you can accept a retry_config when you initiated
a connection with another config, but not with a retry_config.
Clients SHOULD NOT accept "retry_config" in response to a connection
initiated in response to a "retry_config". Sending a "retry_config"
in this situation is a signal that the server is misconfigured, e.g.,
the server might have multiple inconsistent configurations so that
the client reached a node with configuration A in the first
connection and a node with configuration B in the second. Note that
this guidance does not apply to the cases in the previous paragraph
where the server has securely disabled ECH.
I believe the specification clearly describes the required behaviors
(or defers them to ECH-in-DNS, as appropriate, which also suggests
that ECH-in-DNS should be normative), and I don't believe a generic
discussion would be of assistance. If you believe that there is a
specific technical defect or lack of clarity that would prevent
interoperability, can you please flag it so that we can address it?
Otherwise, can you please clear your DISCUSS?
Further responses to your non-blocking comments below.
> > ## Substitute
> >
> > CURRENT:
> > the client MAY substitute
> > extensions which it knows will be duplicated in ClientHelloOuter.
> >
> > Is this substitution triggered by configuration? Can a client make an
> > autonomous decision here? If no, please explicit that this is based on
an
> > instruction/configuration.
>
> I don't understand the question. This is just something the client
> is permitted to do, just as with any other point of variation
> in the protocol. We don't take a position on whether clients should
> do it or not or on what basis they should decide.
> [Med] It isn’t clear to me based on which knowledge the client can make
that substitution.
It can make the substitution any time an extension is identical. It's
a matter of implementation discretion when it actually does so.
> > Please reword for clarity.
>
> I believe this is sufficiently clear and matches our normal conventions.
>
> [Med] by “our”, I guess you meant “TLS WG”. I care about those who will
deploy, hence my comment. The use of “network attacker” is not clear to me,
even.
I think we just disagree here. I believe this is sufficiently clear.
> > ## Reasoning
> >
> > CURRENT:
> > Prior to attempting a connection, a client SHOULD validate the
> > ECHConfig. Clients SHOULD ignore any ECHConfig structure with a
> > public_name that is not a valid host name in preferred name syntax
> > (see Section 2 of [DNS-TERMS]).
> >
> > Any reason why invalid configuration are not unconditionally ignored?
>
> This was extensively debated in the WG and there were some
> situations where people wanted flexibility here. It does not
> create interoperability problems to have it be a SHOULD.
>
> [Med] Thanks for the background. Not sure to agree with you interop
> comment. It is not clear when the client can simply proceed with any
> validation of the ECHConfig.
The client can always proceed with it absent some infrormation otherwise.
> > This may be used for troubleshooting/diagnostic.
>
> I don't understand what you're asking for here.
>
> [Med] The comment is about retrieving what lifetime is used by an
implementation. This can be useful for diagnostic in managed networks.
>
> We don't generally
> specify how to introspect into the behavior of a client's TLS stack,
> though of course it's often possible.
As above, this is not the kind of thing we usually specify.
> > # Do we have record for the “common scenario” claim in Section 10.2?
> >
> > CURRENT:
> > This means that any attacker which can
> > inject DNS responses or poison DNS caches, which is a common scenario
> > in client access networks,
>
> I believe that captive portals are sufficiently well known to
> as be common knowledge.
>
> [Med] Maybe, but this is not characteristic for “access networks”, which
has a specific meaning in operations.
I'm not sure I agree, but if you want to provide some alternate
text that covers this kind of network, I'm happy to take a look.
> > # What is meant by “transit mechanisms” in Section 10.2?
>
> DoT, DoH, etc.
>
> [Med] Aaah, I see. The wording below is better.
>
>
> > CURRENT:
> > Moreover, as noted in the introduction, SNI encryption is less useful
> > without encryption of DNS queries in transit mechanisms.
>
> Changed to "in transport".
>
> [Med] Thanks.
>
> > # Section 10.10.5: Regularly
> >
> > CURRENT:
> > This design does not provide forward secrecy for the inner
> > ClientHello because the server's ECH key is static. However, the
> > window of exposure is bound by the key lifetime. It is RECOMMENDED
> > that servers rotate keys regularly.
> >
> > Any guidance on how frequent key rotation should be done to avoid impact
> > service stability and ensure service continuity? Any pointer to cite on
such
> > matters?
>
> [Med] Seems this one was missed.
I responded to it in the paragraph below.
> > Adam raised a more general comment:
> >
> > “If it is possible (possibly not in this drat) to offer more detailed
> > operational guidance on key rotation, that would be helpful. There
are some
> > points in the document that might allude to implementation-specific
> > configuration choices. Implementations would ideally expose these
choices to
> > operators so they can make the best possible choices for their needs.”
> >
> > Some words on these matters would be helpful. Thanks.
>
> The WG discussed this extensively and concluded that we had said
> what could be said.
>
> [Med] Is there any public pointer to that discussion? Thanks.
I believe it was in a live meeting. I don't have the minutes readily
to hand, but perhaps two IETFs ago.
> > # Section 10.11: Redundant padding requirement with the SHOULDs in 6.1.3
> >
> > OLD:
> > Variations in the length of the ClientHelloInner ciphertext could
> > leak information about the corresponding plaintext. Section 6.1.3
> > describes a RECOMMENDED padding mechanism for clients aimed at
> > reducing potential information leakage.
> >
> > NEW:
> > Variations in the length of the ClientHelloInner ciphertext could
> > leak information about the corresponding plaintext. Section 6.1.3
> > describes a recommended padding mechanism for clients aimed at
> > reducing potential information leakage.
>
> I believe RECOMMENDED makes it clearer in this case. It's not
> uncommon to have redundant 2119 language.
>
> [Med] This makes it like a distinct/new requirement. It is cleaner to
keep one such statement.
I think this is a reasonable topic for WG/editor discretion.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
