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 26479120A43 for ; Tue, 12 Nov 2019 10:24:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 DGnAVovETOi4 for ; Tue, 12 Nov 2019 10:24:26 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 3FEDB120946 for ; Tue, 12 Nov 2019 10:24:25 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id t5so18947975ljk.0 for ; Tue, 12 Nov 2019 10:24:25 -0800 (PST) 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=D08vZjThllY0RvkhROl5KrWAY9XaJwDECW/4zxxQrMU=; b=aG1c9YgwKELpy/0c5iHv6T6yLLwBAWZk2Uq94ihd4aDt7mZ+Hq3D9UzvBVxxDu+tlD ZtDdAqz3X8Lquo5Lik50yiNkn2R4U8ACB/MiA6Etq+X3OI+kpMtVK6Me7hEoI2L2jkQG 3YYGDOa9rMoDVo2Q0vlBtaAThWmBXzSPdh8PHPlMIzWY25HYgz2T+x1fcKhBSEnR1537 EWrudErii58F/q/He+WwuneCScILj0QUSYXHz9OS5WTRLrjdeiIAKiQUJ30zqjDFjlCX wN7zfDuKX06y00tNp2n9eB5kzKqCPpbRWoZY3UZ/7HabHnIcDxLOGk/skSzBOgBg8cxb 1P5w== 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=D08vZjThllY0RvkhROl5KrWAY9XaJwDECW/4zxxQrMU=; b=rBIYlb7DjZDyqD0ssrh2bPfVUEDUdHjUMeQjv1C+/ly/59dHAmD5igeXQvQsoF+Fdn NURWuZ8l775uAqM8ChQkzPUn39EPgNfBYgfmXBmlH3iPI05HQsXAthZSBAcOaH8tFRH2 ibsGmmwgZMB+cdtig+NBVfL6Q4Sl7WplyzUeEIlfynX3/Hq90yh/iVqRJdgSQZHYZ5f4 MdJ8zy/ePY6kCcM1VVoU+ZBIqkuTkvIDVw+j8XaK8cJ307SWV4VGy9cp/6/UNyonct2l 9qb2wF+RjAjO8q/MGLCs1uTs/+XMpxTk4fMWuFKuvm9xnrHJb91KH3BjnHuqVR44BVjJ B7YQ== X-Gm-Message-State: APjAAAWy/jwrQZxfUPl/wxo2xKE+nW1VMQlyV5U/tUKh98kOlOvNDHUl shKWoc8kmMLmUQ1yvGCVL78GKQYn8BWDa0wdgmlUmw== X-Google-Smtp-Source: APXvYqx/HxDfT58y1lKK/crabvbKHhLVJazWAszL4y3x3N66TTH2rVe1T3dbQyL5aM+ig/DVDUBVkKNHkEGQQLtjuvg= X-Received: by 2002:a2e:7301:: with SMTP id o1mr13437111ljc.16.1573583063503; Tue, 12 Nov 2019 10:24:23 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Tue, 12 Nov 2019 10:23:46 -0800 Message-ID: To: Rob Sayre Cc: "Kaduk, Ben" , "tls@ietf.org" , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086698605972a5b0c" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 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: Tue, 12 Nov 2019 18:24:31 -0000 --00000000000086698605972a5b0c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 9:56 AM Rob Sayre wrote: > > > On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla wrote: > >> >> >> On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote: >> >>> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: >>> >>>> The one concrete one that I remember (and can't attribute to the >>>> HTMLized version dropping stuff) is RFC 7030 only in the header. >>>> >>>> I guess we can check what we want to do to DTLS as well, as RFC 6347 is >>>> listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself >>>> confusingly claims in the body text to "update DTLS 1.0 to work with TLS >>>> 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically >>>> we update in 6347. >>>> >>> >>> I think the text in question is the last paragraph of RFC 6347's >>> Introduction: >>> >>> "Implementations that speak both DTLS 1.2 and DTLS 1.0 can >>> interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of >>> course), just as TLS 1.2 implementations can interoperate with >>> previous versions of TLS (see Appendix E.1 of [TLS12] for details), >>> with the exception that there is no DTLS version of SSLv2 or SSLv3, >>> so backward compatibility issues for those protocols do not apply." >>> >>> This draft says "don't interoperate" in this situation. >>> >> >> I don't typically get too exercised about what appears in these metadata >> headers, but I don't actually think this updates 6347. The statement there >> is still true, we just tell you not to do it. >> > > Well... I think the clearest definition of "updates" is in RFC 2223: > > https://tools.ietf.org/html/rfc2223#section-12 > > "... e.g., an addendum, or separate, extra information that is to be added > to the original document." > Yes, and I don't think that this does that. -Ekr > thanks, > Rob > > --00000000000086698605972a5b0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 12, 2019 at 9:56 AM Rob S= ayre <sayrer@gmail.com> wrote= :


On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :


On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre <sayrer@gmail.com> w= rote:
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
The one concrete one that I remember (and can't = attribute to the HTMLized version dropping stuff) is RFC 7030 only in the h= eader.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

I don't typically get too exercise= d about what appears in these metadata headers, but I don't actually th= ink this updates 6347. The statement there is still true, we just tell you = not to do it.

Well... I t= hink the clearest definition of "updates" is in RFC 2223:

https://tools.ietf.org/html/rfc2223#section-12

"... e.g., an addendum, or separate, extra inform= ation that is to be added to the original document."
=

Yes, and I don't think that this does = that.

-Ekr


thanks,
Rob

--00000000000086698605972a5b0c--