Re: [Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
Rob Stradling <rob@sectigo.com> Mon, 14 October 2019 14:07 UTC
Return-Path: <rob@sectigo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC04120058; Mon, 14 Oct 2019 07:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXC4U18-W5iY; Mon, 14 Oct 2019 07:07:55 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770087.outbound.protection.outlook.com [40.107.77.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D1512002F; Mon, 14 Oct 2019 07:07:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cuz/I36A+4OUR7lFa6F0jONgxGfWlDs/UAMxmHvVIxfKWWKv+hME+XYjXbA/OlyPCqEgjm3F3pu9SKFvu8zV0UuQEFUqd7A3KG13IYwcSmqauHmIufnkhYp6X4aEANqiinNmBeL1I72uASE+Q5ofRSFwhrp8lgUzlrwd37lwroxc7IQm6iM7Ql3WP5HP4IFMSKnxKG/Ym1VJg9c/sIcCmi9LIbt3pAxPZgqLQnu75MHwN0xwdBjI74fngCE6a84J0WUu9RLCBtmCf4hA2Gd8L0SwnN1OluQ4BhOwXeUgfosqCgtN7/W/X8ZLUAhi/I+7WKs81coONfBJioCg8GARZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=39TJMRulFfXtLHd+slCYawbGpV3itmA5eTRhXyNMMt4=; b=oT/ntdT+IJ6y/DLWpU0jDI6jIAgwuHJeEn0Ul2GDqolHT9L0K8QaqwHRaUXL2IIYn8dHWSckskwnpd1TAi++HZA39Ow6jhq4plXtj+3ZpPZ3gkd+Y5fP/6ADAy3ipFa2ILLMA3InCYCWDitTM8ptHcImthL5GFrVdmNEkrIEzORuJmWw50d2uFvo+o1lCOBkJ5JsBKkZm60G6Mqm+LWRga42DOySkHfplXQBqYbMPl3NsAJuYYDzXas0x433uN0xzLsitEmUyda6KLfgZiLEfxsNmz8p5BiEzr4WHgnnPOPt+CjcwArxb5unQL4qhrIRG4ZAUwRMbzf0vcEc2zewfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sectigo.com; dmarc=pass action=none header.from=sectigo.com; dkim=pass header.d=sectigo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector2-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=39TJMRulFfXtLHd+slCYawbGpV3itmA5eTRhXyNMMt4=; b=TiqzX/Y+d40QR+XPgvaxUWuY9nNR7ca+QFqf6XJULXfVjsPtNBgFDOatD6dgFAllUwb/TF97Xv5v25Sa/IZNuqRORRNphi7inlQTiVisMMhnYjkUNRm2yuWhs3DgjJF6ZJn/5besZDqMhpTloGkAs+pwkyp8RWZ026CtU22fAZQ=
Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2780.namprd17.prod.outlook.com (20.178.225.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 14 Oct 2019 14:07:53 +0000
Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 14:07:53 +0000
From: Rob Stradling <rob@sectigo.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-trans-rfc6962-bis@ietf.org" <draft-ietf-trans-rfc6962-bis@ietf.org>, Paul Wouters <paul@nohats.ca>, "trans-chairs@ietf.org" <trans-chairs@ietf.org>, "trans@ietf.org" <trans@ietf.org>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
Thread-Index: AQHU2mzZvrQWumqliU+mEnmmbgWJ/adbfJiA
Date: Mon, 14 Oct 2019 14:07:53 +0000
Message-ID: <a4159bb4-b761-a4d5-6367-5aebb6aa984f@sectigo.com>
References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com>
In-Reply-To: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0143.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::35) To DM6PR17MB3162.namprd17.prod.outlook.com (2603:10b6:5:192::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a0e:ac00:25d:300:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7e49a51e-411c-41f2-bdca-08d750afe7c7
x-ms-traffictypediagnostic: DM6PR17MB2780:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <DM6PR17MB2780E72253AF6A38FC4DC179AA900@DM6PR17MB2780.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(346002)(366004)(39850400004)(189003)(199004)(54094003)(99286004)(6512007)(186003)(54906003)(6306002)(7736002)(31686004)(8936002)(52116002)(25786009)(6486002)(229853002)(224303003)(53546011)(2906002)(76176011)(6506007)(386003)(31696002)(6436002)(102836004)(86362001)(66574012)(11346002)(256004)(14444005)(36756003)(4326008)(71200400001)(71190400001)(478600001)(81156014)(81166006)(305945005)(446003)(46003)(110136005)(2616005)(66556008)(64756008)(66446008)(966005)(316002)(66946007)(66476007)(14454004)(5660300002)(6116002)(486006)(476003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2780; H:DM6PR17MB3162.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mUZ64joB3JBqi6nAlUHTpV6A1SrhRRoY4Y16hrNzLwBO/Hl9ZehFNq5xPlfsRWiIci8oDcfkA0mlauR3Ul+MzhdPQL2kM7yM8Se2+XhqgxfE3E+TgqcaqVTfH/W34zpIZIsSMSbkYhbc9mLliqdqov0Hg4krLRI591+cyqRAoa4slqwk+Tf8havTutaTU4Fn7XSeu9vEg6ggm4RUOWLBkWNktLtjXZ7IGNwg6jdAand1Qcr2XdeKpmUo6obD89YbcCiXerQTvfu+qlO7CzYtapNLzklWOSOV9/e7Uw/XPbpu9tOGXcYP86q39pkbVt4OsIJ+cfYv9jauFB8FXXAOH4Cp6tOMIUqYn+C1hxoyh4dG4uG6Pd2Xo3ScrgWt/lA2ALenPF1EXI3+dQG1+5oCKnLKLulim/zDwU5JwjvpvkbDaJGFiBm7V5KdC7BvYae0M0gNNmOGzEji8itO19aMkw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <435A175BB312DE409421626CE83D86C0@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e49a51e-411c-41f2-bdca-08d750afe7c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 14:07:53.6079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jmNaTgZIKhQp3F3nkZb9lHn8CnzvZDPA4rBuT5/ZjaOmPGzyCwSYPDaqjCxz/tJdB7RjVZBgSi30xVMYbgHw+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2780
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/VrEOQXl6D70YfQkXGkkLKNpr3uQ>
Subject: Re: [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
Precedence: list
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: Mon, 14 Oct 2019 14:07:59 -0000
Hi Mirja. Sorry for the looong delay. Comments inline, and I've just posted this PR: https://github.com/google/certificate-transparency-rfcs/pull/316 On 14/03/2019 13:50, Mirja Kühlewind via Datatracker wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-trans-rfc6962-bis-31: Discuss > > 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. Addressed by https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2ec0a51f8abb4c8c0b985614fefa4291432dd9 > ---------------------------------------------------------------------- > 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 We'll consider these comments on section 2 at a later date, along with Benjamin Kaduk's comments on section 2. > 2) Please expand STH on first occurrence (in sec 4.1) Addressed by https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6b0ac303af2659e5df538391002f1bf454edb > 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? The Log ID Registry is merely a source of OIDs that have short DER encodings. A log operator may either (1) request an OID from the Log ID Registry, or (2) allocate an OID themselves (from an OID arc that they control, naturally). The Registry is not intended to be a global directory of all logs. > 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? "It" (the precertificate or certificate) must have already been logged, because the corresponding SCT (that contains a potentially unrecognized extension) couldn't otherwise exist. > 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? The very next sentence in section 5 already specifies a mechanism for doing just that: 'Note that as per [RFC7231], in the case of a 503 response the log MAY include a "Retry-After:" header in order to request a minimum time for the client to wait before retrying the request.' > 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? I don't think that's a good idea. I can imagine that operational issues might cause a log operator to want to vary this restriction at any time. Clients should always be prepared to receive get-entries responses that contain fewer entries than they requested. See also https://trac.ietf.org/trac/trans/ticket/95 > 7) sec 10.3: Couldn’t you use the TLS SignatureScheme Registry directly > (instead of forming an own registry)? It makes sense to synchronize the signature algorithm values we use with the TLS SignatureAlgorithm registry, because our data structures are defined according to the conventions laid out in the TLS RFC. However, I don't think it's a good idea to use the TLS SignatureAlgorithm registry directly. In 6962-bis, we've taken steps to make log artifacts smaller (compared to RFC6962); related to that, we've removed the option of logs being permitted to use RSA keys/signatures. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 permits RSA, and several other signature algorithms that we don't wish to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for Private Use"). > 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate > for the VersionedTransTypes registry? In 6962-bis section 10.4.1, we ask the appointed Expert to "review the public specification to ensure that it is detailed enough to ensure implementation interoperability". AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, whereas "Specification Required" does. So I think we should leave it as "Specification Required". > 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 recommend to > always (clearly) name the registry. Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (see https://github.com/google/certificate-transparency-rfcs/pull/309), we've already clarified that the Log ID Registry is indeed First Come First Served. > 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? Please don't restart the format wars. ;-) We must use ASN.1 for all data structures, because X.509 certificates are involved. But we must use "TLS encoding" for all data structures, because TLS is involved. But we must use JSON for all data structures, because JSON is more API-friendly. It was impossible to please everyone. We had to choose something, so we chose TLS encoding for the data structures, and JSON for the APIs. As I mentioned earlier, one goal of 6962-bis is to make log artifacts smaller. TLS encoding is more suited to this than JSON. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited
- [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