Re: [Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

[Eran Messeri <[e-mail]>]

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 <[e-mail]> wrote:

> How about "Servers may wish to send a Retry-After header" ?
>
>
> On 10/23/19, 6:15 AM, "Rob Stradling" <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: [e-mail]
>     Bradford, UK
>     Office: [phone] <+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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/trans
>
>
>