On March 25, 2016 at 15:15:22 , Mark Risher ([email protected]) wrote:
The discussion around whether to include a timeout in DEEP was basically to ask
the question: Should a domain that makes a commitment to be secure be allowed
to revoke that commitment? The rough consensus in the face-to-face meeting was
that the answer to that question should be “no”. That is, once the domain makes
the commitment to a certain level of security, they’ll have to only use hosting
providers that offer the same or better security. Isn’t that a good thing if
we’re trying to make the Internet more secure?
I agree philosophically that we should strive to be ever-increasing in
security. What some of the authors worried about was, at least in early days
when there is spotty deployment, would fear of "lock-in" act as a deterrent.
It's theoretical and hard to measure what would happen in practice. Sounds like
the "hmmm" consensus was that it's worth the risk?
If we're not worried about lock-in, then we could remove a lot of complexity.
Any empirical studies people can point to?
The XML schema parsers I’ve used produce such poor error reports that I find
XSD only useful to provide a binary valid/not-valid result.
There's pretty universal consensus that nobody likes the XML we started with.
I've got this one flagged for the face-to-face meeting; ideally we would
leverage an existing reporting (JSON) format, but there seem to be myriad
options but none with more than modest adoption. Any suggestions?
While I have implemented the leading extensible syntaxes (XML & JSON), I don’t
have much experience with reporting formats. What I do know is that
generalizing a data model too broadly has a tendency to make the models
sufficiently complex that they’re harder to deploy and less useful. So unless
there’s a clearly winning generalized reporting model I don’t know about, I’d
try to focus on “SMTP TLS security policy error reporting” or “SMTP/MUA TLS
security policy error reporting” and resist generalizing the format further
than that. Beyond that, the two concerns I have with a reporting data model are
having the syntax and semantics of the fields defined with reasonable
clarity/precision and having enough extensibility in the model so an
incompatible version change is unlikely to happen in the future as things are
added.
- Chris
Thanks for the comments,
/m
--
Mark E. Risher | Group Product Manager | [email protected] |
650-253-3123
On Fri, Mar 25, 2016 at 2:28 PM, Chris Newman <[email protected]> wrote:
On March 23, 2016 at 18:45:45 , Daniel Margolis ([email protected]) wrote:
Hey,
Of course we reviewed DEEP during the drafting process, but as you say, the
targets are slightly different. I've responded to some individual points
inline; in summary, though, I think you raise some actionable points about
using the DEEP policy framework (which I will read up on), changing the
reporting syntax, and recording cipher usage. I have questions for you below on
some of the other points.
Thanks.
On Thu, Mar 24, 2016 at 4:44 AM, Chris Newman <[email protected]> wrote:
This document is providing STS functionality for SMTP relay, while DEEP is
providing STS functionality for SMTP submission (plus IMAP & POP). I believe
it’s important to align these two proposals and am open to changing DEEP to do
so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).
Agreed that there's some overlap. One rather obvious observation, to frame the
discussion, though, is that DEEP addresses a case where clients connect to
relatively few *novel* servers (you rarely configure a new IMAP or SMTP MSA
server) and have user-facing UIs, so some of the challenges around discovering
and remembering policies and handling failures are a bit different. But we
should certainly try to align the proposals nonetheless.
Note that early versions of DEEP also provided STS for SMTP relay but solving
the STS problem for MUAs is sufficiently difficult and different that I think
it’s good to have a separate document for SMTP relay STS. If you are open to
editing this as a WG document with rough consensus changes, I would welcome the
collaboration.
I agree with most of Viktor’s comments so I won’t repeat them. Here are some
new comments:
1. I personally dislike using DNS records for any of this proposal. I believe
SMTP security policy is best communicated within SMTP as this minimizes attack
surface, eliminates the need for TOFU in some scenarios, and puts the policy
configuration closer to the server operator. We can use the PKIX trust model
with SMTP/STARTTLS just as we use it with HTTPS (with Viktor’s notable caveats)
so HTTPS is not needed and shouldn’t be used to validate SMTP security policy.
If I read correctly, you're making two different comments here:
a. We should communicate the STS policies within SMTP, not using DNS.
b. We should authenticate the STS policies directly using the SMTP-TLS server
certificate, not some HTTPS side-channel. (Of course this follows from (a), for
the most part.)
Those are spot-on comments. We had initially proposed solely extending SMTP for
policy exchange, similarly to Jim's proposal in "REQUIRETLS" but in reverse
(https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01). However, for
our proposed semantics (i.e. "always require TLS for my domain in the future,
unless I give you a signed change of policy"), this is tricky in a very
specific case: if changing the policy requires serving a new signed policy, and
serving policies is done via SMTP, then users of hosted mail services who turn
on "require TLS" will be unable to revoke their published policy if they move
to a hosted provider who doesn't support the protocol to begin with.
The discussion around whether to include a timeout in DEEP was basically to ask
the question: Should a domain that makes a commitment to be secure be allowed
to revoke that commitment? The rough consensus in the face-to-face meeting was
that the answer to that question should be “no”. That is, once the domain makes
the commitment to a certain level of security, they’ll have to only use hosting
providers that offer the same or better security. Isn’t that a good thing if
we’re trying to make the Internet more secure?
(It also means these domains' SMTP servers will have to support SNI and serve a
server certificate that actually matches the recipient domain, whereas the
current mechanism allows one to run a separate HTTPS server with client.com's
cert but to "bless" SMTP connections to mailhost.com's cert.)
That doesn’t follow if there is a mechanism to get trustworthy routing
information (specifically, signed MX records).
So as far as I can see, to satisfy this scenario, the policy exchange *must* be
some out-of-band protocol. HTTPS is purely a choice of convenience; I had
originally proposed signed blobs stuck in DNS RR, but big resource records seem
problematic in practice (even if the RFC supports them) and the whole thing
gets ugly fast.
Can you think of a way to handle the hosted scenario with SMTP, or some other
more elegant solution?
I believe using HTTPS as an alternative to DNSSEC to bless the MX routing
information makes sense; IMHO it’s a significant good idea in your draft
(obviously using DNSSEC to sign the MX record is a better security model, but
an HTTPS well-known URI model is presently more deployable at many domains).
But I see no reason to use HTTPS to bless SMTP policy; that seems like a
semantic mismatch to me.
2. I think using HTTPS to validate MX records in the non-DNSSEC scenario is a
very interesting idea. But MX records are routing rather than policy and thus
don’t belong in a policy record. How about just defining a well-known HTTPS URL
that contains a copy of the actual binary MX record for the domain (or a
semantically-identical syntax transformation of that binary record)? Then we
just need the SMTP server to advertise the binary policy flag Viktor mentioned
to get a non-DNSSEC model to reasonably trustworthy MX records.
I think this is mostly pending the discussion for #1: if we need DNS for the
reason outlined above, it's convenient to use it for this, too. If we don't, of
course, it may not be.
3. DEEP goes through a lot of trouble to create an extensible framework for
policy by creating a registry (while still keeping the model simple). Your
proposal notes the need for future policy work but lacks a model to add new
policies. I think the SMTP STS document is incomplete without an extensibility
model and you can get it by referencing DEEP (and if we need to change the
syntax or model in DEEP to make that more palatable, I’m open to that
discussion).
I will have to reread this part of your proposal more closely, but unifying the
policy framework certainly sounds reasonable on its face.
4. UTA already discussed the idea of timeouts for security policy in DEEP and
reached rough consensus not to include timeouts. I doubt the SMTP relay use
case is sufficiently different to alter that rough consensus. So I suspect we
can drop timeouts from SMTP STS after a discussion, but if there is rough
consensus to keep timeouts in SMTP STS then I’d like to reconsider that
decision for DEEP on a proposal-alignment basis.
Is there a particular mail thread I should read to get the context here?
Sorry...
It should be in the minutes for the Prague IETF UTA meeting last summer.
5. DEEP’s reporting mechanism for SMTP submission (the CLIENT command) is an
as-it-happens rather than after-the-fact mechanism. I’d like to investigate the
idea of an after-the-fact mechanism for MUAs although I’m not sure it’s a good
fit. Regardless, we need to use the same reporting syntax for submission SMTP
and relay SMTP, so I’m open to changing DEEP’s current submission reporting
syntax as needed to align them.
6. I think JSON would be a better format than XML for reporting. The reports
are coming from an untrusted source and will be parsed. JSON has a much smaller
attack surface than XML and as this is part of a security mechanism, I think
that’s an important consideration. The one potential advantage I see to XML is
the wide availability of SAX-style parsers that can handle large volumes of
data, but I think the attack surface argument should win in this case. I know a
number of XML parser libraries are insecure-by-default due to schema URI
resolution. Regardless, this is an interesting design trade-off for a rough
consensus decision.
No strong feeling here on my end. XML is in theory convenient because it
supports XSD; in practice I think the XSD I wrote in the draft has some bugs.
;) Using JSON is also quite reasonable, and *feels* like a natural choice if we
want to support reporting via HTTP/S POST as well, which we may.
The XML schema parsers I’ve used produce such poor error reports that I find
XSD only useful to provide a binary valid/not-valid result. It’s also difficult
to write XSD with a correct extensibility model. For a reporting syntax this
simple, I think a prose description and examples are going to be more useful to
an implementer than XSD. My feelings on this issue are not so strong that I’d
try to block a rough consensus to use XML, but I think the security issues are
significant enough that the syntax debate is needed.
7. I think your document should reference DEEP section 6 so SMTP relay cipher
usage is recorded for trace purposes; that’s another aspect of your
transparency goal.
Thanks, makes sense.
7. I note in passing that DEEP allows use of the PKIX trust model and the DANE
trust model at the same time. I think that’s good.
I’m wondering if I should rename DEEP to MUA STS?
DEEP is a pretty cool acronym, but yeah, STS has this dis/advantage of
referencing a mostly known item (HSTS). Insofar as I was trying to hew as
closely to the HSTS trust model as possible (within the confines of the
protocol) I think that's a helpful analogy. But probably not the biggest point
right now. ;)
- Chris
On March 21, 2016 at 20:11:06 , Daniel Margolis ([email protected]) wrote:
Thanks for the feedback to both of you. I don't disagree; I think Viktor makes
a very solid point in favor of simplicity. In addition, a report-only protocol
could be extended to support arbitrary error reporting; an out-of-band (e.g.
HTTP) channel to share delivery failures between domains strikes me as useful
in the general case.
Separately, because we're already assuming providers (both sending and
receiving) make a choice on implementing DANE and/or webPKI, I don't think
actually splitting the two makes it any more or less complex to implement, or
should discourage adoption of one or the other mechanism.
So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd like
to chat a bit more with my co-authors and think about it first. ;)
Viktor, as an aside regarding the hosted mail scenario, we already had the
suggestion to move the HTTPS endpoint to something like
"_smtp_sts.example.com/current". If we do that, the customer (example.com) can
make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to serve
the policy with the customer's cert (assuming the customer trusts the hosting
provider with this; for domains that don't operate their own HTTPS endpoint
this seems to me to be likely). For the more complex case, the cron setup you
describe doesn't seem too onerous, I agree.
Thanks again for the feedback.
On Tue, Mar 22, 2016 at 10:21 AM, Neil Cook <[email protected]> wrote:
> On 22 Mar 2016, at 08:49, Viktor Dukhovni <[email protected]> wrote:
>
> On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote:
>
> My (strong) suggestion: use DNS for just cache invalidation, and
> perhaps also publication (via a separate record) of the "rua"
> reporting URI. Do not duplicate data which one must in any case
> obtain and cache via HTTPS in DNS.
>
> Do not attempt to hedge your bets and support DANE/DNSSEC via STS,
> I don't think that makes much sense either.
>
I agree with the “don’t hedge your bets” part. I was quite surprised to see all
the justification for STS in the first part of the document, including “the
mechanism described here presents a variant for systems not yet supporting
DNSSEC”, and yet then goes on to include DNSSEC as one of the policy
authentication mechanisms.
> * Allow (DANE or other) domains to publish just the RUA,
> the feature is not STS-specific.
>
+1
Neil
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
