[Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
Mirja Kühlewind via Datatracker <noreply@ietf.org> Thu, 14 March 2019 13:50 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 57829129B88; Thu, 14 Mar 2019 06:50:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind 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: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com>
Date: Thu, 14 Mar 2019 06:50:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/0R9dKzZ4h2bLQX4pyHqwdA4uVdo>
Subject: [Trans] Mirja Kühlewind'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:50:10 -0000
Mirja Kühlewind 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: ---------------------------------------------------------------------- There was a presentation at maprg IETF 103 about the question if CT helps attackers to find new domains. I think this risk should at least be mentioned in the security considerations section. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms? Maybe that could be further clarified 2) Please expand STH on first occurrence (in sec 4.1) 3) Sec 4.4: „A log's operator MUST either allocate the OID themselves or request an OID from the Log ID Registry (see Section 10.6.1).“ Isn't there an obligation to register? 4) sec 4.8: „If an implementation sees an extension that it does not understand, it SHOULD ignore that extension.“ Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not? 5) sec 5: „MAY retry the same request without modification at a later date.“ Would it be possible to provide a recommendation how long the client should wait? 6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per "get-entries" request.“ Should this be added to sec 4.1? 7) sec 10.3: Couldn’t you use the TLS SignatureScheme Registry directly (instead of forming an own registry)? 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry? 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 recommend to always (clearly) name the registry. And finally one higher level question mainly out of curiosity: was it considered to e.g. use json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?
- [Trans] Mirja Kühlewind's Discuss on draft-ietf-t… Mirja Kühlewind via Datatracker
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Rob Stradling
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Rob Stradling
- [Trans] Assignment Policy for the "CT VersionedTr… Rob Stradling
- [Trans] Assignment Policy for the 6962-bis "CT Ve… Rob Stradling
- Re: [Trans] Assignment Policy for the "CT Version… Salz, Rich
- Re: [Trans] Assignment Policy for the 6962-bis "C… Melinda Shore
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Rob Stradling
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Salz, Rich
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Eran Messeri
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Rob Stradling
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Salz, Rich
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Rob Stradling
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Paul Wouters
- Re: [Trans] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind