duplicate

[azet]

Hi,

There's already a couple of proposals being worked on in that direction. One is called DEEP [0]. I've presented a similar solution to your draft to UTA in july at IETF93 and on list (though not very formal) [1] using JSON instead of XML -- which could also be used for MTA-MTA, though this is an issue. DEEP actually brings security indications for user-agents as well. For MTA to MTA traffic we have a huge problem with fallback: which is, of course, plaintext if we fail to establish any new scheme properly between servers. TACK and a local cache could do, I've written about this to UTA [1] multiple times [2]. I've also presented our preliminary e-mail TLS-enumeration results at IETF93 in the security area open meeting [3] warning about large-scale MITM attacks. A document that updates various e-mail related RFCs on how to handle certificate validation is currently in IETF Last Call in UTA [4]. Distributing policy information via DNS has the usual problem of missing DNS authenticity and zero DNSSEC deployment. Even where DNSSEC is available, upstream ISPs collaborating with governments will deliver wrong records. This might be nice for large mail hosters but will yield zero additional security for all of the small MXs that are out there. You guys are already doing pretty well anyway.

Am I missing something? Sorry, I'm not trying to be rude - just curious what you are up to.

Aaron

[0] - https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/
[1] - https://mailarchive.ietf.org/arch/msg/uta/nB5Vf_8BRhYR54fNrYn4CeNVh0o
[2] - https://mailarchive.ietf.org/arch/msg/uta/coFJM0sU6nL-ycJ5nMyAx4rN8Qg
[3] - https://www.ietf.org/proceedings/93/saag.html
[4] - https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/

[danmarg]

Not at all. I appreciate the links. I'll try to reply as best I can; some of these links (particularly the mailing list threads) are new to me, though.

DEEP: The last I looked at the DEEP draft it was, to the best of my reading, only for MUA-server connections, not server-server connections. So this would be a complementary protocol.

Your link [1] is quite on target. We started out by analogizing to HSTS, and similar suggestions have been made (I believe on this list) in the past by some of my colleagues (https://www.ietf.org/mail-archive/web/dane/current/msg06044.html, https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07768.html). I think there's a lot to like about this, but there are two reasons (that I can think of offhand) to prefer a DNS-based approach over an SMTP extension:

1. A "report only" mode (as described here) can be implemented without any changes to an MTA itself (aside from logging verbosity, perhaps).
2. It allows users of shared hosted mail services (like Google for Work) to migrate off those services without having to either a) "unpin" (how do you ensure all those who have pinned your HSTS-like policy have fetched the "unpinned" setting) or b) migrate to a new service that also complies with the policy.

Without the second property, pinning becomes in certain ways irrevocable, which is of some concern for the hosted use case, especially if you want to both make such security features available to hosted customers and to avoid locking them in during early stages of adoption.

That said, I am very open to suggestions on how to improve this or bring it in line with complementary efforts, of which, as you say, there are quite a few. Our goal was really to try to figure out what we could do today-ish that would both provide a real security benefit and complement further work (by us and, hopefully, others) down the road.

Do you think we miss that target? Do you think there are changes we should consider to improve on either of those goals?

Thanks for the thoughtful comments and links.

Dan

[azet]

I've also thought about a way for feedback, though I've not a final, presentable solution yet.

We seem to have the usual "not invented here" problem. TACK was a better solution in my opinion but Google heavily pushed for HPKP and HSTS in IETF and other bodies instead, we now have zero pinning deployment on the web [0]. As an attacker, I will attack anything that relies on DNS with ease in a local WiFi/LAN and at the carrier as nation-state or soon-to-be-ousted-government attacker. This is also why DNSSEC and DANE are broken by design [1] [2].

As I understand this solution it's very useful to large hosting providers - controlling a lot of support infrastructure, but again, you're doing well. I know, I use Gmail for my domain :)

Most MXs on the Internet are some small Postfix, Sendmail or ancient Exchange boxes that won't do that well and are barely reachable nor anywhere near secure and have no "proper" DNSSEC setup, DMARC et cetera. We need a real solution for them. I think the solution is something that works without use of DNS but TACK (which is a TLS extension anyway) and maybe a $PROTO extension. Maybe even something custom with JOSE [3] providing feedback? Need to think about that last one though, not sure.

