Skip to main content

Minutes for TLS at IETF-93
minutes-93-tls-1

Meeting Minutes Transport Layer Security (tls) WG
Date and time 2015-07-22 07:00
Title Minutes for TLS at IETF-93
State Active
Other versions plain text
Last updated 2015-08-10

minutes-93-tls-1
IETF 93 - TLS working Gorup Minutes
Dates - Tuesday, July 21, 2015 and Wednesday, July 22, 2015
Place - Prague, Czech Republic
Chairs - Joe Salowey, Sean Turner
Minutes - Jim Schaad
Revision - 0.1
=============================================================

TLS Meeting Session #1

Chairs: SPT & Joe Salowey

** Agenda Bashing

** WG Status

** TLS 1.3 Status - EKR (Eric Rescorla)
    PRESENTATION

Question on why Finished Secret only depends on xSS
   Reason is based on doing security analysis as it removes some circular logic.

Question when ServerConfiguaration is sent (SPT - Sean Turner) - It is optional
and fails goal of making entire sequence of items known based on server &
client hello.

Question on absolute time vs relative time:  (Ian@google) Could a configuration
be delivered because local clock is skewed?
        EKR - problem with relative time is that need to adjust at all times,
        absolute time will have a fixed stop point. Like in Quic there is a
        clean fallback if the configuration is rejected.

Question on what early data w/o early handshake (DKG - Daniel Kahn-Gilmor) -
        No client auth
        Should rename things

DKG - Sugest that skipping over items (ceritifcate, verifi, app data) could be
in a single message and skip forward.  This deals with case of server cannot
make the pre-existing shared key on a 0-RTT handshake

MT (Martin Thomson) - Thought this was how things were going to be - Can put
multiple messages in a single handshake record. EKR- Cannot see into the
handshake message - so does not work - can be other things.
        Question if the size or temperal sequence are issues in creating the
        first ClientHello message.
DKG -Doing the API is a problem if you do not make the 0-RTT appliation data as
part of the first function call.  This implies that you know the initial data
size.  Problem is that forward security properties in the middle of the stream
w/o the user knowing when it happens. MT - Perhaps should just not do encrypted
content type - only protects the transistion from non-PFS to PFS.  If that is
the issue - then sending app data may not be a good idea anyway.

MT - Number of things in the handshake which are optional - can we reudce the
number of options.  Expect that we are optimizing for a case which is going
away.  Move from RSA to ECDSA cheapings the cost of signing. DKG - Suggesting
removeal of * on the Cert and Cert Verify server side messages.

SF (Stephen Farrell) - Question on checking about IoT world - does this affect
them much? MT - Mostly using PSK modes so less affecting of them. EriK Nygren -
Worry about the computational cost for mobile devices - this change would
affect them.

DKG & EKR- looking at strawman for
        Extensions are the server offered rather than client suggested.
        Group of configuration data is going to provide some crypto
        configuration. Question on clear text vs encrypted content of
        extensions - EKR thinks it should only be clear.
MT - Sould not need to have the signature - as it is going to be in client
hello anyway? EKR - will flesh this out

MT - Looking for positive statement of rejection of 0-RTT data.
EKR - response - why would a client offer identity on the resume if not on the
first session? DKG - what about a resume due to ask for identity info from the
server to client. EKR - need to have the server be able to say that it is
expected in the configuration data. AP (Andrei Popov) - May need different
credentials depending on where one goes from a landing page - need to do this
for either add identity to current connection or push to a new connection - and
needs to have the client push identification data correctly.

MT - If you allow for PSK + certificate authentication for the client - you
also need to allow it for the server and that becomes hairy very fast.

MT - Ignored problem earlier - inheritly bind cipher suite to the PSK.
EKR - Problem with ugrading cipher suites in the field w/o upgrading keys.
Only an issue with the KDF not with the symmetric key.

*** Andrei - TLS 1.3 CLient Auth

YN (Yoav Nir): HTTPS 2 does not allow this pattern of inline either.
AP:  Some sites will stay and not upgrade
(unknown): couple of ways even in HTTP2 to get certificates - including "go
back to 1.1 to do this" Stephen Farrel - Questionss about WebDav - does it need
it? EKR - on interleaving - server must stop sending data after asking for a
cert. MT - worried that avoiding ungliness in HTTP by introducing it into TLS.
Server should not be sending resource data until authentication done.  So no
need to not interleave. DKG - If interleaved sessions - what resource is the
negotation being done for?

Session #2

**** EKR Status starting w/ AEAD IV

