Subject: Re: Skipping DNS resolutions with ORIGIN frame

From: Erik Nygren <[email-masked]>
Date: Sat, 15 Jul 2017 12:47:49 -0400

My concerns align with Ryan and Mike's.  My preference would be to remove
the current language about not consulting DNS from the ORIGIN draft (having
it focus on restricting scope with hooks for future expansion).

Separately we can start collaborating on a draft that finds a good set of
controls to give the balance of security and privacy and performance
properties.  Alt-Svc (perhaps with an extension attribute?) does seem like
a good starting point as it gives positive control from an Origin.  The
other ideas (eg, something CT like) seem intriguing but need more
exploration.

- Erik

On Jul 15, 2017 1:36 AM, "Patrick McManus" <[email-masked]> wrote:

> Hey Ryan, thanks for the comments.
>
> On Fri, Jul 14, 2017 at 3:18 PM, Ryan Hamilton <[email-masked]> wrote:
>
>> . It is crystal clear that saving DNS resolutions represents a real
>> performance win, especially for long-tail users.
>>
>>
> I want to re-emphasize here that I believe a perhaps larger win here is
> the privacy implication of a lookup never made - especially when combined
> with secondary certificates and exported authentiactors (still to come to
> h2). This achieves much of what encrypted SNI could do.
>
> My first question is would you be ok with just loosening the draft
> language a little bit.. i.e. instead of saying must not consult DNS, define
> this in a way that it is the client's decision.
>
> As I've said before, I don't think the DNS is providing any real value
> here now that ORIGIN is playing the role of traffic routing. Indeed it is
> creating a privacy cost - so I'm eager to get it out of the loop.
>
> If we can't get consensus on that I'd prefer some kind of stapled
> assertion that kept the perf and privacy properties of the current draft. I
> guess that could be dnssec though that would certainly limit use for imo
> limited value.. I'm not sure I fully understand what you're thinking of wrt
> expect-ct -does it fit that model?
>
> -Patrick
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Jul 2017 20:59:46 +0300

> other ideas (eg, something CT like) seem intriguing but need more

Let's take four schemes:

1) No checks (beyond usual certificate checks)
2) Require CT qualification (and possibly OCSP).
3) ALT-SVC (not entierely clear to me, but I can guess)
4) Consult DNS

For privacy and speed, 1) and 2) have big advantage over 3) and 4)
(and 3) is even worse than 4) in both)..

For security using standard assumptions, all are very close to one
another. 

The main problem with not giving control seems to be servers that have
overly wide certificates and then mishandle requests (through sadly
most servers do mishandle requests).

-Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Sun, 16 Jul 2017 10:15:26 +0000

There is merit to both sides. Requiring DNS adds a weak second factor for
routing decisions, which is useful in multi-CDN situations, or extra-broad
certificates, where you want to prevent a CDN from routing extra traffic
via ORIGIN. On the other hand, skipping DNS is a big step forward for both
performance and privacy, it basically solves the encrypted SNI issue.

The question we should ask is: who should make the determination of whether
or not the user agent should check DNS given an origin frame? This
discussion shows there is no consensus that the answer is that the ORIGIN
proposal makes this explicit. Given differing views from browser
representatives, the answer might be that it's up to the user agent to
decide. However, server operators don't seem too happy about dealing with
divergent client behaviors, so it doesn't seem that letting the UA decide
is feasible.

I think the answer that makes sense is to allow the site owner decide if
content for its domain should require a DNS check or not. Martin Thomson
was on to something with his certificate extension idea in the Github
discussion. The policy around the requirement for DNS can be set in the
certificate.

How do people feel about adding a certificate extension with a meaning
along the lines of "require DNS"? Site owners with multi-CDN setups could
give such a cert to third parties they want to handle direct traffic, but
not be able to coalesce into an existing connection.

Alternatively there could be a "skip DNS" extension, which tells the
browser that the site owner has delegated routing from DNS to the cert
holder, and that DNS checks are superfluous.

Thoughts?

Nick

---

From: Piotr Sikora <[email-masked]>
Date: Sun, 16 Jul 2017 13:18:29 +0200

As mentioned on GitHub [1], where we also discussed this, I believe
that the "skip DNS" extension makes sense, provided that it's used
together with CT.

But if we go that route, then that extension might be a bit more
generic and perhaps not restricted to the ORIGIN frame, in which case
the ORIGIN frame draft should re-focus on restricting the scope of the
origin-set and not bypassing DNS, as suggested by Erik.

[1] https://github.com/httpwg/http-extensions/issues/330

Best regards,
Piotr Sikora

On Sun, Jul 16, 2017 at 12:15 PM, Nick Sullivan
<[email-masked]> wrote:
> certificates, where you want to prevent a CDN from routing extra traffic via
> ORIGIN. On the other hand, skipping DNS is a big step forward for both
> divergent client behaviors, so it doesn't seem that letting the UA decide is
> feasible.
>
> content for its domain should require a DNS check or not. Martin Thomson was
> on to something with his certificate extension idea in the Github
> How do people feel about adding a certificate extension with a meaning along
> the lines of "require DNS"? Site owners with multi-CDN setups could give
> such a cert to third parties they want to handle direct traffic, but not be
> able to coalesce into an existing connection.
>
> Alternatively there could be a "skip DNS" extension, which tells the browser
> that the site owner has delegated routing from DNS to the cert holder, and
> that DNS checks are superfluous.
>
> Thoughts?
>
> Nick
>
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 16 Jul 2017 18:35:01 +0300

> that the "skip DNS" extension makes sense, provided that it's used

Unfortunately, certificate extensions have a few problems here:

- Probably takes a long time for many CAs to support them, or to get
  support that allows the extension be requested via CSR, as other 
  methods are a PITA.
- It is just as easy to get misissued certificate with this
  extension as one without (provoded CA that misisues supports this
  extension)!
- In which case I would want a certificate without this extension?
  (the decision weither to actually coalesce or not can be rather
  complicated one... Even when it does not involve perverse
  incentives, like in that "CDN policy" case in the issue).

> origin-set and not bypassing DNS, as suggested by Erik.

Oh, and with regards with my earlier comment about many servers
mishandling origins, I suppose that if server actually sends an ORIGIN
for given origin, it can actually properly handle that origin. As the
the overwhelmingly most common source of mishandling is default
virtual hosts.

-Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Sun, 16 Jul 2017 16:05:11 +0000

>   support that allows the extension be requested via CSR, as other

I actually don't see this as a particularly high barrier. Only a few
high-powered sites that use a multi-CDN strategy are going to need it
(assuming it's a "require DNS" extension). They have a lot of leverage over
their CAs.

>   extension as one without (provoded CA that misisues supports this

This is why CT is an important requirement. If a CA issues such a cert, it
is misissuance will be caught.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 16 Jul 2017 19:25:27 +0000 (UTC)

On Sun, Jul 16, 2017 at 12:15 PM, Nick Sullivan <[email-masked]

> performance and privacy, it basically solves the encrypted SNI issue.
I think this notion of exchanging the DNS weak second factor for some other
factor(s) with better perf and privacy properties is promising. Let's work
with that and thanks especially to Ryan for getting the conversation going
in that general direction.

First, I'd like to add to the ORIGIN benefit list - beyond perf and privacy
I believe ORIGIN is operationally superior to the DNS coalescing of 7540.
By 7540 rules this DNS test will fail any time the zone operator can't
return a set that matches the resolution that happened when the connection
was established. For any DNS server that has more addresses to choose from
than it puts in the RR set, this can be a challenge. I _know_ that 7540
coalescing fails all of the time because of this (and if it were because of
traffic management (which it generally is not because I've debugged it with
the operators) then ORIGIN provides a finer control for that anyhow)

ISTM the primary concern is that the DNS provision amplifies the power of
the certificate (depending on how much value you think DNS has a second
factor that could be by a factor of 1.0001 to MAXINT - we probably don't
need to come to consensus on it) in the case of misissuance or compromise.

So curating from the ideas floating around I would suggest that a origin
client MUST skip the DNS check if
a] the connection certificate used to validate the origin comes with SCT.
This is to mitigate against mis-issuance. Given that we can expect all
public certifcates published a year from now to deal with CT, this seems
pretty easy operationally to me.

b] the connection certificate used to validate the origin passes a
revocation check. This is to mitigate against compromise. In the case OCSP
was not stapled the client could choose between ocsp and just doing the dns
(or ignoring the origin extension). So there
is motivation to staple.

I don't think we want to make a certificate extension that says "opt-in to
skip DNS" (it is tatamount in some ways to selecting for people who have
something to hide that they're willing to put in the work to deal with
certificate changes - not a good privacy feature)..

-Patrick

---

From: Emily Stark <[email-masked]>
Date: Mon, 17 Jul 2017 01:40:33 -0700

On Sun, Jul 16, 2017 at 12:25 PM, Patrick McManus <[email-masked]>
wrote:

> On Sun, Jul 16, 2017 at 12:15 PM, Nick Sullivan <
> [email-masked]> wrote:
>
> I think this notion of exchanging the DNS weak second factor for some
> other factor(s) with better perf and privacy properties is promising. Let's
> work with that and thanks especially to Ryan for getting the conversation
> going in that general direction.
>
> First, I'd like to add to the ORIGIN benefit list - beyond perf and
> privacy I believe ORIGIN is operationally superior to the DNS coalescing of
> 7540. By 7540 rules this DNS test will fail any time the zone operator
> can't return a set that matches the resolution that happened when the
> connection was established. For any DNS server that has more addresses to
> choose from than it puts in the RR set, this can be a challenge. I _know_
> that 7540 coalescing fails all of the time because of this (and if it were
> because of traffic management (which it generally is not because I've
> debugged it with the operators) then ORIGIN provides a finer control for
> that anyhow)
>

Do you mean literally comes with a single SCT? Or complies with the
client's CT policy (which might require multiple SCTs)? Is it reasonable to
assume that all clients implementing ORIGIN will also implement CT?

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Jul 2017 19:28:04 +0200 (CEST)

On Mon, 17 Jul 2017, Emily Stark wrote:

> Is it reasonable to assume that all clients implementing ORIGIN will also 
> implement CT?

I think that's a stretch. It is easy to see how supporting ORIGIN can be an 
obvious benefit to a lot of libraries and tools (ie non-browsers) that want to 
coalesce/reuse connections better and that might very well be implemented 
without doing CT or at least independently of it.

-- 

  / daniel.haxx.se

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 18 Jul 2017 07:34:24 +0000

+1 for the requirement for CT. I feel uncomfortable skipping DNS without requiring at least CT.

