Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13

Dhruv Dhody <dd@dhruvdhody.com> Fri, 14 October 2022 17:24 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97E3C1524B7 for <pce@ietfa.amsl.com>; Fri, 14 Oct 2022 10:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy65WPyPca29 for <pce@ietfa.amsl.com>; Fri, 14 Oct 2022 10:24:23 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C2EC14F718 for <pce@ietf.org>; Fri, 14 Oct 2022 10:24:23 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id k6so5635255vsp.0 for <pce@ietf.org>; Fri, 14 Oct 2022 10:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XqgHqrywguaYLOH77Riyatr0HI2O4QINigbNDwlfCLI=; b=FtT0WVYqHR1pcJThst7A9dgd6ZoitMx1AROBn3SNM6irBHqPNpfFaVnZrT65VPspM3 RiY81ydiinf+9KGIougrPQwBNpPR1OoK9lqJZY92QjF2H+twGZCeRK7+s4l9JjyyHShy 5Txit1M8P+ag9n7mE0eXpnBT7RpdWxp3hgwARVfKRFSEGbKiee35ruxyUEZBf6Q42IhF 5g+hfD0+131eriZOjTGx7KG26M00EREShQyEW8FO62LcdOcMj6HYbBg0F4CguNdOrvGZ qiMNGqr7vQEuxNb4bV9PmRwvHt+BNfZaolsTjlZ+eR7sYfTnNG0Um2PItSEv5nrIvH8+ v+1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XqgHqrywguaYLOH77Riyatr0HI2O4QINigbNDwlfCLI=; b=KgzxbrckA7zljJbmO2LQVfx3fb1EPzOSFUAiXTrqBfsAzkrM3rPx2VMGCWMPY9d+BE qSt6A6a8KPknZXIyRx+vrgt2kUt8jmuAFta4iHrj5YENgPqUH0hLA7cKFptp8AjNpixK 3wd8Ri04Qan2Kmwh+YpHUP5FRlY4pL9tWdGOb44FZmZ8/coGu3kUGxTI9WlSRMB9l0cP C2RW/1/ZyEguljhnx60uiTXI5D+6oqqs2TWUR8dlU6zbV/gWNiuY71pSLgER9WoTG1/K HCPBccdgt+EtnTMw5HCROtj2uOUTWjHVvvYbiEwo5ipCMLDc5YFOeEDgoJ+97hK+k8KW LJbg==
X-Gm-Message-State: ACrzQf2rHDIKytYc+/siulnCjCnNfvmK0TYYVS4z7u/BwXVjMhFLBzQs BwUnrRlyGUEQdoSYNDFjciGkTpAEdzBR6gaSyk1vdg==
X-Google-Smtp-Source: AMsMyM5T0dwy/xAqvL+jWNwl2dBY6jzfpN+sdSF6E/nY3u6CvP9KtndN+HvloKrv5LrDVb4+zHif2X5ef9DDeaoiSw0=
X-Received: by 2002:a67:c297:0:b0:3a7:5f0c:54c4 with SMTP id k23-20020a67c297000000b003a75f0c54c4mr3901199vsj.76.1665768262570; Fri, 14 Oct 2022 10:24:22 -0700 (PDT)
MIME-Version: 1.0
References: <069901d8df4c$a17ef430$e47cdc90$@olddog.co.uk> <50D4CB57-CA03-4E40-861B-CAC16B291533@vigilsec.com> <072e01d8dfd0$ddc88fd0$9959af70$@olddog.co.uk> <97602738-057B-4483-BC1D-46D0EAD46D24@vigilsec.com> <073f01d8dfda$e83a5070$b8aef150$@olddog.co.uk>
In-Reply-To: <073f01d8dfda$e83a5070$b8aef150$@olddog.co.uk>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Fri, 14 Oct 2022 22:53:46 +0530
Message-ID: <CAP7zK5amurs5MLG9PpdbRE2xbRNSpA+qnrOBFkKtoFSs=P6E+Q@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: Russ Housley <housley@vigilsec.com>, draft-dhody-pce-pceps-tls13@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000091a9c105eb01e5bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/n81MZ2vK_Hms8pBnl9S5CduL0A4>
Subject: Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2022 17:24:25 -0000

