[Trans] Alexey Melnikov's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Thu, 14 March 2019 13:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02B1130DC4; Thu, 14 Mar 2019 06:09:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trans-rfc6962-bis@ietf.org, Paul Wouters <paul@nohats.ca>, trans-chairs@ietf.org, paul@nohats.ca, trans@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155256895272.2621.1849917214823286530.idtracker@ietfa.amsl.com>
Date: Thu, 14 Mar 2019 06:09:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/qiURoDHiWrP1l7X3WY9RRvYrWFg>
Subject: [Trans] Alexey Melnikov's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 13:09:13 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this is an important document and I am looking forward to seeing it as
a Proposed Standard in the future. However, it has a good number of editorial
issues that make the document hard to read and implement.

5.  Log Client Messages

   type:  A URN reference identifying the problem.  To facilitate
      automated response to errors, this document defines a set of
      standard tokens for use in the "type" field, within the URN
      namespace of: "urn:ietf:params:trans:error:".

I think you need to register this in
<https://www.iana.org/assignments/params/params.xhtml#params-1>

Also, can you clarify whether error need an IANA registry?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General:

STH is only defined in the table of Content! Please define it early in the
document (before the "Changes since v1" section), so that it would be easier to
understand for somebody who is new to this.

"LSB" is never defined.

It might be just me, but I don't know what is the meaning of the ":" operation
for an expression "A : B" outside of an index.

DER encoding needs a Normative Reference.

TLS 1.2 needs at least an Informative Reference.

In 4.1: URL needs a reference.

In 4.1:
 What is the typical resolution for Maximum Merge Delay? 10 seconds? 20 minutes?

In 4.3:

   This prevents the CA from avoiding blame by logging a partial or empty chain.

"prevents the CA from avoiding blame" reads very awkwardly, maybe rephrase?

4.4.  Log ID

   Each log is identified by an OID, which is one of the log's
   parameters (see Section 4.1) and which MUST NOT be used to identify
   any other log.  A log's operator MUST either allocate the OID
   themselves or request an OID from the Log ID Registry (see
   Section 10.6.1).  Various data structures include the DER encoding of
   this OID, excluding the ASN.1 tag and length bytes,

OID encoding in DER really needs a normative reference.

5.  Log Client Messages

   Messages are sent as HTTPS GET or POST requests.  Parameters for
   POSTs and all responses are encoded as JavaScript Object Notation
   (JSON) objects [RFC8259].  Parameters for GETs are encoded as order-
   independent key/value URL parameters, using the "application/x-www-
   form-urlencoded" format described in the "HTML 4.01 Specification"
   [HTML401].  Binary data is base64 encoded [RFC4648] as specified in

Please clarify whether you are using Section 4 or Section 5 version of base64.
Also, are the trailing "=" expected in values?

   the individual messages.

   Note that JSON objects and URL parameters may contain fields not
   specified here.  These extra fields SHOULD be ignored.

Why not "MUST be ignored"? This is important for forward compatibility.

8.1.6.  Evaluating compliance

   A TLS client can only evaluate compliance if it has given the TLS
   server the opportunity to send SCTs and inclusion proofs by any of
   the three mechanisms that are mandatory to implement for CT-using TLS
   clients (see Section 8.1.1).  Therefore, a TLS client MUST NOT
   evaluate compliance if it did not include both the

Maybe "evaluate" above is a wrong verb, I think "enforce" would be better here.

   "transparency_info" and "status_request" TLS extensions in the
   ClientHello.

8.2.  Monitor

   1.  Fetch the current STH (Section 5.2).  Repeat until the STH
       changes.

I think the above text should recommend how often the client should poll for
this.