Subject: [Trans] comments on -05 (Abstract, Section 1 and Section 2)

From: Stephen Kent <[email-masked]>
Date: Thu, 05 Mar 2015 16:39:39 -0500

Overall comments

The correct expansion of the acronym CA is certification authority, not 
certificate authority. I believe I noted this typo in my comments months 
ago. I won’t cite each instance of it the document.

There are a number of instances where the document cites normative 
references, but the cited documents appear as informative references in 
Section 10.2

**

**

**

*Abstract*

Reword the opening sentence; it’s five lines long!

*1. Informal Introduction*

Why is this still an “informal” introduction? Doesn’t a standards track 
RFC deserve a real introduction :-)?

public CAs -> Web PKI CAs? (since the scope, is TLS)

each chain is rooted in a CA certificate … -> each chain terminates with 
a certificate verifiable under a CA certificate …

“provide evidence to TLS clients that the chain has been submitted …” 
just TLS clients, not monitors?

The text still talks about TLS clients requiring that all certificates 
they accept having been logged.Since TLS client behavior is out of 
scope, this statement, which motivates the use of logs, is out of scope 
as well. (we can’t have it both ways, i.e., defer definitive statement 
about client behavior and then cite such behavior as a motivation for 
the proposed mechanism.)

This section still discusses monitoring of logs, but defers 
specification of exactly how that monitoring is performed. Again, if 
monitor behavior is out of scope for this document, it is inappropriate 
to make vague statements about how such behavior justifies the 
development of a specification for logs.

The phrase “domains for which they are responsible” is vague. It 
suggests an attempt to convey how monitoring works, while deferring the 
real definition to another document.

“The checking operation is asynchronous to allow TLS connections to 
proceed …” The reference to asynchronicity suggests that this is 
describing TLS client behavior, which is out of scope.

The last paragraph in this section asserts that it is efficient for 
(unspecified parties, formerly known as Auditors) to detect log 
misbehavior, but does not provide evidence that such detection is, in 
fact, efficient.

This section refers to certificate mis-issuance, yet defines it 
nowhere.Since mitigating problems caused by mis-issued certificates is 
the rationale cited for CT, this omission is serious. And, I note, that 
I have offered text to define this term.

*2. Cryptographic Components*

As I noted in my initial review of 6269-bis, I think most of the text in 
2.1.1-3 belongs in an appendix.

It is common practice in the IETF today to place crypto algorithm specs 
in a separate document, to better accommodate changes to such specs in 
the future. This suggests removing the specs of hash and signature 
algorithms from 2.1.4. There also is a need to describe how changes to 
the algorithms will be accommodated by CT.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 14:58:49 +0000

In general, if you want us to remember to do something about your comments,
you need to open or update Trac tickets (discussion here before doing so is
fine, of course).

> ago. I won’t cite each instance of it the document.

I have just done this, so no need to open a ticket.

> references, but the cited documents appear as informative references in

And I am doing this right now, so again, no need for a ticket.

> RFC deserve a real introduction :-)?

It is informal in that the treatment of the subject is informal. The
remainder of the RFC is the formal part.

> each chain is rooted in a CA certificate … -> each chain terminates with a
> certificate verifiable under a CA certificate …
>
>
>
> “provide evidence to TLS clients that the chain has been submitted …” just
> TLS clients, not monitors?
>
>
>
> they accept having been logged.  Since TLS client behavior is out of
> scope, this statement, which motivates the use of logs, is out of scope as
> well. (we can’t have it both ways, i.e., defer definitive statement about
> client behavior and then cite such behavior as a motivation for the
> proposed mechanism.)
>
>
>
> This section still discusses monitoring of logs, but defers specification
> of exactly how that monitoring is performed. Again, if monitor behavior is
> out of scope for this document, it is inappropriate to make vague
> statements about how such behavior justifies the development of a
> specification for logs.
>
>
>
> The phrase “domains for which they are responsible” is vague. It suggests
> an attempt to convey how monitoring works, while deferring the real
> definition to another document.
>
>
>
> proceed …” The reference to asynchronicity suggests that this is describing
> TLS client behavior, which is out of scope.
>
>
>
> misbehavior, but does not provide evidence that such detection is, in fact,
> efficient.
>

However, the remainder of the document does. If we turn the introduction
into a formal treatment, it becomes the whole document. And then we need to
write a new introduction.

>
>
> This section refers to certificate mis-issuance, yet defines it nowhere.  Since
> mitigating problems caused by mis-issued certificates is the rationale
> cited for CT, this omission is serious. And, I note, that I have offered
> text to define this term.
>
>
>
> It is common practice in the IETF today to place crypto algorithm specs in
> a separate document, to better accommodate changes to such specs in the
> future. This suggests removing the specs of hash and signature algorithms
> from 2.1.4. There also is a need to describe how changes to the algorithms
> will be accommodated by CT.
>

This point has already been addressed in the next version of the I-D.

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 06 Mar 2015 11:11:29 -0500

Ben,

