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

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 May 2017 22:07:37 -0400

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 May 2017 11:09:20 -0700

Hi Kathleen,

Thanks for your review.

>    significant security analysis.

Yeah, we'll remove this.

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

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

> verification and revocation checks for TLS 1.2.  Is this just for TLS

I think that these requirements apply equally to TLS 1.3, it's
just that 7525 is older.

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

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

> job of logging, so I think it's important to call that out here as a

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 <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 15 May 2017 12:46:56 -0400

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.

> revisit once that PR has been completed.

Thank you.
>     certificate validation. This section provides TLS-specific

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/

> I think that these requirements apply equally to TLS 1.3, it's

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.

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

> 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
> <[email-masked]> wrote:
>>
>> Hello,
>>

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 May 2017 15:38:43 -0400

Just commenting on Section 4.2 …

> > be to something that explains why it is out-of-scope.

I think the the separation of certificate path validation from the TLS protocol is correct, but perhaps this can be explained differently.  Perhaps the approach should be that TLS depends upon certificate path validation as described in RFC 5280.

>     requirements.”

I agree with the reasoning, however the dependency on RFC 5280 should be called out in a MUST statement.  I suggest something like:

    "TLS depends on certificate path validation, and a conformant
    TLS implementation MUST implement certificate paths validation
    in a manner that achieves the same result as [RFC5280]. This
    section provides TLS-specific requirements.”

Note that RFC 5280 is already a normative reference.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 May 2017 16:19:07 -0400

> On May 15, 2017, at 3:38 PM, Russ Housley <[email-masked]> wrote:
> 
> I think the the separation of certificate path validation from the TLS
> protocol is correct, but perhaps this can be explained differently.
> Perhaps the approach should be that TLS depends upon certificate path
> validation as described in RFC 5280.

That's not always true.  With DANE-EE(3) TLSA records there is no
path validation.  You just validate the EE certificate directly.

With DANE-EE(2), there's an RFC5280 chain, but it terminates on
a trust-anchor provided by the peer as part of its chain, with
a hash in DNS.

With unauthenticated opportunistic TLS, the peer's chain is ignored
entirely.

How and whether the peer's certificate message is used is properly
outside TLS.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 May 2017 16:01:53 -0700

On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[email-masked]> wrote:

> I agree with the reasoning, however the dependency on RFC 5280 should be
> called out in a MUST statement.  I suggest something like:
>

A MUST here would be a pretty material change to historical TLS practice.
As Viktor says, there are TLS-using applications that just don't validate
the cert via 5280 at all.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 May 2017 11:17:44 -0400

> On May 15, 2017, at 7:01 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

I think we want to say that if the certificates are used, then the certification path MUST be validated in a manner that is compatible with Internet X.509 certificate profile [RFC5280]; however, other approaches to validation of the public key, such as the DANE TLSA resource record [RFC6698], are also acceptable.

Russ

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 May 2017 11:20:05 -0400

On Tue, May 16, 2017 at 11:17 AM, Russ Housley <[email-masked]> wrote:
>> protocol is correct, but perhaps this can be explained differently.  Perhaps
>> the approach should be that TLS depends upon certificate path validation as
>> described in RFC 5280.
>>
> I think we want to say that if the certificates are used, then the
> certification path MUST be validated in a manner that is compatible with
> Internet X.509 certificate profile [RFC5280]; however, other approaches to
> validation of the public key, such as the DANE TLSA resource record
> [RFC6698], are also acceptable.

I do like this a lot better as it will help with interoperability and
security, with well defined implementation guidance.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 08:23:15 -0700

> [RFC6698], are also acceptable.

I can see how you would want to say that, but it's not really consistent
either
with historical practice or with the way that other standards track RFCs
use TLS
with certificates (see RFC 5763).

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 May 2017 11:31:27 -0400

> On May 16, 2017, at 11:23 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On May 15, 2017, at 7:01 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> I can see how you would want to say that, but it's not really consistent either
> with historical practice or with the way that other standards track RFCs use TLS

Actually, that is a great example.  I accept the need for loose coupling.

Russ

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 May 2017 11:36:36 -0400

> Actually, that is a great example.  I accept the need for loose coupling.

OK, does that put us back to the suggested wording:

For any developers following, does this help enough with any
interoperability questions?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 May 2017 12:37:42 -0400

> On May 16, 2017, at 11:36 AM, Kathleen Moriarty <[email-masked]> wrote:
> 

TLS does not depend on certificate path validation.  Many TLS
*applications* rely PKIX certificate path validation (along with
RFC 6125 server identity verification), but TLS itself supports
various alternative authentication (and non-authentication) modes.

   * PSK or SRP without certificates
   * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <= 1.2)
   * TOFU public key pinning
   * Static leaf key or leaf cert matching
   * RFC7250 raw public keys
   * DANE-EE(3) leaf certificate/key verification, without expiration
     or server name checks
   * DANE-EE(3) ... with name checks (where UKS attack are relevant)
   * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
     is part of the chain, and identified via DNS TLSA records.
   * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
   * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"

Keeping in mind that many implementations of RFC5280 violate that specification
by interpreting EKUs in CA certificates to constrain the kinds of certificates
that the CA may issue.  That de-facto usage is I think much more widely implemented
than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 May 2017 12:49:39 -0400

> than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

Sorry, I grabbed the wrong text as I was ineffective at multi-tasking.
I think we are back to the following text and would like to confirm
that and make sure it is agreeable to the WG and implementers:

There's also a thread that was discussing some interoperability
problems related to validation and I'd like to see the resolution for
that as well.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 10:44:39 -0700

On Tue, May 16, 2017 at 8:36 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Perhaps
> use
> > TLS

Hmm... I don't think so. Wouldn't the fingerprint-matching prescribed by
5763
contradict this?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 12:01:56 -0700

>     certificate validation. This section provides TLS-specific
Yeah, I think so.

> problems related to validation and I'd like to see the resolution for

Matt has provided a PR for that that I'll be looking at this week.

Thanks,
-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Tue, 16 May 2017 22:05:20 -0400

>    * RFC7250 raw public keys

Just as a footnote to anyone reading this discussion that may not know:
The current version of the TLS 1.3 spec explicitly recommends RFC7250
raw public keys as a viable option and provides the needed information
on how to handle this in TLS 1.3. Anonymous cipher suite support has
been dropped from TLS 1.3, and trust on first use raw public keys are
the first of the two recommended alternatives.

>    * TOFU public key pinning

Trust on first use public keys in unvalidated certificate chains is the
second recommended alternative.

https://tlswg.github.io/tls13-spec/#unauthenticated-operation
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#appendix-C.6

Dave

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 May 2017 20:10:26 -1000

> job of logging, so I think it's important to call that out here as a

I think I agree with what Kathleen wrote here, but the PR that
attempts to address this
(https://github.com/tlswg/tls13-spec/pull/1021) seems too strong in
recommending that servers send alerts. In particular, IMO logging the
alert shouldn't necessarily be the default and there should be a way
to disable such logging. I guess saying something such as "The
implementation SHOULD provide a way to facilitate the logging of the
error" or similar, instead of "SHOULD log" seems better to me.

In particular, an implementation might not do any logging itself, but
might return an error code that the higher level thing could log (if
it wants to). I would generally recommend implementations do this than
to do logging themselves.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 May 2017 09:08:29 -0400

This works for me, does anyone object to my updating the PR in this fashion?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 May 2017 10:02:20 -0400

> This works for me, does anyone object to my updating the PR in this fashion?

Go ahead.