Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Watson Ladd <watson@cloudflare.com> Wed, 12 February 2020 23:41 UTC

Return-Path: <watson@cloudflare.com>
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 7613F12002F for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 15:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.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 YMCTBd2172Fh for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 15:41:25 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 A607A120019 for <tls@ietf.org>; Wed, 12 Feb 2020 15:41:25 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id b7so3927580qkl.7 for <tls@ietf.org>; Wed, 12 Feb 2020 15:41:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7jxFLbxyfNh20A3NBblVm9g04k9CtHsbGyl8h8pWl9I=; b=wvJyeDcXxq9naRGzsk2pqGmWkGqMYICHAy1YJ70IgBU0wcrn+w1Kmxq7aL2iKY6o3C qMOF0mSxPS7VU5XA1ncuwPmrxvdl6fOlejv5JM/NToGxHWxsZN1PFz0Xh4BWiRYP9Mc3 wQeBnEtUOmX5enbfhOvfDJzskC4iBySigk1iY=
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:content-transfer-encoding; bh=7jxFLbxyfNh20A3NBblVm9g04k9CtHsbGyl8h8pWl9I=; b=AkR+yR+tvajohiWXYGKjiMYWAQPRzBhYI9uqLwRz9sXbmJMLHMkrc9LjKHT2cdAdeC HtLspWeQpWPVlmW3S34vX8zBdjNrzTZjvNf100saPrmutxbn1V09bk+xLhXohwh9LFLK vIKaIIxEOOlpKRYm0wV3QogWqfa6ARFFweIhEJro1vWCTSKtjxD0IUNivsu+FU7GKGr+ UNA/e+/bGrGxoYwHh/jTz8C3WFoZNGMmRTwBeEIbyADLcu3spBPYRVfWlGyrkf0O5nOQ y9xUjXyps2h+L+skTdAE1b+DKlrGicuWoPfAYRbxOqVrztIiHgCcuH4ZV414pwOTd0Xl l0hg==
X-Gm-Message-State: APjAAAWlSK5EpVT9xXU7vDspPErWc9+L2z+JMuJpvKs4DD4TQvlt/Zhj wzKIVf4tibloNaTV5wOEMFNLY24r3Olb8DLfI6eELw==
X-Google-Smtp-Source: APXvYqz9PmeOzGEcFWS04hNrPJllYh9eLfESIa+9SeV7RSCtppmQ9moAbqUWEs6XKn48nFIolaH37DT0YWc9qKrUBnU=
X-Received: by 2002:a37:9407:: with SMTP id w7mr7962064qkd.55.1581550884399; Wed, 12 Feb 2020 15:41:24 -0800 (PST)
MIME-Version: 1.0
References: <CAFBh+SRAJAbviyrcQM2PjztumAH565i4-ui28OQ-pCJE9nePJg@mail.gmail.com> <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <D4DBD81C-6555-4EBD-AA77-49905CB88B22@icloud.com> <b91df74c-cec7-44a3-9224-6240553af223@www.fastmail.com>
In-Reply-To: <b91df74c-cec7-44a3-9224-6240553af223@www.fastmail.com>
From: Watson Ladd <watson@cloudflare.com>
Date: Wed, 12 Feb 2020 15:41:13 -0800
Message-ID: <CAN2QdAFjDbeMHd_SsgFj8LWGxqgPOHv-S0GJU0=48fdiQ2EQ3g@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: Carrick Bartle <cbartle891@icloud.com>, tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Fnyo1l5aWn2jZnTIFkYQbs5Z_VM>
Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2020 23:41:27 -0000

On Wed, Feb 12, 2020 at 3:23 PM Martin Thomson <mt@lowentropy.net> wrote:
>
> On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
> > I'm brand new to the IETF, so please forgive me if I'm totally off base
> > here, but my understanding is that Informational RFCs are explicitly
> > not recommendations (let alone mandates)?
>
> This would of course be information, but my comment was about phrasing.  This document comes off as being quite prescriptive, where it doesn't really need to be.  Absent actual algorithms, it's just a set of guidelines.  That's reflected in its Informational status, but it would be better if the verbiage also reflected that more clearly.
>
> To address Stephen's comment at the same time: I think that we can publish an RFC on this before the competition completes if it is just a framework.  That might in fact make standardizing the one true composite scheme easier.

What's the point of composite schemes after the NIST competition
finishes? The reason imho to have composite schemes now is to be able
to do deployment experiments where the security of the postquantum
scheme doesn't negatively impact the confidentiality of the
transmitted data. Obviously after a scheme has significant
cryptanalysis thrown at it, the value of a composite decreases because
the scheme is considered much more secure, and so the composite adds
much less security and still has costs.

>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls