On Fri, 11 Oct 2024, Eric Rescorla wrote:
Thanks you for your review. I have created a PR that addresses a number of
these.
https://github.com/tlswg/draft-ietf-tls-esni/pull/632
That looks fine, other than the accidental typo introduction I pointed out.
[ deleted agreements, thanks for proposed changes ]
> Section 4.2
>
> See Appendix A for guidance on which types of extensions are
appropriate for this structure.
>
> If this is guidance, then it probably does not belong in an appendix, but in
its own real Section ?
> Also, since Appendix A is a single paragraph, why not just fold it in right
here?
I think this is a taste issue, so I'm comfortable leaving it where it
is, but if you insist, I will change it.
I won't insist, but it does seem better. Both to avoid one-paragraph
appendix sections, as well as spending a whole sentence to point to
a meagre one appendix paragraph. But not my hill.
> Section 6.1.6
>
> If an earlier TLS version was negotiated, the client MUST NOT enable
the False Start optimization
>
> How is this possible? If you sent and received ECH, then you cannot have negotiated an
"earlier" TLS version?
> At least not until we have TLS 1.4. And if we have that, wouldn't an earlier
version 1.3 be fine for ECH?
This section is about where you are handshaking with ClientHelloOuter,
in which case it is possible that you are not doing ECH, in which case
False Start would be possible.
Ahh right.
> Section 10
>
> Downgrade resistance - makes me think of the tls-dnssec pin discussion :-)
>
> If the HPKE private key is lost and replaced, and the ECH DNS entries are
being
> updated, there is a time period (depending on TTL and cache) where the tls
client
> connecting to the client-facing TLS server will not be able to distinguish the
> connection from an attack, and thus not downgrade to try without ECH. This is
an
> outage. Unfortunately, DoH has no way of asking a "refreshed DNS record" to
get
> its DoH server to drop the cached record. I guess the SVCB/HTTPS record could
> introduce a syntax with a prefix on the old keyid or something with an
explicit
> signal that points to the updated (uncached because it only exists when such
an
> outage appears). But this might be a bit complicated for a failure case. It
is probably
> best to postpone such work until it shows to be needed in practice.
I don't think I follow the scenario you have in mind here.
Suppose that the server was using key A and publishes an appropriate
record. It then loses the key and starts using B. If a client comes
in using key A, the server is supposed to follow the ECH configuration
correction procedure in S 6.1.6 and provide a retry configuration with
key B. The client will then retry with B. This isn't an outage, though
it has a negative performance impact, which is why it's best to have
keys overlap.
I am confused how this can happen "securely" if the only way to prove
this is not a malicious attack is to use the private key that was lost?
I guess I am confused about:
If the server provided "retry_configs" and if at least one of the
values contains a version supported by the client, the client
can regard the ECH keys as securely replaced by the server. It
SHOULD retry the handshake with a new transport connection,
using the retry configurations supplied by the server.
The retry_configs contain ECHConfigList. The ECHConfigList contains
ECHConfig structures which it clains "allows a server to support multiple
versions of ECH and multiple sets of ECH parameters".
But either these are confirmed by key A, which was lost, or these are
indistinguishable from an attacker pretending to have lost key A and
accepted? I must be missing something here?
> Section 10.5
>
> It MAY send such values in the ClientHelloInner.
>
> Since it is talking about "such values", this should be "It SHOULD"
The reason for "MAY" here is we aren't telling it to send the values
at all. We've already told them not to send them in the outer, so
Inner is all that's permitted. I'm not sure how a SHOULD helps.
Ah yes, rereading it I see this now. Not sure how to write it
differently.
> Section 10.10.2
>
> I do not understand this section. I think it is trying to say "dont share
> the secrets with too many operators", and not "don't share this secret
> with many servers/domain under the same administrative control" ? But
> it reads like it is recommending that an operator uses multiple smaller
> ECH groups preferably over less but bigger groups?
I am also struggling with this text. Maybe some other author can help
explain what this is trying to say?
I feel a little better now :)
> How does a client know which public names the server does not respond to?
The client doesn't know. It ignores these configurations
I think the context was that the client is told it should use an invalid
public name, one it "knows" the server isn't authoritative for. But
to know what it is not authoritative for, it needs to know what it is
authoritative for, or it needs to use a clearly invalid name. If it
picks a random valid syntax domain (to avoid needing to get a list of
all authoritative domains here), eg "sfkjgldsagakdga.com", it cannot know
if server1.cloudflare.com happens to be also authoritative for that. It
is unlikely, but not guaranteed. It could instead pick something like
sfkjgldsagakdga.invalid, which is guaranteed to not be a real DNS name
as per RFC2606.
My point was to perhaps give good advise about how to create such
invalid domains.
> Section 11.3
>
> The registration policy for for
>
> Remove duplicate "for".
I am failing at finding this. Can you send the whole paragraph.
This was a leftover from an older version.
Paul
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
