Hi Martin, Just to follow up, the following exchange was had with Ben, who also raised a DISCUSS on the topic of ALPN:
> As Allison already stated in reply to Martin, the authors agree that the > `dot` ALPN should be used here, in light of the recent discussions. > > In terms of updating the text, I believe what is required is to add a new > section at the start of section 8: > > "8.1 Connection establishment > > During connection establishment the ALPN token “dot” [ref] MUST be selected > in the crypto handshake.” (I'd s/crypto/TLS/, myself, but that's hardly critical.) > I believe the later text relating to XoT vs ADoT in section 8.6 is still > fully applicable, unless you see something you believe also needs updating? I also think that part looks fine. > I will also update the first paragraph of Appendix A to reflect that the main > reason for not using a separate ALPN (as originally proposed) is actually > because XoT is DNS and so should share the `dot` ALPN. Good catch; thanks! I hope this addresses your DISCUSS too? Regards Sara. > On 3 May 2021, at 20:35, Martin Duke <[email protected]> wrote: > > Excellent, > > Thanks for clarifying. > > On Mon, May 3, 2021 at 12:32 PM Allison Mankin <[email protected] > <mailto:[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] > <mailto:[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 > <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/ > <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy > <https://www.ietf.org/mailman/listinfo/dns-privacy>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
