2013.02.20 20:36:07 (304313501508325377) from Daniel J. Bernstein, replying to "Tony Finch (@fanf)" (304307676576358400):
@fanf @colmmacc @matthew_d_green Those proposals destroy _all_ of the claimed advantages of DNSSEC+HTTPSEC while keeping the problems.
2013.02.20 11:54:28 (304182226495614978) from Daniel J. Bernstein, replying to "Matthew Green (@matthew_d_green)" (304051839433838592):
@matthew_d_green No, no, no. HTTPSEC's only ability is to sign redirects. The designers were trying to keep the protocol simple.
2013.02.20 20:04:08 (304305454123716608) from "Tony Finch (@fanf)":
@hashbreaker @matthew_d_green can you translate that into DNSSEC for me? because it does not just sign referrals.
2013.02.20 20:07:49 (304306378481213440) from "Colm MacCárthaigh (@colmmacc)", replying to "Tony Finch (@fanf)" (304305454123716608):
@fanf @hashbreaker @matthew_d_green DNS serves routing data, not content data.
2013.02.20 20:12:58 (304307676576358400) from "Tony Finch (@fanf)", replying to "Colm MacCárthaigh (@colmmacc)" (304306378481213440):
@colmmacc @hashbreaker @matthew_d_green and TLSA or SSHFP couple the DNS chain of trust to the content transport, so what's missing?