Re: [Add] draft-ietf-add-resolver-info: next steps after IESG evaluation

[[e-mail]]

Hi Éric, all,

Thank you for the summary and next steps. Looks like a plan.

An attempt to address the first three point is available at:

https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-add-resolver-info&url_2=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt

We would appreciate if Paul/Warren/John/Orie/Roman can review and share feedback. We can adjust as appropriate.

For (4)"As the infourl can be hosted in a different server (or even organization) than the DNS server, how can the validity be ensured ? (e.g., there could be some discrepancies after a couple of years)"

We used to have the following in older versions of the draft,

      The
      client MUST validate that both the encrypted DNS server and the
      resolver information server are owned and managed by the same
      entity by establishing a TLS connection to the domain name in the
      URL and checking if the subjectAltName entry in the server
      certificate includes the name of the encrypted DNS server.  If
      this match fails, the client MUST ignore the resolver information.
      The URL should be treated only as diagnostic information for IT
      staff.

But was removed because the url is only for IT staff but more importantly because we received this fair comment (no need to over specify):

==
That looks like a lot of work required of the client for something it
itself is not interested in and a human looks at for diagnostic
purposes. Because of section 6 we know the infourl is authentic and
wasn't changed during transport. We kinda trust the resolver but we
don't trust the web server that the resolver tells us to trust. That
seems odd. It might also be annoying to arrange shared certificates
between a resolver and a web server.

As someone who might implement this in a client I'd rather not reach out
to a web server to check it's TLS certificate just so that I can show
additional information to the user.
==

Cheers,
Med

De : Add <[e-mail]> De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 5 avril 2024 13:11
À : [e-mail]
Cc : Paul Wouters <[e-mail]>; Warren Kumari <[e-mail]>; John Scudder <[e-mail]>; [e-mail]; Roman Danyliw <[e-mail]>
Objet : [Add] draft-ietf-add-resolver-info: next steps after IESG evaluation

You may be aware of the new status 'revised I-D needed' for draft-ietf-add-resolver-info after the IESG telechat of 4th of April 2024:
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/ballot/

I.e., more work to do by the authors and the ADD WG:


  1.  Adding context for the I-D, i.e., describing one or more use cases as some IESG members were unable to understand how this can be used (notably by OS and/or browsers/apps)
  2.  Can a human end-user make use of this information ? Again lack of context/use cases
  3.  This is also linked on whether this I-D is providing a client policy (or just hints). The former is out of scope of the ADD charter, but use case(s) could help to clear this issue.
  4.  As the infourl can be hosted in a different server (or even organization) than the DNS server, how can the validity be ensured ? (e.g., there could be some discrepancies after a couple of years)

It was proposed to either have a real ADD WG interim with the DISCUSS holders and the WG (and possibly other topics) or simply a *public* Webex (happy to organize it) with DISCUSS holders, authors, chairs (plus any IETF participants of course). My own take is that the I-D can progress over email during April and then have this interim/Webex mid-May for a final check.

All in all, with the number of requested changes, the I-D will most probably undergo another IESG telechat (and possibly another IETF Last Call)

The problem is solvable but will require more work.

Regards

-éric
____________________________________________________________________________________________________________
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.