Minutes for UTA at IETF-95
minutes-95-uta-1

UTA WG @IETF 95, Buenos Aires
Chairs:  Orit Levin, Leif Johansson

MONDAY, April 4, 2016

1400-1530  Afternoon Session I
Atlantico C    ART      uta        Using TLS in Applications WG

14:00 - 14:15    Welcome by chairs and getting organized

14:15 - 14:30    SMTP Require TLS Option
                           https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/

14:30 - 15:05    SMTP Strict Transport Security
                           https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/

15:05 - 15:20   Deployable Enhanced Email Privacy (DEEP)
              https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

15:20 - 15:30   As needed

Three email-related drafts.  There are multiple interfaces related to SMTP, and
we have drafts for multiple aspects of it.  Draft-fenton-smtp-require-tls,
draft-margolis-smtp-tls , draft-ietf-uta-email-deep.  There are some aspects
which are complementary.

SMTP-STS considered first, then deep, then require-TLS.

Mark Risher presents draft-margolis-smtp-tls.  Strict transport security
proposal; began as a discussion at Maawg; this is the work of multiple folks,
I'm the one who happens to be here today. I'd like to describe the policy space
and what our current thoughts are, so we can get feedback on the early stage
work.

Three key problem areas:  opportunistic aspects of SMTP make downgrades and
interception a problem; reporting is valuable and sometimes sufficient to
assist operators to understand the scale of the problem; DNSSEC not (yet)
universal.  So we wanted to meet the goals as best as possible without.

STMP STS:  Failure reporting and enforcement for large and small email domains.
 Several desirable properties:  1) Deployable without DNSSSEC, 2) Suitable for
multi-domain hosting, 3) "Report-only" possible without MTA changes. 4) Minimal
"wheel-reinvention".  Orit asked for how many people have read the draft?
(About half the room).  There have been some issues raised in both UTA and SMTP
lists.  Looking to know whether the general direction is appropriate and what
the next steps might be.

DNSSEC and STS in draft-00.  There were two different options for
authentication and two for validation.  The first is a=dnssec or a=webpki (e.g.
HTTPS URL at which a cert-chain validation is available).  For Validation,
c=tlsa or c=webpki.  There was discussion on the complexity.  Some proposed
edits:

Remove DANE-based MX validation (C="tlsa")? Avoids a silly state when there is
disagreement between this and STS validation.

Remove DNSSEC-based policy authentication ("a=dnssec"?)  There is a complexity
argurment against having these choices; there is also some possibility of a
silly state;  this isn't as small a change, but it would be possibility.  If we
do this, it may make it more appropriate to remove the redundant policy from
the DNS.  The DNS same extensive changes would no longer problem.

If all we're doing in DNS is version control, move cache control to HTTPS
Cache-Control?  That would put the whole thing in the web, and means change is
only one place.  This might also allow you to cname over to a web provider.

John Levine:  I watched all the discussion on the list, and the objections are
reasonable, but many of the solutions are not.  Reserved host names are going
to be a no-go.  John suggests splitting "if you believe in DANE, do this" and a
"ELSE, do this".  Maybe the logging piece is the most important piece, so we
could specify something, then take the logs and figure out if it needs to
change.

Rich Salz:  Jabber relay:  Andrew Sullivan, if you don't believe in DNSSEC but
then rely on unsigned DNS for a critical piece?  Doesn't that seem nuts?  Mark:
 part of the attack surface that is covered by DNSSEC is attacks against the
DNS; there are issues with that when you don't have that.  The bootstrapping is
discussed in the draft, both using TOFU-like bootrstrapping, and others. 
Andrew:  That remark makes me deeply nervous.  I have barely glanced at the
draft, and I apologize.  I think what John says is true, and there is very
little not trusting the DNS and work your way up from there. Dan York:  You
mention that if you remove these pieces, what happens?   The draft now says you
can borrow some pieces from DANE, and that may be confusing.  Dan, but if you
remove this and I have a TLSA record, what happens?  (IF you have a TLSA, STS
isignored).  Chris Newman, so with these simplification, there is 1 bit in the
DNS for this; can we get rid of the extra dns lookup for that one bit, so it
occurs in one of the other flows, e.g. the SMTP server?  PHB:  this is
connected to DNSSEC, but which way is not clear.  This looks to be layered on
DNSSEC (DANE has a circular dependency).  You should avoid a MUST for
DNSSEC--there would still be a reason to do this.  If you have data to
validate, you then need a protocol to confirm it (and that looks like DNSSSEC
but without a circular )Viktor Dukhovni (remote): is the one bit DNS signal
necessary?  Since I am in the position of worrying about DNS and maintianing an
MTA, I suggest that is useful.  The majority of domains won't have deployment
of HTTPS server; they may have firewalls that make it hard to discover if there
is a web server.  I think it is important to explicitly signal whether the
HTTPS exists.  How crazy are we to publish a policy via an insecure channel? 
It is a pinning mechanism with long time-outs, so the policy, once discovered
remains available by a reasonably secure channel--only when idle for a long
time, will it be lost.  I am all in favor of the one-bit signal.  In the
discussion, the question is whether the DNS should have a nonce or version to
indicate a refresh, or whether the HTTP data should have this (e.g. via e-tags
or cache control).  The signal bit DNS signal to avoid high latency cost there
is no web server).  Richard Barnes, coming from the web,  comparing and
contrasting between these HSTS and ESTS.  A high degree of coherence in the
policy language would be usable.  Does this draft re-use the directive level
details of HSTS?  Richard:  It would be a nice design goal to have the
directives congruent as much as possible.  With regard to the DNSSEC question,
HSTS got things about right--the policy is always HTTPS, so not quite the same,
but with regards to thing like DANE it uses a whole separate specification for
the key management--decoupling them here would be a good objective.

