Alexey Melnikov & Hannes
5 min. Administrativia (jabber scribes, note takers), Note Well, Agenda bashing
No agenda bashing
5 min. WG documents status update
Valery talks about WG status.
Some progress on 2 draft that will be presented today.
Disappointing of almost no discussion on draft-ietf-uta-tls13-iot-profile-02
Rich is presenting.
Alexey asking whether the suggestion to remove the text about X.500 also includes the removal of the explaination of the DN structure.
Rich: The idea is to “not recommend” using of CN-ID, so the whole text should probably go.
Alexey is looking forward to see how the new text will look like.
Roman from jabber: To be clear, are we saying drop text about CNs or explicitly say don’t use CNs?
Rich: the title is rather long.
Sean Turner: compress it by using TLS, people know what it means
Issue about wildcard - remove “*foo.example.com”, which was discussed on the list
Valery: from the mailing list there seems to be consensus for this change
“pinning”: should the term/concept be included or not?
Alexey: Want to have it covered in the document because it deals with the same code segment. Conceptually, it does not need in there.
Watson: pinning creates problems. I would recommend against it.
Viktor: agree that pinning is out of the scope of this document.
Rich is also opposed to it.
Action: take discussion about pinning to the mailing list.
Viktor: there was no consensus to remove wildcards from the document, but add a warning that wildcards should be avoided if possible?
Valery: Viktor, send text to the mailing list?
Peter was asking Viktor about a comment he left on jabber wrt whether he suggested that this document should be advanced to Full Standard (from Proposed Standard)
Viktor clarified that he was not suggesting to advance it to a Full Standard.
Peter is presenting. Thomas Fossati became a co-author of the draft.
Should ChaCha20/Poly1305 and ECDSA ciphers become a SHOULD for 1.2?
Should suggestions from draft-cooley-cnsa-dtls-tls-profile be adopted?
Deb Cooley offered help regarding the text in her draft. In particular if you need rational for various recommendations.
Peter will start a mailing list discussion.
Watson Ladd: There is a huge performance impact for moving to P384r1.
Peter: We haven’t finished the discussion yet to make a recommendation.
The authors feel that the document is pretty complete (modulo the open issues). WGLC around IETF 112?
Valery: should we concentrate on promoting TLS 1.3?
Peter: it is a bit premature to deprecate TLS 1.2. But the document talks about both TLS 1.2 and TLS 1.3.
Rich: How to configure a 1.2 stack is what the draft should say and if you want features only available in 1.3 then use 1.3. Your reasoning, Peter, makes a lot of sense.
Carrick, and Sean agree with Rich and Peter.
Alexey: (relaying Stephen) has anyone looked at the docs referencing this BCP to check if there’s anything we may break by accident? (sorry, can’t send audio right now)
Peter: No, we haven’t done. There are a huge number of documents referencing this document (inside the IETF and outside the IETF). We should do a little bit of that. I cannot promise this investigation to be comprehensive. Stephen, do you have any specific concerns?
Stephen (in jabber): no just generic worrying :-)
Viktor: The key length increases to 384 for ECC and 3072 for RSA are not wise. The ecosystem is not moving there. P384r1 is barely used anywhere. I would not make these recommendations since they would prevent developers from taking the document serious.
Peter (from Jabber): What Viktor says makes some sense. We might want to point in the direction of larger key sizes for instance (and informatively reference the CNSA document), but not make that a SHOULD.
Yaron: In response to Stephen: we don’t try to be reckless, we are conservative. But we don’t guarantee full backward compatibility with previous version of the RFC. We have an opportunity to raise the bar.
Stephen (from Jabber): Yaron: that’s fair, I guess since we encouraged other IETF docs to refer to BCP195 and not RFC7525 we do owe 'em a bit of due diligence in cases where the bis RFC isn’t the same as 7525
Roman Danyliw (in jabber): Not raising the floor something because it’s not PQ resistant doesn’t motivate me. We don’t have enough fidelity into the PQ solution yet and we can’t just freeze our evolution of improving classic recommendations.
Sean Turner: will the WG close after the current set of documents is done?
Valery: Francesca (responsible AD) will be consulted. At the moment the thinking is that the WG might become dormant, instead of closing. For example to deal with TLS 1.3 related updates.
3 open issues. One relates to AEAD limits. Maybe CFRG should be consulted?
Another one is about certificate revocation for long lasting connections. Need to add some text about that. Approaches to do this changed over time.
Retransmission timers in DTLS 1.2 were different from 1.3. Granularity is different.
Valery: bring your questions to the mailing list.
Peter: we talked to CFRG AEAD limits authors about draft-ietf-uta-rfc7525bis.
Hannes: it looks like analysis in the CFRG document might not be correct.
Watson: it is weird to have 2 WGs related to TLS. Close UTA and continue in TLS WG itself?
Watson: There might still be more work but I am not sure we need more work in UTA.
Roman: There is a long history here. The idea was that this group would polish TLS for use with applications rather than with the work on TLS itself.
Valery: TLS works on the protocol/extensions and UTA offers profiles for use in specific applications/environments.
Meeting closed 12 mins early.