Skip to main content

Minutes IETF103: tls
minutes-103-tls-02

Meeting Minutes Transport Layer Security (tls) WG
Date and time 2018-11-05 06:50
Title Minutes IETF103: tls
State Active
Other versions plain text
Last updated 2018-11-15

minutes-103-tls-02
Minutes for TLS at IETF 103, Monday

Did administrivia (scribes, agenda, bluesheets)

Reviewed document status

DTLS 1.3 update, ekr

- New unified packet header that is flexible and more tightly packed
- Sequence (record) number is now encrypted
- DTLS 1.3 MUST NOT use compatibility mode
- Removing end of early data marker
- Changes to allow ConnectionID flexibility
- Next version would go into WGLC

Deprecating TLS 1.0 and 1.1, Stephen Farrell

- Details about which RFC's, BCP's are affected
- Will remove the 'measurements' part
- Remove SHA-1 deprecation from this document
- Discussion of timeline; will do new draft and WGLC soon

Encrypted SNI, Nick Sullivan

- Early drafts deployed by CloudFlare and FF Nightly, for experimentation
- Changes from initial draft: two key shares, none, AEAD, replay protection,
version - Major pending change: new DNS RRType instead of TXT - Proposal from
floor: have list of ESNI records, for middleboxes (and others); DNSSEC
  implications and other discussion
- Operational issues: DNS/server out of sync, multi-CDN usecase

Discussion of re-Chartering, chairs

- Detailed text was sent to the mailing list
- Discuss DTLS items in the charter (e.g., are they already done?)
- Discuss timing of this; maybe wait for DTLS 1.3 to be done

External PSK, Russ Housley

- Determine way forward via series of hum's
- Decided to adopt the draft, which has only "external PSKs with certificates"

TLS Authentication using ITS ETSI and IEEE Certificates, Mounira Msahli

- These are apparently smaller certificates than X509; used in vehicles
- Description of new certificate types; will ask for IANA registration

External PSK Importers, Christopher A. Wood

- Motivation was TLS 1.2 and 1.3 hashed differently
- An importer takes an existing PSK, adds hash and optional label as base key,
  then generate key per hash supported
- Comparison of this and "universal hash" document by David Benjamin

TLS Ticket Request, Christopher A. Wood

- Clients want more/less tickets than servers send by default
- Add ClientHello extension that hints number of tickets desired
- Consensus to adopt as a WG document, to be confirmed on the list

-----

Minutes for TLS at IETF 103, Wednesday

# Sean Turner - draft-ietf-tls-dnssec-chain-extension

See the presentation at
https://datatracker.ietf.org/meeting/103/materials/slides-103-tls-sessb-dnssec-chain-exetnsion-01

- Odd that the chairs are having to do the presentation

- Indicates that we're not necessarily in a good place

- Goal to figure out what to do with this draft

- Only 3 hands raised for planning to implement

- Only 3 hands raised for planning to deploy

- Use case making DANE practical for HTTPS

- Discussion started at IETF 93

- There were no IETF last call comments

- There's a downgrade attack against DANE PKIX attacks.

- Ekr cleared his discuss during IETF 101

- There were multiple appeals

- Very few people responded to the chairs' consensus call

- Participation in discussion of the draft is going down

- There was a 4-part consensus call during the Security Considerations thread.
There were only seven participants in the consensus call.

- Editorial, Denial of Existence (DoE), and Security Considerations commits
will be merged

- We don't have consensus to add pinning or reserved bytes

- We are having less and less participations

- We need to figure out whether to let the draft gracefully die because it's
not useful in the consensus state

- Viktor Dukhovni objects to what is happening here. The slides were published
late.

- Ben Kaduk: responsible AD: Apathy does not represent consensus

- Paul Wouters: Consensus does not override the security considerations

- Richard Barnes: We are continuing to progress ACME despite security risks

- Paul: This extension proves that you're not under attack only when you're not
under attack

- Sean Turner: Are there any browser vendors willing to come to the microphone
saying that you're planning to implement? (none did)

- Nicholas Williams: I'm confused. What are the real objections?

- Martin Thompson: I (Mozilla) have no plans to implement this. When you're not
planning to implement something, participating in discussion is a waste of
time. That accounts for the decrease of participation. The conversation has
become toxic.

- Paul Hoffman: I agree that I didn't want to participate in a toxic
conversation. Wants these questions to be called on the list. It was pulled out
of Auth48 and is back in the working group.

- David Schinazi: I have no plans to implement this in either browser I'm
involved in. Please kill this because it's wasting the working group's time.

- Ekr: Mozilla will not implement. Exhaustion is a better description than
apathy.

- Viktor: The document still has major gaps even with the 24 commits. It failed
to describe how virtual hosting works. It failed to describe DNS TTLs.

- Sean: There's more than one person here who are interested in this but there
don't seem to be many more

- Rich Salz: The claims and the way it was sold are no longer accurate

- Wes Hardaker: Highly negative discussions cause people to drop out. 90% of
the negative perceptions of the IETF come from this working group. I am
concerned with publishing the document with pieces missing. That does not
represent consensus. There is not consensus to publish the whole document.

- Eric Kinnear: Apple has no plans to implement this.

- Paul Wouters: There are lots of mechanisms in use that already exist. Why are
the people who aren't interested in this blocking me from my use case?

- Ekr: RFC 8447 allows document to be published and get code points. He
suggests taking the draft out of the working group. People could still publish
a document by other means. Let us be done.

- Richard Barnes: I agree with removing the document from the working group.

- Tarek Sarat from the Jabber room: It is still a contribution. We don't have
consensus to publish it. Let it die gracefully.

- Stephen Farrell: Remove it from the working group and let it die gracefully

- Viktor: On what basis can you remove a document from the working group?

- Lorenzo: I have seen this happen in other working groups when toxic documents
are being discussed

- Sean: The ISE editor will consult the chairs and the working group history

- Kathleen Moriarty: The ISE takes WG advice in conflict review. They do not
have to follow it. We have had contentious documents go through the ISE stream.

- David Schinazi: I wasn't suggesting that people can't implement this I was
suggesting that the draft leave the working group.

- Ekr: In the IETF we don't convey the power for people to prevent people from
implementing. I don't think there's consensus for the document or to implement
it.

- Nicholas Williams: I won't object to any of the paths forward. I really want
the DoE stuff to be present - the bugs have to be fixed.

- Cullen Jennings: Consensus is measured at a point of time. It's open whether
there is consensus to work on this now. We should re-ask the standard question.

- Sean: Doing a hum on whether there's consensus to work on this.

- Steve York: ISE means it's informational or experimental.

- Hum: Is the WG interested in working on this document? Sean: There was
consensus in the hum to not work on this document.

- Sean: I'm not very happy with this outcome - this was not our finest hour. It
would have been better if we came to this conclusion before spending all this
time. There are things to learn from this.

(Mike Jones thanks Matt Miller for helping him with details of the minutes on
the fly)