From nobody Thu Apr 29 12:03:37 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 A59C83A15C3 for ; Thu, 29 Apr 2021 12:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 WoYTMDYYvdoq for ; Thu, 29 Apr 2021 12:03:25 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 A708B3A14C2 for ; Thu, 29 Apr 2021 12:02:43 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id l21so23024114iob.1 for ; Thu, 29 Apr 2021 12:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJoPvyn9PVMUge5LvwMz5prE7c21uC2z01RqjxaCGPc=; b=FNdMoWRmIGkc+4w/0TUgt7HkSOPdzR/1Jw6hVtzFDgdSJyqCCz1QMubtIZnaG80IGN i8wZkl9DwrSh3pkWT912ZEJtlSzenit0Inn/PnOjP2d3oydBCUtte+nx9sCicBJA0XlL rWzzPlgalbus/BhL5q6C6zKf8kJvM1mhmTr21uu1diMzEwRs+1D5jZmOLZKTLYBtg54h UamWzDzWPYR+UAHAHjm5iRAC2/Qh1PtBzp734qEBMUY6r6s3PQrg4DrpE65rA+mshfGR 4DKMxk9L8fdly0u2Z2QEnzkaD1iYogYgMRspLDG13DFTH1Ye7zDM6D2yyc92OuvYhusi /R9A== 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=EJoPvyn9PVMUge5LvwMz5prE7c21uC2z01RqjxaCGPc=; b=RHQbRI+Vno0EO1m1PAXVLckz4070+5Hzd3WKzi2uSlEJ7UoZXLKqC7PSKP3ZiTIlcb psKskkrbGzjwonbt8mHGgrmxZCqsCkyk9QrteDEG5EY5rO0kIpynHfHZkhiQnURcCvRT s7fTVYD6y8RC3dXtCmATHp9MPgjtQ0ixOvwjFGf2AR3i2XtEyf861U068hGbeOjnNllx mPoNkx1wcXIBRLSAOMVgPtLkOjucPxBcAz6wkwEX+1kPOYj0day3Z83d+9i7CN/LPREC g36X4ifaQaBY7ZAWtYMdiQAyA5BxnezxVespiDfG8/QSonMtVYKkGn3pI4opace6qPbp jqzA== X-Gm-Message-State: AOAM5314dmq2QRVlKAsylORnUZeKLk+P7089bV7KM+eeZyGUbMSTACTg o8LnB+FlTLpA2JXgpdH7PlMPG5A8g/avZJVOwxNIdA== X-Google-Smtp-Source: ABdhPJxxyrM37WlwZ+zR5vgRuATl0Sw09WaKMQJ1835JFciROHj6tx+/R3fqPyG/K6V8MR/oL4Fm1lUxcevZukjXamg= X-Received: by 2002:a02:cab3:: with SMTP id e19mr456149jap.64.1619722962382; Thu, 29 Apr 2021 12:02:42 -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: Eric Rescorla Date: Thu, 29 Apr 2021 12:02:06 -0700 Message-ID: To: Allison Mankin Cc: "Salz, Rich" , "dns-privacy@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cec5a205c121237d" 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 19:03:36 -0000 --000000000000cec5a205c121237d Content-Type: text/plain; charset="UTF-8" On Thu, Apr 29, 2021 at 11:49 AM Allison Mankin wrote: > 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 don't have the message you are referring to at hand, so I'm not able to respond to that. However, I don't believe that an ALPN is needed to distinguish XoT from DoT because there is no confusion between the protocol traces of XoT and DoT. However there should be an ALPN to distinguish XoT and DoT from HTTP, SMTP, etc.IOW, this protocol should use ALPN="dot". 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 > I don't think anyone is saying that the WG somehow did something wrong procedurally, merely that this is a defect that ought to be corrected prior to publication. -Ekr 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 >> > --000000000000cec5a205c121237d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 29, 2021 at 11:49 AM Alli= son Mankin <allison.mankin@gmail.com> wrote:
Hi Ekr,

As Sara wrot= e, 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 th= e lines that distinguishing between XoT and DOT was an incorrect usage of A= LPN.=C2=A0

I don'= ;t have the message you are referring to at hand, so I'm not able to re= spond to that. However, I don't believe that an ALPN is needed to disti= nguish XoT from DoT because there is no confusion between the protocol trac= es of XoT and DoT. However there should be an ALPN to distinguish XoT and = DoT from HTTP, SMTP, etc.IOW, this protocol should use ALPN=3D"dot&quo= t;.
=C2=A0

I = understand that the perspective changed since IETF108 (that WG discussion w= as at the end of July 2020) and that communications were not wide enough fo= r us to know about it in March when the WG moved the draft to WGLC, Directo= rates Review, and IETF LC

= I don't think anyone is saying that the WG somehow did something wrong = procedurally, merely that this is a defect that ought to be corrected prior= to publication.

-Ekr


On Thu, Apr 29, 202= 1 at 14:25 Eric Rescorla <ekr@rtfm.com> wrote:
Probably not, but I agree with MT.

The general idea here is that any given protocol tra= ce should only be interpretable in one way. So, either you need the interio= r protocol to be self-describing or you need to separate the domains with A= LPN. I don't believe that either the IP ACL or mTLS addresses this issu= e, and in fact arguably mTLS makes the problem worse because it provides au= thenticated protocol traces which might be usable for cross-protocol attack= s.

-Ekr


On Thu, Apr 29, 20= 21 at 7:26 AM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 No = new protocol should use TLS without ALPN.=C2=A0 It only opens space for cro= ss-protocol attacks.=C2=A0 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
--000000000000cec5a205c121237d--