[TLS] Re: Mohamed Boucadair's Discuss on draft-ietf-tls-esni-24: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ben,

Thanks for the clarification.

I consider the "(apparent) Inconsistency vs ECH-IN-DNS?" point closed.

Cheers,
Med

De : Ben Schwartz <[e-mail]>
Envoyé : mardi 6 mai 2025 17:17
À : The IESG <[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [TLS] Mohamed Boucadair's Discuss on draft-ietf-tls-esni-24: (with DISCUSS and COMMENT)


...

> # (apparent) Inconsistency vs ECH-IN-DNS?
>
> ECH spec says the following in Section 8.1
>
>    Thus server operators SHOULD ensure servers understand a given set of ECH
>    keys before advertising them.
>
> ECH-IN-DNS says the following in Section 4:
>
>    When publishing a record containing an "ech" parameter, the publisher
>    MUST ensure that all IP addresses of TargetName correspond to servers
>    that have access to the corresponding private key or are
>    authoritative for the public name
>
> Avoiding failures is the main motivation for both "ensure" behaviors.

Not quite.  The first quote is about avoiding the ECH recovery flow.  This flow is slower than a normal handshake but does not result in a user-visible failure.  The second quote is about avoiding user-visible failures.

> Is there
> a reason why one spec uses SHOULD while the other uses a MUST?
Taken together, these quotes mean "deployments SHOULD avoid using the recovery flow, and MUST NOT create an arrangement that will fail to connect".

--Ben Schwartz
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.