Minutes IETF98: uta
minutes-98-uta-00

UTA session draft minutes, IETF 98, Chicago 28 March 2017

Note Well, welcome

SMTP STS drafts, Dan Margolis
            draft-ietf-uta-smtp-tlsrpt and draft-ietf-uta-mta-sts
Open questions:
Q1: policy format: now JSON, could be key=value
Q2: MX hostnames or server cert CN/SAN

A Meyerhofer: does it respect DNS TTL?
DM: Policy has embedded max age.
V Duhkovni: for json issue, focus on MTAs, not other environments
J Fenton: how does reporting policy compare to DMARC? Do recipients advertise
willingness to receive reports? DM: Not really, you can already spam people
directly. JF: what is deployment expectation? DM: seems less confusing than
DMARC, semantics are simpler A Zauner: uncomfortable shipping trust related to
STS

Hand/hum for json vs. key-value, roughly tied
A Zauner: json parsing is potential security concern
DM: is this critical either way? few thought so

Murry Kucherawy: both k=v and json parsers are already written
Keith Moore: MTAs implement k=v but cases are all different so code is
different. JSON only needs one parser, but allows silly data, e.g. list where
string expected Alexey: please propose concrete k=v language in the list

Hand/hum for host vs. identity, prefer identity

Mail User Agent Strict Transport Security (MUA-STS), Keith Moore
             draft-ietf-uta-email-deep
J Fenton: two specs here, one is confidentiality practices like a BCP, other is
STS like stuff, which seems overcomplex KM: no, it's a protocol, says to
abandon connections that don't meet requirements. Both affect UI, cleaner to
have them together. V Dukhovni: spec assumes DANE is well defined for IMAP,
POP, SUBMIT, but I don't think it does. Leif: is this implemented? Don't know,
Chris may have data Brian: why can you turn this off, users will turn it off
when their mail breaks? Why not just have a "use TLS" config button? KM: work
with legacy systems, mostly Neil Jenkins: could do SRV lookup for imaps, pop3s,
etc. Seems too much complexity with little gain? Can force upgrade by changing
server to require users to upgrade to keep service

SMTP Require TLS Option, Jim Fenton
                draft-fenton-smtp-require-tls
Viktor: overengineered, anything beyond must use TLS or must use verified TLS
won't be useful; shouldn't this be a header; should this go to an SMTP WG?
Alexey: perhaps WG will form soon JF: header seems wrong layer, DNSSEC solves
large vulnerability VD: still very little DNSSEC A Zauner: advertising before
STARTTLS gives the opportunity to strip the feature this seems to be a bad idea
Keith: could be useful in marginal cases Brian: header not good, can't check
that subsequent MTAs support it

Leif: is this in scope?
Alexey: yes, would prefer WG handle existing drafts first
Leif: who would implement this? three hands
Some interest, not overwhelming

AOB: none