Yes, I'll lift it once the change lands. On Thu, May 6, 2021 at 3:32 AM Sara Dickinson <[email protected]> wrote:
> 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]> > 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
