Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Internet Draft: SMTP Strict Transport Security

tools.ietf.org

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Internet Draft: SMTP Strict Transport Security

#61

Post by mned »

yuhong wrote: post #60
mned wrote: post #59

Earlier quoted context omitted.

> It is a selling point in that it simplifies the protocol, making it easier to implement. In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementati…

I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).

Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.

Re: Internet Draft: SMTP Strict Transport Security

#62

Post by yuhong »

mned wrote: post #61
yuhong wrote: post #60

Earlier quoted context omitted.

I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).

Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.

I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.

Re: Internet Draft: SMTP Strict Transport Security

#65

Post by mned »

yuhong wrote: post #62
mned wrote: post #61

Earlier quoted context omitted.

Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.

I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.

You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.

Re: Internet Draft: SMTP Strict Transport Security

#66

Post by wizkkidd »

Disadvantages When Used Without DANE

   When deployed alone (i.e. without a DANE record, and using Web PKI
   for certificate verification), SMTP STS offers the following
   disadvantages compared to DANE:

   o  Infrastructure: DANE may be easier for some providers to deploy.
      In particular, for providers who already support DNSSEC, SMTP STS
      would additionally require they obtain a CA-signed x509
      certificate for the recipient domain.

   o  Security: DANE offers an advantage against policy-lookup DoS
      attacks; that is, while a DNSSEC-signed NX response to a DANE
      lookup authoritatively indicates the lack of a DANE record, such
      an option to authenticate policy non-existence does not exist when
      looking up a policy over plain DNS.

Re: Internet Draft: SMTP Strict Transport Security

#67

Post by yuhong »

mned wrote: post #65
yuhong wrote: post #62

Earlier quoted context omitted.

I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.

You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.

It is just a bunch of ideas at this point and not even a complete list of them.

Re: Internet Draft: SMTP Strict Transport Security

#68

Post by richardwhiuk »

drdaeman wrote: post #48

Can't we pretty much please make it reasonably generic and not SMTP-specific? There are a lot of protocols (say XMPP, IRC or IMAP) around that have opportunistic encryption with STARTTLS-like semantics. Surely, they could all benefit from a similar solution.

XMPP is easy to enforce SSL connections on...

Re: Internet Draft: SMTP Strict Transport Security

#69

Post by Natanael_L »

tptacek wrote: post #35
nly wrote: post #32

Earlier quoted context omitted.

I don't know where to begin. > Arguments like this presuppose that the TLS security system is exactly as it was in 1999 For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about sec…

TLSA records do not have that capability, and, more importantly, the root of trust for TLSA records are organizations controlled by the government . The "Five Eyes" partnership can replace signatures for any DNSSEC domain in .COM, .NET, .ORG, .EDU, .UK, .AU, and .IO. It seems crazy to me that, after years of hyperventilating about the implications of the Snowden disclosures, anyone could take DNSSEC seriously. But pe…

Forged DNSSEC replies are inherently more public than forged TLS certificates, anybody can log the results and publish them.

And by doing so, the world would have evidence that somebody in that trust chain for that TLD has been lying. For TLS, that could be any CA in the world, which means that the number of single points of failure for services on DNSSEC is waaay lower. Because with DNSSEC you at least can chose who has the capability of forging results, with TLS alone that's all of the CA:s.

And why couldn't one combine the approaches anyway, using DNSSEC+DANE with certificate pinning? How would that possibly reduce security vs using standard DNS?

Re: Internet Draft: SMTP Strict Transport Security

#70

Post by AndyMcConachie »

tptacek wrote: post #16

Successful deployment of STS would bring to zero the number of real-world use cases for DNSSEC/DANE, which would be a very good thing.

Read the draft dude. STS is designed to interoperate with DANE.

Also, if you deploy your STS info via DNS you'll need DNSSEC validation to to ensure that what you read in DNS is actually what the zone holder put there. Without DNSSEC how does a sending SMTP daemon trust the STS policy of the recipient zone. STS policies are stored in DNS TXT records, or their own new RR.

Post reply on HN