As for OCSP stapling, I can see the argument for requiring it, but I would also like to offer short lived certificates or delegated credentials (https://tools.ietf.org/html/draft-rescorla-tls-subcerts-01) as equivalent requirement.

In general I think it's incredibly valuable to define the guidelines for skipping DNS in the specification. This makes it easier for service operators to be able to use this functionality in a uniform manner. These guidelines were missing for PUSH which made it very hard to use.

Subodh

________________________________
From: Daniel Stenberg <[email-masked]>
Sent: Monday, July 17, 2017 10:28:04 AM
To: Emily Stark
Cc: Patrick McManus; Nick Sullivan; Ilari Liusvaara; Erik Nygren; Piotr Sikora; Ryan Hamilton; [email-masked]
Subject: Re: Skipping DNS resolutions with ORIGIN frame

--

  / daniel.haxx.se

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 18 Jul 2017 11:05:27 +0300

On Tue, Jul 18, 2017 at 07:34:24AM +0000, Subodh Iyengar wrote:
> As for OCSP stapling, I can see the argument for requiring it, but I 
> would also like to offer short lived certificates or delegated
> credentials (https://tools.ietf.org/html/draft-rescorla-tls-subcerts-01)
> as equivalent requirement.

Note that delegated credentials do not replace OCSP. E.g., handling key
compromise of the issued EE certificate.

And yes, short-lived certificates can be used to replace OCSP stapling:
In WebPKI, if OCSP response valid to EoL of the certificate is signed,
the certificate becomes effectively impossible to revoke.

Since normal OCSP lifetime in WebPKI (not refresh interval, which must
be shorter for things to work properly) is 7 days, it follows that
certificates that are valid for at most 7 days do not need OCSP
stapling. The 7 days figure also pops up in TLS 1.3, when operation
independent of certificates is concerned.

> In general I think it's incredibly valuable to define the guidelines
> for skipping DNS in the specification. This makes it easier for
> service operators to be able to use this functionality in a uniform
> manner. These guidelines were missing for PUSH which made it very
> hard to use.

Are you referring to more exotic ways to use PUSH, e.g. pushed cache
invalidation? Those look to be rather subtle.

(There are other problems with PUSH, like controlling resources to
push from web application and guessing what to send, but I think that
would be much beyond the scope of HTTP/2 RFC).

-Ilari

---

From: Emily Stark <[email-masked]>
Date: Tue, 18 Jul 2017 10:36:12 +0200

> independent of certificates is concerned.

I imagine that the definition of a strong revocation check is going to vary
from client to client. For example in Chrome I'm not sure that it would be
reasonable to require OCSP/short-lived cert if the certificate is covered
by a fresh CRLSet.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 18 Jul 2017 08:44:22 +0000 (UTC)

>
> I imagine that the definition of a strong revocation check is going to
> vary from client to client.
>

+1.

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 18 Jul 2017 09:17:35 +0000

I'm referring to that the delegated credential has a requirement to be short lived as well. You're right that it doesn't imply a physical separation between the long term private key and the short term private key, however practically it will be deployed as such. So that's why I offered it up as an alternative to short lived certs and we can add a caveat as such.

> I imagine that the definition of a strong revocation check is going to vary from client to client.

It is useful to have a document how the revocation mechanisms apply to ORIGIN. For example most people have no idea what a fresh CRLSet would be and updating the CRLSet is not under their control. For example if a CRLset is not fresh, the latency of requests might increase and a server operator would have no idea why that happened. I don't think we have to enforce a MUST, but at least documenting them would be incredibly useful.

Ya there are some weird rules in how stuff gets into the http cache which I believe differs between browsers which aren't really documented anywhere.

Subodh

________________________________
From: Patrick McManus <[email-masked]>
Sent: Tuesday, July 18, 2017 1:44:21 AM
To: Emily Stark
Cc: Ilari Liusvaara; Subodh Iyengar; [email-masked]
Subject: Re: Skipping DNS resolutions with ORIGIN frame

I imagine that the definition of a strong revocation check is going to vary from client to client.

+1.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 10:37:30 +0000

Daniel,

If the client doesn't send the "SCT" or "OCSP Stapling" support, then the
server can't send them. What if the requirement for OCSP Stapling and CT
Qualification was contingent on the client sending that extension? If the
client supports CT and/or OCSP, then the server must send them for the
client to accept the ORIGIN. If the client does not advertise support for
these features, then they're not mandatory for the client to accept ORIGIN.

Nick

---

From: Patrick McManus <[email-masked]>
Date: Tue, 18 Jul 2017 12:37:22 +0000 (UTC)

> assume that all clients implementing ORIGIN will also implement CT?

Thanks Emily.

I think you're right that we mean SCT policy. I also wonder if we shouldn't
say something like "if the origin doesn't meet the client's  ct/revocation
requirements it[*] MUST be ignored" rather than having the client do the
DNS lookup.. it seems to me like that could leak some domain names for
little value.

[*] it here means the origin in the origin frame... not blacklisting that
origin from the whole client :)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Jul 2017 15:21:57 +0200

Editor hat on.

The spec currently contains:

"""
* Clients MUST NOT consult DNS to establish the connection's authority for new requests. The TLS
  certificate MUST still be used to do so, as described in {{!RFC7540}} Section 9.1.1.
"""

It sounds like we're moving towards something more like this:

"""
Clients MAY ignore the requirement in {{RFC7540}} to check DNS when establishing a connection's authority for new requests, but the TLS certificate covering any additional origins MUST still be used to do so, as described in {{!RFC7540}} Section 9.1.1. Additionally, such certificates MUST adhere to client policy regarding revocation and certificate transparency {{trans ref}}.
"""

Thoughts / suggestions / modifications? 

One thing that's been discussed is requiring either a) one of a selection of techniques as a "second factor", b) a specific one (e.g., CT). I *think* the details of that is the big question remaining.

I'm not including that in the version above yet because historically, we've been shy of specifying client policies in HTTP specs. Discuss.

(There's a fair amount of other editorial work this will entail to get it to integrate well into the text, but I think that's the meat of it)

> On 18 Jul 2017, at 2:37 pm, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> Do you mean literally comes with a single SCT? Or complies with the client's CT policy (which might require multiple SCTs)? Is it reasonable to assume that all clients implementing ORIGIN will also implement CT?
> 
> Thanks Emily.
> 
> I think you're right that we mean SCT policy. I also wonder if we shouldn't say something like "if the origin doesn't meet the client's  ct/revocation requirements it[*] MUST be ignored" rather than having the client do the DNS lookup.. it seems to me like that could leak some domain names for little value.
> 
> [*] it here means the origin in the origin frame... not blacklisting that origin from the whole client :)
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jul 2017 07:59:47 -0700