Chris Newman on in-band distribution "Deep uses deployed cert validation for
in-protocol SMTP submission policy, can SMTP STS use in-protocol model?"  Some
of the objections that came up on the list, MTAs that serve many domains you
may have to be deeper in the connection before bringing this ?  DKG: The
concern here is that if I delegate my MX handing to a third party, I may not
want to delegate my policy to the third party; the MX handler may have bad
incentives (e.g. lock-in).  Moving to someone that does not support this, for
example, can you go back?  Also in-band mechanisms force both MTAs to be
updated before you get good logging.  While side-channel mechanisms let you
start logging right away.  Jim Fenton asks how you avoid a downgrade here and
Mark replied (missed reply).

Options on reorting formats: Standalone specification, xml vs. json, re-use
some generalized format, split into its own spec, reporting granularity and
specifity.  Richard:  reuse some tools here, there are reporting tools for HSTS
and friends--reuse all that stuff.  Mark--also having some people says that
some over-generalized formats are not useful.  John Levine: DMARC also has
related logging, and they are useful, even if you don't like DMARC.  Richard:
that's a fair point, I just mean some set of existing tools should be re-used.

DANE failures are also something that could be reported, even if DANE is the
sole source of policy.  Working group--what next?  Mark we want to make sure
that this makes sense, so want to understand from the chairs and audience
what's next.  Leif, this is in scope for the WG, so does the WG want to take
this on and if so are we ready to do so now.  Note that this is a change
control moment; so it should be done possibly a bit later.    Is this
appropriate for UTA?  Humm for yes:  moderately strong?  Stephen Farrel
clarification--tackling the problem, not this version?  Leif, not this version,
once adopted it will change.   What is it we are trying to solve?  Hmm:
Moderately strong for yes, No: none, undecided:  a little.  Apparent consensus
for adoption.  Chairs leave it up to the authors whether or not to rev before
adoption--if rev'ved, re-confirmation on adoption will occur on the list.

Chris Newman: Email and TLS.  DEEP Overview reviewd (MUAs IMAP/POP/Submission),
took out MTA relay, as this was too different from the MUA problem. 
Confidentiality Assurance Level for mail account (UI indicator TLS use, cert
verification) covers pop, imap, and smtp submission.  Preference for implicit
TLS over STARTTLS.

Change in -01 Changetls 10 security tag to tls 11, clarify certificate rules,
Changes in -02, more references to uta-tls-certs, based on Alexey's feedbacks.
Changes targetted in -04:  reorganize to make algorithm clearer. 
Advertise+validate+latch. Add text about versioning security tags, change
tls-cert reference to new RFC udpate DANE reference as suggested. Would have
been done, but the STS proposal came out, and we should change from DEEP to MUA
STS to align the two.   Change delimiter between security from SP to, to be
more URI friendly (SMTP alignment) (possible ;, to align with hsts), allow
transition between tls-cert and tls-dane-tlsa with option to latch both? 
Should we add text to allow transition or double latching?  Anjali Goyal: did
not get audio. Viktor Dukhovni: DANE latches itself, so I don't see any reason
to latch DANE outside of itself.  We can simplify by just using that.  I don't
see a need to publish DANE latches via DEEP; it publishes own latches in the
DNS.  Chris:  if you latched on to PKI-style, do we need to support a
transition to shift to DANE?  Viktor: local policy.  Chris:  remove the
DANE-tlsa latch?  Viktor: Yes, but I need to read the draft more closely. 
Chris:  I think I understand how to write that as well.  SMTP STS:  would SMTP
STS to just reference DEEP security tag registry, and add tags it needs, so
there is no need for a redundant registry.  Is it there something missing?

