- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 5 Jun 2018 11:55:26 +0200
- To: "Emily Stark (Dunn)" <estark@google.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
On Mon, Jun 4, 2018 at 10:56 PM Emily Stark <estark@google.com> wrote: > Might have been blindly cribbed from HSTS/HPKP -- I don't remember discussing it specifically for Expect-CT. Filed https://github.com/httpwg/http-extensions/issues/637 Thanks. >> CAs can (and do) issue IP certificates, so why does this specifically >> exclude those? If this is a requirement imposed by CT, then please >> cite that. Otherwise, I think that this should allow IP literals. > > > This was also cribbed from HSTS/HPKP. I'll try to find out the motivation for including it in those specs; I'm a little wary of dropping it from Expect-CT without understanding why it's there for the other two... There was some confusion about the status of IP certificates at some points in the past. I don't think that it is necessary to concern this spec with the types of identifier that need to be covered. I thought that it might be a CT-specific requirement, but if it is not, then I don't see any reason to mention anything about the type of subjectAltName. >> The storage model doesn't account for the Age of a response. If that >> is intentional, please call it out, otherwise, cite RFC 7234. > > > Not sure I quite follow this, can you clarify? Are you expecting that an Expect-CT header should be disregarded if Age is present? No, just that the times need to be accounted for relative to the time that the response was generated, that's all. See https://tools.ietf.org/html/rfc7234#section-4.2 > Section 2.4 is intended to cover this: "It is acceptable to skip this CT compliance check for some hosts according to local policy. For example, a UA may disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform)." Missed that. Thanks. >> What is the interaction model of Expect-CT reporting with other >> similar features. Say we have 10 reasons for rejecting a connection, >> of which Expect-CT and a small subset of others could both trigger >> errors and reports. Do all report if they fail? Just the first? The >> document is currently written with the assumption that there is a >> bunch of checks that either pass or fail and that Expect-CT is the >> very last check, but that's unlikely to be the case forever. > > > I think this should probably be up to the UA. I'm not sure I see where the document assumes that Expect-CT is the very last check; Section 2.4 is intended to say that the UA evaluates CT compliance if it is able to successfully set up a TLS connection, but intentionally doesn't specify exactly when except that it should be before beginning an HTTP conversation, and that if CT compliance isn't evaluated for whatever reason, reports aren't sent. "When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection has no errors, then the UA will apply an additional correctness check" That implies that the Expect-CT check is the last to me. I think that recognizing that this is one of many checks would make this a little cleaner. Observing that there is a possibility that reporting might not happen unless all other checks pass is something that would also be useful. > I think we could reasonably drop one copy of the certificate chain, and maybe just limit it to the leaf cert... but the SCT list and other information is certainly useful for debugging misconfigurations. I'm not sure it's worth making the backwards-incompatible change of reducing the cert chains at this point -- it doesn't remove enough data to remove the risk of a self DoS. Sites are advised to use separate reporting infrastructure for this reason. I guess the question is: how complex is the server infrastructure going to get before this is useful for debugging. >> application/expect-ct-report+json needs to be registered. There's a >> whole process and it's annoying, but necessary. You can crib the text >> from other recently successful examples (I recently shepherded RFC >> 8142, but you can probably find a few others), and someone needs to >> send an email to a mailing list somewhere. > > > Errr... how do I find out who needs to send what email to what mailing list? I'm sure that your chairs are able to help here. As I said, crib the template from someone else (see above). The registration process is described here: https://tools.ietf.org/html/rfc6838#section-5 That's far more detailed than you need. I have had success with sending an email to the media-types@iana.org list with a pointer to the draft. The folks there are generally very helpful. Thanks for getting these all fixed so quickly.
Received on Tuesday, 5 June 2018 09:56:04 UTC