Re: [Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
Eran Messeri <eranm@google.com> Wed, 23 October 2019 14:54 UTC
Return-Path: <eranm@google.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 7EA8712082B for <trans@ietfa.amsl.com>; Wed, 23 Oct 2019 07:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 W1UPNHb9cMIz for <trans@ietfa.amsl.com>; Wed, 23 Oct 2019 07:54:10 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01CD12088B for <trans@ietf.org>; Wed, 23 Oct 2019 07:53:53 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id s7so6392524ybq.7 for <trans@ietf.org>; Wed, 23 Oct 2019 07:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e2+5PtHrYgq43l9Oak9r4Rn87ublXMsSVj3Lr/oZ3GQ=; b=Z/C3lCqjhey4pzKBWfcLGoLDkEkAaKp9uHKziTlF78TDSNI3CeDSPle7iSRmIAdx3+ hkPrfErxkPj9tOIS3pgTCR6rxA9DlZJKtl6YbWau8rsI1LGF+aapWFFrn5LPyN9ynp9C hsYYC3wGTsob2Ywrb8ZVuCVVX5ofFP+QIO+dNuFPTnB35iciCl/3OXjYv/5HC5czzeUt Fm35UAZg6kCvL4vr5eHl4ZKM9eQXLLiGfnX9YVp2Sz7pYhwh+ektVEl+tkeffoiByZ5K 400Mmfa2TSQ+jO+gmw9mhDv+qnJd7No38blJu3L5m8o7YTD5UOokGqzYLLhx9717HaUk 900Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e2+5PtHrYgq43l9Oak9r4Rn87ublXMsSVj3Lr/oZ3GQ=; b=pszjns86EmAel/8Oby3N4ipqbxI9ZltEJSdcwZ/xCR5OuYTdSrMVGa3AeDbYTbECZC JVM8kruqUb4FqZZpxsJyqc0OQ53YPp58bTSRXFi0uEaEZ7jb2bx+aMbbg6QnSbRd8OV7 OVoq0O1EBVRZ9koNIIOYqCLRBpZKBKSn/kpsNBP0DI5VZGlLW+OwjWzqPj2yow+87GIq ESbRKzyy1QIk9GSlbkL0LaW94CcMGyJ56EiOnJUP6YQZf6UV881AjNu2XcSvijjwDu/T KKiB+JiicMpks4wxyYJ7uMhvIKquGbPyUXviZbs+2JGKQ+tYK+VGtw5y0OYGngeFr+Fp 09vw==
X-Gm-Message-State: APjAAAULQn+laIAdXyk0oThZTGwjk4eGwqZUugsgJWox427XYhO1//Kv 3SDUgrvyVAdiv2/wy2EpOyJQ9pgHv3XYsz4rRdjPwOLhZTg=
X-Google-Smtp-Source: APXvYqwIZGa0d1/9l2aMFH+PqGvRpN7xwuC89PEKGP4ERm5TeSV5NGMAdiJJLZla4GVRItmp9rsVJczBiaLsbv9R+pA=
X-Received: by 2002:a25:ae48:: with SMTP id g8mr6526815ybe.419.1571842432240; Wed, 23 Oct 2019 07:53:52 -0700 (PDT)
MIME-Version: 1.0
References: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com>
In-Reply-To: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com>
From: Eran Messeri <eranm@google.com>
Date: Wed, 23 Oct 2019 15:53:25 +0100
Message-ID: <CALzYgEdW8LVMJ+akjMQJepQ2WV-z2GFHw5q+0czfpQHS-Hu7CA@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Rob Stradling <rob@sectigo.com>, "trans@ietf.org" <trans@ietf.org>, "draft-ietf-trans-rfc6962-bis@ietf.org" <draft-ietf-trans-rfc6962-bis@ietf.org>, Paul Wouters <paul@nohats.ca>, Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "trans-chairs@ietf.org" <trans-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d159a805959515ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/pamdC5am5zlF0aSbIQzrO8E4aKY>
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: Wed, 23 Oct 2019 14:54:17 -0000
I second Rich's suggestion. The problem I see with recommending a retry time is that a request could fail due to one of two reasons: * Transient failure: Some RPC to some backend service errored so re-trying soon after the original request is likely to succeed. * More permanent failure: On-going outage that will take a while to resolve (e.g. people working to resolve it). And each of the reasons would merit a different time-out. If I had to pick a number, 60 seconds _seems_ like a reasonable retry delay, but I'm more than happy to learn of circumstances where this would be excessive / too short. On Wed, Oct 23, 2019 at 1:22 PM Salz, Rich <rsalz@akamai.com> wrote: > How about "Servers may wish to send a Retry-After header" ? > > > On 10/23/19, 6:15 AM, "Rob Stradling" <rob@sectigo.com> wrote: > > On 23/10/2019 10:52, Mirja Kuehlewind wrote: > > Hi Rob, > > > > Just one more comment regarding the default for the waiting time: I > understand that it is arbitrary but I guess someone implementing CT in the > first place has to make the same arbitrary choice and just select some > value. Of course this value should be configurable but recommending some > default or at least a range or order of value could reduce surprises. > However, this is a just a recommendation from me and it’s your call! > > Would anyone else like to comment on whether they agree or disagree > with > this recommendation? > > If you agree, then please propose a default waiting time (for > situations > where the log server does not send an explicit "Retry-After" header). > > Thanks. > > > Mirja > > > > > >> On 16. Oct 2019, at 15:36, Rob Stradling <rob@sectigo.com> wrote: > >> > >> On 14/10/2019 16:32, Mirja Kuehlewind wrote: > >>> Hi Rob, > >>> > >>> Thanks for your replies and edits. I will clear my discuss as soon > as the new version is submitted. > >> > >> Thanks Mirja. > >> > >>> Please see some minor comments below! > >> > >> Replies inline. > >> > >>> Thanks! > >>> Mirja > >>> > >>> > >>>> On 14. Oct 2019, at 16:07, Rob Stradling <rob@sectigo.com> wrote: > >>>> > >>>> 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. > >>> > >>> Could be good to clarify in the text. > >> > >> Addressed by > >> > https://github.com/robstradling/certificate-transparency-rfcs/commit/18be3bdc0eb3a8f5b95040081ccfaddcd2924fcb > >> > >>>>> 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. > >>> > >>> Could be good to clarify in the text. > >> > >> I think other sections of the document already make it clear that a > >> certificate or precertificate must be submitted to (and accepted > by) a > >> log before an SCT will be produced. > >> > >> Section 3 says: > >> "If a log accepts a submission, it will return a Signed > Certificate > >> Timestamp (SCT)" > >> > >> Section 4 says: > >> "When it receives and accepts a valid submission, the log MUST > return > >> an SCT that corresponds to the submitted certificate or > >> precertificate." > >> > >> I think reiterating this point again would be both unnecessary and > out > >> of scope for section 4.8, the purpose of which is to define the > >> structure of an SCT. > >> > >>>>> 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.’ > >>> > >>> I meant, would it make sense to actually provide a default value > or something for this waiting time? > >> > >> We could, but it would be fairly arbitrary. So why bother? > >> > >> Some transient failures may be very short-lived, but others may > last for > >> hours. Only the log operator can possibly know how long a client > should > >> wait before retrying a request would be expected to succeed. > >> > >>>>> 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”. > >>> > >>> RFC Required implies that the document got some reviews based on > the respective process. > >>> > >>> However, I guess I actually wanted to propose IETF Review (and > used the wrong term). That would imply that it had to go through the IETF > process with respective review (and therefore usually it is expected that > no expert review is needed in addition). Anyway this was mainly a comment > to double-check this decision. > >> > >> I personally don't have a preference, but I'll start another list > thread > >> to discuss this proposal. > >> > >>>>> 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. ;-) > >>> > >>> Didn’t know that… > >>> > >>>> > >>>> 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. > >>> > >>> Okay thanks for the background info. As long as this was discussed > that's fine! > >> > >> -- > >> Rob Stradling > >> Senior Research & Development Scientist > >> Sectigo Limited > >> > > > > -- > Rob Stradling > Senior Research & Development Scientist > Email: rob@sectigo.com > Bradford, UK > Office: +441274024707 <+44%201274%20024707> > Sectigo Limited > > This message and any files associated with it may contain legally > privileged, confidential, or proprietary information. If you are not > the > intended recipient, you are not permitted to use, copy, or forward it, > in whole or in part without the express consent of the sender. Please > notify the sender by reply email, disregard the foregoing messages, > and > delete it immediately. > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > >
- [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