Minutes IETF101: uta
minutes-101-uta-00

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.