From nobody Thu Apr 29 11:50:07 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A363A134D; Thu, 29 Apr 2021 11:50:02 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WTpEjT2FHCLT; Thu, 29 Apr 2021 11:49:58 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 F351B3A1363; Thu, 29 Apr 2021 11:49:57 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id l4so101379392ejc.10; Thu, 29 Apr 2021 11:49:57 -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=eN0bXTE+ogXZ5vc2WzSPGM9iNej9a95Af8rE9fg7Q54=; b=Zw147AT3kKeUKPn0rd3w5AfXDnu0C/UFCniawEYbh0DOcnx3NEks2Disep4+w2PLHl psu4yitjejXhVhOEMDtX9t6h0ZKqngIvi7MfGarejzxMUDOCb/Vi+FC8vic2US4feO/x tpOc3McrzYg0WWXGMb88fjlAle5+BxAXjyauDdgvndSAS+9a4Y3SOFA6Wl7zgUGv1+TX NUSITF8UDjFJb1yQgbrKa+8M2b+gNtx27tMcxdvcHh+pB5ZqGI7kOHbB0Zx2UfVxM3dF hnFFxkDqVOXHG+1tcIMovFNiY4zCYQuhYxaSLn84mo2wp5MZjOuTZC0TBgAH/xypTFsS Xuqg== 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=eN0bXTE+ogXZ5vc2WzSPGM9iNej9a95Af8rE9fg7Q54=; b=LHaXvS4LICmOnnS5PuG7AI7XYcwc/0/CupvVrllRmbDFCy9IAcBLwLqOO7r9MusmNg kfsVL071DLLXwH8UJW56lBmYIEwnVHSU5/ikc7PjTj+TJM9HkTVMIQXqIwI0ySbqtA7x FvMAZocG6582bjOj9JSNCYOjboVNreY9gmCtRVHz4SVut7TRDtAekVtYmIWZsmX/H/2A BNI8F6drTlq6wgTnEtYam8up5Yj3N7xFgiaaJzF7zKmmdIprrjobRVDgPEPmefvd3PI8 B8XJNU9iMZUiL+GPDLJ/11OicvqtEBACub5Mfo/R9sc1qQX0MCclds9eWR8IkRs7p+8b D/PQ== X-Gm-Message-State: AOAM5318AAPL4ZZtzDUxmzPvOEYxfi5L26/e0M1dCWgpxb+g38lUUUCW BeL74g5MMzlXK1Lwu2z8Gd+YjAhYIUi2V9RplwYXYdwz X-Google-Smtp-Source: ABdhPJxDStuSaO7YW90k5cKbh3JcRIrqcjykwTnY+n2fmnOcl3tyhG9YKN8Vfe3Aq4QueB/KmQbrTuopj38C1rMw/+s= X-Received: by 2002:a17:906:f41:: with SMTP id h1mr1389578ejj.399.1619722191198; Thu, 29 Apr 2021 11:49:51 -0700 (PDT) MIME-Version: 1.0 References: <161921129877.20343.10624609154750488813@ietfa.amsl.com> <034F6C49-0195-4FAF-9EF2-1E39E809F902@sinodun.com> <7d8fa1d2-ef1a-4ed3-b660-955248a4ec63@www.fastmail.com> <753E5DAA-37C6-4F82-829D-29DA5458C1DB@akamai.com> In-Reply-To: From: Allison Mankin Date: Thu, 29 Apr 2021 14:49:40 -0400 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "dns-privacy@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d75e0405c120f5a9" Archived-At: Subject: Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 18:50:03 -0000 --000000000000d75e0405c120f5a9 Content-Type: text/plain; charset="UTF-8" Hi Ekr, As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108 meeting was very strong to take it out, including quite strong statements from you along the lines that distinguishing between XoT and DOT was an incorrect usage of ALPN. I understand that the perspective changed since IETF108 (that WG discussion was at the end of July 2020) and that communications were not wide enough for us to know about it in March when the WG moved the draft to WGLC, Directorates Review, and IETF LC On Thu, Apr 29, 2021 at 14:25 Eric Rescorla wrote: > Probably not, but I agree with MT. > > The general idea here is that any given protocol trace should only be > interpretable in one way. So, either you need the interior protocol to be > self-describing or you need to separate the domains with ALPN. I don't > believe that either the IP ACL or mTLS addresses this issue, and in fact > arguably mTLS makes the problem worse because it provides authenticated > protocol traces which might be usable for cross-protocol attacks. > > -Ekr > > > On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich 40akamai.com@dmarc.ietf.org> wrote: > >> > No new protocol should use TLS without ALPN. It only opens space >> for cross-protocol attacks. Did the working group consider this >> possibility in their discussions? >> >> I don't believe that message has been made as public as it should be. >> >> _______________________________________________ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d75e0405c120f5a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Hi Ekr,

As Sara wrote, the spec had ALPN. The = WG consensus during the IETF 108 meeting was very strong to take it out, in= cluding quite strong statements from you along the lines that distinguishin= g between XoT and DOT was an incorrect usage of ALPN. =C2=A0

I understand that the perspective changed since IETF108 = (that WG discussion was at the end of July 2020) and that communications we= re not wide enough for us to know about it in March when the WG moved the d= raft to WGLC, Directorates Review, and IETF LC

On Thu, Apr 29, 2= 021 at 14:25 Eric Rescorla <ekr@rtfm.com= > wrote:
Probably no= t, but I agree with MT.

The general idea here is t= hat any given protocol trace should only be interpretable in one way. So, e= ither you need the interior protocol to be self-describing or you need to s= eparate the domains with ALPN. I don't believe that either the IP ACL o= r mTLS addresses this issue, and in fact arguably mTLS makes the problem wo= rse because it provides authenticated protocol traces which might be usable= for cross-protocol attacks.

-Ekr

On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich <rsalz=3D40akamai.com@dmarc.iet= f.org> wrote:
>=C2=A0 =C2=A0 No new pro= tocol should use TLS without ALPN.=C2=A0 It only opens space for cross-prot= ocol attacks.=C2=A0 Did the working group consider this possibility in thei= r discussions?

I don't believe that message has been made as public as it should be.
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.= org
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d75e0405c120f5a9--