BTW why do you prefer XML to JSON?

My preference would be to abolish all current e-mail protocols and build something that fits today's times, considering the deployment of more than 4 million mail servers on the Internet this is not likely to happen in any considerable amount of time. Which also means we need a solution that is easy to deploy (say sudo apt-get upgrade).

Aaron

[0] - https://www.ietf.org/proceedings/92/slides/slides-92-saag-2.pdf
[1] - http://sockpuppet.org/blog/2015/01/15/against-dnssec/
[2] - https://www.imperialviolet.org/2015/01/17/notdane.html
[3] - https://jose.readthedocs.org/en/latest/

[danmarg]

It might be not-invented-here, but (as in all such cases) that's not the
goal. ;)

I think our proposal is somewhat tolerant of compromised DNS. (In fact,
we've gone to great lengths to ensure that people who don't have DNSSEC
deployments can still use it and get a real benefit due to the way policy
caching works.) But it's a fair point that there's more work to be done;
better transparency and reporting are one way to mitigate the risks of
universal, always-MITM'ed connections.

You could do more or less the same thing as we proposed with x509
extensions or SMTP protocol extensions. Our reasons for not going that
route were purely about simplicity of implementation: our bet is that it's
easier to publish some TXT record and a .well-known path than to get a cert
signed with some custom extension or to change MTAs. (And for report-only
implementations, no MTA changes are required.)

But there's no particular preference for DNS here, of course. Another
solution with similar properties would be just as good.

The XML is mostly cribbed from the existing DMARC reporting format. I
personally find JSON a bit easier to read as well, but a lot of mail people
are already going to be familiar with DMARC reports, so hey.

Dan

On Thu, Dec 3, 2015 at 9:57 PM Aaron Zauner notifications@github.com
wrote:

I've also thought about a way for feedback, though I've not a final,
presentable solution yet.

We seem to have the usual "not invented here" problem. TACK was a better
solution in my opinion but Google heavily pushed for HPKP and HSTS in IETF
and other bodies instead, we now have zero pinning deployment [0]. As an
attacker, I will attack anything that relies on DNS with ease in a
local WiFi/LAN and at the carrier as nation-state attacker. This is also
why DNSSEC is broken by design [1] [2].

As I understand this solution it's very useful to large hosting providers,
but again, you're doing well. Most MXs on the Internet are some small
Postfix, Sendmail or ancient Exchange boxes that won't do that well and are
barely reachable nor anywhere near secure and have no proper DNSSEC setup,
DMARC et cetera. We need a real solution for them. I think the solution is
something that works without use of DNS but TACK (which is a TLS extension
anyway) and maybe a $PROTO extension. Maybe even something custom with JOSE
[3] providing proper feedback? Need to think about that last one though,
not sure.

BTW why do you prefer XML to JSON?

[0] - https://www.ietf.org/proceedings/92/slides/slides-92-saag-2.pdf
[1] - http://sockpuppet.org/blog/2015/01/15/against-dnssec/
[2] - https://www.imperialviolet.org/2015/01/17/notdane.html
[3] - https://jose.readthedocs.org/en/latest/

—
Reply to this email directly or view it on GitHub
#1 (comment).

[azet]

I'm not sure the run-of-the-mill postmaster will have such ease publishing DNS records nor a web-page to which his domain belongs (there's often a lot of indirection and bureaucracy, think universities and large non-tech organizations/companies), even less so for authenticated DNS (DNSSEC). MTAs usually have unsigned certificates, they're now required to use signed ones for out-of-band authentication anyway by your proposal (as far as I can tell). TACK deals nicely with the problem of untrusted/unsigned certificates. The caching is nice but I think TACK would do more nicely. What I really like about your proposal is the feedback-loop, I don't like that it is completely out-of-band though. I've suggested and discussed a very similar out-of-band design using HTTPS but quickly abandoned it after discussion with other crypto and security people this last January at RWC15.

