[Int-area] Re: Mohamed Boucadair's Discuss on draft-ietf-intarea-proxy-config-11: (with DISCUSS and COMMENT)

[[e-mail]]

Re-,

Thanks Tommy. Your reply helped me as well see that the intended applicability scope is even more that I got when first reviewing the document. This claims to cover discovery of any random proxy (including proxies that are widely deployed out there such SIP proxies, etc.). I’m concerned as this is adding duplicated functionality, not backed by real operational problems. I’m more concerned that we are adding a duplicated mechanism for the discovery of these mechanisms using a tool that is not deployed today  (PvD).

I will update my ballot to ABSTAIN.

Cheers,
Med

De : Tommy Pauly <[e-mail]>
Envoyé : jeudi 7 mai 2026 20:26
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-intarea-proxy-config-11: (with DISCUSS and COMMENT)



Hi Med,

Thanks for providing concrete examples of the text you’re thinking of. That helps a lot! I did just submit a review there (https://github.com/tfpauly/privacy-proxy/pull/354#pullrequestreview-4246685596) and I think that both of the current suggestions are not correct. I don’t think those limitations about proxy types or local network connectivity do apply here.

Best,
Tommy


On May 6, 2026, at 10:31 PM, [e-mail]<mailto:[e-mail]> wrote:

Hi Tommy,

I sent you a PR with some minimal changes to address some of my concerns: https://github.com/tfpauly/privacy-proxy/pull/354.

I won’t insist more on the DNS dependency part and the other items in the comments block.

Thank you.

Cheers,
Med

De : Tommy Pauly <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 1 mai 2026 00:52
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-intarea-proxy-config-11: (with DISCUSS and COMMENT)



Hi Med,

Thanks for your reply. Responses are inline.

Best,
Tommy



On Apr 30, 2026, at 2:52 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Tommy,

Thank you for the follow-up.

Given there was many threads, I was waiting to see some of these discussion settle.

Please see inline.

Cheers,
Med

De : Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>
Envoyé : jeudi 2 avril 2026 05:16
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-intarea-proxy-config-11: (with DISCUSS and COMMENT)


Hi Med,

Thanks for the review. Responses inline!

Best,
Tommy




On Apr 1, 2026, at 9:32 AM, Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Mohamed Boucadair has entered the following ballot position for
draft-ietf-intarea-proxy-config-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Tommy, Dragana, and Yaroslav,

Thank you for the effort put into this document.

Please find some points for discussion below:

# IETF LC Comments

Unless I’m mistaken, there was no discussion/follow-up to the comments received
during IETF LC.

I have delayed my review with the hope to see a new version.

I’ve responded to the various reviews today. Some of the changes were made a while ago in the working copy, but the email responses had not gone out. The plan is to publish a revision with the changes from IESG feedback as well.
[Med] ACK.

# Applicability Scope & Target Deployment

I appreciate that the document includes the following:

  Additionally, this document outlines how these mechanisms might be
  used to discover proxies associated with a network (Section 5).
  However, this approach is not described for the purpose of generic
  proxy discovery, and requires careful security considerations for
  clients to limit usage to trusted scenarios.

However, it is not clear the target protocols and the conditions under which
this can be used.

The examples are more about HTTP, but still there is no explicit discussion
about target deployment. Please consider clarifying the scope and target
deployment.

That case is not about a different “target protocol” but a different base source of configuration information.

In all cases, the PvD Additional Info (the JSON dictionary) is fetched over HTTPS. It contains descriptions of various proxies (SOCKS, HTTP CONNECT, MASQUE).

What’s left is how to know which PvD Additional Info to fetch — from what name.

There are two options:
1. A proxy name/address that the client is already configured to use (by the user or a profile or similar)
2. Based on the RA from the network using the mechanism exactly as described in 8801

Section 5 is about that #2 case. This is fine to use if there is explicit configuration to allow it, but doing this automatically is not what we want to recommend. It can be allowed by policy if the device gets some configuration to say “on your trusted corporate network use the proxy you get from the RA PvD”.
[Med] The explanation is crystal clear. However, there is still an assumption about the nature of the proxies. This is not about discovery of random proxies. Having some few words early in the document would help here.

As part of the responses to the other IESG feedback, the sentence "Additionally, this document outlines…” has been removed. The content of section 5 is here:

https://www.ietf.org/archive/id/draft-ietf-intarea-proxy-config-13.html#name-discovering-proxies-from-ne

I’m not clear on exactly what change you’re suggesting regarding “not about discovery of random proxies”. Can you suggest particular verbiage to clarify what you’re asking for?



# Partial Solution

CURRENT:
  The mechanisms defined in this document are intended to offer a
  standard alternative that works for URI-based proxies and avoids
  dependencies on executing Javascript scripts, which are prone to
  implementation-specific inconsistencies and can open up security
  vulnerabilities.

However, the alternative design proposed in this document does only provide a
partial solution as it relies on RFC 8801. This can be seen as encouraging
fragmented solutions with the inherit implications on deployment (including
selection when several mechanisms as supported by a client: which one has
higher priority, etc.).

The document lacks a discussion about operational constraints/limits, including
a discussion about how IPv4/IPv6 feature parity can be provided.

I don’t understand your comment here; could you help clarify? How is using the JSON dictionary defined in 8801 a “partial” or “fragmented” solution? This solution does add support for URI-based proxies and avoids dependency on Javascript, as it intends. There also is not a difference in support for IPv4/IPv6 here.
[Med] It is partial as you rely on the availability of RAs.

RAs are not a requirement for using this mechanism, given that this mechanism is focused on taking cases where you start with a known proxy name and discover more information and other proxies. None of that requires RAs. Only section 5 (linked above) even mentions router advertisements. Even when looking at that specifically, RFC 8801 covers PvD identifier association with IPv4 networks (https://www.rfc-editor.org/rfc/rfc8801#section-3.1-3.8)

Also note that discovery bootstrapped via DNS is covered: https://www.ietf.org/archive/id/draft-ietf-intarea-proxy-config-13.html#name-discovery-via-https-svcb-re

I do not view this as a “partial” solution, and I don’t think we want to call out anything in the document that would tell people to not use this and prefer WPAD instead =)

Again, if you are thinking of a particular piece of text to suggest, please suggest it.



# DNS Dependency

CURRENT:
  Presence of this SvcParamKey, named pvd indicates that the proxy host
  supports PvD discovery via the well-known PvD URI ".well-known/pvd"
  defined in Section 4.1 of [PVDDATA].  The presence of this key in an
  HTTPS or SVCB record signals that the proxy's PvD Additional
  Information can be fetched using the "https" scheme from the proxy
  host on port 443 using the well-known path.  The presentation and
  wire-format values for pvd SvcParamKey MUST be empty.

How this works for private proxies for which there is no record in the public
DNS? Wouldn’t this be problematic especially in cases where resolvers supplied
by the PvD access network are not used to resolve the name?

If a proxy that is configured by name on the client device requires private network access, such as a corporate VPN, then the device must have the VPN and fetch the PvD Additional Information over the VPN. That would be expected and correct, since it could not use the proxy it was configured with otherwise.
[Med] Can we remind that in the text and have any impact (or lack of) use of DNS resolvers other than those provisioned by an PvD domain?

There’s no need to use resolvers that were received via explicit PvD discovery, etc. I don’t think it makes sense to necessarily call out any VPN or private DNS case here — it comes down to a bit of a tautology: if you configure a proxy with a name, you need to be able to reach that name to be able to look up the additional proxy information; you also need to be able to look up that name to use the proxy.

Unless I’m missing something the usefulness of these attributes depends on the
underlying setup. These assumptions (and implications) should be described.

# CIDR

CURRENT:
  The subnets array includes IPv4 and IPv6 address literals, as well as
  IPv4 and IPv6 address subnets written using CIDR notation [CIDR].

CIDR is normative for subnet attribute. Please move that ref to Normative.

Thanks, addressing that here:

https://github.com/tfpauly/privacy-proxy/pull/339/changes



[Med] ACK.

# Inappropriate Uses of Key Words

Several parts of IANA section include normative language such as in:

CURRENT:
  New assignments in the "Proxy Information PvD Keys" registry will be
  administered by IANA through Expert Review [RFC8126].  Experts are
  requested to ensure that defined keys do not overlap in names or
  semantics, do not contain an underscore character ("_") in the names
  (since underscores are reserved for vendor-specific keys), and have
  clear format definitions.  The reference and notes fields MAY be
  empty.

The use of key words is not compliant with
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/.
Please fix. Thanks.

Sure, fixing here: https://github.com/tfpauly/privacy-proxy/pull/346
[Med] ACK. Thanks.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Upgrade

CURRENT:
  Using this mechanism a client can learn that a legacy insecure HTTP
  proxy that the client is configured with is also accessible using
  HTTPS.

Can’t this be done by leveraging existing SVCB records (i.e., without the pvd
keys)?

# Mixing Protocol and Operational considerations

There are several places where deployment considerations are mixed with
protocol matters. For example,

CURRENT:
  Note that all proxies that are co-located on the same host share the
  same PvD Additional Information.  Proxy deployments that need
  separate PvD configuration properties MUST use different hosts.

Better to have these grouped into a dedicated Operational Considerations
section.

# Mandatory keys

CURRENT:
  PvD Additional Information is required to contain the "identifier",
  "expires", and "prefixes" keys.

Please consider citing rfc8801#section-4.3

# Discovering proxies from network PvDs

## I suggest to place this section under an Operational Considerations Section.

## BTW, can this part be expanded to elaborate which specific aspects need more
exploration and how the lack thereof is a hinderance for deployment:

CURRENT:
  Further security and experience considerations are needed for these
  cases.

## Please consider reminding that OSP cons in rfc8801#section-5 apply.

# [IANA_PVD] and [IANA_SVCB]

CURRENT:
  This document registers two new keys in the "Additional Information
  PvD Keys" registry [IANA_PVD].

  ..
  IANA is requested to add a new entry to the "DNS SVCB Service
  Parameter Keys (SvcParamKeys)" registry [IANA_SVCB]:

I think both should be listed as Informative, not Normative.

Cheers,
Med






____________________________________________________________________________________________________________

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.


____________________________________________________________________________________________________________

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.

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