IETF Logo Mail Archive

Re: Stream0 Design Team Proposal

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 23 May 2018 21:20 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49612D7F6 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 14:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wl_vnLU3fWIH for <quic@ietfa.amsl.com>; Wed, 23 May 2018 14:20:09 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 A10EE1201F8 for <quic@ietf.org>; Wed, 23 May 2018 14:20:09 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id p3-v6so6324484itc.0 for <quic@ietf.org>; Wed, 23 May 2018 14:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=UY7othutBv8VHD2q99Fl/HKzhiO/e7EKIEa/B5R9YVg=; b=A0x/RrgI47lwcJ6XMvDRUjX8s2KQhYD3qFce7tAxqf3mbzrGTxzoQxjvzEeicvJp2A 4UMMfFGC2QAztc2Yr0AeLC8dl26hqH81RpiXZ8AbOh4nSST1xvQCHQ8ngJyDSJES4F9U OICZz9/0dkzlcZeNsNb3E5QteiHhrKRW1+9OcWeCNqpDpjoYkDK2cMgmYGMUzJzBc4Oh UPFhaZulYl35VvMeQGLWhdWpZ1RTfKHqQJl6iPtfoIgJWo0dHWlNaspbrhy2UbqaTSC3 3Oh3a3oBNjknF57KHNqzc51I6cNLt7ZixZs1xI540pQcQPuOF3cUvPBzs4iH9L+qMfrB i8zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=UY7othutBv8VHD2q99Fl/HKzhiO/e7EKIEa/B5R9YVg=; b=IUW/rOdAsPrwDHVOWyy8kdFsHsnbVEbZyIezOcq+9Fn7iYggwEEm8HB7Y7/IuzDnWY 2rwihLMtVtiqOSWJ33ml3+Iu5TqHYNLNWPlZJy+598YVzNXODXQITsmOic4yf6f7f9Qq FjNw8gpKIboSdizToT6AH/gXlkTuzmjG0pgvE1up1VKYJvWkwDpcAlmKYEsqb1q85BvM IrsRTRHm/xhDk8E73tJ7RuZVLt3eavW1ubAQo+m10f2O9q6wmzhi0qjX7PQ2q5HsMXC3 aa6hF9FjlnabvZktVcXZwD/6aTivT8BPRd5/f3bzBKs9cA2XSZLk2sSxsjfo1rYfnpA/ yacQ==
X-Gm-Message-State: ALKqPwdnZdIq8VuZOYIkl26ELUekSIMyP761V4oA3HqgCtJTzjKe0sil Qko0/AR449dXUWIc3I43oWbyU0wE8ugeOzl8/tU=
X-Google-Smtp-Source: AB8JxZrwydR7ixMSf+mBo/FPY2NMF7wV771qi+dlHzFjuVEZZGqzidk2ylDNImacFVYQKtzETUJn9gVCFLKq/dfocPw=
X-Received: by 2002:a24:186:: with SMTP id 128-v6mr6942630itk.25.1527110409057; Wed, 23 May 2018 14:20:09 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 23 May 2018 17:20:08 -0400
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CA+9kkMDiV8MHGSF1Uz0+mA5n12+tb-vcJzPSX1J8gPb-mmNXCw@mail.gmail.com>
References: <CAKcm_gM39_x+==WwYfb5qeiqB_qxdAt0ow69V+s_Jny3Ek_hDw@mail.gmail.com> <CA+9kkMC0a+HELyVvh+DtvkiorWmKkUQ346zt49Xfyd1zzZ780Q@mail.gmail.com> <CABcZeBP-BWwVAbPuT8rT12pMoNpWhD0qdOLB=-Lj=qrRrwq3ag@mail.gmail.com> <CA+9kkMDiV8MHGSF1Uz0+mA5n12+tb-vcJzPSX1J8gPb-mmNXCw@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 23 May 2018 17:20:08 -0400
Message-ID: <CAN1APdcq2zgsk-Y-w0YX8VnRq7S=6LvzrfX9HY0wbFYR+ojg-w@mail.gmail.com>
Subject: Re: Stream0 Design Team Proposal
To: Ted Hardie <ted.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Eric Rescorla <ekr@mozilla.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076faee056ce619b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cl5MMpLf0SRfMPNAeXtVf4mxxk8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 21:20:12 -0000

I believe you have misunderstood. In this document, there are no TLS
> records and TLS handshake messages are carried in CRYPTO_HS frames.
> Accordingly, padding is provided in the same fashion as QUIC ordinarily
> does, i.e., using PADDING frames.
>
> That's what I understood from the design document.  The point I'm making
is that this actually a substantive change to the padding structure that
was previously present (in TLS records), and the security analysis has to
take that into account, so it (and similar things) should be described.

As an example of things to consider, padding is probably a fair point. From
a practical perspective, padding could be seen as a pain from older crypto
formats that needs to be dealt with in TLS while the crypto primitives of
QUIC already has an answer to this problem.

But if TLS messages contain encryption primitives beyond what QUIC provides
in early handshake that assumption breaks down while the QUIC crypto is
still weak. For example concerning the encoding of key exchange parameters.
So at the very least it must be stated that this is not an issue and why it
is not issue.

v2.15.0 | Report a Bug | By Email