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

[Kathleen Moriarty <[e-mail]>]

Hi Eric,

Thanks for your response.  Sorry for the delay, I'v been traveling.
The responses sound good, I do have a clarification and will respond
inline.

On Sat, May 13, 2017 at 2:09 PM, Eric Rescorla <[e-mail]> wrote:
> 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.
>

Thank you.
>
>> 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."
>

This reads much better, thank you.  However, shouldn't it say TLS1.3
since TLS 1.2 referenced RFC3280 and subsequently in RFC7525 includes
use of RFC5280 as a best practice.  It may be true for TLS 1.0 and
1.1, but it changed for TLS 1.2/

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

I think this was poor phrasing on my part for the point.  and is
hopefully clarified in my response above.  RFC7525 came after TLS 1.2
and updated it's guidance recommending 5280.

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

>From list discussions, the underspecification seems to be causing some
interoperability problems.  Maybe a response to the list discussion
with this point will result in something to improve this section and
clarity for developers.  I'll look in the next update.  Thank you.

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

Thank you, this is very helpful.

Best regards,
Kathleen

>
> -Ekr
>
>
> On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty
> <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>



-- 

Best regards,
Kathleen