IETF Logo Mail Archive

Re: Alissa Cooper's Yes on draft-ietf-quic-tls-33: (with COMMENT)

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 04 January 2021 22:10 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 B3CD63A0407; Mon, 4 Jan 2021 14:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 wcPVI_UPI5Xp; Mon, 4 Jan 2021 14:10:25 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 899953A03F8; Mon, 4 Jan 2021 14:10:24 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id h205so68051843lfd.5; Mon, 04 Jan 2021 14:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MqmEeF2KmclZ67p48BvT4lnKrDRbWT9ekhB4oxNLmO0=; b=Sea9k7JAXbnCMTbhcVxUjYQ2Ms3XAL08SoTX6wn773li8S4NtKsxkeFBZSJLCqvKNZ QdFNJpaup4Fpamr8jYI05ATEnW5AqfrWl1gqpIwhiAge6Tq5Ev6Yw+8qUU6USFifdpFk UTKleVjgMH8okLgmTckFd9AAm7c1JPcRldoM+5TlqM90bqJ4FDv2ocnQqjK8ZRrp9oW4 3tGZGmSX5eTMqq89TdWDPuQJdX4zsSkd+SQsTKGorjEiEikQCVXtg58gXHHiCts7lMhG n+xuxEMNcjrRVj+8DOcKeg8BXBM8xSO3o2bZ5GQDr30CnCmlhHsDU0Y41c5Qrc2oeaf3 72/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MqmEeF2KmclZ67p48BvT4lnKrDRbWT9ekhB4oxNLmO0=; b=M0AxKHhC1gdszGQbelHJkwMptKdSbm52AqpUxyUh2KgJvUWvCYbT6qwA6DzxVb6d6k XUdiE4DZzcDGAQEywTtkhqSoQnSMVXyuSHiFBbWf7fuMtfEN4WVnX5qbpxjhQSYgt9BL W/mJ/O6YvVd7TPxTFdv/ALRGpXDKpKfSJOi4vszzfluryRJSLHUj6A6RiwJlQqLf1Jik f/m0La7BAlYOcSpgHTnWTaTZOnUqAJ5lJYA8IkpsTVmebD+IwcfzCdlQr3pOR+nkdh4Y uApJevtOgtMiHLral+4h9fzg35yefv91YA2pa8TpaC+c36CwJxd0d6PBdziE8qVsky4c Wrcg==
X-Gm-Message-State: AOAM530IGO0JFtyqU2ZcpBy2V1TzYOFfoQ822hywVSpeQJpy9QyFImX4 rYbrmhftxb/7U7rZCL3XipUJ3LqUHyLQEPVH
X-Google-Smtp-Source: ABdhPJxZQHea8MeLWuqCzX2Z+OAkFwzWgvKMbcFxYpcRwW/HSfcrrS1H+XqJn4sIJc/Dr9eFAzcPrQ==
X-Received: by 2002:a05:651c:228:: with SMTP id z8mr38567790ljn.310.1609798222341; Mon, 04 Jan 2021 14:10:22 -0800 (PST)
Received: from [192.168.8.100] (109.58.155.143.mobile.3.dk. [109.58.155.143]) by smtp.gmail.com with ESMTPSA id l205sm7391216lfd.284.2021.01.04.14.10.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2021 14:10:21 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Message-Id: <C42B2EEE-BA96-4D41-A9B4-450849D7CD8F@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_27E68946-66D9-49EA-B961-F4F46790378D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Alissa Cooper's Yes on draft-ietf-quic-tls-33: (with COMMENT)
Date: Mon, 04 Jan 2021 23:10:20 +0100
In-Reply-To: <160979684778.26454.8927762465877033100@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, Mark Nottingham <mnot@mnot.net>, quic-chairs@ietf.org, quic@ietf.org, draft-ietf-quic-tls@ietf.org
To: Alissa Cooper <alissa@cooperw.in>
References: <160979684778.26454.8927762465877033100@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tHZaUYJChtHhR2CqAGZUEcVNcps>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Jan 2021 22:10:27 -0000

below

> On 4 Jan 2021, at 22.47, Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-quic-tls-33: Yes
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for a clear and complete document.
> 
> Section 17.4: For someone coming to this new, it might not be obvious why
> requiring the disabling of the spin bit on a fraction of connections is useful.
> This may be worth a sentence of explanation.


If it is not clear by now, this is because a user that disables a spin bit would look suspicious, similar to the police looking for cell phones that have been turned off during the commiting of a crime. If everyone randomly disables the spin bit, this becomes less obvious.

I think this because the QUIC document has been trying to not motivate every single decision for the sake of brevity, although the text got quite long anyway.

Some of these explanations have moved to the manageability document. Maybe a reference to that document would be in place?

https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-using-the-spin-bit-for-pass

To avoid making these connections identifiable based on the usage of the spin bit, it is recommended that all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.


Mikkel

v2.23.0 | Report a Bug | By Email