I have no particular problem with XML there (doesn't seem to be too bloated), just curious. The draft is still unfinished, so I guess my commenting is a bit unfair. But it might help to improve the draft. Depending on the way you go I'd even collaborate on it -- the draft should maybe explicitly state deployment problems for small-scale set-ups and choose a more appropriate name as I cannot imagine this tech. to be widely deployed among mail servers in a couple of years (but who knows, I've been wrong on quite a few occasions. DNSSEC and IPv6 security were not among them for now :)).

What do you define as "MTA changes"? MTA server daemons will have to be upgraded (e.g. sudo apt-get upgrade -y) eventually, if only for an OpenSSL/CryptoAPI CVE or ABI-break. What kind of deployment problems with MTA code do you specifically see with a SMTP-extension based proposal? Further, if we go with (something-, updated-, like) TACK there isn't a lot to be done on the TLS implementation side either, it's an extension, there's even code around. I still have to check if TLS 1.3 would break anything and using e.g. EdDSA instead of ECDSA for the TACK signatures would maybe also make sense these days, among other stuff. The real problem and work to be done I see is in creating a cool in-band feedback-loop like you've proposed out-of-band.

Thanks,
Aaron

[danmarg]

(Sorry for the slow reply. This was in my Drafts folder for a while.)

I think depending on DNS TXT records is pretty reasonable, since
DMARC/DKIM/SPF also depend on the same. But you have a fair point about the
.well-known stuff; ultimately, it still seems to me to be easier to set up
an HTTPS endpoint somewhere than to do many other things (including
DNSSEC, as you say, but also custom solutions like signing with an x509
cert and delivering a cert chain through some other manner). I think,
unfortunately, that TACK also falls into this camp, though TACK is nice for
other reasons.

I'm happy to integrate changes and suggestions, by the way. It's probably a
fair point that while I have a lot of insight into how we run our mail
systems at Google, I have less insight into how mid-size shops run theirs.
So please do feel free to send concrete changes. I think moving away from
XML is more trouble than it's worth right now--being close to DMARC struck
me as more important than avoiding XML, with all its warts--but it's fair
to have suggested it.

Anyway, feel free to send along pull requests or more suggestions. Thanks!

Dan

On Tue, Dec 8, 2015 at 12:06 AM Aaron Zauner notifications@github.com
wrote:

I'm not sure the run-of-the-mill postmaster will have such ease publishing
DNS records nor a web-page to which his domain belongs (there's often a lot
of indirection and bureaucracy, think universities and large non-tech
organizations/companies), even less so for authenticated DNS (DNSSEC). The
caching is nice but I think TACK would do more nicely. What I really like
about your proposal is the feedback-loop, I don't like that it is
completely out-of-band though. I've suggested and discussed a very similar
out-of-band design using HTTPS but quickly abandoned it after discussion
with other crypto and security people.

I have no particular problem with XML there (doesn't seem to be too
bloated), just curious. The draft is still unfinished, so I guess my
commenting is a bit unfair. But it might help to improve the draft.
Depending on the way you go I'd even collaborate on it -- the draft should
maybe explicitly state deployment problems for small-scale set-ups and
choose a more appropriate name as I cannot imagine this tech. to be widely
deployed among mail servers in a couple of years (but who knows, I've been
wrong on quite a few occasions. DNSSEC and IPv6 security were not among
them for now :)).

What do you define as "MTA changes"? MTA server daemons will have to be
upgraded eventually, if only for an OpenSSL CVE. What kind of deployment
problems with MTA code do you specifically see with a SMTP-extension based
proposal? Further, if we go with (something-, updated-, like) TACK there
isn't a lot to be done on the TLS implementation side either, it's an
extension, there's even code around.

Thanks,
Aaron

—
Reply to this email directly or view it on GitHub
#1 (comment).

[azet]

Hey Dan,

I have no issues with XML. I was just curious why it's used here. Makes sense - as you say - with DMARC sporting a similar syntax and using the same markup language. That wasn't my problem with your proposal, I did already note that.

I don't really follow what you mean by "TACK also falls into this camp"? Could you explain in more detail? I'd be very interested as I'm working on a TACK based proposal. TACK is especially interesting for MTAs as these usually use unsigned Certs. TACK is not a X.509 (PKIX) extension, it's a TLS extension. Which means roll-out is as easy as shipping an OpenSSL update (noted before) with some hooks in MTAs. Which would be required with your proposal as well (out-of-band authentication via WebPKI - the MTA still has to signal there somewhere). I actually think the MTA integration would even be simpler with TACK + SMTP extension than with the current SMTP-STS proposal. Added to that is the deployment problem for small mail-shops, as I've noted before - these would have a much easier time upgrading their MTA and TLS libraries, on any platform really. Setting up the out-of-band WebPKI authentication (which, again, requires valid certificates in the first place) will be more bothersome to them.

Let me quote from the TACK draft (https://datatracker.ietf.org/doc/draft-perrin-tls-tack/) as of version 02. Section 5.3:

5.3.  Certificate verification

   A TACK client MAY choose to perform some form of certificate
   verification in addition to TACK processing.  When combining
   certificate verification and TACK processing, the TACK processing
   described in Section 4 SHALL be followed, with the exception that
   TACK processing MAY be terminated early (or skipped) if some fatal
   certificate error is discovered.

   If TACK processing and certificate verification both complete without
   a fatal error, then client behavior is left to other specifications
   and client policy.  An example client policy would be to allow the
   connection to proceed only if it passes certificate verification and
   is not contradicted by a pin.

As you see, this is entirely optional.

2.1.  Tack life cycle

   A server operator using TACK may perform several processes:

   Selection of a TACK signing key (TSK):  The server operator first
      chooses the ECDSA signing key to use for a set of hostnames.  It
      is safest to use a different TSK for each hostname, though a TSK
      may be reused for closely-related hostnames (such as aliases for
      the same host, or hosts sharing the same TLS key).

   Creating initial tacks under a TSK:  The TSK private key is then used
      to sign the TLS public keys for all servers associated with those
      hostnames.  The TSK public key and signature are combined with
      some metadata into each server's "tack".

   Deploying initial tacks:  For each hostname, tacks are deployed to
      TLS servers in a two-stage process.  First, each TLS server
      associated with the hostname is given a tack.  Once this is
      completed, the tacks are activated by setting the "activation
      flag" on each server.

   Creating new tacks under a TSK:  A tack needs to be replaced whenever
      a server changes its TLS public key, or when the tack expires.
      Tacks may also need to be replaced with later-generation tacks if
      the TSK's "min_generation" is updated (see next).

   Revoking old tacks:  If a TLS private key is compromised, the tacks
      signing this key can be revoked by publishing a new tack
      containing a higher "min_generation".

   Deactivating tacks:  If a server operator wishes to stop deploying
      tacks, all tacks for a hostname can be deactivated via the
      activation flag, allowing the server to remove the tacks within 30
      days (at most).

   Overlapping tacks:  If a server operator wishes to change the TSK a
      hostname is pinned to, the server can publish a new tack alongside
      the old one.  This lets clients activate pins for the new TSK
      prior to the server deactivating the older pins.

Section 3 describes the TACK extension in more detail:

3.2.1.  Tack fields

   public_key:  Specifies the public key of the TSK that has signed this
      tack.  The field contains a pair of integers (x, y) representing a
      point on the elliptic curve P-256 defined in [FIPS186-3].  Each
      integer is encoded as a 32-byte octet string using the Integer-to-
      Octet-String algorithm from [RFC6090], and these strings are
      concatenated with the x value first.  (NOTE: This is equivalent to
      an uncompressed subjectPublicKey from [RFC5480], except that the
      initial 0x04 byte is omitted).

   min_generation:  Publishes a min_generation for the tack's TSK.

   generation:  Assigns each tack a generation.  Generations less than
      the highest published min_generation for the tack's TSK are
      considered revoked.

   expiration:  Specifies a time after which the tack is considered
      expired.  The time is encoded as the number of minutes, excluding
      leap seconds, after midnight UTC, January 1 1970.

   target_hash:  A hash of the TLS server's SubjectPublicKeyInfo
      [RFC5280] using the SHA256 algorithm from [FIPS180-2].  The
      SubjectPublicKeyInfo is typically conveyed as part of the server's
      X.509 end-entity certificate.

   signature:  An ECDSA signature by the tack's TSK over the 8 byte
      ASCII string "tack_sig" followed by the contents of the tack prior
      to the "signature" field (i.e. the preceding 102 bytes).  The
      field contains a pair of integers (r, s) representing an ECDSA
      signature as defined in [FIPS186-3], using curve P-256 and SHA256.
      Each integer is encoded as a 32-byte octet string using the
      Integer-to-Octet-String algorithm from [RFC6090], and these
      strings are concatenated with the r value first.

Working code: https://github.com/tack (we need to build on that and get it running, too. I know.)

As I've noted before; the draft is expired and some work would be needed to update it to todays recommended crypto standards (see CFRG discussion on new signature algorithms, curves et cetera). TACK was originally designed for client <-> server communication, so a few changes will be needed there as well to work well within a server <-> server model. But I think as it stands, it's very well suited for this particular problem. Namely: MTAs with unsigned certificates that need to be protected against MITM attacks (even from state sponsored actors, oppressive governments or upstream ISPs/carriers). If you see a particular issue with working on this proposal - again - I very much appreciate feedback on that as I'm sure we can figure out some solution. I'm in the process of getting more long time or large-scale mail operators involved for feedback and testing within their environments. If you'd be interested as well, let me know.

Thanks,
Aaron

[danmarg]

But these are orthogonal concerns (as I think you indicated): telling MTAs
that they should require some kind of validation (SSL, CA signedness, TACK)
is unrelated to the problem of validation itself. TACK can solve the
certificate validation problem, but I don't believe it can solve the
"require certificate validation for these domain names" problem.

On Mon, Dec 21, 2015 at 8:09 PM Aaron Zauner notifications@github.com
wrote:

Hey Dan,

I have no issues with XML as I've noted before, was just interested why
it's used here. Makes sense - as you say - with DMARC sporting a similar
syntax.

I don't really follow what you mean by "TACK also falls into this camp"?
Could you explain in more detail? I'd be very interested as I'm working on
a TACK based proposal. TACK is especially interesting for MTAs as these
usually use unsigned Certs. TACK is not a X.509 (PKIX) extension, it's a
TLS extension. Which means roll-out is as easy as shipping an OpenSSL
update (noted before) with some hooks in MTAs. Which would be required with
your proposal as well (out-of-band authentication via WebPKI - the MTA
still has to signal there somewhere). I actually think the MTA integration
would even be simpler than with SMTP-STS.

Let me quote from the TACK draft (
https://datatracker.ietf.org/doc/draft-perrin-tls-tack/) as of version
02. Section 5.3:

5.3. Certificate verification

A TACK client MAY choose to perform some form of certificate verification in addition to TACK processing. When combining certificate verification and TACK processing, the TACK processing described in Section 4 SHALL be followed, with the exception that TACK processing MAY be terminated early (or skipped) if some fatal certificate error is discovered.

If TACK processing and certificate verification both complete without a fatal error, then client behavior is left to other specifications and client policy. An example client policy would be to allow the connection to proceed only if it passes certificate verification and is not contradicted by a pin.

As you see, this is entirely optional. Section 3 describes the TACK
extension in more detail:

3.2.1. Tack fields

public_key: Specifies the public key of the TSK that has signed this
tack. The field contains a pair of integers (x, y) representing a
point on the elliptic curve P-256 defined in [FIPS186-3]. Each
integer is encoded as a 32-byte octet string using the Integer-to-
Octet-String algorithm from [RFC6090], and these strings are
concatenated with the x value first. (NOTE: This is equivalent to
an uncompressed subjectPublicKey from [RFC5480], except that the
initial 0x04 byte is omitted).

min_generation: Publishes a min_generation for the tack's TSK.

generation: Assigns each tack a generation. Generations less than
the highest published min_generation for the tack's TSK are
considered revoked.

expiration: Specifies a time after which the tack is considered
expired. The time is encoded as the number of minutes, excluding
leap seconds, after midnight UTC, January 1 1970.

target_hash: A hash of the TLS server's SubjectPublicKeyInfo
[RFC5280] using the SHA256 algorithm from [FIPS180-2]. The
SubjectPublicKeyInfo is typically conveyed as part of the server's
X.509 end-entity certificate.

signature: An ECDSA signature by the tack's TSK over the 8 byte
ASCII string "tack_sig" followed by the contents of the tack prior
to the "signature" field (i.e. the preceding 102 bytes). The
field contains a pair of integers (r, s) representing an ECDSA
signature as defined in [FIPS186-3], using curve P-256 and SHA256.
Each integer is encoded as a 32-byte octet string using the
Integer-to-Octet-String algorithm from [RFC6090], and these
strings are concatenated with the r value first.

As I've noted before; the draft is expired and some work would be needed
to update it to todays recommended crypto standards (see CFRG discussion on
new signature algorithms, curves et cetera). TACK was originally designed
for client <-> server communication, so a few changes will be needed
there as well to work well within a server <-> server model. But I think
as it stands, it's very well suited for this particular problem. Namely:
MTAs with unsigned certificates that need to be protected against MITM
attacks (even from state sponsored actors, oppressive governments or
upstream ISPs/carriers). If you see a particular issue with working on this
proposal - again - I very much appreciate feedback on that as I'm sure we
can figure out some solution. I'm in the process of getting more long time
or large-scale mail operators involved for feedback and testing within
their environments. If you'd be interested as well, let me know.

Thanks,
Aaron

—
Reply to this email directly or view it on GitHub
#1 (comment).

[azet]

Sorry for the delay, have been busy the last couple of days and without a notebook/PC.

I don't really follow your last sentence could you clarify what you mean by "require certificate validation for these domain names"? sAN? SMTP banners not matching CNs in certificates? As it stands today the TACK proposal is not very useful for this approach (MTA to MTA security), I'm currently looking into updating it and maybe define the SMTP extension and 'MTA TACK' in a single document. I'm still speaking with operators and implementers about details and am a bit busy with research as well at the moment, but I hope to have something ready to present within the next month or two.

Thanks,
Aaron

[mrisher]

Hi
Sorry, I've been mostly lurking on this thread; I'm Dan's less-technical
counterpart :)

I think what he meant is that we need something like STS to say "when you
send a message to *@gmail.com you should expect a certificate that fits
these criteria and can be validated using {our policy, TACK,
CA-chain-of-trust, etc.}" From our standpoint so far, the bigger huddle has
been establishing a policy of what to expect (and what to do when you find
something else) for a given domain; we actually kind of punted on how to
validate for now because the policy exchange, and the data we can gather
from that, seemed a big enough prerequisite. MTA-TACK could still work for
the validation, and we'd be happy to explore that with you.

Thanks for all the commentary.

Happy New Year
/m

On Wed, Dec 30, 2015, 1:10 PM Aaron Zauner notifications@github.com wrote:

Sorry for the delay, have been busy the last couple of days and without a
notebook/PC.

I don't really follow your last sentence could you clarify what you mean
by "require certificate validation for these domain names"? sAN? SMTP
banners not matching CNs in certificates? As it stands today the TACK
proposal is not very useful for this approach (MTA to MTA security), I'm
currently looking into updating it and maybe define the SMTP extension and
'MTA TACK' in a single document. I'm still speaking with operators and
implementers about details and am a bit busy with research as well at the
moment, but I hope to have something ready to present within the next month
or two.

Thanks,
Aaron

—
Reply to this email directly or view it on GitHub
#1 (comment).

[mrisher]

Closing this as an "issue" because the discussion has moved to the uta thread.

[azet]

@mrisher is the offer on looking into MTA-TACK for auth/validation still open? I had been busy until recently and as you had published this to UTA by then I figured we should just go on over there.