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

[Martin Duke <[e-mail]>]

Yes, I'll lift it once the change lands.

On Thu, May 6, 2021 at 3:32 AM Sara Dickinson <[e-mail]> 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 <[e-mail]> wrote:
>
> Excellent,
>
> Thanks for clarifying.
>
> On Mon, May 3, 2021 at 12:32 PM Allison Mankin <[e-mail]>
> 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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>