From nobody Mon May 3 12:35:40 2021 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06843A0B21; Mon, 3 May 2021 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr7ENo9P46_N; Mon, 3 May 2021 12:35:34 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEDE3A0B20; Mon, 3 May 2021 12:35:33 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id z14so5054331ioc.12; Mon, 03 May 2021 12:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=89ObGhmC9Jvwof6slQmEW4UC3fSbmA1UuNL9+XdHqYA=; b=Pq3wFx07lc9iY7fqmeonCnGKKkr/Fsk1BSnxVym7cLnqlJxF79FlesRNExdVrhR60U SbxdVYZut94keMxuY4lqKjXE+DF5gQJNPacFdxaxtCBxO2Ag0uZBrAPeyIkDA0JE9cyr kpfd/h/IuiYoPIJVXsFhg69nAeILx8DPqyFc8Ljbe45z5hbaqPzfmUDjmVSrr97wCXSj JXK+EEp0OSKQz5FWSx9WNZ1fYh8YdLzhjifozULX/FUXli9RN8huD3z2URbJmrcqp9d7 4QhV2BV8OlK98E0iOB3zPpEhSmC5r3SaJ+8mdPZatlpaqJWr6qA860e/o7qbRucUQFZ6 JONg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=89ObGhmC9Jvwof6slQmEW4UC3fSbmA1UuNL9+XdHqYA=; b=JcwKaEAncZeu16EB7JdYAhtKmOSaH0/v2KtcSliS4a+oVgMVEXrPRKBGR5ILAWrGSA q5QuXYkakF6gGBP/qQa5sOcP0rsT29759JMp+mMDDznnoMFA1cavalZS5h1QPldfmGqF jNaAM0t2PLuaPItJTaOFQhsGJxa9eh8etuUwMRguznoNWjJmeizg5PeC7Fqu2XrMTBns jVnTw7PT8e45vy8WZGJboCJkLQhsubkuVx4hgctB9IuyTwDs5nskEjs/tdeX7eCm1Q11 MpmgiU8GCzctreGETsCtNe/3p7m82thqN0W1Kf3vqU1Bzg90RG0VY0dNryAM1H8zhZtU drTQ== X-Gm-Message-State: AOAM5323E7PAaC0OL1UgtVzQDkhEx+w5pwuEMtmbdsK4+09qBHNSrcSh 8JM3RLtAKENtJ0f5H6Hqo2mX6YhrqmqZRzXRaPE= X-Google-Smtp-Source: ABdhPJyV4KInj7sJ4VZygKU8U5BmO6/YrFsWmw4anubdBBxic5StgEj+pk3iR5WnX4wNUx+HcZ1As3nzP/c8C+u9jfc= X-Received: by 2002:a5d:8ad2:: with SMTP id e18mr16046739iot.51.1620070532269; Mon, 03 May 2021 12:35:32 -0700 (PDT) MIME-Version: 1.0 References: <162006706040.3639.6179900042922096790@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Mon, 3 May 2021 12:35:29 -0700 Message-ID: To: Allison Mankin Cc: The IESG , Tim Wicinski , dns-privacy@ietf.org, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000096488b05c1721029" Archived-At: Subject: Re: [dns-privacy] Martin Duke's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:35:39 -0000 --00000000000096488b05c1721029 Content-Type: text/plain; charset="UTF-8" Excellent, Thanks for clarifying. On Mon, May 3, 2021 at 12:32 PM Allison Mankin 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 < > 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 >> > --00000000000096488b05c1721029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent,

Thanks for clarif= ying.

On Mon, May 3, 2021 at 12:32 PM Allison Mankin <amankin@salesforce.com> wrote:
<= div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-size= :small">Hi, Martin,

Sara is out of the off= ice for a day or two, so I will jump in.=C2=A0 We do not object to using an= ALPN code for DoT, and indeed, the message that ALPN should not distinguis= h between DoT and XoT drowned out the more important message that ALPN for = DoT had to be there.=C2=A0 A miss by the earlier reviewers.
<= br>
Allison


<= div dir=3D"ltr">
Allison Mankin,= Principal Architect, DNS-AEO Cloud Leader | Salesforce


<= /div>


On Mon, May 3, 2021 at 2:37 PM Marti= n 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/s= tatement/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/dra= ft-ietf-dprive-xfr-over-tls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In further discussions it became clear that the authors do not intend for X= oT
traffic to use an ALPN code at all. I'm afraid this may be a misunderst= anding
of previous guidance from TLS that XoT did not need its own ALPN code, but<= br> 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 i= n
Appendix A, that this creates difficulty for proxies, doesn't make sens= e 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<= br> verified identity, while IP ACLs merely prove that the bearer can observe t= he
path to the address. The former is much stronger than the latter, unless th= ere
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
--00000000000096488b05c1721029--