[TLS] AD Review of draft-ietf-tls-tls13

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Sat, 13 May 2017 02:11 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9933212EBC6 for <tls@ietfa.amsl.com>; Fri, 12 May 2017 19:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8OZroHmGcFMH for <tls@ietfa.amsl.com>; Fri, 12 May 2017 19:11:14 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 D6C15129B26 for <tls@ietf.org>; Fri, 12 May 2017 19:08:18 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id q125so18098398pgq.2 for <tls@ietf.org>; Fri, 12 May 2017 19:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hfDOzwYpxTAPM5vjodUUQSsSlkIAZ5ttCxFEZLF+i4U=; b=YWTPZYPDQuVonCT5CyUSd+rONOw1tak/1BC0ON7XRA3jcNcC7MUzP2g7KgogtxSYuO K/rquM5fjRRn10I4evlwBkh5NoaBgPL2FpakNV4NFJjjGaJP6uIA82RxN5qvge9SCsnM ABuWYweZmug2+F90tUaF2por4XdczGRJlreXjPc2xov3iR25RDcRJEfhEu68/hTGHUmz lgGIhtXIr/FbB8T7uV7cFDlKRq/KwUM1QnFbGJnXfZX66c2PnSOFu4Iz733DpcIPkWJq jVQ3aaxh1KiNH9ZYS0Y5agvg2xX6oBhX3DPWcGhmIkbIuHC60rS9GtvmX4Jf6NeZB46v KXTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hfDOzwYpxTAPM5vjodUUQSsSlkIAZ5ttCxFEZLF+i4U=; b=UH2LCmXhbXQ9XIsh8C/7HTMhbLXRsGH5BNiLWxUPA8Uv2Ra4tt2QrRXYzHQ7Tn6VHk ssajTmJMeJSZdx/OO2M4jqLSeb+qpnLixsOfiSKUydELAAJfwJ0q7kPbpl1FScHOIF7i oc5KMCnRGWzI62PZ8e+reMdALm+MElw6pLqL6tFJ5ZmUyDlSRS81Mi2k2Qb53eUo3Mbz vO9zwxHGBkAMQyC9Zra35S9eog52iDrnCYYCe0wTAc1YPR5jt6HWGzdVnyglWSKnEsjK 1Z7AzwjRfrWIGRPx7E/KV/jGGvEBK+LAP2/fKSMWLNz1/OrqE06Z5Oumn3fN9HoIV7Qn NLdQ==
X-Gm-Message-State: AODbwcAq5+xLd165LSzmlEl2I9joek2iHA0aREIr30YVqb46eF+klwJ2 h4O9fY5uuml50XLw3KUbpse+XygRMM5Y
X-Received: by with SMTP id p68mr3803527pfk.55.1494641298216; Fri, 12 May 2017 19:08:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 May 2017 19:07:37 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 12 May 2017 22:07:37 -0400
Message-ID: <CAHbuEH4PXU5569RYJ1uPcriQruCewmRrXUU3MVBZ+GtpyceiAw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nKLHMTVJ-h2OQy69a6i5BP-yJmw>
Subject: [TLS] AD Review of draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 13 May 2017 02:11:16 -0000


Thank you all for your work on TLS 1.3.  The list has still been
active on a few topics, so I want to see how that all settles out in
addition to the questions I have on the draft below.


1. Since this is going for IETF last call soon and there has been
review of the draft (workshop, but is clearly ongoing from the list
discussions), should the first sentence of the Introductions be

   DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
   significant security analysis.

2. Section 4.2.9 - There should be some mention or pointer to the
security considerations and recommendations on replay attacks for
0-RTT from this section.  I don't see any mention of discouraging
0-RTT from being a default and think that would be good for
applications that use TLS expecting replay protection.  I know the WG
agreed to keeping 0-RTT, but I think it's very important to make the
issues clear and not have this come up as a default in any
implementation/deployment for unsuspecting users.  Part of this will
get down to implementation specifics and configuration options, but
offering some guidance is important. This document will be read by
many, not just developers.

Since clients have to initiate 0-RTT, the user has to have some idea
that replay attacks are possible and accept that risk.  If this were
used in web applications, then all servers that don't want to see
replay attacks (banking, etc.), would have to have explicitly reject
this usage.  As such, there needs to be very strong guidance to this
point. Would it be that browsers configure this as a default or
something users would have to turn on or just leave it as an option
(with warnings) for a client to enable?  Would servers have clear
information in configuration files (or setup) about the implications
of this option for those that don't read the RFC and are not aware of
this problem?

Most of this discussion belongs directly in the security consideration
section, but there has to be mention of it with a reference from
section 4.2.9.  It's not just an API consideration, this is for
developers, implementers, and users of the protocol. Many other
protocols use TLS beside HTTP and do so with the expectation of replay

While Appendix C1 is helpful, I don't think it's enough.  It's
disappointing to see a protocol with a replay attack written as a
prominent feature of TLS 1.3 and little discouragement from use.

3. Section 4.2.

   "In general, detailed certificate validation procedures are out of
   scope for TLS (see [RFC5280]).  This section provides TLS-specific

I don't see an explanation of why it is out-of-scope.  The reference
is just to RFC5280, which seems odd.  I would expect the reference to
be to something that explains why it is out-of-scope.

RFC7525 has use of RFC5280 as a best practice for server identity
verification and revocation checks for TLS 1.2.  Is this just for TLS
1.3?  Why?
RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
explanation here would be helpful since this seems to be a departure
(or reference to the changes section).

If RFC5280 remains out-of-scope, this section should fully describe
the certificate validation process for TLS 1.3. I think you need to
list out everything that should be checked as opposed to just
including one example:

   "Also, if some aspect of the certificate chain was
   unacceptable (e.g., it was not signed by a known, trusted CA), the
   server MAY at its discretion either continue the handshake
   (considering the client unauthenticated) or abort the handshake."

4. Section 6.2 Error Alerts

In addition to sending the error, I don't see any mention of the error
being logged on the server side, shouldn't that be specified?  Logging
errors (at least in debug modes when needed) provides valuable
troubleshooting information and many applications don't do an adequate
job of logging, so I think it's important to call that out here as a


Best regards,