On Tue, Jul 18, 2017 at 6:21 AM, Mark Nottingham <[email-masked]> wrote:

> Clients MAY ignore the requirement in {{RFC7540}} to check DNS when
> establishing a connection's authority for new requests, but the TLS
> certificate covering any additional origins MUST still be used to do so, as
> described in {{!RFC7540}} Section 9.1.1. Additionally, such certificates
> MUST adhere to client policy regarding revocation and certificate
> transparency {{trans ref}}.
> """
>

This language seems a bit confusing. Usually, MUSTs are intended to impose
requirements on the server, but there's no way for the server to know if
they are meeting client expectations. One could of course invert this to
make it a requirement on clients, but then it's just a tautology that the
client has to enforce client policies.

-Ekr

>
> One thing that's been discussed is requiring either a) one of a selection
> of techniques as a "second factor", b) a specific one (e.g., CT). I *think*
> the details of that is the big question remaining.
>
> I'm not including that in the version above yet because historically,
> we've been shy of specifying client policies in HTTP specs. Discuss.
>
> (There's a fair amount of other editorial work this will entail to get it
> to integrate well into the text, but I think that's the meat of it)
>
>
> > I think you're right that we mean SCT policy. I also wonder if we
> shouldn't say something like "if the origin doesn't meet the client's
> ct/revocation requirements it[*] MUST be ignored" rather than having the
> client do the DNS lookup.. it seems to me like that could leak some domain
> names for little value.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Jul 2017 17:01:53 +0200

> On 18 Jul 2017, at 4:59 pm, Eric Rescorla <[email-masked]> wrote:
> 
> This language seems a bit confusing. Usually, MUSTs are intended to impose requirements on the server, but there's no way for the server to know if they are meeting client expectations. One could of course invert this to make it a requirement on clients, but then it's just a tautology that the client has to enforce client policies. 

Yeah. Like I said, we don't usually specify this sort of detail in HTTP-land, hence the vagueness. We can change that, of course.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jul 2017 17:09:38 +0200

I think that you might want to say that the client might want to
stipulate some additional constraints on the validation of the
certificate before it chooses not to make the request.  This will be
up to client policy.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Jul 2017 16:41:18 +0000

I'd either say something like "Clients opting not to check DNS SHOULD employ some alternative means to increase confidence that the certificate is legitimate, such as Certificate Transparency or revocation checks," or just stop after the first sentence.  If it's a MAY, then it's up to the clients under what specific conditions they employ it.  The main reason, in my mind, for adding the second sentence is to inform less-security-aware developers that they shouldn't just toss DNS out the window without having something else in hand.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2017 6:22 AM
To: Patrick McManus <[email-masked]>
Cc: Emily Stark <[email-masked]>; Nick Sullivan <[email-masked]>; Ilari Liusvaara <[email-masked]>; Erik Nygren <[email-masked]>; Piotr Sikora <[email-masked]>; Ryan Hamilton <[email-masked]>; [email-masked]
Subject: Re: Skipping DNS resolutions with ORIGIN frame

Editor hat on.

"""