> In general, if you want us to remember to do something about your 
> comments, you need to open or update Trac tickets (discussion here 
> before doing so is fine, of course).
that was my plan. post comments first, then generate tickets.
> Why is this still an “informal” introduction? Doesn’t a standards 
> track RFC deserve a real introduction :-)?
>
>
This is not a distinction we tend to make in RFCs. I don't recall seeing 
another
RFC that has an introduction labelled as informal. See 
https://www.rfc-editor.org/policy.html
>
>     The last paragraph in this section asserts that it is efficient
>     for (unspecified parties, formerly known as Auditors) to detect
>     log misbehavior, but does not provide evidence that such detection
>     is, in fact, efficient.
>
>
> However, the remainder of the document does. If we turn the 
> introduction into a formal treatment, it becomes the whole document. 
> And then we need to write a new introduction.
no, just add a pointer to the place in the doc where you believe the 
assertion is substantiated.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 16:22:33 +0000

On 6 March 2015 at 16:11, Stephen Kent <[email-masked]> wrote:

> comments, you need to open or update Trac tickets (discussion here before
> doing so is fine, of course).
>

Thanks. Given how close we are to the submission deadline, I imagine many
of these will have to wait for the next cycle. Of course, we can continue
the conversation in the meantime...

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 16:44:23 +0000

> And I am doing this right now, so again, no need for a ticket.

And here's the diff:

@@ -1455,41 +1455,33 @@ Carl Wallace for their valuable contributions.
       </t>
     </section>
   </middle>
-  <back>
-
-
-
-    <references title="Normative Reference">

-    <?rfc include="reference.RFC.2119" ?>
-
-</references>
-
-<references title="Informative References">
+  <back>
+    <references title="Normative References">

-    <?rfc include="reference.RFC.2616"?>
+      <?rfc include="reference.RFC.2119" ?>

-    <?rfc include="reference.RFC.2560"?>
+      <?rfc include="reference.RFC.2560"?>

-    <?rfc include="reference.RFC.3447"?>
+      <?rfc include="reference.RFC.2616"?>

-    <?rfc include="reference.RFC.4627"?>
+      <?rfc include="reference.RFC.3447"?>

-    <?rfc include="reference.RFC.4648"?>
+      <?rfc include="reference.RFC.4627"?>

-    <?rfc include="reference.RFC.5246"?>
+      <?rfc include="reference.RFC.4648"?>

-    <?rfc include="reference.RFC.5280"?>
+      <?rfc include="reference.RFC.5246"?>

-    <?rfc include="reference.RFC.5652"?>
+      <?rfc include="reference.RFC.5280"?>

-    <?rfc include="reference.RFC.5905"?>
+      <?rfc include="reference.RFC.5652"?>

-    <?rfc include="reference.RFC.6066"?>
+      <?rfc include="reference.RFC.5905"?>

-    <?rfc include="reference.RFC.6125"?>
+      <?rfc include="reference.RFC.6066"?>

-    <?rfc include="reference.RFC.6962"?>
+      <?rfc include="reference.RFC.6125"?>

       <reference anchor="DSS" target="
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf">
         <front>
@@ -1504,21 +1496,16 @@ Technology</organization>
         <format type="PDF" target="
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf"/>
       </reference>

-      <reference anchor="CrosbyWallach"
-target="http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf">
+      <reference anchor="FIPS.180-4"
+target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
         <front>
-          <title>Efficient Data Structures for Tamper-Evident
Logging</title>
-          <author initials='S.' surname='Crosby' fullname='Scott A.
Crosby'>
-            <organization/>
-          </author>
-          <author initials='D.' surname='Wallach' fullname='Dan S.
Wallach'>
-            <organization/>
+          <title>Secure Hash Standard</title>
+          <author>
+            <organization>National Institute of Standards and
Technology</organization>
           </author>
-          <date month="August" year="2009"/>
+          <date month="March" year="2012"/>
         </front>
-<seriesInfo name="Proceedings of the 18th USENIX Security Symposium,"
-value="Montreal"/>
-        <format type="PDF" target="
http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf"/>
+        <seriesInfo name="FIPS" value="PUB 180-4"/>
       </reference>

       <reference anchor="HTML401" target="
http://www.w3.org/TR/1999/REC-html401-19991224">
@@ -1539,17 +1526,27 @@ value="Montreal"/>
         <format type="HTML" target="
http://www.w3.org/TR/1999/REC-html401-19991224"/>
       </reference>

+    </references>

-      <reference anchor="FIPS.180-4"
-target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
+<references title="Informative References">
+
+    <?rfc include="reference.RFC.6962"?>
+
+      <reference anchor="CrosbyWallach"
+target="http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf">
         <front>
-          <title>Secure Hash Standard</title>
-          <author>
-            <organization>National Institute of Standards and
Technology</organization>
+          <title>Efficient Data Structures for Tamper-Evident
Logging</title>
+          <author initials='S.' surname='Crosby' fullname='Scott A.
Crosby'>
+            <organization/>
           </author>
-          <date month="March" year="2012"/>
+          <author initials='D.' surname='Wallach' fullname='Dan S.
Wallach'>
+            <organization/>
+          </author>
+          <date month="August" year="2009"/>
         </front>
-        <seriesInfo name="FIPS" value="PUB 180-4"/>
+<seriesInfo name="Proceedings of the 18th USENIX Security Symposium,"
+value="Montreal"/>
+        <format type="PDF" target="
http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf"/>
       </reference>

       <reference anchor="EVSSLGuidelines" target="
https://cabforum.org/wp-content/uploads/EV_Certificate_Guidelines.pdf">