tlswg/tls-subcerts

Security Considerations: network layer

Closed this issue · 5 comments

The paper below, and several others, concern "...prefix hijacking on the network layer, which may lead to traffic blackholing or transparent interception".

https://dl.acm.org/citation.cfm?id=2834102

How does this draft interact with problems in things like BGP? Could it make those kinds of problems even more difficult to track down? This is not an objection, but I was surprised not to see it in the Security Considerations.

ekr commented

I'm not seeing the connection. We generally assume an RFC 3552 Dolev-Yao style attacker, and the first section explicitly talks about theft of the signing key.

I don't think I'm talking about "theft of the signing key", although maybe the definition is more broad than I thought.

The issue raised in the various BGP/TLS presentations and papers is that applications trust a lot of roots, those roots issue intermediate certificates, etc. Standardizing short-term delegated credentials seems like it might raise many of the same problems--with benefits as well, of course.

Alternatively, if there's an RFC that describes this issue, a short citation might help. I looked for one, but didn't find anything.

ekr commented

Now I'm really not following. DCs just extend the existing EE cert and we assume that the DCs are issued by direct trust, not domain validation. I don't see how this BGP/TLS point is relevant to this draft. Indeed, TLS generally treats the whole PKI as someone else's problem, so it wouldn't really be relevant for 8446 either.

DCs are issued by direct trust, not domain validation.
...
TLS generally treats the whole PKI as someone else's problem

That is a sensible position to take. Is there any WG or draft that has addressed this problem? I started wondering because the "direct trust" you mention seemed imprecise to me, and I wondered whether this draft could make it more difficult to detect BGP hijacking after the fact.

ekr commented

It's imprecise because it's not our problem. What I mean by "direct trust" is "the same person/org who controls the end-entity cert also controls which DCs get issues", so this is not somethign we specify.

I don't see how this makes BGP hijacking harder to detect. If you think it does, please lay out how.