3 ms·

>Not if the connection is encrypted, as was stipulated. Hmm, yes, there does appear to be some confusion. I misread artursapek and missed the "encrypted connec

>Not if the connection is encrypted, as was stipulated. Hmm, yes, there does appear to be some confusion. I misread artursapek and missed the "encrypted connection" part. Assuming "encrypted connection" refers to the connection to the website, then my question is what is telling the connection to be encrypted? The article is about current non-encrypted connections. So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that.

teddyh 7y ago
> So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that. HSTS is already being used for this, although it uses a TOFU-like model where the very first connection is vulnerable to MITM downgrade. DANE (which uses DNSSEC) does not have this problem, and could be used for this, but it’s the browser vendors who would have to be convinced to implement it, and I don’t have high hopes.
- tptacek 7y ago
  DANE does in practice have this problem; see the chain-extension fiasco. A lot of these things look like they work until you actually try to get a browser to do them.
  - teddyh 7y ago
    I can’t seem to find what you are referring to. Could you specify what the problem is?
    - tptacek 7y ago
      From memory, but you can just look it up: DANE is untenable in browsers because (1) it's much too slow and (2) a lot of networks won't pass DANE lookups; if your HTTPS connection relies on DNSSEC/DANE "just working", the web breaks for those people. So instead, you staple DANE records to the TLS handshake with an extension. But that's incoherent: the purpose of DANE is to establish a root of trust for TLS connections, but the extensions carried in a TLS handshake depend on a root of trust. In practice, if you can get an X.509 certificate issued, you can strip stapled DANE records. So there's no point to stapling DANE records. Solution: dynamic pinning and continuity over multiple connections.
      - teddyh 7y ago
        > DANE is untenable in browsers because Neither of those things make sense to me: > (1) it's much too slow Browsers already do A/AAAA DNS lookups, which presumably does not present any huge latency issue. If latency would be a problem, DNS servers could send the additional DANE records in the “additional” section, just like they do now with an A or AAAA query leading to a CNAME record; this would completely eliminate any additional latency with DANE. > and (2) a lot of networks won't pass DANE lookups I don’t think so; if that were the case, DANE would not be rolled out as widely as it is for SMTP.
        tptacek 7y ago
        I'm not making either of those up; you can find them at the top of the chain-extensions draft, which is a collaboration between Mozilla and DNSSEC people. Both are also in Adam Langley's "Why Not DANE In Browsers" post. I'm pretty confident these are real issues, and not really a productive live debate for HN.
        teddyh 7y ago
        You’re merely making an argument from authority, not responding to anything I wrote. Furthermore, that blog post is both old (and itself refers to even older references to back up its claims, and has a large discussion of now-fixed issues in DNSSEC) and it also presents an incomplete list of reasons for why DANE might be wanted. It is ignoring DANE’s HTST-like feature of signalling that HTTPS must be used, to prevent protocol downgrade attacks, which is exactly the reason we are discussing DANE here.
        tptacek 7y ago
        I can no longer keep track of what you're trying to argue. The chain-extensions debacle is less than a year old. It was motivated by the same concerns as the AGL article. Since you acknowledged upthread not being aware of chain-extensions in the first place, despite it being a big-ticket issue for DANE deployment (enough for Geoff Huston to write a whole article bemoaning its failure as a standard) I'm not sure from where you're drawing the certitude that these issues aren't real.

teddyh 7y ago

> So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that. HSTS is already being used for this, although it uses a TOFU-like model where the very first connection is vulnerable to MITM downgrade. DANE (which uses DNSSEC) does not have this problem, and could be used for this, but it’s the browser vendors who would have to be convinced to implement it, and I don’t have high hopes.

tptacek 7y ago
DANE does in practice have this problem; see the chain-extension fiasco. A lot of these things look like they work until you actually try to get a browser to do them.
- teddyh 7y ago
  I can’t seem to find what you are referring to. Could you specify what the problem is?
  - tptacek 7y ago
    From memory, but you can just look it up: DANE is untenable in browsers because (1) it's much too slow and (2) a lot of networks won't pass DANE lookups; if your HTTPS connection relies on DNSSEC/DANE "just working", the web breaks for those people. So instead, you staple DANE records to the TLS handshake with an extension. But that's incoherent: the purpose of DANE is to establish a root of trust for TLS connections, but the extensions carried in a TLS handshake depend on a root of trust. In practice, if you can get an X.509 certificate issued, you can strip stapled DANE records. So there's no point to stapling DANE records. Solution: dynamic pinning and continuity over multiple connections.
    - teddyh 7y ago
      > DANE is untenable in browsers because Neither of those things make sense to me: > (1) it's much too slow Browsers already do A/AAAA DNS lookups, which presumably does not present any huge latency issue. If latency would be a problem, DNS servers could send the additional DANE records in the “additional” section, just like they do now with an A or AAAA query leading to a CNAME record; this would completely eliminate any additional latency with DANE. > and (2) a lot of networks won't pass DANE lookups I don’t think so; if that were the case, DANE would not be rolled out as widely as it is for SMTP.
      - tptacek 7y ago
        I'm not making either of those up; you can find them at the top of the chain-extensions draft, which is a collaboration between Mozilla and DNSSEC people. Both are also in Adam Langley's "Why Not DANE In Browsers" post. I'm pretty confident these are real issues, and not really a productive live debate for HN.
        teddyh 7y ago
        You’re merely making an argument from authority, not responding to anything I wrote. Furthermore, that blog post is both old (and itself refers to even older references to back up its claims, and has a large discussion of now-fixed issues in DNSSEC) and it also presents an incomplete list of reasons for why DANE might be wanted. It is ignoring DANE’s HTST-like feature of signalling that HTTPS must be used, to prevent protocol downgrade attacks, which is exactly the reason we are discussing DANE here.
        tptacek 7y ago
        I can no longer keep track of what you're trying to argue. The chain-extensions debacle is less than a year old. It was motivated by the same concerns as the AGL article. Since you acknowledged upthread not being aware of chain-extensions in the first place, despite it being a big-ticket issue for DANE deployment (enough for Geoff Huston to write a whole article bemoaning its failure as a standard) I'm not sure from where you're drawing the certitude that these issues aren't real.