Hi Kathleen,
Thanks for your review.
> 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.
Yeah, we'll remove this.
> 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.
I agree this should figure more prominently. I'm working on a PR
for this now which addresses at least some of these points, so
I'll hold off on responding to this for now and maybe we can
revisit once that PR has been completed.
> 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.
In general, TLS's policy (dating back to TLS 1.0) has been that the
job of TLS is to carry the certificates and other authentication
material but to leave it up to other parts of the system to
interpret them. It's been a long time since that decision was made,
but from my perspective, there are a number of major reasons:
1. Most of PKI processing (path construction, etc.) is generic and
not specific to TLS. What is specific to TLS is:
* How to indicate what your PKI capabilities are
(see, e.g, S 4.2.4 and 4.3.2)
* How to stuff the PKI material into the protocol
(principally S 4.4.2)
* How to determine whether a given certificate is suitable for
use in TLS 4.4.4.2 and 4.3.2.1).
So we want to outsource the generic PKI part
2. It matches the software architecture that people often use,
which is to have a TLS stack but separate PKI validation. For
instance, Firefox uses NSS for TLS but moz::pkix for
validation. Similarly, Chrome uses BoringSSL for TLS
but the system PKI libraries for validation.
In this case, I think that this text was more intended to
say "and go read 5280 to learn how to do this". To that end,
I suggest we say"
"In general detailed certificate validation procedures are out of
scope for TLS. [RFC5280] provides general procedures for
certificate validation. This section provides TLS-specific
requirements."
> 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?
I think that these requirements apply equally to TLS 1.3, it's
just that 7525 is older.
> 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).
This is part of our generalized attempt to update to point to
the latest RFCs in our references. I'll add something to the
references section.
https://github.com/tlswg/tls13-spec/issues/1015
> 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."
In general, I think we'd prefer to avoid providing a catalog of
all the ways that things can go wrong, because there are a lot.
The point of the text here is just supposed to be that servers
don't have to fail if they ask for client auth but they are then
sad about what the client provides. That's actually generally kind
of true, but it's more obvious with client auth because in many
cases the server has many ways of authenticating the client and
can fall back if it doesn't like the cert.
> 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.
I agree. I think it would be useful to say something about this. I've
filed https://github.com/tlswg/tls13-spec/issues/1014 to track this.
-Ekr
On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