Traffic Key Generation question - Ask for sense of the room on doing this
MSJ (Mike St Johns) - Biggest attck is from HMAC -
EKR - Why does not key length fix that
MSJ - maybe it does - still issue of strong vs weak
EKR - Usage labels are devided in to interior and exterior keys.  Extererio
list is explicit, interior keys are the rest. * EKR Will look at the two
current proposals and go forward with this.

Signatures w/ known configuartion - question for objections
Nobody in the room stood up to object, several people said it should be done.
EKR will write it up and send to the list for other objectors.
SF - raised question on what parallel means for signature amortization
EKR - think about in parellel - write in serial
Chair Humm on the always sign issue - rough consinsus for always sign

0-RTT Failure Recovery
?? - Is there a server resource problem with the decryption time
EKR - Don't believe it is a real concern
MT -Agree w/ cost being low concern

A La Carte Cipher Suites
MT - Need to consider the anonymous modes as well - Key exchange, AEAD, hash
Joe - would prefer to see everything negotiated together.
EKR - Signature on the server side is independent - client indicates no
signature by not sending data. RS (Rich Salz) - This is bad for consumers to
try and use - current is bad enough DKG - Most people freak out on one part of
list - People say don't want to do PSK rather than just one cipher suite. YN -
confusing story of users and protocol.  These do not need to have the same
presentation EKR - summary - think people either do not want to change or make
very minimal changes DKG- do think signature should split out MT -
Authentication mode may need to be dealt with as a separate issue, needs to be
agreeed on. Presentation of things is oing to be based on what the provider
supplies.  Different vendors do differentthings Humm - should we kill off the
ala carte menu options? Split of the room on this.  So will entertain proposals.

*** TLS Traffic Padding - DKG
YS - This ability has been in IPSEC for alot of time -but has not been used much
DKG - I have a concrete case today for using this.  And it is not clear that
historically poeple have understood the problem with it. YN - Can this be used
to do zero length application data to hide user timing issues DKG - Yes it can.
DKG and EKR - Discussion of issue on where the padding occurs in handshake
messages and how the MACs are computed in terms of where things exist.  NSS
does not have problem with this as the padding is done at a very low level. MT
- Issue dealing with minimum padding issues - People have requested ability to
have down to one byte of padding.  This is not in current proposal. DKG - Seems
hard to say that if you are padding, you need some type of "minimal" padding. 
Push 127 to 256 rather than 128 seems to be ok EKR - Padding question - PR #147
- question on including things in the session hash computation Quynh Dang -
Suggest that padding be done in a new scheme - zeros followed by 1 instead of
the TLV EKR - no real problems - small problem with doing the scanning

4492bis  - no slides - YN
SPT - Ask for reviews on this draft to get it up to EC on std track
SPT Will check with the CFRG that 25519 and goldilocks are stable and go foward
EKR - What about brainpool- can these code points be put here as well.  Want
only one document to look at for code points Humm - High desire to omit
brainpool curves - small hum on no - bigger hum on yes.  Room concensus is yes.

*** dnssec-chain-extension - Richard Barnes
PHB (Phillip Hallam-Baker) - Asking if this should be experimental - don't want
to make ICANN as a trust provider who is privleged EKR -Why and extesion and
not a new certificate type? DKG - want it to be coroberative thing not an
either/or Many arguements over where and how the DNS records should be placed.
HUMM for question on adoption - more pro than con - will go to the list

*** ETSI and IEEE certificate formats
EKR - are the certifictes isomoriphic between the different formats?
Any chance the IEEE and ETSI formats are going to be merged.
Spt - there is a third one as well -
SPT - Question from plenary about butterfly algorithm
SPT - Procedural question - is this to be a working group item?
Request for feedback prior to thinking about adoption

** TLS Session Key Interface
Issues raised in the room - RSA as an oracle, What is the Edge server
authentiation method, other designs that have done this

*** ECDHE_PSK for AES-GCM and AES-CCM
EKR - Yes and 1.3 has removed all these cipher suites
Dan Harkins - should specify the hash size as well for this
        Issue on key randomness should be a security consideration
EKR - we should have question of how algorithms should be done and how
completeness for suites is going to be done.

*** Quantum safe hybrid cipher suites
MT - Why not just do a new key exchange method?
MT - Pushing in a number of key exchange methods under a single identifier is
problimatic.
        Should look to CFRG to get some review on both this and authentication
Tanya & DKG - both think the hyred is good
DKG -why not make it an extesnion to add quantim safe