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 <[email protected]> wrote: > How about "Servers may wish to send a Retry-After header" ? > > > On 10/23/19, 6:15 AM, "Rob Stradling" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
