Excellent, Thanks for clarifying.
On Mon, May 3, 2021 at 12:32 PM Allison Mankin <[email protected]> wrote: > 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 < > [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy >> >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