"""

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cc5df925db14a405978a308d4cde07d56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359811454583008&sdata=tWKd9qRMXhw4U2T0AuHonrlDw6mIhLqVQDqREeXTTqY%3D&reserved=0

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 18 Jul 2017 11:47:58 -0700

On Tue, Jul 18, 2017 at 9:41 AM, Mike Bishop <[email-masked]>
wrote:

> I'd either say something like "Clients opting not to check DNS SHOULD
> employ some alternative means to increase confidence that the certificate
> is legitimate, such as Certificate Transparency or revocation checks," or
> just stop after the first sentence.  If it's a MAY, then it's up to the
> clients under what specific conditions they employ it.  The main reason, in
> my mind, for adding the second sentence is to inform less-security-aware
> developers that they shouldn't just toss DNS out the window without having
> something else in hand.
>

This seems like the right direction to me.​

---

From: Erik Nygren <[email-masked]>
Date: Tue, 18 Jul 2017 18:31:34 -0400

On Tue, Jul 18, 2017 at 2:47 PM, Ryan Hamilton <[email-masked]> wrote:

> On Tue, Jul 18, 2017 at 9:41 AM, Mike Bishop <[email-masked]
> > wrote:
>

To me as well.  Based on the discussion above, CT and revocation checks are
addressing different threats, so "Certificate Transparency AND some
revocation checking mechanism" may not be appropriate.  "Additional" is
also better than "alternative" since this is above and beyond other
checking normally done.

We may also want to explicitly suggest (in Security Considerations?) that
clients SHOULD NOT trust certs side-loaded outside of the trust chain for
coalescing.  Otherwise this makes it much easier for MitM appliances to
slurp up traffic without even needing to be on-path.

What I means is that if I connection to www.example.org which presents an *.
> example.org certificate, I need some second piece of information before
> using it for mail.example.com. In the alt-svc case, if an earlier
> connection to mail.example.org advertised alt-svc for www.example.org,
> then I would be comfortable coalescing the connection​ and would not need
> to do any resolution of mail.example.org.
>

While this does still require going back to mail.example.com at least once
(so doesn't help for the privacy scenario), it may be worth considering
this. In particular, if multiple origins all Alt-Svc to the same server
name (and perhaps also include a "coalesce=1" attribute to the Alt-Svc?)
then this may also be a good enough indication of positive control by the
origins when combined with normal cert validation?

In a side-discussion in Chicago, there was a conversation around "signed
Alt-Svc attestations" that could be distributed out-of-band from requests
(e.g., signed by a cert covering the origin with a special cert extension
and perhaps also logged in a CT log) and combining those with server-pushed
certs to enable coalescing and skipping DNS (for privacy and performance
purposes).  This seems to have similar security properties and threat
vectors to some of what we're discussing.  Factoring out the security
analysis and mitigations to generalize across these might be useful?

Mark Nottingham wrote:
>
> Yeah. Like I said, we don't usually specify this sort of detail in
> HTTP-land, hence the vagueness. We can change that, of course.

The challenge is that attackers won't be constrained by layer boundaries,
and the practical attacks here likely come from creatively exploiting
weaknesses spanning a few layers, especially if we are removing inter-layer
constraints (eg, DNS following that used to be present).  As such, our
specific mitigations or recommendations may also need to cross layers more
than usual.

      Erik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Jul 2017 14:57:03 +1000

> On 19 Jul 2017, at 8:31 am, Erik Nygren <[email-masked]> wrote:
> 
>> On Tue, Jul 18, 2017 at 9:41 AM, Mike Bishop <[email-masked]> wrote:
> To me as well.  Based on the discussion above, CT and revocation checks are addressing different threats, so "Certificate Transparency AND some revocation checking mechanism" may not be appropriate.  "Additional" is also better than "alternative" since this is above and beyond other checking normally done.

...

> The challenge is that attackers won't be constrained by layer boundaries, and the practical attacks here likely come from creatively exploiting weaknesses spanning a few layers, especially if we are removing inter-layer constraints (eg, DNS following that used to be present).  As such, our specific mitigations or recommendations may also need to cross layers more than usual.

I was trying to say that we don't want to MUST a particular solution (e.g., a CT or revocation check), since we don't go to that level of detail currently. You seem to agree with this approach above, or do I read that wrong?

Regards,