W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Working Group Last Call for draft-ietf-httpbis-expect-ct-05

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 5 Jun 2018 11:55:26 +0200
Message-ID: <CABkgnnX+n=gc9xEY1j_0bj2L+1t1Z4Zwrv3r+y4HUb8jtgWqDQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC