Subject: Re: [Last-Call] [Gen-art] [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07

From: Alissa Cooper <[email-masked]>
Date: Wed, 5 Feb 2020 13:49:23 -0500

Mohit, thanks for your review. Sara, thanks for your responses. I entered a DISCUSS ballot to talk about Mohit’s point related to Section 5.1.7, among other things.

Best,
Alissa

> On Jan 17, 2020, at 10:33 AM, Sara Dickinson <[email-masked]> wrote:
> 
> 
>> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Reviewer: Mohit Sethi
>> Review result: On the Right Track
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>> 
>> Document: draft-ietf-dprive-bcp-op-07
>> Reviewer: Mohit Sethi
>> Review Date: 2019-12-29
>> IETF LC End Date: 2020-01-02
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:
>> This draft discusses privacy challenges for recursive DNS resolvers. It then
>> describes policy and security considerations that DNS service providers can use
>> for enhanced user privacy. The draft is 'On the Right Track' but not yet ready.
> 
> Many thanks for the detailed review! Ben, Rob I hope theses fixes also address your comments.
> 
>> 
>> Major issues:
>> 
>> I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP
>> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want
>> to mention it here in section 5.1.2.1/5.1.3.1?
> 
> What exactly are you thinking of here - something that just says “Server operators should also follow the best practices with regard to OCSP as described in RFC7525”? If something more could you please suggest text?
> 
>> 
>> In section 5.1.2.1, what is meant by 'authentication domain names'? Later, the
>> text says 'authentication name for the service'. I guess you are implying the
>> authentic domain name of the DNS resolver service that the client software
>> should verify through the common name (CN) in the certificate? Some more
>> explanation here would be beneficial.
> 
> It is defined in the terminology section of RFC8310:
> 
> "Authentication domain name: A domain name that can be used to authenticate a privacy-enabling DNS server.  Sources of authentication domain names are discussed in Section 7."
> 
> I have added a reference for RFC8310 after the first use of ‘authentication domain name’ and made sure every instance of 'authentication name' is updated to 'authentication domain name' for clarity.
> 
>> 
>> In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock
>> avoidance'? And please add a reference to RFC 8027 here if that is the case.
> 
> Yes, good catch - will do. 
> 
>> 
>> Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A". It
>> is pointing to the wrong appendix. 
> 
> Fixed - thanks.
> 
>> Also, this section talks about implementing
>> traffic monitoring by the DNS service provider. I would argue that in most
>> deployments, the traffic monitoring is required (and implemented) by a
>> different entity. Think of a home network router that has a parental control.
>> Or an enterprise restricting employees from visiting certain sites (to prevent
>> insider attacks)? The impact of encryption is more serious for them and less so
>> for a DNS service provider. What is the BCP advice for them? 
> 
> You are correct that the there are differing concerns but I don’t believe this document should tackle that - the audience of the document is specifically operators of DNS privacy services, typically monitoring to prevent DDoS or similar, not network operators in general (although they may be both in some cases). For the more general case I think the impact is covered in RFC8404 'Effects of Pervasive Encryption on Operators’?
> 
> I do notice a couple of places where just ‘operators’ is used in the text so could add ‘DNS Privacy Service’ before that to clarify?
> 
>> Also, is it fair
>> to say that this is a best current practice? It feels that we need more
>> experience before we start recommending it as an optimization.
> 
> Given the specific scope discussed above I think it is fair. The privacy policies of most of the public resolver operators and ISPs that offer encrypted DNS are pretty good today in terms of how they try to minimise the user data retained and I’m sure they all still have monitoring in place… 
> 
>> 
>> This comment applies to all 5.1.1-5.1.8. Each subsection starts rather abruptly
>> by discussing threats. It would be nice if you add a sentence at the beginning
>> of each sub-section telling the reader what are they heading into. This is
>> probably most obvious from section 5.1.8. Without even telling the reader what
>> is a pure TLS proxy, you start listing the DNS privacy threats. Only later on
>> you mention option that operators may implement DNS-over-TLS using a TLS proxy.
> 
> If we go down this road then I think to be consistent we would need to add text for all 16 sections 5.1.1 to 5.3.3. I could do this but I have a feeling it would be come quite repetitive with respect to the section title text and I think if we could get the titles correct (and possibly add more text to section 5) this might be unnecessary. I suggest:
> 
> Section 5: Add a first paragraph:
> “In the following sections we first outline the threats relevant to the specific topic and then discuss the potential actions that can be taken to mitigate them.”
> 
> And for section 5.1.8 change the title to “Limitations of fronting a DNS Privacy Service with a pure TLS proxy”.
> Happy to update any other headers you thought too vague. 
> 
> Would that address the issue or do you still think additional text is required?
> 
>> 
>> In section 5.3.2 'way and OUGHT obfuscate'. OUGHT is not part of RFC 2119/8174.
>> Why is it capitalized? And, 'ought' ought to be followed by a 'to’.
> 
> I was confused by this and then realised it is a hangover from a much earlier version of the draft that used EXPECTED/OUGHT/MIGHT keywords defined in the draft to described the various levels of actions…. so as you suggest:
> 
> OLD: “For example, a resolver with a very small community of users risks exposing data in this way and OUGHT obfuscate this...”
> 
> NEW: “For example, a resolver with a very small community of users risks exposing data in this way and ought to obfuscate this..."
> 
>> 
>> At the beginning of section 5, you describe three classes of actions. However,
>> none of the subsections contain clear "Additional options" that operators need
>> to follow for "maximal compliance”?
> 
> Sections 5.3.1 and 5.3.2 do have them. In earlier versions several more sections but they have been removed. 
> 
>> 
>> The document seems focused on TLS 1.2 (and does not talk about TLS 1.3). In
>> fact, RFC 8446 is not even in the list of references even though section
>> 5.1.3.1 mentions it. Similarly, Appendix A.2 mentions TLS session resumption
>> without server-side state. How about servers using TLS 1.3 and PSK resumption?
>> RFC 8446 has text on client tracking in appendix C.4:
>> https://tools.ietf.org/html/rfc8446#appendix-C.4 <https://tools.ietf.org/html/rfc8446#appendix-C.4>.
> 
> A slight hangover from the fact the DNS-over-TLS spec was published in 2015 before TLS 1.3 was standardised (so it just says TLS 1.2 or later) and so most of the early DoT services used just TLS 1.2. 
> 
> Section 5.1.3.1 had the text ‘RFC8446’ but it wasn’t actually a reference so I’ve fixed that - thanks.
> 
> I’ve added a bullet point to Appendix A.2
> “RFC8446 Appendix C.4 describes Client Tracking Prevention in TLS 1.3"
> 
>> 
>> There is something wrong about the last sentence of Appendix A.2 'Note that
>> depending on the specifics of the implementation [RFC8484] may also provide
>> increased tracking'. You already mention RFC 8484 in Appendix A.1 as a means to
>> increase privacy. Perhaps you wanted to cite a different RFC here?
> 
> The point is that the use of HTTP headers in DoH can add additional privacy concerns over the other DNS transports, but that RFC8484 leaves that as an implementation decision. I suggest replacing the text with 
> 
> “Note that Section 8 of RFC8484 outlines the privacy considerations of DoH. Depending on the specifics of a DoH implementation there may be increased identification and tracking compared to other DNS transports."
> 
>> 
>> Minor issues:
>> 
>> Nits/editorial comments:
>> 
>> There is mixed usage of Anonymisation (in Table 1) vs Anonymization. The same
>> with Pseudoanonymisation (in Table 1) vs pseudonymization in text. Please check
>> with the RFC editor on what is expected and use that consistently. Also noticed
>> optimisation.
> 
> Thanks - have fixed. I have now used the American English forms (z not s) throughout. 
> 
>> 
>> In Table 1, Crytpographic should be Cryptographic.
> 
> Ack.
> 
>> 
>> Maybe you could use an Oxford comma when using lists of items.
> 
> Had it some places, but not all - should be fixed now.
> 
>> 
>> In section 5.1.2.1, there is stray space character at the end of the bullet on
>> "Follow the guidance in Section 6.5 of [RFC7525] with regards to certificate
>> revocation ..”
>> 
>> Perhaps expand DNSSEC on first usage: Domain Name System Security Extensions
>> (DNSSEC).
>> 
>> In section 5.1.6 'in terms of such options as filtering' should instead be 'in
>> terms of options such as filtering'.
>> 
>> In section 5.1.8 'a DNS aware proxy such as [dnsdist] which offer custom
>> (similar to that proposed in'. Consider using 'offers' instead of 'offer' and
>> 'similar to those proposed in' instead of 'similar to that proposed in'.
>> 
>> In section 5.2.2 'presents and overview' should be 'presents an overview'.
>> Consider rephrasing 'the better to resist brute force'. Also, in 'agreed
>> solution or any Standards to inform', why is standards capitalized?
>> 
>> In section 5.2.4 'queries on multiple TCP session' should be 'queries on
>> multiple TCP sessions'. Please expand CPE on first usage.
>> 
>> In section 6.3 'This is by analogy with e.g. several TLS or website' could
>> instead be 'This is analogous to several TLS or website'.
>> 
>> In Appendix A.1 'documents apply to recursive to authoritative DNS' shouldn't
>> there be an 'and’?
> 
> All fixed - thanks. 
> 
>> 
>> In Appendix C.1, consider changing the format for the sub bullets of '2.  Data
>> collection and sharing.'. Instead of numbering them with 1/2/3, perhaps use
>> a/b/c.
> 
> I’m currently using markdown which won’t let me do that…. :-( I do think that would be better so I suggest adding a note that this is done at RFC editor time….?
> 
>> 
>> In Appendix C.1 'of use of system' could be 'of system use'. Also why is there
>> a line break between 'items that are' and 'included'? There is an extraneous
>> 'the' in 'available with the our threat intelligence'. Consider re-wording
>> parts of paragraph '3. Sharing of data. '. At one place you say 'with our
>> threat intelligence partners' and a few words later you say 'with its threat
>> intelligence partners’.
> 
> Fixed.
> 
>> 
>> In Appendix C.1 'In the event of events or observed behaviors' is a bit hard to
>> parse. Consider rephrasing the 'event of events' part.
> 
> Replaced events with actions.
> 
> Best regards
> 
> Sara. 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 10 Feb 2020 10:36:01 +0000

Hi Sara,

I understand the desire to get this done with. However, I have some further comments in-line:

On 1/24/20 5:29 PM, Sara Dickinson wrote:
Mohit,

I’m out of the office next week so in order to try to move the draft along I have published an -08 version which I think addresses most of your comments (there were a few questions in my response below). Please let me know if any are still outstanding.

Best regards

Sara.

On 17 Jan 2020, at 15:33, Sara Dickinson <[email-masked]<mailto:[email-masked]>> wrote:

On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Reviewer: Mohit Sethi

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Summary:

Major issues:

I was hoping that the text would be more precise rather than a cursory reference to another RFC. You could say something along the lines: 'The TLS client and server MUST use Certificate Status Requests [RFC6066] for the server's certificate chain and the client MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.'. In the same vein, I would expect that you would strongly mandate the use of TLS 1.3 with DoH and DNS over TLS?

I have added a reference for RFC8310 after the first use of ‘authentication domain name’ and made sure every instance of 'authentication name' is updated to 'authentication domain name' for clarity.
Personally, I find the phrase 'Authentication domain name' very unclear. From the phrase, it doesn't look like it has anything to do with DNS? On first reading, I interpreted it as the domain name where I should authenticate. Since the IESG let this through for RFC 8310, I guess we will have to live with this (poor) choice.

Fixed - thanks.

I do notice a couple of places where just ‘operators’ is used in the text so could add ‘DNS Privacy Service’ before that to clarify?
I leave it to Alissa and IESG to decide what they want here.

Also, is it fair

Given the specific scope discussed above I think it is fair. The privacy policies of most of the public resolver operators and ISPs that offer encrypted DNS are pretty good today in terms of how they try to minimise the user data retained and I’m sure they all still have monitoring in place…
My question was specifically about using Bloom filters? Which DNS operators are currently using it? Do we have sufficient evidence other than the research publication that this is 'Best Current Practice'?

Section 5: Add a first paragraph:
“In the following sections we first outline the threats relevant to the specific topic and then discuss the potential actions that can be taken to mitigate them.”thorita

Sections 5.3.1 and 5.3.2 do have them. In earlier versions several more sections but they have been removed. thorita
Okay. Thanks. I hadn't seen this. I have a question related to the following text:

   o  Aggressive Use of DNSSEC-Validated Cache [RFC8198<https://tools.ietf.org/html/rfc8198>] and [RFC8020<https://tools.ietf.org/html/rfc8020>]
      (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
      number of queries to authoritative servers to increase privacy.

Suppose I own the domain mydomain.com? My application requires clients to lookup for non-existent sub domains. So if a client sends a query to the local resolver for non-existent1.mydomain.com and non-existent2.mydomain.com, will both be sent to the authoritative server for mydomain.com?

https://tools.ietf.org/html/rfc8446#appendix-C.4.

Think of the reader of this document. Appendix A.1 says that DoH can increase privacy. The Appendix A.2 says that with DoH 'identification and tracking may be increased'  Should I use DoH or not? I recommend to re-phrase the text in A.2 along the lines 'While DoH can increase privacy, section 8 of RFC 8484 outlines potential mechanisms that can nonetheless be used by on-path adversaries for correlation and tracking. As recommended in RFC 8484, DNS resolvers that offer DoH need to consider the benefit and privacy impact of these features, and their deployment context when deciding what features are enabled. Resolver implementations are advised to expose the minimal set of data needed to achieve the desired feature set.'

Minor issues:

Nits/editorial comments:

Ack.

revocation .”

All fixed - thanks.

Yes, please do. It will help with readability.

Thanks for the rest of the changes.

--Mohit

Fixed.

Best regards

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2020 11:18:40 -0800

On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> I’m out of the office next week so in order to try to move the draft along
> I have published an -08 version which I think addresses most of your
> comments (there were a few questions in my response below). Please let me
> know if any are still outstanding.
>
> Best regards
>
> Sara.
>
> On 17 Jan 2020, at 15:33, Sara Dickinson <[email-masked]> wrote:
>
>
> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <[email-masked]>
> wrote:
>
> Reviewer: Mohit Sethi
> What exactly are you thinking of here - something that just says “Server
> operators should also follow the best practices with regard to OCSP as
> described in RFC7525”? If something more could you please suggest text?
>
> I was hoping that the text would be more precise rather than a cursory
> reference to another RFC. You could say something along the lines: 'The TLS
> client and server MUST use Certificate Status Requests [RFC6066] for the
> server's certificate chain and the client MUST treat a CertificateEntry
> (except the trust anchor) without a valid CertificateStatus extension as
> invalid and abort the handshake with an appropriate alert.'. In the same
> vein, I would expect that you would strongly mandate the use of TLS 1.3
> with DoH and DNS over TLS?
>
Mohit: I actually don't think we should require OCSP at all. For instance,
most browsers are moving away from it. We should require or at least
strongly encourage revocation checking.

-Ekr

> "Authentication domain name: A domain name that can be used to
> authenticate a privacy-enabling DNS server.  Sources of authentication
> domain names are discussed in Section 7."
>
> I have added a reference for RFC8310 after the first use of
> ‘authentication domain name’ and made sure every instance of
> 'authentication name' is updated to 'authentication domain name' for
> clarity.
>
> Personally, I find the phrase 'Authentication domain name' very unclear.
> From the phrase, it doesn't look like it has anything to do with DNS? On
> first reading, I interpreted it as the domain name where I should
> authenticate. Since the IESG let this through for RFC 8310, I guess we will
> have to live with this (poor) choice.
>
>
>
> You are correct that the there are differing concerns but I don’t believe
> this document should tackle that - the audience of the document is
> specifically operators of DNS privacy services, typically monitoring to
> prevent DDoS or similar, not network operators in general (although they
> may be both in some cases). For the more general case I think the impact is
> covered in RFC8404 'Effects of Pervasive Encryption on Operators’?
>
> I do notice a couple of places where just ‘operators’ is used in the text
> so could add ‘DNS Privacy Service’ before that to clarify?
>
> Given the specific scope discussed above I think it is fair. The privacy
> policies of most of the public resolver operators and ISPs that offer
> encrypted DNS are pretty good today in terms of how they try to minimise
> the user data retained and I’m sure they all still have monitoring in
> place…
>
> My question was specifically about using Bloom filters? Which DNS
> operators are currently using it? Do we have sufficient evidence other than
> the research publication that this is 'Best Current Practice'?
>
>
>
> If we go down this road then I think to be consistent we would need to add
> text for all 16 sections 5.1.1 to 5.3.3. I could do this but I have a
> feeling it would be come quite repetitive with respect to the section title
> text and I think if we could get the titles correct (and possibly add more
> text to section 5) this might be unnecessary. I suggest:
>
> “In the following sections we first outline the threats relevant to the
> specific topic and then discuss the potential actions that can be taken to
> mitigate them.”thorita
>
> I was confused by this and then realised it is a hangover from a much
> earlier version of the draft that used EXPECTED/OUGHT/MIGHT keywords
> defined in the draft to described the various levels of actions…. so as you
> suggest:
>
> OLD: “For example, a resolver with a very small community of users risks
> exposing data in this way and OUGHT obfuscate this...”
>
> NEW: “For example, a resolver with a very small community of users risks
> exposing data in this way and ought to obfuscate this..."
>
>
> Sections 5.3.1 and 5.3.2 do have them. In earlier versions several more
> sections but they have been removed. thorita
>
>    o  Aggressive Use of DNSSEC-Validated Cache [RFC8198 <https://tools.ietf.org/html/rfc8198>] and [RFC8020 <https://tools.ietf.org/html/rfc8020>]
> Suppose I own the domain mydomain.com? My application requires clients to
> lookup for non-existent sub domains. So if a client sends a query to the
> local resolver for non-existent1.mydomain.com and
> non-existent2.mydomain.com, will both be sent to the authoritative server
> for mydomain.com?
>
>
>
> A slight hangover from the fact the DNS-over-TLS spec was published in
> 2015 before TLS 1.3 was standardised (so it just says TLS 1.2 or later) and
> so most of the early DoT services used just TLS 1.2.
>
> The point is that the use of HTTP headers in DoH can add additional
> privacy concerns over the other DNS transports, but that RFC8484 leaves
> that as an implementation decision. I suggest replacing the text with
>
> “Note that Section 8 of RFC8484 outlines the privacy considerations of
> DoH. Depending on the specifics of a DoH implementation there may be
> increased identification and tracking compared to other DNS transports."
>
> Think of the reader of this document. Appendix A.1 says that DoH can
> increase privacy. The Appendix A.2 says that with DoH 'identification and
> tracking may be increased'  Should I use DoH or not? I recommend to
> re-phrase the text in A.2 along the lines 'While DoH can increase privacy,
> section 8 of RFC 8484 outlines potential mechanisms that can nonetheless be
> used by on-path adversaries for correlation and tracking. As recommended in
> RFC 8484, DNS resolvers that offer DoH need to consider the benefit and
> privacy impact of these features, and their deployment context when
> deciding what features are enabled. Resolver implementations are advised to
> expose the minimal set of data needed to achieve the desired feature set.'
>
>
>
> Minor issues:
>
> Nits/editorial comments:
>
> I’m currently using markdown which won’t let me do that…. :-( I do think
> that would be better so I suggest adding a note that this is done at RFC
> editor time….?
>
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 10 Feb 2020 19:44:01 +0000

On 2/10/20 9:18 PM, Eric Rescorla wrote:

On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M <mohit.m.sethi=[email-masked]<mailto:[email-masked]>> wrote:

Hi Sara,

Best regards

Sara.

Reviewer: Mohit Sethi

Summary:

Major issues:

I wonder if section 5.1.2.1/5.1.3.1<https://protect2.fireeye.com/v1/url?k=91d59bed-cd5e90d7-91d5db76-86925ec6fd56-2a24500b228246a8&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1> should also talk about recommending OCSP
stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want
to mention it here in section 5.1.2.1/5.1.3.1<https://protect2.fireeye.com/v1/url?k=5f5ab97a-03d1b240-5f5af9e1-86925ec6fd56-8fb25ccf521d98d2&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1>?

Mohit: I actually don't think we should require OCSP at all. For instance, most browsers are moving away from it. We should require or at least strongly encourage revocation checking.

And what is it being replaced with? i found this blog on OCSP stapling in firefox: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/. Is there an updated blog post about new techniques for revocation checking?

--Mohit

-Ekr

Fixed - thanks.

Also, is it fair

Suppose I own the domain mydomain.com<http://mydomain.com>? My application requires clients to lookup for non-existent sub domains. So if a client sends a query to the local resolver for non-existent1.mydomain.com<http://non-existent1.mydomain.com> and non-existent2.mydomain.com<http://non-existent2.mydomain.com>, will both be sent to the authoritative server for mydomain.com<http://mydomain.com>?

Minor issues:

Nits/editorial comments:

Ack.

All fixed - thanks.

In Appendix C.1, consider changing the format for the sub bullets of '2..  Data
collection and sharing.'. Instead of numbering them with 1/2/3, perhaps use
a/b/c.

--Mohit

In Appendix C.1 'of use of system' could be 'of system use'.. Also why is there

Fixed.

Best regards

Sara.

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2020 11:56:51 -0800

On Mon, Feb 10, 2020 at 11:44 AM Mohit Sethi M <[email-masked]>
wrote:

>> I’m out of the office next week so in order to try to move the draft
>> along I have published an -08 version which I think addresses most of your
>> I wonder if section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=91d59bed-cd5e90d7-91d5db76-86925ec6fd56-2a24500b228246a8&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> should also talk about recommending OCSP
>> to mention it here in section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=5f5ab97a-03d1b240-5f5af9e1-86925ec6fd56-8fb25ccf521d98d2&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> ?
>>
>>
> And what is it being replaced with? i found this blog on OCSP stapling in
> firefox:
> https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/.
> Is there an updated blog post about new techniques for revocation checking?
>

https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/

-Ekr

--Mohit
>> If we go down this road then I think to be consistent we would need to
>> add text for all 16 sections 5.1.1 to 5.3.3. I could do this but I have a
>> Suppose I own the domain mydomain.com? My application requires clients
>> to lookup for non-existent sub domains. So if a client sends a query to the
>> non-existent2.mydomain.com, will both be sent to the authoritative
>> server for mydomain.com?
>>
>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Feb 2020 03:39:41 +0000

> https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/

Nice! Hope the experiment goes well as it seems
a good-looking idea. Bit of a pity this mechanism
also pushes towards more centralisation, (IIUC). But
on balance, that's not a huge deal, the Mozilla
version of this being part of the already-centralised
(via browser-makers/root store operators) webpki.

Anyway overall I take this as more evidence that
x.509-based pki has outlived it's useful lifetime.
Given the webpki needs CT (which it totally does)
and now maybe novel revocation mechanisms like this,
(as well as soon-to-be PQ schemes if we believe
what people tell us), I'd argue it may well be time
to try see if there's any consensus on a post-x.509
direction towards which to head.

Cheers,
S.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 11 Feb 2020 13:02:45 +0000

On 2/10/20 9:56 PM, Eric Rescorla wrote:

On Mon, Feb 10, 2020 at 11:44 AM Mohit Sethi M <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sara,

Best regards

Sara.

Reviewer: Mohit Sethi

Summary:

Major issues:

Cool. Thanks for sharing this blog post. I also read the corresponding Oakland paper (available: https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland17.pdf). Cascading bloom filters is indeed a nice optimization that works rather nicely here. While CRLite makes sense, it has some caveats (as Stephen points out in his email). I also wonder about the optimal update frequency. But those are discussions for a separate thread.

For the purpose of this document, I am fine with mandating (or strongly encouraging) revocation checking without mandating OCSP stapling. It is still too early (at least for me) to list CRLite or any variant as a BCP.

--Mohit

-Ekr

--Mohit

-Ekr

Fixed - thanks.

Also, is it fair

Minor issues:

Nits/editorial comments:

Ack.

All fixed - thanks.

--Mohit

Fixed.

Best regards

Sara.