Leif: Should we break out the registry bits into a separate document?  Chris; 
Would be willing, but not need.  Leif:  go talk to Richard, Mark, et al and
figure out what the alignment would look like.  Adam Roach:  HSTS does have a
directive registry now.  Chris: will need to read that in more depth.   Skipped
the "possible improvements"  deck, as STS had already gotten signficant
discussion.  Viktor:  important discussion between the MX hosts-level policy
and domain-level policy.  So latches may need to be less fine-grained, in order
to handle diversity.  Chris: that's a good point, but we have done registries
where the items are flagged by use of context (essentially, a scope indicator).
 Viktor, right we need to clearly scope the latches.

On to Jim Fenton:  require-tls draft.  Problem statement:  STARTTLS is too
opportunistic, mail deliverability is paramount--no way to say prioritize
security over deliverability.  Common answer, end-to-end encryption does not
protect metadata.  Goal here is to allow senders to specify when envelope and
headers require protection.  Encourages TLS use; Fine-grained, in that it
doesn't impact messages that don't specify this marking.  Some control over
certificate verification.  Like STS and so forth, there is some control over
verification; a use-case for this might be a reporter or dissident in a
situation where a state actor is able to generate trustable webpki cert--rely
instead on DANE, by sender insistence.

Non-goals,
         MUA--to M*A outside SMTP.
         Choice of encryption algorithms
                Consider reqiurement for PFS?
        Logging

Sending a requiretls-tagged message.  Can tag to require dnssec, open an smtp
sesson, fail if startttls and requiretls not advertised; starttles, verifying
certifcate as required by message; send message with requiretls option on MAIL
FROM.

Possible issues/FAQs:

MTAs falsely advertiising requiretls (trustable to say this should be trustable
to do requiretls)
     -MTAs trusted to handle mail should be trustable to do REQUIRETLS when
     advertised.
Mail forwarders/exploders
     apply requiretls to downstream recipient
Mailing lists
        its up to the list operators
Bounce handling
       Use requiretls with same options
        Yes, some bounce may be lost.

Slide 7 shows state diagram for the require negotiation.

Richard:  this is TLS roullete; it may or may not have a full tls path, so you
don't know Jim: What we do now is roullete, since you don't know whether it is
encrypted or not. John:  The good news is I have implemented this, but in a
passive aggressive way.  When I receive something that requires TLS of an
onward message, I drop it.  Unless you can explain why a recipient would take
the hassle of doing this, when it generates support tickets?  Jim gives a
receiving mta at a newspaper.  Richard: use: PGP?  Local mailboxes on starttles
on submission.  Jim, there is still local mailboxes that are bet.  EKR, I don't
see the value here compared to the value of end-to-end security, Jim: I would
prefer you use both. Viktor;  I have some experience in this, was a postmaster
at a financial security; what makes sense here is signalling from a submit
server to the border MTA; once it leaves the organization, attempting to
enforce policy doesn't make sense, but within an organization it would still be
useful.  end-to-end and fine-grained it won't succeed, but that is one use
case.  Orit Levin, from the floor:  I have an observation, related to Ted's
point earlier:  if an MTA in the middle doesn't understand this, it still gets
forward?  No, it drops.  Dan York: Orit's question raises a deployability
question:  have you had interest from MTAs beyond John (I haven't solicited
that yet, really an indvidual effort).  Dan; thanks for bringing it here, but I
share some of the concerns about deployability.  Jim:  I am trying to protect
the long hop, the outgoing MTA in my organization to the recipient; if my MTA
will drop instead of forward, then I get what I am looking for.  Leif: what are
you plans here?  Experimental draft--I am looking for interest and trying to
engage whether folks are ready to implement and explore?  Leif are you asking
for adoption?  Leif, I think there is work to be done on this.  The problem is:
 ability to signal security over deliverability.  Very rough hums, I'd like to
see additional revisions of this before coming back to the question.  Barry: 
for the people who hummed for not in this working group, was it working group
specific or more general?  Come up to the mic and comment if it changes your
view?  Chris Newman: my view is that getting the STS stuff done is higher
priority, wouldn't care after that.  Richard:  I care about getting TLS
deployed for email, so I think this should be deprioritized in favor of the STS
and similar work.  EKR:  I agree with Richard; maybe is STS gets a lot of
traction, then this might be attractive, but it is too high collateral damage
now.

Now TLS extension for service indication.  3 minutes for
draft-zhang-tls-service-indication-extension-00.  Motivation scenario:  Content
provider scenario for providing discounts, the operator charging gateway needs
to know what the charging method should be:  proposal to carry this in TLS
handshake, so it is visible prior to start of encrypted traffic.  Slide 2 (Ali
Baba is big, 115 million buyers, and 467 transaction on a single day). Why not
SNI? Length limit, no protection, spoofable.  Secure SI solves this, and we
propose an extension to carry hmac and timestamp to guarantee this.  Comments:
Ted and EKR not recommended as a layer violation at best.