Re: [dns-privacy] Martin Duke's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)

Hi, Martin,

Sara is out of the office for a day or two, so I will jump in.  We do not
object to using an ALPN code for DoT, and indeed, the message that ALPN
should not distinguish between DoT and XoT drowned out the more important
message that ALPN for DoT had to be there.  A miss by the earlier reviewers.

Allison

Allison Mankin, Principal Architect, DNS-AEO Cloud Leader | Salesforce

On Mon, May 3, 2021 at 2:37 PM Martin Duke via Datatracker <noreply@ietf.org>
wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-dprive-xfr-over-tls-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/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> In further discussions it became clear that the authors do not intend for
> XoT
> traffic to use an ALPN code at all. I'm afraid this may be a
> misunderstanding
> of previous guidance from TLS that XoT did not need its own ALPN code, but
> could simply use the DoT ALPN since the messages are distinguishable on the
> wire.
>
> To not use an ALPN at all violates best TLS practice. The reasoning given
> in
> Appendix A, that this creates difficulty for proxies, doesn't make sense
> to me.
> We can talk about it in the telechat.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - There ought to be a warning somewhere that mTLS verifies that the CA has
> verified identity, while IP ACLs merely prove that the bearer can observe
> the
> path to the address. The former is much stronger than the latter, unless
> there
> are more mechanisms built into the ACL than are obvious from the text here.
>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>