[TLS] TLS 1.3 comments
Yaron Sheffer <email@example.com> Mon, 17 August 2015 10:22 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD81A9034 for <firstname.lastname@example.org>; Mon, 17 Aug 2015 03:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Y0IPf7r7Dh for <email@example.com>; Mon, 17 Aug 2015 03:22:07 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 E52481A9031 for <firstname.lastname@example.org>; Mon, 17 Aug 2015 03:22:06 -0700 (PDT)
Received: by qged69 with SMTP id d69so89842246qge.0 for <email@example.com>; Mon, 17 Aug 2015 03:22:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=hl7oUZh0qtFW1ZHC/BTFczljUm9f+GbXz87hbaMM5PE=; b=kaI5q5/SM4UgNfDixbX9xo44AO1UvhUQoNKlsE3CsLNkc2I6ZFXvwgwDKAWBSGFnEs 4FfDgRaQG56Vv0bGRJbM7XFneSQrsgHpT630pMK4fZgkh2fGcY//w3C9q4NqGBGFdWvN YCBlcrt/g90Fb5gFxHvdqGCJfRMWWCcW2BgH7D174Fsz4/xWfLYKF06IeSeeaG3t+wRv yD+JPcN4Nw9fzagsQ6w+l7o8ubUSGQygRZyAaqIRYyVaSUHYnSHiZC5x8xdlkepsDTSc FHSU1mqdyEfdTErmWAo5/j7W5anCFimJ9jB0YzeJzbUeGL6oOLKE0GTbq2t+TwSbx+Hz /a0g==
X-Received: by 10.140.237.70 with SMTP id i67mr1083886qhc.48.1439806926137; Mon, 17 Aug 2015 03:22:06 -0700 (PDT)
Received: from [10.71.63.158] ([22.214.171.124]) by smtp.googlemail.com with ESMTPSA id k89sm7986337qgk.36.2015.08.17.03.22.05 for <firstname.lastname@example.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 03:22:05 -0700 (PDT)
Date: Mon, 17 Aug 2015 06:22:04 -0400
From: Yaron Sheffer <email@example.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
Content-Type: text/html; charset=utf-8
Subject: [TLS] TLS 1.3 comments
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:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2015 10:22:08 -0000
- The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes".
- 6: the definition of session contents should also contain identities. The client's identity, if authenticated by cert, or the peers' PSK identity.
- "Access denied" alert: the description starts with "a valid certificate was received", but it may also apply to PSK.
- Handshake_failure alert seems to be synonymous with insufficient_security (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate one of them?
- Typo: "via a certificates".
- Server Configuration: how does the client know to whom the configuration applies? For example if I connected to "*.example.com" (a wildcard cert) and now I connect to "srv.example.com", should I use the stored configuration?
- 6.2.2: typo: has complete.
- 126.96.36.199.2: it's time we specified that the recipient (in this case, the server) MUST verify the received ECDHE public key (see RFC 6989). This is mentioned in Appendix D but only for modular DH.
- 188.8.131.52: "identifier" should read "identity".
- 6.3.4: "Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted." - this doesn't work, because we might come up in the future with an extension that needs to be unprotected. Maybe we can say "SHOULD" instead.
- 6.3.7: expiration_date: there's no reason to force/assume time synchronization between client and server. This can just as well be relative time (number of seconds since negotiation), like ticket_lifetime_hint.
- 6.3.10: "If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication ... Also, if some aspect of the certificate chain was unacceptable ... the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or send a fatal alert." This is strange. There is no way for the client to understand that the server considers it unauthenticated and modify its behavior accordingly. A warning alert would be appropriate here, even if in general we don't like warning alerts.
- Typo: main-in-the-middle
- "Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. " This is not precisely true, because the other peer may not know that you're not verifying the exchange, and so it might behave differently.
- D.1.2: do we really need to worry about version rollback to SSLv2? I suggest to remove this section.
- [TLS] TLS 1.3 comments Yaron Sheffer
- Re: [TLS] TLS 1.3 comments Ilari Liusvaara
- Re: [TLS] TLS 1.3 comments Hubert Kario
- Re: [TLS] TLS 1.3 comments Martin Thomson
- Re: [TLS] TLS 1.3 comments Yaron Sheffer
- Re: [TLS] TLS 1.3 comments Viktor Dukhovni
- Re: [TLS] TLS 1.3 comments Martin Thomson
- Re: [TLS] TLS 1.3 comments Dave Garrett