Thanks Russ & Adrian!

I have updated the working copy with this commit ->
https://github.com/dhruvdhody/draft-dhody-pce-pceps-tls13/commit/05027a5251a0290bd8c960b2c03aa2b13ae01c79


Dhruv

On Fri, Oct 14, 2022 at 8:10 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Wfm, thnx
>
> -----Original Message-----
> From: Russ Housley <housley@vigilsec.com>
> Sent: 14 October 2022 14:58
> To: Adrian Farrel <adrian@olddog.co.uk>
> Cc: draft-dhody-pce-pceps-tls13@ietf.org; pce@ietf.org
> Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
>
> Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST
> ...
>
> Russ
>
> > On Oct 14, 2022, at 9:28 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> >
> > Thanks, Rus.
> >
> > What I didn't express well (don't write emails when you have been doing
> hard
> > concentration work for 9.5 hours straight!) is that it is possible to
> think
> > that this work is telling all PCEP implementations what they must do. I
> have
> > spoken to one person who was very worried that this was updating what
> their
> > existing implementation would need to do.
> >
> > I'm clear that the intention is to describe what PCEPS implementations
> that
> > support TLS 1.3 are supposed to do, and that doesn't have any knock-on
> for
> > other work, but, yes, a very simple addition of "of this specification"
> > makes all the concerns go away.
> >
> > Cheers,
> > Adrian
> >
> > -----Original Message-----
> > From: Russ Housley <housley@vigilsec.com>
> > Sent: 14 October 2022 13:46
> > To: Adrian Farrel <adrian@olddog.co.uk>
> > Cc: draft-dhody-pce-pceps-tls13@ietf.org; pce@ietf.org
> > Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
> >
> > Adrian:
> >
> > TLS 1.2 does not have early data, and the algorithm registries arefor TLS
> > 1.2 and TLS 1.3 are separate, o I do not think there is confusion.  That
> > said, I do not object to adding the phrase.
> >
> > Russ
> >
> >> On Oct 13, 2022, at 5:42 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> >>
> >> Hi,
> >>
> >> Thanks for kicking off work to get PCEP able to work with TLS1.3.
> >>
> >> This is important.
> >>
> >> However... :-)
> >>
> >> I think it would be helpful to clarify that statements about what
> >> implementations must or must not do (etc.) should be scoped as
> >> "implementations of this document." That is, you are not constraining
> PCEP
> >> implementations in general, and I don't even thing you are constraining
> >> TLS1.2 PCEP implementations. Well, if it was your intent to do
> otherwise,
> >> you really need to be clear that you are updating the base specs, but I
> > hope
> >> you're not.
> >>
> >> Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a
> >> normative reference. I understand that the long term intention is that
> > that
> >> draft will obsolete RFC 8446, but it seems to be moving slowly (if at
> all
> > -
> >> it has expired). I think that implementers wanting to apply TLS1.3 to
> > their
> >> PCEP code will want to pick up TLS1.3 implementations that are stable
> > (i.e.,
> >> based on RFCs). Now, by the time this draft gets to completion, it is
> > quite
> >> possible that 8446bis will have completed, and the draft can be updated
> to
> >> reference it and pick any additional points it makes. On the other hand,
> > if
> >> this draft makes it to the RFC Editor queue before 8446bis is complete,
> I
> >> don't think you'd want it to sit around, and a subsequent bis can be
> made
> >> when 8446bis becomes an RFC.
> >>
> >> What do you think?
> >>
> >> Cheers,
> >> Adrian
> >>
> >>
> >
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>