TLS WG - IETF 98 Chairs: Joe Salowey Sean Turner Minutes: Jim Schaad Tuesday, March 28, 2017 9:00-11:30 (CDT) TLS1.3 (30min) - EKR https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ https://github.com/tlswg/tls13-spec PR #768- proposed to drop the item - No response in the room to object. PR #762 - short headers - proposed to drop the item - No response from the room Non-X.509 Certificates Hannes - raw public key in cached info used for IoT EKR - that should be the easiest to fix. Send me a paragraph on how to use it would be easiest Victor - Remember discussions say cache_info should just work. DKG - open pgp cert implemention is probably deprecating Post handshake client auth Hannes - think browser use case - problem w/ IoT EKR - Expect to remove from DTLS size of memory is the same as for HRR Andre - ok w/ extension MT - W/ should make sure small devices are happy. Carl - makes sense for server to know who does it support EKR - room consensus is to send the extension to opt out. Tero - the strings seem tobe somewhat random - is there/should there be a plan? Might be nice if they are shorter also if a table existe of them. The name of the secret and the string name are not always consistent EKR - should not be an issue to make things more consistent Not expecting a new WG last call as no big technical changes so far. Expect implementations to camp on 18 for while and then jump forward DTLS1.3 (30min) https://datatracker.ietf.org/doc/draft-rescorla-tls-dtls13/ ACK - structure MT - should not ack handshake messages - because we just process them follow the quick style - include a list of records received. Hannes - w/mesh networks - kept timers short right direction - need to think about approach more Ian - don't need timestamp unles need super accurate time. EKR - why wait lots of round trips to get any feedback MT - new content type so not in transcript. ACK - which epoch for encryption MT - quck position is either one Adam - does it need to be encrypt? Ben - Epochs are cheap - give them their own. DKG - the more in the clear - the greater the linkability and traffic analysis Adam - probably can infer conent anyway. EKR - suggest do an ack of everything and see what happens. Key Upate Shrink Packet Header MT - hello is in long form already - therefore would have two header types anyway IAN - two bytes for the sequence is fine, one is very iffy. MT - this is currently 1.5 bytes Connection ID Christian - Add new requirement - need to look at privacy at just one layer privacy event to change all identifiers at same time EKR - worried about both intended and unintended transition events Eric - token buckets work well w/ load balances as well Scott - Random idea for improving token buckets; server has static key $K$; for a particular client, server generates a random $R$, and gives the client R, and E(R). When the client sends a packet to the server, it picks a value i, and sends the server E(R) and i; it then uses Hash(H II i) to encrypt Adam - public key encrypt identifier - server only needs to decrypt when it does not recognize Have idea to make it not expensive to client DKG - Tethering case of laptop to phone would be one where client is not aware of phone transitions as internal address remains the same as it comes from the phone Hannes - want case where this is lightweight Ian - Sufficently costly - might be easier to not send connection idea much of the time Do support adding to transport. New for every packet is going to be too expensive Handshake Message Transcript Ben- rather not changeit as 1.2 needs to still be supported - so cross-version is a problem. A DANE Record and DNSSEC Authentication Change Extension for TLS (15min) - Melinda https://github.com/tlswg/dnssec-chain-extension https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ DKG - Need to deal w/ SRV records so the server would not know the client path. client may need to add this info MT - final name is still the same, server does not know how you got there PHB - Problem is DNS does not distinguish between hosts and services. May want IAB to look at this. EKR - Worried that the rules do not create an unabigous list for correct evaluation. Either don't need to know about breaks, or breaks are explicit. ADAM - original text must moved forward - move more towards the TLS cert chaining - give starting point and then all of the data and move foward from there might be a better paradymn EKR - Should we request a more formal review from the DNS world? Certificate Compression (15min) - Victor https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/ EKR - Are these ECDSA or RSA certs? - mostly 2048 byte keys Point compression would also remove 32 bytes in certs. 32 octets on the key Adam - just switch to Ed25519 - same effect EKR - suggesting entire certificate - what happens if you add SCT and OCSP responses. Ryan - Many responders adding certs into the OCSP response - Victor - these are now part of certificate messages - so this would be covered. MT- How often is this useful w/ cached info Pre-seeding w/ OID values might be useful Victor - resumption does not give amplification problems. Premade dictionaries are under considerations Need to hand assemble it, can't just use current data set as it might be biased Primarly worried about first time talking to server and not second time - can do resumption in many cases there Victor - If response to long then do HRR Adam - Big when given the number of sub-hosts that websites use today - 200 connections times 1 K EKR - May want to require client support for quic Victor - some concerns about compression w/ expansion and code Jana - could apply to things like pass tokens? Ian - Harder to get resumption on mobile devices - so benifit there Hannes - push cache info again - Sean - looking for hum for adoption Hum to adopt - good strong hum Hum to not adopt - crickets Delegated Credentials (15min) - Subodh https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ EKR - notes on structure of the TLD protocol version string Ben- need table of all of these strings Adam - This is injected - may want to length prefix it DKG - length prefix and cert type Richard - reason not to use EKU? Adam - ask CA which is easier to do Rich - Are any CAs going to support? Suboh - not yet Ryan - EKU policy flow down may be problimatic Adam - one time not two - only 32-bits Subodh - relative to the start time MT - what about clock skew on clients - this can be a problem. Can only do this if the client has done something to get a "fresh" time recently EKR - reduce the end point time, but not starting clock skew MT - reverse clock skew is to make things last longer and also made an argument about not-before being an issue as well Sanjay - how is the re-issue done S - this is just a server side issue - no changes on clients PHB - issue short certs? S - don't use short certs rather than going back to CA can be an issue. DKG - increase of the CT logs for the CA Piotr - 7 days may be too long - given this is untrusted site S - This is a max that is enforce by clients. Can be lower EKR - Attacker would put in the cert for forging Yoav - The shorter the time, the worst the clock skew problems are Erik - knowing rough time from the client might help shorten this. spt - Hum to adopt - good hum Hum to not adopt - a couple of people Rich - Not sure that a real problem is being solved because of the exposure of keys Disposition of additional drafts discussed on list (15 min) - SPT - Exported Authenticators in TLS draft-sullivan-tls-exported-authenticator read draft - ~ 10 Support adoption - mod hum Unsupport adoption - crickets - TLS 1.2 Update for Long-term Support draft-gutmann-tls-ltss read draft - ~10 Support adoption - small hum Unsupport adoption - mod hum JLS - asking if published by different stream EKR - want correct warnings - TLS Server Identity Pinning with Tickets draft-sheffer-tls-pinning-ticket read draft - few support adoption - small hum unsupport adoption - about the same