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