Re: Quic: the elephant in the room

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 09 April 2021 23:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67F3A16B5 for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 16:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 nWDViWNeOCey for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 16:26:36 -0700 (PDT)
Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) (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 A0C6F3A16B3 for <ietf@ietf.org>; Fri, 9 Apr 2021 16:26:36 -0700 (PDT)
Received: by mail-yb1-f180.google.com with SMTP id l14so2110584ybf.11 for <ietf@ietf.org>; Fri, 09 Apr 2021 16:26:36 -0700 (PDT)
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=UVi+UA5xMlxy5Ro2S00SwCfSF9XZLqFpQGpm6ZHwVSU=; b=VJW6v+ZPvwGJ6cwI6iNwjf6v22XhFVuXWyJ11jBg3PjCrOLGkQupONnSa9VotcRi9Y 69DBGsdt5s0QtBbRFZVXshusgE2HWbVyfSRJEG5jYeE2ylYaI0x1/vi+Rl5L2XBZSSot 2KAHSPN6krG/TdGc+WnRS1O+ZE3F/Dd/0PKQQj51D2BhVMn7QEjxUJqvEj59JWkbI9ks 2Yo3jrYbermhQ5aPaTq52TRWA7CZn0fbtol7m1Pi8QJhnLEog3+QxBQvXa3g8V7dbmf0 Mv/nqSv08J3IsmT58Jk6xpHvt/WXTtkinIwOnqbhqdz9/HALujn02Mb/SnUyjE0VHaqX F0XQ==
X-Gm-Message-State: AOAM531LIcXa7PyKUHplh/Zp/BJ53sKxqdT3QvhGDcjK9V3144oJ8gX7 dp/u78Yi26cs6lnR6NBmPnEG1JEjJY5/wGGAozM=
X-Google-Smtp-Source: ABdhPJyaWiRPhNnM2oTRtlqRvNFAyyuUGs8goeTlsYnSzeoDERrmO363yk6mG8QiLaB4TG3ScgY7wKZJWRtjFcREx2Y=
X-Received: by 2002:a5b:d41:: with SMTP id f1mr23571078ybr.523.1618010795625; Fri, 09 Apr 2021 16:26:35 -0700 (PDT)
MIME-Version: 1.0
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com>
In-Reply-To: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 9 Apr 2021 19:26:23 -0400
Message-ID: <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com>
Subject: Re: Quic: the elephant in the room
To: Michael Thomas <mike@mtcc.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7535705bf927eba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/3nuUhqhkXLf5mD6J3Rw4hdgxpcs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2021 23:26:42 -0000

It is only a 'three packet handshake' if you ignore the off path
interactions with the DNS service. The timeout on DNS tens to be rather
smaller than that most would be comfortable with for crypto.

On Fri, Apr 9, 2021 at 7:17 PM Michael Thomas <mike@mtcc.com> wrote:

>
> I wrote a blog post about how something like DANE could be used instead
> of certificates for the TLS handshake to get it back to the original 3
> packet handshake. I know that isn't news to a lot of people, but the
> interesting part is that a Google could perform an experiment to see how
> well it works in real life just like they did with Quic and Spdy. Since
> Quic is all about making setup time faster, it seems like a pretty
> reasonable experiment since it would cut out 2 packets generally
> speaking since DNS can be cached.
>
> https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html
>
> Mike
>
>