Minutes IETF98: tls
Transport Layer Security
||Minutes IETF98: tls
TLS WG - IETF 98
Chairs: Joe Salowey
Minutes: Jim Schaad
Tuesday, March 28, 2017
TLS1.3 (30min) - EKR
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
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
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
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
ACK - structure
MT - should not ack handshake messages - because we just process them
follow the quick style - include a list of records
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.
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
Christian - Add new requirement - need to look at privacy at just
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) -
DKG - Need to deal w/ SRV records so the server would not know the client
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
EKR - Are these ECDSA or RSA certs? - mostly 2048 byte keys
Point compression would also remove 32 bytes in certs. 32 octets on
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
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
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"
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
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.
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
read draft - ~ 10
Support adoption - mod hum
Unsupport adoption - crickets
- TLS 1.2 Update for Long-term Support
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
read draft - few
support adoption - small hum
unsupport adoption - about the same