IETF Logo Mail Archive

Re: Quic: the elephant in the room

Michael Thomas <mike@mtcc.com> Sat, 10 April 2021 18:13 UTC

Return-Path: <mike@fresheez.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 ECC9A3A1774 for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 11:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 6suNEs4fg2uA for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 11:13:26 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 73A283A1787 for <ietf@ietf.org>; Sat, 10 Apr 2021 11:13:26 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id q10so6228251pgj.2 for <ietf@ietf.org>; Sat, 10 Apr 2021 11:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=NBEGfLyqSzQRCLFs4ZxKHxvur5/aOnPPyOQNE4jlefc=; b=Of1U7YSHTKeUlMe9cJect+thYx2l/fiXAPvddiKsznNU4XdROtjkIKcAdE0qg9a357 bNSHzwGbiKbvdNZUFy/HrbbikH/h4hmNTK/hI3IWYY+GyDhp/nBXMR16TXghO0/x6lbZ p9zbldV0c4Vxfoqj4myTQmmoLF+jHnO/3qhiERz3bKIbOll58yEPPPa88dwjyXH8K4Fv bvuPN7DzozC25Ewg6vkCB3LG8c/FAW4Euy7RDr33iOtXfEXwJ1lYVKEMMh0CMKz9ketZ 8Cyg3+QdY+3CTfdOY7QQhW+uWyBO5OXvooRR1W+ZHtTabqNed1Aq+MDFdOFXOhfl7w4I lcYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NBEGfLyqSzQRCLFs4ZxKHxvur5/aOnPPyOQNE4jlefc=; b=QeGdG9n9qa4F+WDb9pn8F81zkdOk2TFrmTmHSiV7JEv6Tib18+tgmjR6VOylOlZPex 1lwXyRrjRhhqH3JLNfBKCQXABGK6W2WAqJPuap51hoCMDUAlteL8nDUmWb+/cndBsdU+ wtL5zUemMwVPfxHo3VYILtfgwu+3COMW5vZAVNbtqdGfSQtJgF3pHz4YnQNhCZKg2rUP K2HoOEQH/YZ+7+aiPIm5lp051K6lGGBykwywP81mpbzc35FgQCGOHv5sLl9JN0WQwpda nIAhTG7vyFHzqNXgkp1pOQOZb94UaYBJyI/0HFYufDvdmOf78nIpwEJEQSfjWfhX1sUA 4tNw==
X-Gm-Message-State: AOAM533uoR70EimO0AypBOyqYKu0e/LyIcJDAaq0mIRVN8zUDxDKStak rTwXrCeGlq0BlgctTBXZ/SnAWUgjvzQQVA==
X-Google-Smtp-Source: ABdhPJytla0D2g5wJsDwairsG/gP+32wGNGeO+jQE1MboNuSSP/GEhM4Gb9Q4uCaydm908J/2rmA2A==
X-Received: by 2002:a62:d043:0:b029:241:ee7b:6ee9 with SMTP id p64-20020a62d0430000b0290241ee7b6ee9mr17398404pfg.76.1618078404782; Sat, 10 Apr 2021 11:13:24 -0700 (PDT)
Received: from mike-mac.lan (107-182-38-56.volcanocom.com. [107.182.38.56]) by smtp.gmail.com with ESMTPSA id q8sm6176292pgn.22.2021.04.10.11.13.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Apr 2021 11:13:24 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: Ben Laurie <benl@google.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com> <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com> <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <b8195e39-0dfa-d877-cdff-66febd087764@mtcc.com>
Date: Sat, 10 Apr 2021 11:13:23 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A73D3A418AC0CF323588FD3D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fnGzn6eAc_uicmC3ho9KOTCIX24>
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: Sat, 10 Apr 2021 18:13:31 -0000

On 4/10/21 2:29 AM, Ben Laurie wrote:
>
>
> On Sat, 10 Apr 2021 at 00:35, Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>
>
>     On 4/9/21 4:26 PM, Phillip Hallam-Baker wrote:
>>     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.
>
>     I don't see why it can't be long lived, but even normal TTL's
>     would get amortized over a lot of connections. Right now with
>     certs it is a 5 message affair which cannot get better. But that
>     is why one of $BROWSERVENDORS doing an experiment would be helpful.
>
>
> When I was designing Certificate Transparency, Chrome ruled out any 
> side channel communications requirement during handshake. Given that 
> DNS is required anyway, perhaps this would be different.


It occurs to me that it would be possible to return the DANE RR's as 
additional RR's in the address query so that it is always the case that 
it is in cache for the sake of the handshake. Or it could possibly be 
the other way around: you query for the DANE RR and get back A/AAAA 
records as well. I don't know how this might work in real life, but it 
seems theoretically possible. That would satisfy the no "side channel" rule.

Mike

v2.23.0 | Report a Bug | By Email