2018-03-22 18:06:56+0000 ------------------------ UTA (Using TLS in Applications) at IETF 101 Note Taker: Daniel Kahn Gillmor Jabber Scribe: Jeff Hodges Slide: Document Status. Slide: Document Status (???) Alexey Melnikov: tlsrpt is on IESG agenda for April 19, but mta-sts might slip tuntil May. discussion about mta-sts draft Slide: Major Issues (1) Daniel Margolis: i'm fine with requiring utf-8 or us-ascii, and saying that we should check it. There is consensus to accept Alexey's suggestions. Slide: Major Issues (2) There is consensus that trailing whitespace is fine. leading is problematic. Slide: Minor Issues (1) Slide: Minor Issues (2) Slide: Minor Issues (3) Slide: Minor Issues (4) Slide: Minor Issues (5) Slide: Minor Issues (6) Slide: Minor Issues (7) Slide: Minor Issues (8) nit-picking on minor issues doesn't seem to raise any objections Slide: Minor Issues (9) Alexey says that this point is not actually so minor. the document should point to RFC 5280 instead. Margolis is fine with that, but unclear on keyUsage. Jim Fenton wants to know whether we can use DANE certs as well. Viktor Dukhovni: wants to know whether we care about extendedKeyUsage in the EE or higher up the chain? as a maintainer of the validator in OpenSSL, he wants to know what he should do. Margolis doesn't know, was hoping to do whatever browsers do. Martin Thomson: simplify by saying "it must be valid for that host", or you could reference 6125 and 2818; but you're going to get people's HTTPS stacks, so just say that and get what you get. Alexey: the text should either be exhaustive, or it should be hand-wavey. but these are automated clients, not web browsers. MT: client makes policy decisions but they're pretty hand-wavey. Jeff Hodges: it already references 6125, but we don't actually have a document that describes what people do. MT: none of this is written down as well as it should. but i don't want to stick Dan Margolis with the job of writing it down just to get MTA-STS out the door. Margolis: let's not make this the spec where we do that. We'd rather reference external documents. Jim Fenton: it sounds like we're identifying another work item on Using TLS in Applications. MT: it took ages to get 6125 out the door -- due warning. 2818bis would be a massive amount of work. Tim Hollebeek: "for example" is a good idea, including the name validation, since that's what people usually forget to do. Viktor: "do like other HTTPS clients do" Consensus in the room seems to be that no one wants to write this, so this should just do as other HTTPS clients do, and be outbound references where possible. Slide: Minor Issues (11) Margolis: Clients must send SNI because some servers will need it. Chris Newman: how widely implemented is client-side SNI, though? Martin: any TLS stacks that don't do SNI are hosed already. even windows XP supports SNI. Viktor: we must require SNI on the client. not all modern stacks are used by MTAs Chris Newman: no need for server to implement SNI. MT: just wanted to make sure we connect to servers using IP addresses. Consensus seems to be Clients MUST implement and use; don't-care about servers. Viktor: server shouldn't abort connection if it doesn't have a matching name. it should give the best guess default certs. Viktor: If there's some sort of manual administrative override that requires IP addresses, then DANE doesn't apply. MTA-STS shouldn't either. Viktor wants the spec to say that servers MUST NOT abort even if it can't find a certificate that doesn't match. please reuse text from RFC 7672. Slide: Minor Issues (12) Discussion about whether mitigation text should be here. Room is ambivalent, but ok either way. leaning toward accepting Chris's text, but keeping mitigation sections. Slide: Minor Issues (13) Chris Newman retracts the issue, he says he was wrong. Secdir review: PHB wants the document to use the IANA registry for underscore-prefixed names. Leif suggests that we just count on the RFC-Editor to manage the race condition. Alexey can suggest concrete text with guidance to the RFC-Editor. There is discussion about whether to do two levels of DNS layer or just one. i think we're all fine with one. Goal: get this final revision out within 2 weeks. ------------------- REQUIRETLS overview MT: why turn off TLS? Jim: tornado warnings -- public info, no privacy concerns, deliverability is priority. Viktor: troubleshooting, working around implementation errors. MT: please don't add too many knobs to constrain multiple hops. viktor: keep it simple read rfc 7435 dkg: agree, please keep it simple. Bron Gondwana: keep it simple also -- making it simple might just mean "best practices today" Consensus in the room seems to be to keep it simple. Leif calls for consensus.