Re: Éric Vyncke's No Objection on draft-ietf-httpbis-client-cert-field-05: (with COMMENT)

Thank you, Éric, for the review and ballot position. I've tried to reply to
your comments as best I can inline below.

On Thu, Mar 9, 2023 at 3:31 AM Éric Vyncke via Datatracker <noreply@ietf.org>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-httpbis-client-cert-field-05: No Objection
>
> 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-httpbis-client-cert-field/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
>

Wrong draft? :)


> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and one nit.
>
> Special thanks to Mark Nottingham for the shepherd's detailed write-up
> including the WG consensus *and* the WG discussion about the intended
> status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Use of normative BCP 14 language
>
> Yet another IETF draft using the normative BCP14 language in an informative
> document. No need to reply, this use of normative language is becoming
> usual
> :-( but I wanted to point it out.
>

> ### Section 2.4
>
> In
> ```Any occurrence of the Client-Cert or Client-Cert-Chain header fields in
> the
> original incoming request MUST be removed or overwritten before forwarding
> the
> request. An incoming request that has a Client-Cert or Client-Cert-Chain
> header
> field MAY be rejected with an HTTP 400 response.``` shouldn't the last MAY
> be a
> SHOULD ?
>

The important requirement is the MUST in the first sentence remove or
overwrite headers. Which is common practice (as far as I know) and meets
the security needs. The MAY is only noting the option the TTRP has to
reject such a request, which it may or may not want to do. MAY was intended
here and seems appropriate.


>
> About deployment, how will the system work with a client sending those
> headers
> via a TTRP that does not support those headers (i.e., do not remove them)?
> I
> would have preferred a kind of signature of those headers by the TTRP so
> the
> the origin server trust them. I.e., how can the last paragraph of this
> section
> be enforced ? It is (too) briefly discussed in appendix B.1 (which should
> be in
> the security section).
>

The security considerations attempt to explain what's necessary in a
deployment. Basically that a TTRP always sanitizes headers in requests and
the origin is unreachable other than via the TTRP. And all server side
participants have to support the headers/protocol. While appendix B.1
attempts to give some rationale for that being the approach to security.
Honestly not sure what else meaningful I can say here.



> ### Section 3.1
>
> Suggest to qualify the owner the dynamic table in `increasing the size of
> the
> dynamic table`
>

The first part of that sentence does indicate the origin server as such,
"An origin could mitigate the efficiency loss by increasing the size of the
dynamic table."


>
> ### Deployment of TTRP farms
>
> Please accept my lack of knowledge in HTTP... two questions:
>
> 1) are those headers sent in *each* HTTP requests to the origin or only in
> the
> first one ?
>

The header(s) are sent in each request from TTRP to origin.


>
> 2) AFAIK, TLS termination can be shared among a TTRP farm by sharing the
> TLS
> states, should also the states for those headers be also shared among the
> farm
> members?
>

Those are (I think) implementation/deployment details of the TLS layer and
honestly I'm out of my depth here but would assume client auth state would
be shared too in such cases.


>
> ## NITS
>
> ### Section 2.1
>
> Should quotes be used in `it will be sufficient to replace ---(BEGIN|END)
> CERTIFICATE--- with :` ?
>

The literals are wrapped in a <code></code> tag in the HTML and HTMLized
versions of the draft.


## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._