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

[Kathleen Moriarty <[e-mail]>]

Hello,

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.

Introduction:

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
removed?

   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
protection.

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
   requirements."

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
recommendation.



-- 

Best regards,
Kathleen