Re: [TLS] [Technical Errata Reported] RFC8446 (6145)
Ben Smyth <research@bensmyth.com> Thu, 30 April 2020 08:02 UTC
Return-Path: <research@bensmyth.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B698A3A0AEF for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 01:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=bensmyth.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 rZ5fYnBfjtzi for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 01:02:10 -0700 (PDT)
Received: from 2.smtp.34sp.com (2.array2.smtp.34sp.com [IPv6:2a00:1ee0:2:5::2eb7:902]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909103A0AE7 for <tls@ietf.org>; Thu, 30 Apr 2020 01:02:09 -0700 (PDT)
Received: from smtpauth2.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 2.smtp.34sp.com (Postfix) with ESMTPS id 9ECB65816D8 for <tls@ietf.org>; Thu, 30 Apr 2020 09:01:49 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588233709; bh=Hm7eV1bnHpChnEKuwMqbIQa8HLwf0r8V0EVOtIXuZ+k=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=Mji9DY0phJHBRNY3o/1b8dgrnGqpjGq0VqIP4zafQ34i+CoEjaz39SwWdVRiRRk3T tE0G/eA01KOifQozcImoqgBq40x4cmDHD3IdiztFsIqZiETryoVXFaKCdb+3h4cnXj qRdoRdvXnhsq09LaFVzYt6H4WSPFkVBUb5dqxn8g=
Received: from mail-ej1-f54.google.com ([209.85.218.54]:33244) by smtpauth2.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <research@bensmyth.com>) id 1jU48j-0001fi-93 for tls@ietf.org; Thu, 30 Apr 2020 09:01:49 +0100
Received: by mail-ej1-f54.google.com with SMTP id s9so3934239eju.1 for <tls@ietf.org>; Thu, 30 Apr 2020 01:01:49 -0700 (PDT)
X-Gm-Message-State: AGi0PuahULaP7hsk0TgijPdblInBSEvGGzt4KWn5mKapIFTBmNukzcd1 nhLrxLEflcBd0vm0+SPkH8PUy/9qh2Me/nlhraA=
X-Google-Smtp-Source: APiQypIF0yOaehqgxZp4PtTlyQBp+L5GASKCwqBlzWdYJipLDRCBhlMwqCtt39RPv8RanI5r1g8EuPzFzezK28p30KQ=
X-Received: by 2002:a17:906:2410:: with SMTP id z16mr1587953eja.1.1588233708912; Thu, 30 Apr 2020 01:01:48 -0700 (PDT)
MIME-Version: 1.0
References: <20200429094723.A87CBF40756@rfc-editor.org>
In-Reply-To: <20200429094723.A87CBF40756@rfc-editor.org>
Reply-To: research@bensmyth.com
From: Ben Smyth <research@bensmyth.com>
Date: Thu, 30 Apr 2020 10:01:21 +0200
X-Gmail-Original-Message-ID: <CA+_8xu2sE4bY9oKtVOvWy9PfRUFCm+rjyOc9Ai_q21L2N_jaNQ@mail.gmail.com>
Message-ID: <CA+_8xu2sE4bY9oKtVOvWy9PfRUFCm+rjyOc9Ai_q21L2N_jaNQ@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ekr@rtfm.com, rdd@cert.org, Benjamin Kaduk <kaduk@mit.edu>, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com, tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000a47ac05a47d7a50"
X-Authenticated-As: research@bensmyth.com
X-OriginalSMTPIP: 209.85.218.54
X-34spcom-MailScanner-Information: Please contact the ISP for more information
X-34spcom-MailScanner-ID: 9ECB65816D8.A6BE9
X-34spcom-MailScanner: Found to be clean
X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00)
X-34spcom-MailScanner-From: research@bensmyth.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/crgLWfM4oMiQ8YCSVz4BpE2NQHE>
Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (6145)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2020 08:02:14 -0000
> Original Text > ------------- > When a PSK is used and early data is allowed for that PSK > > Notes > ----- > I couldn't find restrictions that forbid early data for a PSK. Explaining > where such restrictions > could exist would be useful. E.g., PSKs might be associated with data that > forbids early data. > That's an oversight on my part: The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data The client may only send early data when permitted: When a PSK is used and early data is allowed for that PSK, the client can send Application Data in its first flight of messages. Servers don't appear to be forbidden from consuming early data when keys don't permit them to. Perhaps I've missed that too. Or perhaps it doesn't matter: If a client does something they aren't supposed to, then they're only compromising their own security.
- [TLS] [Technical Errata Reported] RFC8446 (6145) RFC Errata System
- Re: [TLS] [Technical Errata Reported] RFC8446 (61… Ben Smyth