Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 11:33:40 -0000

#74: normative statement of TLS client behavior in Section 3

Comment (by [email-masked]):

 Describing how the protocol works from the client's POV is _not_ about
 client behaviour, it is about the client's understanding of the situation.
 How it behaves as a result of that understanding is behaviour.

 I propose this should be closed "wontfix".

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  blocker      |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 11:39:36 -0000

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 Thanks Ben.  Good point.  I agree that WONTFIX makes sense.

 Priority:  blocker      |   Milestone:  review

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 10:50:47 -0400

I note the following text from the -07 draft that appear to specify TLS 
client behavior:

Section 1

    TLS clients can thus require that all certificates they accept as 
valid have been logged.

Section 3

    A certificate not
    accompanied by an SCT (either for the end-entity certificate or for a
    name-constrained intermediate the end-entity certificate chains to)
    MUST NOT be considered compliant by TLS clients.

Section 3.4

    TLS clients MUST implement all three mechanisms.

Section 3.4.1

    TLS clients that support the extension SHOULD send a ClientHello
    extension with the appropriate type and empty "extension_data".

    TLS clients
    SHOULD include the extension type in the ClientHello, but if the
    session is resumed, the TLS server is not expected to process it or
    include the extension in the ServerHello.

Section 5.3

    In addition to normal validation of the certificate and its chain, 
*TLS**
**   clients SHOULD validate* the SCT by computing the signature input from
    the SCT data as well as the certificate and verifying the signature,
    using the corresponding log's public key.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 10:58:52 -0400

I note the following text from the -07 i-D that seems to specify TLS 
client behavior:

Section 1

(doe not use 2918 reserved words, but ...)

Section 3

    A certificate not
    accompanied by an SCT (either for the end-entity certificate or for a
    name-constrained intermediate the end-entity certificate chains to)
*MUST NOT be considered compliant by TLS clients*.

Section 3.4

*TLS clients MUST implement all three mechanisms*.

Section 3.4.1

*TLS clients that support the extension SHOULD *send a ClientHello
    extension with the appropriate type and empty "extension_data".

*TLS clients SHOULD include *the extension type in the ClientHello,

Section 5.3

    in addition to normal validation of the certificate and its chain, 
*TLS**
**   clients SHOULD validate the SCT *by computing the signature input from
    the SCT data as well as the certificate and verifying the signature,
    using the corresponding log's public key.

*A TLS client MAY audit the corresponding log *by requesting, and
    verifying, a Merkle audit proof for said certificate.*  If the TLS**
**   client holds an STH that predates the SCT, it MAY, *in the process of
    auditing, request a new STH from the log (Section 4.3), then verify
    it by requesting a consistency proof (Section 4.4).

*TLS clients MUST reject SCTs whose timestamp* is in the future.

Section 8.1

*Misissued certificates that have not been publicly logged, and thus**
**   do not have a valid SCT, will be rejected by TLS clients.*

---

From: Ben Laurie <[email-masked]>
Date: Mon, 6 Jul 2015 16:01:11 +0100

On 6 July 2015 at 15:50, Stephen Kent <[email-masked]> wrote:
>    TLS clients can thus require that all certificates they accept as valid
> have been logged.

This doesn't specify anything, just notes that clients can do it (if
they want to, obviously).

>    MUST NOT be considered compliant by TLS clients.

Again, no behaviour is specified. The client is required to understand
that the cert is not in conformance with CT. It can do what it wants
with that understanding.

>    TLS clients MUST implement all three mechanisms.

What we ruled out of scope is how clients behave in terms of user
interface, et al. Clearly a protocol document has to describe how the
protocol works. That is not the kind of behaviour we ruled out.

>    include the extension in the ServerHello.

See above.

>
>
> Section 5.3
>
>
>    In addition to normal validation of the certificate and its chain, TLS
>    clients SHOULD validate the SCT by computing the signature input from

And again.

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 14:36:08 -0400

Ben,

> On 6 July 2015 at 15:50, Stephen Kent<[email-masked]>  wrote:
the term disingenuous comes to mind here.
> that the cert is not in conformance with CT. It can do what it wants
This seems an attempt to have your cake and eat it too. We generally do not
define "compliance" when there is no specified response to non-compliance.
We do sometimes define compliance so that non-compliant data or behavior is
ruled out of scope. But, that doesn't sem to be the intent here.

But, in the spirit of compromise, how about:

A certificate not accompanied by an SCT is not CT compliant.
> protocol works. That is not the kind of behaviour we ruled out.
OK. This is describing an extension of functionality for TLS to make use of
CT. As such it updates (pick a version) of TLS. The headers for this
doc need to state that the RFC(s) in question are updated by this doc. It
also is customary to coordinate with the chairs of the WG responsible for
the specs being updated.
>>     include the extension in the ServerHello.
same as my response for 3.4
>>     using the corresponding log's public key.
How about:

A TLS client claiming conformance with CT MUST be capable of performing 
the following
checks on a certificate accompanied by an SCT:
     - Matching the SCT to the certificate. This entails <update to 
include the hash
       that Rob is adding to the SCT>
     - Verifying the signature on the SCT. The signature on the SCT is 
verified using
       the public key for the log identified by the logID SCT.
A TLS client claiming conformance with CT MUST be configurable (by the 
user or local
administrator) to perform these checks, or not

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 19:15:04 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  blocker      |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:4>
trans <http://tools.ietf.org/trans/>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jul 2015 14:22:58 +0100

On 6 July 2015 at 19:36, Stephen Kent <[email-masked]> wrote:
>>> valid

This seems redundant: I would've thought that in general everything in
an RFC only applies to things that are compliant with that RFC. But if
the WG wants I don't really mind either way.

> also is customary to coordinate with the chairs of the WG responsible for

OK, I get your point here, and I am happy to go either way:

a) Update TLS to require CT, or

b) Update the I-D to say something like "CT compliant TLS clients" or
as you use below "TLS clients claiming conformance with CT", which
presumably does not update TLS?

I guess it is not up to me to decide which.

>>> TLS
> A TLS client claiming conformance with CT MUST be capable of performing the
> following
>     - Matching the SCT to the certificate. This entails <update to include
> the hash
> A TLS client claiming conformance with CT MUST be configurable (by the user
> or local

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Jul 2015 14:26:46 +0100

On 07/07/15 14:22, Ben Laurie wrote:
> a) Update TLS to require CT,

That'd not be a good plan. TLS is used for lots more than
just the web and there aren't logs for many things, e.g.
corporate CAs are presumably much more of a deal for
EAP-TLS.

S.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Jul 2015 11:38:23 -0400

Ben,

> the WG wants I don't really mind either way.
I prefer the wording I suggested because it emphasizes the status of the 
cert relative
to this spec, rather than intimating any TLS client behavior.
> a) Update TLS to require CT, or
that's not what I meant to suggest. I don't think CT is destined to become
a mandatory aspect of TLS; it's an optional feature.
> presumably does not update TLS?
TLS is the definitive spec for the messages exchanged during its 
handshake. So
the specs in Section 3.4 represent an update to TLS (1.2). That does not 
make
support for CT mandatory, but it informs implementers of the new TLS 
extensions
defined here and the processing they imply.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jul 2015 11:30:17 +0000

> defined here and the processing they imply.

Ah, I see what you mean.

A couple of observations:

1. The TLS extension was allocated for 6962, so surely this should already
have happened?

2. I notice other extensions exist which are not referenced in the "update
by" section of 5246.

3. If this is a requirement for new extensions, why is it not part of the
process followed to get an extension allocated?