Re: [quicwg/base-drafts] Better articulate principles for ciphersuites (#2743)

MikkelFJ <> Wed, 22 May 2019 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B07FD120046 for <>; Wed, 22 May 2019 07:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.392
X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J1PU5jZBV9EH for <>; Wed, 22 May 2019 07:25:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E88DF120133 for <>; Wed, 22 May 2019 07:25:00 -0700 (PDT)
Date: Wed, 22 May 2019 07:24:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558535099; bh=kamqHBvc69wyg/381Yz7X5jTJnpW/9xbYRCsDTt2mrM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UWJ63gqda0RKl1PwYHmFGD/33HT1ct+uNTX0pJ2PvX5HZq0sXNeS8QyB1mZU0RXjy 2Skhnb6OI5aPaMpE5uBdh5g88xOjoxZclK45InhjpNebhKlxIs8TRyPN3l6xLfSYsC aCrUefqqsD++P4sB8pzjLLvahK8sUjqt85wOyUR4=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2743/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Better articulate principles for ciphersuites (#2743)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce55bbb88042_d653ff3a10cd96814579bc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 May 2019 14:25:03 -0000

I think I must be entirely missing the point, but I don't understand this:

> An endpoint MUST NOT reject a ClientHello that offers a ciphersuite that ...

Can you please explain how this works? For the sake of argument, TLS_AES_128_CCM_8_SHA256 is not supported, but the peer chooses to use it, and the TLS engine behind it all decides to support it via some configuration that the endpoint is directly aware of.

How does the endpoint now deal with header protection. Is it assumed that this is a TLS black box so it just magically works if the TLS engine has accepted the cipher via some useful API call.

If it is a TLS blackbox API call, how would that work with HW offloading?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: