Minutes for TLS at IETF-95
minutes-95-tls-2

IETF Transport Layer Security Working Group (TLS) Minutes
Meeting : IETF 95, Tuesday, April 5, 2016 and Thursday, April 7, 2016
Location: Buenos Aires Hilton, Buenos Aires, Argentina
Chairs  : Joe Salowey <joe@salowey.net>, Sean Turner <sean@sn3rd.com>
Minutes : Jim Schaad <ietf@augustcellars.com>
Version : 1.1
———————————————————————————————————

TLS Working Group Session #1 - Tuesday, April 5, 2016 10:00-12:30 (Argentina)

a. Agenda Bashing
Slides updated with bashing done before the meeting.

b. Status Report

- Need to deal with the falsestart -

EKR (Eric Rescorla) - Draft has information about what algorithms are.  Problem
is that security guarantees are not the same. Client needs to enforce that
client gets back an acceptable list - as this is not protected SF( Stephen
Farrell) - Lets take this off line

- IANA Registry Rule Changes
Dan Harkins (DH) - what are the rules for this (PWD) draft
SPT (Sean Turner) - Need to determine process for the PWD draft, but nationals
can do this easy. Some will need to go to ISE to have a review. Still hard to
get a publicly available spec published, should the pwd draft go through the WG
or be kicked out? EKR - There was substantial objections from members of the
working group, probably won't get consensus DH - give me a code point and I'll
go away. EKR - verify that 16-bit space above will have this policy. Be sane
about allocation - don't do things that have huge allocations DKG (Daniel Kahn
Gillmor) - Values may change over time - how do we move things from Y to N SPT
- Need to have some type of consensus from the IETF to do the change SF - Does
the TLS working group want to be the gate way for a Y to be allocated? SPT -
Yes SF - will need to have a charter update to do this

- EC Cipher suites for TLS 1.2 - Yoav Nir (YN)
EKR - did you adopt David Benjamin's changes - no need to have a code point
assignement. Going forward from 1.3 - no signature group different from the
signature algorithm. Should move this back into this document. Don't name the
group separately SPT - once the alignment for EC done - go to WGLC

c. TLS 1.3 discussions - EKR

- Have assigned some code points for the PSK for testing.
- Not ready for doing early code point, but we probably need to do some reserve
on this so they don't get used someplace else. - New end-of-early-data marker
for dealing with dead lock situation found during testing
                
- Note that w/ the revised signature algorithm Negotiation -
                 there are things which mean one thing in TLS 1.2 and will mean
                 something somewhat different in TLS 1.3 as the curve is now
                 going to be fixed. Specifically something like SHA-512, ECDSA
                 no implies a curve but did not before.
DKG: not sure that this is not going to be a bigger mess w/ interop with
current systems EKR: probably not well done today MT (Martin Thomson): NSS
looks at the cipher suite selected and do the curve fixed on the certificate. 
Hash is input - and finds one that we like - so will do the David Benjamin
(DB): Could allocate new points so that there are no collisions EKR: Don't
think we need to deal with this except for the non-sensical cases. MT: Burning
the existing code points for compatibility with crazies is needed.  Don't want
to send larger handshakes because of this. YN: Need named curves for the
interop w/ 1.2 EKR: Assign new code point for 1.2 which is the same as here.
for 1.2 - don't change the curves selection, just use the new signature points
DKG: What is the size of the existing cross product - the craze on EKR: in the
neighborhood of - don't know about 10-20 that you can't use any more ??:
Problem comes with a TLS 1.3 client downgrading to 1.2 server. Client might
become confused DKG:  4 entries for signature and 7 for hashes - some are
reasonable and some are not 28 points being blocked out - should not be a
problem in a 64K registry EKR:  Request for DB to do the pull request for DB to
do the pull request for the 1.2 draft

- Anti-downgrade attack
Does not protect w/ weak static RSA
The extended master secret will not solve the downgrade on its own
Possible problem w/ this document forcing behavior on 1.2 implementations
MT: When 1.2 shipped 1.1 was obsoleted, can obsolete and update at the same time
EKR: If 1.2 did this today, then defense against downgrade to 1.1 w/ client
updates. No existing defense deal with the reset problem Client needs to check
against original version negotited not current one in the event of new request
after a reset. DKG: in 1.2 there is time in the start of random. EKR: values
chosen to be in the past DKG: Could resurrect the kill unix time draft and put
this into that draft as well.

- 0-RTT Client Authentication
(remove client authentication from 0-RTT)
EKR: If people object please speak
MT: Can always add back in later
Hannes (HT): Been trying use in IoT - 1.3 has better performance
                Reasons to switch from 1.2 to 1.3 become less apparent
                People who object to TLS become justified
                Understand in web community where client auth is done at the
                app layer not important IoT wants mutual auth.
SPT: May need to have you write something to say how to do this securely.
                Please help find some people to supply this type of text.
Kyle Nekritz (KN):  Can carry over client authenticatiob 0-RTT resumption
Christian: Very hard to do both 0-RTT auth and keep anonymity.  Need to show
how this is done SPT:  Sense of the room is strongly to remove this at this
time. Possibly do something later HUMM:
    Who is in favor of removing: Large noise
    Object to remove: crickets

- ECDHE-based 0-RTT

People really want PSK for resumption
Ian Swett(IS): Slight slight wrong - google only looked at the desktop and not
mobile. May be slightly different answer there EKR: Ticket lifetimes need to be
in the multiple hours to week time frame. Christan (CX): PSK identifier is
clear text so lose some privacy.
                Mitigation - each time get a new ticket
EKR: Current says that tickets supersede.
                Would be useful to get a handful of tickets as well
DKG: two types of tracking -
                server can re-identify the client - no mitigation for this
                external can re-identify the client - need to prevent this.
                Will commit to write the privacy/security text for this.
                <ACTION>
HT: Wondering of mobile uses more trusted secure
Ian Swett (IS): yes there are better trusted storage opportunities.

Server Proof of Private key:
DKG: Why not require 1-RTT if you care about this
EKR: Can change the crypto to provide this for low cost.
                Details to follow later -
CX:  Cases where client decide not to do 0-RTT -
                Since 1-RTT requires support - if this matters to the client
                they can do 1-RTT instead.
MT: I think this is simple - but other things are more important right now.

HUMMM:
    In favor of removal of 0-RTT DHE modes: Large Noise
    Object to removal: crickets

- NewSessionTicket Format
MT: Think this is overly complicated. Hardwire everything possible just with or
without ecdhe fallback is from resumption to no resumption EKR: Issue if the
server couples 0-rtt and resumption MT: Presence or absence of algorithm used
by NSS to make the decision (only one supported cipher suite to do this) EKR:
Client has more problems predicting behavior. Simplify to DHE, no DHE or both
rather than cipher suite list CX:  Does the decision on 0-RTT change this? EKR:
I don't think so EKR: MT please create a PR for that change <ACTION> MT:  will
try this EKR: What type of early data is accepted DKG: if one server and all
state is written and a reliable replay cache - or no side effects. Then can
allow all early data. IS: Need to deal with that all GETs are not side effect
free think its ok, but need to think about it. DKG: Think that the client
should not rely on the server to deal with this JS (Joe Salowey): How tied is
this to the application - what about non HTTP MT: Suggest that it should be
binary and stop there KE: Perhaps this should be ok - some clients are doing
this. EKR: Plan to make this a flags word rather than as two fields <ACTION>

- 0-RTT PSK Extensions (Encrypted Extensions)
The encrypted extensions is not part of the handshake digest
MT: Issue where get an upgrade from HTTP 1.x to 2.0 will have issues in trying
to get things done right Andrey Popov (AP): some of these should be part of the
remembered context such as ALPN. KE: Probably want to kill when changing the
ALPN Tight situation where can trickle data in on the time check from the 0-RTT
data Could move to the end of the 0-RTT EKR: Suggest dealing with that offline.
JS: With change of ALPN - avoid problem with cross protocol attacks. EKR: Talk
to the semantics slide DKG: Client should keep its configuration the same -
store the list of parameters with the cache? EKR: Difference between having the
0-RTT being off and resumption being off. In one case the ALPN change would be
allowed but not in the other case. MT: Really need to keep the ALPN tied in
context

- Find the next handshake block
Discussion of the end-of-early-data-alert and security properties.
CX: When does this happen that cannot deal with bit on server. This is an error
case EKR: I think it will be fairly common to occur MT: Do people have any
stats. IS: about 75% of time successfully complete EKR: Question on how often a
client asks and the server says no IS: About 5-10% ballpark DKG: Why solve this
is a privacy problem if other solutions are safer and just force the TLS
handshake termination EKR: Consensus seems to be to stick with the existing
text.

- Exporter for 0-RTT
Discussion on if it is needed.  MT says that it is not needed.
DKG: Starting to smell a lot like the client auth discussions

—————————————————————————————
TLS Working Group Session #2 - Thursday, April 7, 2016 10:00-12:30 (Argentina)

- Key Separation: A Layman's view
Eric Nygren (EN): would option #2 use a separate api as some data ok even in
client auth case EKR: Still no way for the client to know what the difference
is on the data If resumption is carrying over client auth, this is not an
issue. DKG: Looking for justification of no API EKR: Could concede the point
Russ Housley (RH): Where do you see the failure if the MUST is violated EKR: No
change - server logic should prevent it from happening Nick Sullivan: Does this
include PSK implicit client auth EKR: No HT: How frequently does 0.5 RTT data
occur EKR: HTTP 2.0 lots of items Jim Schaad: describe replay EKR: Will take
action to make sure 0.5 RTT security considerations for PSK resumption w/
client auth is done ACTION: Room consensus is that we should use option #2

- EKR: Demuxing Options
MT: Side channel created for trial decryption
EKR: In TLS you get one byte at the apple and then get alert on encryption
fail. With the two keys you either get an immediate or slightly slower failure
DKG: Please use two keys - active interest from the crypto community KE:
Require 3 trials when switching from 0-RTT to application data on the server?
EKR: hmmmm.. No for unsuccessful 0-RTT either a success decryption and then end
- so just 2 trials AP: Support 2 keys DB: Trial decryption does make doing
decryption in place slightly harder. If mac check fails then have mucked in
place buffers already DKG: recognize problem, but still would like to fix IS:
Only do trial decryption looking for edge but not every packet BK (Ben Kaduk):
Wrapping would not have this problem EKR: Mingling keys that way would be messy
from analysis need to get input from the crypto community KE: Should do an
analysis on doing the reversal encryption to get better data MT: Preference
would be nested and then reverse MT: Would be a problem w/ PKCS#11 HUMM:
Validate w/crypto if wrapping solves the key separation issue and if yes then
continue w/ that
                Pro: Lots
                Con: a couple of people

What key to use for handshake encipher
Suggest that KeyUpdate should be use
<No objections from room>

- Which Key?
MT: suggesting the use of the entire transcript including client second flight?
EKR: Just crank the KDF one more time to get the new key
DKG: Prefer to have cleaner key for PFS type thinks
No objections the room to using new handshake key.
                
- Key Context:
MT: Like the implicit binding
EKR:  will take this as no objections and make a PR and get review

- Simplified Key Schedule:
This should be fine for dealing with the triple wrapping as long as the RMS for
the entire transcript MT: What is ES EKR: Should adopt policy that either
non-existing keys are 0 or that they duplicate the other key (what we do
today). I think duplication is simpler (probably) JS: Will it be impossible to
the the fancy mode of long term if this is done EKR:  No it should be possible
- and gives explanation of how Sense of the room is that this seems correct
SPT: This was presented at TRON and they seemed ok with this

- Issue #215: (let servers send known groups)
No objections in the room for this

- Issue #426
These are people trying to get rid of middle boxes by using a cabinet version
DKG: Be clear about the semantics. This is to say that I reuse to use the last
set of keys Issue of DTLS where there is a delay on this as old keys may still
be used. Want to know what keys (plural) are you willing to accept for DTLS
Need to deal with that issue in the proposal BK: Making a case about forward
secrecy. You need to make sure that both parties have destroyed the key. Makes
it easier to know that the peer has destroyed the key EKR: Make no assurances
about having keys destroyed. MT: Handshake traffic key - do we throw that away
here as well EKR: Since it is not updated, don't bother that BK: Claim that an
attack exists where all update key messages are suppressed SPT: Don't feel it
is baked enoughShould not merge PR.

Chairs will notify the requesters <ACTION>

- RSAPSS
EKR: Document currently says don't use 1.5 for cert verify but can use for
certificates Two code points, one for PSS and one for 1.5, but the semantics of
them don't match Requirement is to in the future say don't send 1.5
certificates DKG: conflated semantics in the signature algorithm field. EKR:
Unfortunate temporary state. DKG: Will continue to have this problem in the
future for a new broken signature algorithm.  Need to accept certificates for a
while even if TLS is updated EKR: Policy question of 1.5 for certificate verify
is the real problem. Want to solve that question before the encoding question
JS: Anyone in the room object to not allowing 1.5 for certificate verify
Crickets in the room

- EKR: Now willing to talk about the encoding question
DKG: Will have this problem again in the future should encode to solve
EKR: Posit new encoding exists
Is this advisory for certificates or mandatory
Less excited if not mandatory
DKG: Can demand that cert verify comes in flavors but might accept. Expect that
servers are going to have multiple chains in the future Server guesses w/o a
signal EKR/DKG: Argue about not having any preference and thus the client has
not control AP: Prefer to make it mandatory and have the client fails if wrong
things returned RS (Rich Salz): Having to guess the optimal cert types based on
heuristics bad.  Prefer to get strong signal from client Both from the OpenSSL
and the Akamai point of views EKR: New extension w/ advisory semantics on the
certificates would be the proposal BK: If the server has to guess, why would it
change what it does today? BK: If the server always pick the stronger one and
the client can reject then would seem ok. Some don't do this correctly today
EKR: Not all servers guarantee conformance w/ client request Distinction is
between certificate verify and everything else RS: Needs this to be a reject on
the client side not the server side. AP: If server does not need to object the
extension, why would it even look at it. MT: Can we do this later? EKR: Yes MT:
What if this was specified if the client says I cannot do PSS YN: Need to be
clearer about what the current extension says in any event.
                Opposed to new extension since this is only an RSA problem.
                Usage is going down for RSA so may not be long problem.
JS: Why do you think this is not going to be a problem w/ new EC algorithms in
the future YN: Has not come up yet JS: Only an issue because of deprecation of
algorithm, but agrees with DKG that this will come up lgain

HUMMMM:
    Change the spec now - some nose
    Leave alone - slightly greater

- OCSP stapling
MT:  Want to move pinning to the top level and don't make it an extension any
more JS: Just EE cert? EKR: Do clients which ignore OCSP need to have the data
dumped as well? MT: Sure EKR: Should it be asked for or always sent? MT:
Inclined to second KE: If the data has not changed then it seems to be alot of
extra data MT: Make cached info better as it has a hash of the cert message
DKG: Will this be true if OCSP message changes over time?

- Questions on timeline
EKR: Should produce two draft by this time in may
Get the technical issues in the next 2-3 weeks
Hopefully last call around end of may
MT: we now have a dependency on draft-matson -
Can we remove citation on this
HT: Have an interop event as well?
EKR: Good idea to think about
SF: think about a TRON + interop event together

- Interop questions:
SPT: When should other implementations be done
RS: OpenSSL - may release is currently all things
Next focus will be 1.3
Hard for non-dev team people to help given the invasive
Proabably not before year end
DB: Start working in Boring SSL soon Duration unknown
AP: Will support at some point in the future Implementing is not the same as
making it the default Kyle ?: Apple will implement but no schedule RS: OpenSSL
probably be by default - but 0-RTT - who knows Richard Barnes: Should be in the
NSS tree soon and start to get some measurements of seeing a new version number
MT: Hope to get some states on reduction of record overhead HT: Playing around
in embedded version - probably better to re-write than to adapt. MT: Don't
change the 1.2 code, write a 1.3 stack and steal code is much better option.

- DNSSEC Chain Extension
Request for adoption
SPT: Had deferred this to deal with 1.3
Would like to get a sense of the room
Nobody really read latest draft based on poll
Is this applicable to both 1.2 and 1.3?  Nods from the room
HUMM:
    Would like to adopt the draft: Lots of nose
    Against: Crickets
DKG:  Would be useful to get an early code point assignment
SPT: Doable after adoption and review

And the meeting closes