[Uta] MTA STS and HTTPS fetch timeouts

Daniel Margolis <dmargolis@google.com> Sun, 11 September 2016 11:57 UTC

Return-Path: <dmargolis@google.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78012B0E2 for <uta@ietfa.amsl.com>; Sun, 11 Sep 2016 04:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.508
X-Spam-Level:
X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 F7mzGkCmRdbf for <uta@ietfa.amsl.com>; Sun, 11 Sep 2016 04:57:07 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 292C612B0CE for <uta@ietf.org>; Sun, 11 Sep 2016 04:57:07 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id d205so41846356ybh.0 for <uta@ietf.org>; Sun, 11 Sep 2016 04:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ncSJwhemInhuKfl/D7zs/EbwjavFeaCwRZzW84s2z48=; b=gHP2rX9R6nlq3wkkLG/nzCjtiPbf4FTrnUBYT4eVTGMvLe7WhbCD8FfYCdII/z1rDf 1OomDtJ/WS4AJyrw2eVVzodqEBC0+vlXlve5ie+w8lMe8DxHkARKkbz1EnVscvRz0wA7 VfE1NN3ENzHh7nmHIQGZgEfjrZL+PuIDFKwFRYjHndFYcsx9OYxm4evSPG1EWDqRbLcs N9pzRTImmBxzQAr+Z7pE26v0Tdg9CLGVw4Ba6S2udyDtR5Ybujbt0mZAjsUIioRBoAyV J7+TPPZCfOrmko23IeAe8dojqyOEkPBwAwuPZv2sNlyHkVB+naL73he/YqzusIZPmL7p NtEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ncSJwhemInhuKfl/D7zs/EbwjavFeaCwRZzW84s2z48=; b=Uy9eBSsTek4fkglHqPzdkgypRZoqvceXOSikkQNPP/K4Hu6rD8aGr2rIOSLRSOEta3 ge1ufV22yIBYHxkWrpa2UneLFWC9AN6EBd4wDTmgdHmUt7fSgDhhoPGmUx+Gfh1e1wuJ gSFeMRL1yR+ZzDTMBE2faHTcqyHnB8rE463/Lqx/1XmqpkBS2BVhul9qy8c1XM9vHrW8 4VqbVASQydbgUOcP7pOnhf25Kj1V1IHg0oB1kBEhw4bDhrmSh0FjChYKzJS6aiyAn1Tv MJ3VIH7hbQQwdt11j750eQEeva81QN2I5DqBAFsdiNzZZyN40I36zY5Ny5hhL0vmYHeW Kaag==
X-Gm-Message-State: AE9vXwOSvVdKpVvKMrkB88q/FM2Xk6uU7k9VEWje48V6Io/BO2tPxgB8+Zj2z613dqctZnKQNaJc6xie8ChzxWqV
X-Received: by 10.37.94.138 with SMTP id s132mr13391651ybb.75.1473595026135; Sun, 11 Sep 2016 04:57:06 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Margolis <dmargolis@google.com>
Date: Sun, 11 Sep 2016 11:56:55 +0000
Message-ID: <CANtKdUcX=pTZsagVZ2v+j_09e_JEhzyK5Caa=Fd7YUweKGzmpQ@mail.gmail.com>
To: "uta@ietf.org" <uta@ietf.org>
Content-Type: multipart/alternative; boundary="001a11422e1613ddd8053c3a1443"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/rDJZoT7rQBbw1Gw_BjsYcPD6in4>
Subject: [Uta] MTA STS and HTTPS fetch timeouts
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Sep 2016 11:57:08 -0000

There was some discussion of this at IETF96: Should we be specifying
timeouts on the HTTPS GET during policy fetch?

I was looking at RFC 2821's timeouts for comparison (section 4.5.3.2):

"Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows..."

The initial 220 timeout is recommended to be 5 minutes. But then I took a
look at qmail and postfix, and if I am reading the docs correctly their
default timeouts on connect are 60 and 30 seconds respectively.

So this sort of makes me think that we should not bother to suggest
specific timeouts in the RFC, as I am not sure how useful they will be.
(Now, granted, the world has changed since RFC 2821 was written; it's
hardly a sign of failure if 15 years later your timeouts aren't quite the
norm!)

Any contrary opinions on this? And if so, any specific thoughts on what
those timeouts should be?

Dan