Minutes for TLS at interim-2015-tls-1
minutes-interim-2015-tls-1-2
| Meeting Minutes | Transport Layer Security (tls) WG Snapshot | |
|---|---|---|
| Title | Minutes for TLS at interim-2015-tls-1 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-03-18 |
minutes-interim-2015-tls-1-2
IETF TLS Interium Meeting - March 10-11, 2015 - 9AM - 5PM
Location: F5 Networks, 401 Elliott Ave W, Seattle, WA
Chairs: Sean Turner, Joe Salowey
Notes: Jim Schaad
Version: 1.0
===============================
Attendees:
Sean Turner
Hannes Tschofenig
Martin Thomson
Daniel Kahn Gillmor
Andrei Popov
Andrey Jivsov
Tod Ouska
Chris Conton
John Safranek
Larry Stefonic
Hoeteck Wee
Hugo Krawczyk
David Holmes
Richard Barnes
Jim Schaad
Adam Langley
Brian Klisch
Colin MacCarthaigh
Rich Saltz
Eric Rescorla
Joe Salowey
J Harper
Jeroen de Borst
Brian Hamon
Agenda Bashing
Hannes - Chached Info
Also add some time for padding with DKG
Status pages with the chairs
TLS 1.3 Changes
EKR -
Review of changes to -04 and -05 drafts
Only allow duplicate curve representations for existing ones
and not for new ones Add restirction on a single point format
to 4492 BIS(?) ---- ACTION Should the list be compete for code
point in handshake? Open issue for now -
Sean no - because would need to do all of the
lists anyway.
Some questions still open about when the hash needs to be included -
dissusions open with Hugo
Not all of the backwards compatiblity changes got incorperated
as some of it is till open issue Pull request 107 finishes
backwards compatability
Pull Rquestion 107
Fixing the record version of the client hello
Mozzilla and Google say - do this and make it strict
EKR - can we remove the record version or not?
Need to have all alerts carry it and the client hello
Prolem with anyone in the middle looking for it
Alternative - force the record version number to always be (3,1)
It could be tested in Chrome - but alot of work
MT - Move to make it fixed to 3.1 in the absence of tests to see if it
can be removed. AP - send whatever and ignore on receipt - sending 3.1
ok. What does it send on the server hello ACTION: Change to always send
3.1 and ignore the value on the receive
0-RTT - EKR
For a 0-RTT mode - server must have some state to prevent replay attacks
Need to make it consentual for the server
** Overview of 0-RTT flow slide
Question of how much PFS is lost - Adam points out that this is the
same as is done currently in TLS, but EKR responds with the fact that
since the key derivication has changed with a different session key and
master key so that this is not going to be an issue for TLS 1.3 Lose
PFS on multple resumptions? Have a timestamp in the clear from the
client - allows for fingerprinting, but this is a requirement to
release this info to somebody. AP - requires a shared database across
multiple machines What to do on failure AL - suggests using retry 0 RTT
mode EKR - Two slides - first one is when the server key is correct but
the window is out Second slide is the normal case when the key has been
changed as well Some preference to just have the second case. It is
required in any event. DKG - Attack - have sent some data using 0-RTT -
messed up in the middle (delay or block) - Retry and succeed with full
handshake - replay (or release) of app data from the first sentence AL
- This is already done in TLS 1.2 with this for HTTP. EKR - might be
prevented because the random is part of the replay AL - If attacker
sends to a new cluster with a different orbit value then cannot be
prevented. AL - Why did I do the strike register with this attack EKR -
If use orbit and it is wrong then do a handshake failure - moves it
back to the appliction layer rather thn the TLS layer ** WHITE BOARD OF
PROBLEM ** Two cases where this works - non-multi home systems, very
tight global cache (relly hard to do ), if partioning can be enforced -
i.e. queries between data centers needed. HTTP has replay in it already
- so not an issue for that protocol, big issue for other protocols
Document the mode - make the requirements are known in the RFC.
State exhaustion attacks are a problem - Close down by narrowing scope
rather than broaden which is normal DDS attack prevention methods. Need
to make sure that you don't race the packets to different servers -
Part of the consistancy definition for the centers
ACTION - Write down what the mechansim and the security text for
implementing this feature
Details of how to do it:
Problem with cases of not sending application data - client may not do
it. Other messages are encrypted, but with a key I don't know - how do
you decide how to skip them. * Skip until I can decrypt * Or tag
which says that I can skip this. * Have a way of specifying in the
hello of the length (fails if you want streaming on the app data) *
Send one application data packet with all data and one handshake packet
- can then skip one item. (AL)
Suggestion to move all of the handshake messages into a single
"extension" so that all of the messages are present and you can
foroward - Break messages on change of encryption and change of
direction - otherwise it goes into a single message
Does kill all existing middleware state machines - have died anyway
Already doing this to some extent for backwards compatability with TLS
1.2 negotiation
Client Hello {
Client Key Share
} ------>
Server Hello {
Server Key Share
}
Server Data 2 {
extensions, server cert, cert
verify, cert request, finish
}
[ App data]
<--------
Client Data {
cert, cert verify, finish
}
[App data]
-----------------------------
0-RTT
Client Hello {
Client Key Share
}
{ Client Data2 {..., finish}
[Replayable app data]
------>
Server Hello {
Server Key Share
}
Server Data 2 {
extensions, server cert, cert
verify, cert request, finish
}
[ App data]
<--------
Issues with encrypting content types - can't figure out what is app
data in that case. There are some problems with encrypting alerts for
DTLS - middle boxes can know when things are going away if not
encrypted.
Every part with consistant cryptographic treatment is batched together.
Use count of app data messages to skip for 0-RTT fail to the next
handshake message
Question of wrapping this together does not change the question of
co-mingling or using a state machine for TLS 1.3 (EKR)
If you have a DTLS implemenation that is doing this piecemeal as chucks
come in, then you are going to have the current state problems [MT]
Question on what happens if a new message shows up - is this fatal or
treat like extensions where it is ignored? Probably should be fatal
which is 1.2 behavior.
Question of removing the numbers from the container handshake messages
except for the client hello - required for bacwards compatability.
ACTION - Adam will sketch out further to know what the messages are and
how processing works.
Identifying Cryptographic Parameters (Bhargavan/Pironti)
EKR - Providing a labeled block with the label reflected by the client
Question on using the same for PSK - Can you do a 0-RTT fail and negotiate
if cyrpto suite changes? Reponse - message because need to have proveing alg
ids which we are trying to eliminate Disadvantage in configuration of the
client and server needs more data. Would need to have the TLS WG define the
ids for the PSK suites so back to equivalent of cipher suites. QUIC is
propsosed as one solution - would need changes to separate the data not
encrypted from the data encrypted so it becomes more complicated Rather than
pickling the data - Server gives state number, and the client uses that
state and value and goes foward assuming that set of state data is correct
and does a full negotation later if there is a problem. Server still runs
the negotation algorithm on re-connect and will get the same answer because
it does not change the algorithm and the client is assumed to supply the
same input (or equivalent) and the result will end up with the same
cyrptographic algirthm set. Problem with resumption as the id would need to
be unique per client because it needs to incude the cipher suite. If config
id disappears - anounce the result algorithm and preference list - and have
server verify it is acceptable result. Still need id for the server dh
share. PROPOSAL - Client sends hello - annouces parameters to use - server
validates correctness - client indicates a key id - EKR to write up
Padding with DKG - Pull request 142
Proposal only provides a mechanism for padding or traffic analysis-
does not say how much or when to pad Two new content types: Padded
data, Padded handshake EKR - Not padding to block sizes or client hello
passing F5 devices. In this proposal Padding is being done in the plain
text block structure EKR - suggest negotate padding in the extesion for
data -always pad handshake messages EKR - if large records - then two
bytes is a small overhead - what is the case where you have mixed
padded and unpadded records where the overhead is large. Can you pad in
one directonly only - AL - it would be crazy to do this. Benefits
appear limited to making the client life eaiser by not having both
methods on send DKG - desire the padding of the data because you are in
1.3 - server could do it because it knows that the data is sentive and
the client must be able to receive it. MT - Suggests that extension on
padding is Opt Out EKR - Updated proposal - allow data padded and data
unpadded - but handshake is always padded MT - push pack on the size of
padding_length - make it 8 Can'd do that because it messes with things.
What is the value of the padding bytes? - OPEN ISSUE: Three proposals -
discussion appears to be approaching zeros and no verify. OPEN ISSUE -
can a record consist solely of padding. AL - There are problems with
having too much padding just like zero length records today. Need to
have some limit on the amount of bandwidth used by the TLS stack.
SUGGESTION - flip the order of fragment and padding in the
PaddedFrgment structure.
Policy description - easy policy is pad to a multiple of X bytes
Discussion of timing attacks based on cache freshness in the server -
could be fixed by always sending on a timing boundary - but this is not
an issue for this document. Timing attack problems are very difficult
to fix.
What about the policy descussions - where should they be?
MT - use somehting similar to what is in the HTTP2 document. - Put it
into security considerations.
Cached-Info - Hannes
Slide set displayed
Question for group: Omission of handshake messages -
AL - grumpy about this because it moves the world to the state
machine hell again AL - what if it had multiple cached server
certificates? - which is chosen by the server. currently only
allows selection of one certificate by client(?) Quick has this
built in - common sets of certificates are tagged Move into
some type of configuration id. EKR - can we move this into 1.3
and not have for backwards compatability? Does IoT need client
certificates? Does it need it for 1.2? Digest of the
ceritifcate message and not the key or the certificate. Use
SHA-256 for the hash Needs to eliminate the issues of the
triple-handshake questions. IoT does not need OCSP
END OF DAY #1
DAY #2 - March 11, 2015
Addendees:
Rich Salz
Sean Turner
Jim Schaad
Martin Thomson
DKG
Hoeteck Wee
Hugo Krawczyk
Andrey Jivsov
Andre Popov
Eric Rescorla
Hannes Tschofenig
Joe Salowey
Adam Langley
David Holmes
Colm MacCarthaigh
J Harper
Peter Bowen
Mike St. Johns (remote)
OPTLS - EKR
1-RTT mode based on signtures, 0-RTT based on shared secret/semi-static DH
negotiation Recapture concerns expressed in Honolulu about the security
issues of having a long term DH key that is signing things. Temp compromise
of a TLS 1.2 server can lead to building a fake TLS 1.3 server beyond the
acutal compromise of the 1.2 server. Look at the Performance Comparisons
Some potential issues for use of HMQV for patents. Both IBM and Certicom
have them. IBM has committed to do free usage for TLS (per Hugo). EKR - If
think could solve into the cases of == or HMQV, then do it and worry about
other issues later For variabe base - VB DH is about 3 times that of
signature
Can always put deligation back in later without it being here now.
Offline will be slower for server than online
The equality hack - can be done unilterally by the server w/o client
support - client can detect by doing a comparison of the publics (memcmp)
Working out details of the equivalent point
Sig(g^s) deivered under encryption, but g^s is not.
Issues for 0-RTT that need to supply a new g^s' for the next time.
Cost of doing RSA for signatures will still dominate the issues.
In the zero RTT case there are no options - no function for signatures -
must use the authetiction from the prevsious round trip in moved forward In
the 0-RTT case could force the server to re-prove key possion - but cost
does not seem worth while Distinct case of 1-RTT with a cached cert from
the server - does not need signature signature again use the caached key
for proof. HMQV cannot encrypt the static key of the server w/o one
additional expodentiation. MT - Currently no stomache for offline signing
case - so worse case is the online signing - but should be able to do line
4 or 5 Hugo - need to make sure that offline signing case can be in the
protocol even if no need to have it present today. need to have a hole for
a ECDH certificate for future work. HMQV has different properties for the
server identity hiding. EKR - I have a hard hat version of line 2 - could
do the line 4 in about a week - if you don't have tight roll over you kind
of get from line 2 to line 4 anyway. ACTION - EKR to write up lines 2 and 4
(+ 0-RTT) for review by the group.
Remove server cert verify
Add signature blob over session hash
Add a bit on the performance numbers
If IP clear on HMQV then can look at if it is worth doing - will require
changes in terms of what goes forward.
HMQV Disscussion
K = g^(x(y+es))
e = H(g^x, g^y)
for 1-RTT case, server needs to send g^s in the clear or encrypted by g^xy
If you split the signatures of g^s from g^s and encrypt only the signature
- less possible information for tracking - less certanty. Possible issue
w/post authentication Privacy model - linkage between two different entityes
Discrimiination between two different servers on the same hardware
Need to look at the implications of SNI encryption and how it
interacts with this.
If use g^y=g^s - then send a separate semi-static key and make g^y be
totally ephemeral.
Update/Rekey - Martin
Want to protect old traffic from future compromise
Need to deal with the sync problem - can only force and sync an update
in one direction Why is there a requirement to make it unidirectional -
DTLS w/ lossy transmission - is possible problem if a message
is dropped Force the other side to update it's keys as well
Allow for force up update for other purposes.
Why do this in DTLS? It is a complexity problem.
Could use epoch change for DTLS if no need for adding
additional entropy.
Client auth is going to be more important than this issue because
exhaustion of IV space is not feasible.
Client Authentication Version of this
keeping current client auth in the front end is protected
Rectroactive authetication of request
HTTP 1.1 problems - AL is willing to say this is dead
Move to application layer for kick
How does this interact with resumption? Server will not remember
authentication added in stream. Can stil remember the one at the start
People are saying that they do not want to deal with new session
tickets to come mid stream - just the one right after the handshae.
Need to be able to deliver the ticket immediately after the initial
handshake. Could use that as the response for TLS session tickets w/
new authentication Concept is that a new client id will retroactively
bless all previous keying material.
EKR - Moving to towards saying that we should do this - does just what
AP needs - Can be optional
Does not roll the traffic keys - make sure that this is not the way to
do a key roll. If that is provided needs to be light weight. ACTION -
AP to do a writup for his cases and also do some work to cleanup the
certificate request so it is not as large.
Given that this is decoupled from Update -
ACTION - make the update mechanism simple and different between TLS and
DTLS
Key Heirachy/Derivation
Suggestion is to do HKDF
In picture - PRF is the extract and PRFH is the expand functions of
HKDF. Make sure don't use the same secret with two different HKDF hash
functions. Questions of why the 0 in the picture - response is that
this is the key and the random values is the data to be hashed. For
HKDF - all context goes into the expansion and not into the extraction.
AL - why is the server config not input to the early appliction traffic
keys? AL - believes that should tie this to SHA-256 for ever. MT - If
we need to fix then new protocol EKR - configure one PSK and allow it
to be used with different hash functions - this violates the problem
ACTION - need a security consideration on this at a minimum Use
different context values for the three way split at the bottom of the
picture. Allows for HSM to enforce on some exporting and others not
Question of where unique comes from Make it just an exporter value For
PSK w/o DH - put the PSK in for both the static and the ephermal secret
Consider doing two extrations for the traffic keys rather than overlong
generation of data and parsing.
Need to correct the nonce so it is always a counter and has no input
from the KDFs for the purpose of AED functions. ACTION: fix AES-GCW top
32bits are 0, 96 bits are counter HUGO - use the same salt value if you
are makeing multiple calls
MTI cipher suites
What should the symmetric algorithm be - AES-GCM-128 vs ChaCha/Poly -
MUST AES-GCM-128 - SHOULD ChaCha/Poly
fips requirements
IoT - wants to use CCM but there could be a profile to
support the environement.
What should the hash function be - SHA-256
What should the ECDH be - MUST P-256 - SHOULD 24559
What should the signature be:
certs - MUST ECDSA P-256, MUST RSA --- need to be able to
drop
SHOULDS from CRFG assume they show up in the "near" future
What to do with the curves currently in the draft.
Pull the rest of the curves and mark as reserved?
EKR - normalize - and mark as reserved/obsolete
Keep - suite B P-384?
Brainpool curves - some german projects may object to removal
ACTION: Create a recommended list of algorithms in the TLS 1.3 spec.
To update the recommended list requires an update to TLS 1.3.
People can do vanity algoirthm registration but does not hit the
recommended list.
Question about ANON_ANON ciphers - do we remove this.
Only known use is mail servers - may be others.
Signature format/orthaognal negotiation
need to specify in 1.2 and above signature information
Cipher suite infrmation either redundant or conflicts
Remove the signature infomration from the current ciphersuite table -
move only to the extension Make the removal of signature infomation
only from new cipher suites Pushing for this was to get PSS signatures
supported correctly.
ACTION - Find somebody who is enthausitic and get a proposal from them
about this. MT will write a pull request on this.
Should we transition to PSS in 1.3 as well?
TLS must be able to process both PSS and 1.5 for verification, must use
pss for online signature creation? Question of hardware support for PSS
would that be an issue? Might be true ACTION: Push the idea out and
see what people are going to think about this