TLS Session #1 - 15 Nov 2016 Seoul, South Korea Chairs: Sean Turner, Joseph Salowey Document Status: Chairs Yoav Nir: State for ECC for 1.2 - Question of Edwards 448 context - suggest just ingore it. But should be ready to last call Russ Housley: for the uplifting of EC 256/384 & AES-GCM - new RFC is going to be produced. Sean Turner(SPT): The chairs are going to WGLC: draft-ietf-tls-rfc4492bis and draft-ietf-tls-ecdhe-psk-aead by the beginning of next week. Open SSL Status - Rich - no discussion TLS 1.3: ekr PR #748 - exists a need to support incompatable drafts - thus a need right now for 1.2 in list No extension sent if 1.3 not used Slightly easier textually to clarify the current text SPT: Lets just do that Issue #758: No arguments against - will adopt Issue #760 Joe Salowey(JS): how are the OID matches being done? Daniel Kahn Gillmor (DKG): is the fact that matching already depdendent on which OID? Martin Thomson(MT): Agree this is a good idea Ben Kaduk(BK): How many bytes are being saved? Eric Rescorla(EKR): If all items empty- 2 bytes Kyle Nekritz: Move ?? schemes to extensions as well EKR: Yes it makes sense to do this. Record Header - PR #762 if doing 0RR and HRR - need to skip new header format to get to old header format for the new client hello I have something that should deal with this Ask for techincal review BK: Ensure that high bit is set for the measurements Longer key lifetimes SPT: this is really editorial and we can change this number later if needed. MT: Lots of discussion with cryptographers @ time text went in. Happy with current implementation numbers are conservative, but don't see a problem with it. JS: Chairs will look at the list to see if text followed or preceeded the text ****ACTION **** MT: Based on second paper, if we always have full size records then re-keying slightly after than we should be. This is the Abdalla/Bellare paper. Quyan Dang(Q): It depends on the total data and not the record size for this limit. EKR: Should we count bytes rather than records instead? Q: seemed to say 'yes' but restated the conditions instead of answering SPT: Ask for a PR from Q about the issue with text and then we can run with the cryptographers. David McGrew offered to review the PR MT: What is currently tracked is record block rather than bytes so changing is problematic. Stanislav S: reference to presentation at CFRG with the possibility of looking at multiple levels of keys, but currently thinks the limits are fine. STP: Question about a state machine to be added? EKR: Plan to add this for the -19 version. EKR: Gone through the blog posting and all items appear to be understood or a misunderstanding of the current protocol. (out of order) PR # 763 - Require point validation for EC Points STP: thought we had a discussion on this EKR: Current requirement for DH but not for ECDH or XDH Rich Salz(RS): What is the state of IPR for this? EKR: Is this in fundamental algs? room - no Nick Sullivan - most applications do it in the conversion to Weierstrass EKR: Maybe we can bounce the question to CFRG YN: This is done for IKE Yaron Sheffer: Recipient tests in IKE apply to FFDH. TLS Version No - STP & JS humm for 1.3 - loud and solid hum for 2.0 - some but much softer hum for 2 - empty hum for 4 - some but softer -- chairs - from this 1.3 seems to win TLS Visibility Inside the Data Center: Steve Fenter/Jason Witty - 20 min YN: PFS is the only reason for TLS 1.3 - No need to maintain 1.2 it exists. Changes to 1.1 and 1.0 have known problems thus they have a problem No sure knowledge of what will happen if a new vulerability is found Draft has nothing that cannot just be statically setup on the server w/o a draft. Jason Witty (JW): Problem with MiTM is that internal communications are all TLS as well. DKG: Some degree of MiTM already exists between inter and intra Looks like you are on an attractive nuesence based on the fact that archives exist with all of the data and keys Recommend don't lose PFS, log ephemeral to the log. Still the same attractive nuisense, but does not loose PFS. Don't want to see as base spec. Steve Fenter(SF): problem with tracing everything is that lots of ephemeral keys from a lot of different places to look at. RS: Move security considerations from the green document to this document. No protocol needs to be changed. Can't stop bad server behavior. EKR: NSS already uses ephemeral over multiple sessions Would be nice to have a security analysis for the case of not having all new ephemerals. Client enforcing freshness would require too much state What are the standards requirements that are needed from the docment stamping prospective? JW: Ideally would be from the TLS WG and helped from there EKR: Might take to X9 as they are generally more sympathetic Dan (from akamai): Why is the move from RSA privates to ephemerals jump a big deal SF: The problem is the complexity of corrolation of time and item. ??: Suggeestion to use PSKs based on time DKG: Other mechanisms right now for repeated messages session resumption is going to cause non-forward secrecy. Need to be clear about the window of forward security is needed. Kathleen: This needs to be careful to not drop into the wire-tapping world which might be an issue. Draft is baked enough to be publish - we can get some suggestions but might be better on the ISE. Don't see this going std track from the WG. Doable even w/o a working group document. Looking for more logging on drafts as they are coming to the IESG. May be some techniques that can be used that will avoid the need to do as much decryption as you are currently using. Examples of TLS 1.3 dumps - Martin Thomson EKR: don't know if this is really good or not - publish after the 1.3 document? SPT: this would be the expectation. MT: Use input from the WG to decide which test cases to include MT: This has intermediate results - need to capture the key schedule. DKG: Would be more useful to have lots of copies and nobody wants to extract from this document Joe Hildebrand: Could maybe point to github as normative - send to the rfc-interest mailing list Richard Barnes(RB): Might be useful to be automatically extractable and reproducable for verification. Cullen: Best reason to do this is because checking a golden copy always had issues with finding bugs in code and in the test examples. SPT: Early next week take WG adoption to the list. Post-handshake Auth: Nick Sullivan(NS) Need to some analysis if this was done in the 0-RTT case before the TLS finish message Jeff Hodges(JH): Does the call from the app change the state of the TLS stack? NS: No, this is agnostic to TLS JH: Why not just use token binding? MT: Multiplex protocol on top of TLS - need to bind authentication to a specific request Which tab in browser should get the UI Andrei Popov(AP): Like the correct placemet of the crypto. Does allow necessary correlation w/request Does a distribution of identity state between TLS and the appliation NS: Could in principle cache the identity at te call to EX-A API all time NS: Currently assuming that PSK resume is always to the same SNI NS: Yes we might want to make the response be opaque to the application EKR: step 1 - get some crypto analysis step 2- look at the application semantics step 3- how should we be treating these certificates - gluing origins is one problem that needs to be dealt with SPT: Early to ask for adoption, but seems to be a reasonable approach to follow up and ask later Second Session - 11/18/16 DTLS 1.3: ekr No discussions Optimizing DTLS for use in IoT - Martin Thomson EKR: Two situations to look at on HOTP roll over - If you have a sequence and you know you changed, life is fine If you don't know you have change and you roll forward then you have a problem if you didn't BK: What are the use cses where you cannot use quic? MT: Difference between deployed code and stuff the IETF is just starting to work on. EKR: Given negoation - just do sizing on CID as part of extension EKR: How far is this discussion? This was the biggest mistake of DTLS to start with MT: Don't think w/ HT that a solution has been agreed on first. EKR: How do you solve the privacy issues - don't see this as possible. ??: If deploying quic in scale, then a fixed size is better for roll over on server MT: Client gives range, but server picks. MT: 32bits is probbly right for really small IOT world, quic may need to get up to 128-bits potentially, so a fixed sized and thus dead code is probably not going to be a problem. DNS validation chain extension: Melinda Shore - 10 min Paul Wouters(PW): Order is DNS recieve order? Why does this make a difference? MT: Does anybody have an alternative? MT: Talking about client certs in draft may just rathole you. MT: If need the capacity in the future, in 1.3 can negotiate extensions from the server to the client. EKR: Are you delivering both chains or replace the X.509 chain - if replace then use the certificate messages PW: Can see that you might have a server where both are delived. EKR: Just a question of how you deliver for what extension Paul Hoffman: Support using cert message ? Sullivan: Make this as an extension to the EE certificates EKR: What goes into the EE cert? Is this the regular cert or something else? MT: Believe you can have 1) only cert, 2) only DANE, 3) a bit of both. Provide some on the fly design sugestions BK: Proposal for rawk public keys - may need to look at this as well. MT: otptions are cert, raw, look elsewhere EKR: Suggest that we do a fast design as a small group after. Paul Hoffman: Need to do some list based discussion NS: Have you thought about doing some multiple chain work for inclusion of other DNS records other than DANE? Alison Mankin: Should there be an identifier of the type of records here for different types PW: Thought of this as pre-population of the DNS cache on the browser. Delegated Credentials: Nick Sullivan - 20 min EKR: Want to stress the security considertions - Must need to come with a certificate extension bit which says I am doing this. Sean Leonard: Being proposed for both server and client? NS: Just server Sean Leonard: Proxy certificates are running in a number of places, so this would be my preference. RH: Suggest use EKU for allowing this type of authorization. Also like proxy Deb Cooley: Think that this looks intersting for both server and client. Would potentially help with firewalls to see things Like the opt in on this. Ryan Slevi: Number of options w/o going to the CA Forum. Proxy would work for this. ??: Question about doing upstream/downstream CDNs. NS: Notin this proposal, but proxy cert spec does allow this. ??: Preference for #3 KN: Facebook implementer - prefer #3 for easier to validate and implement RB: Given current libraries, I don't know that I can do the proxy. AP: Worried about the deployment model as one client which does not support this means that you still need a lurk type proposal w/ fast and slow path. Lief Johansson: OpenSSL does do proxy certs and has for a long time. CHAIRS: quck Hum. Should the working group continue with this investigation? Good amoount Bad idea? Crickets MT: Is this a document that we want to adopt? Few people have read so this is deferred. Trust on First Use - Ticket pinning - Yaraon Looking for adoption after the 1.3 work is finished. RS: One of the concerns of HPKP is that this is a key life cycle managment problem. This seems to have the same problem. What failure recover techniques are there? YS: This does not have a manual component - need to backup the protection keys. BK: Privacy situation if clients are using same ticket If the reject occurs, why would there not just be the same type of operation as pinned certificates? Similar to questions of session resumption key. Key managements seem to be the same. YS: privacy is a problem w/ the server, but we recommend a new ticket be issued on each connect so that an observer cannot cooralate