* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tls Status Pages

Transport Layer Security (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 1996-May-24 —  
Chairs
 
 
 


IETF-105 tls minutes

Session 2019-07-23 1710-1810: Place du Canada - tls chatroom
Session 2019-07-25 1000-1200: Place du Canada - tls chatroom

Minutes

minutes-105-tls-00 minutes



          # TLS at IETF 105, Tuesday
          
          # Status update (drafts, code points, etc) -- see the slides
          
          CFRG working on PAKE selection;  integration with TLS is obviously
          important, come to CFRG meeting.
          
          ## Delegated credentials
          
          Server side patch in BoringSSL; NSS client side soon to be in FF nightly;
          FB work in progress.
          
          Plan to drop LURK mention, remove PKCS#1 v1.5 (RSA PSS only).
          
          Martin Thomson: this needs more text for clarity.
          
          Plan was to not go forward without proof that this doesn't weaken PKI
          security; a by-hand one is in progress
          
          Refine "Delegated credentials" term to "Delegated authentication keys"
          
          Plan is to start WGLC, but make sure it isn't finished until the analysis
          is done and reviewed by the WG
          
          ## Deprecate MD5 and SHA1 in TLS 1.2
          
          Make signature_algorithms mandatory in handshake; forbig MD5 and SHA1
          algs in that extension
          
          Andrei says Microsoft can't enforce now but willing to do so in the future
          
          Consensus in room is to adopt as a WG item; to be confirmed on the list
          
          ## TLS Flags Extension
          
          TLS 1.2 has 46 extensions; TLS 1.3 has 28; more coming
          
          Many extensions have no data, just 1 bit of data (their presence) --
          call them "flag extensions"
          
          Various methods (fixed-size bitmask, varying-size bitmask, array of
          bytes, etc)
          
          Can't re-do existing extensions (at least in clientHello), but server
          response and other messages could do so
          
          Consensus in room is to adopt as a WG item; to be confirmed on the list
          
          ## Suppress Intermediates
          
          A new flag in clientHello says "don't send intermediates"
          
          Not clear what to do if intermediate ends up not being available;
          options are then ugly
          
          Server would ignore extension if it "knows" its chain is "unusual"
          ("weird" etc)
          
          There is interest, but not ready to ask for adoption yet
          
          ## TLS 1.3 Impact on Network Based Security Solutions
          
          Network solutions sometimes insert a middlebox proxy between the
          client and the server, observers TLS metadata to do policy and access
          control. TLS 1.3 handshake changes affect these solutions.
          
          Incorporated feedback, has been stable since IETF 104. New commentary
          started today.
          
          Original plan was to ask for publication as informational even though
          it's not in charter.
          
          More people read this draft than any other draft; interesting and
          surprising factoid.
          
          Adjourn without action.
          
          # TLS at IETF 105, Thursday
          
          ## DTLS 1.3
          
          Should there be key separation between TLS 1.3 and DTLS 1.3?
          
          Conservative thing is to check for space and make change to do separation
          if room - plan of record.
          
          ## ESNI
          
          Summary of changes since last version and open issues (see materials)
          
          (Discussion of probing of distinct servers.. suggestion is to make all
          servers in same anonymity set respond same way to hello)
          
          Ekr - why is 'wrong one' is responding at all?
          
          Martin Thomson - might be a fallback.
          
          Martin Thomson - says right forumulation is that SH must be similar not
          identical, especially after crypto is configured or installed.
          
          Rich Salz - Martin is right and we need to document that.
          
          Martin Thomson - Will open issue and text
          
          (Discussion of on path hrr attack (See Materials))
          
          Martin Thomson - proposal with key schedule makes it impossible to do
          the wrong thing. As opposed to relying on quality of implementation
          
          Ekr - may want to consider a more general way to annotate key schedule
          as a strategy.
          
          Ekr - is a binding across the CH also necessary? Formal Analysis time.
          
          Jonathan Hoyland is working on a draft on how to inject into key schedule.
          
          Christian Huitema - if all CH extensions bound in the ESNI and sorting
          who is on top.. process not healthy. suggest a single secret for a binding
          
          Chris Wood - concerned that keyshare and cipher suites are not enough.
          
          (Question 1 from slides probably yes (according to author))
          
          (Question 2 and 3 smaller team needed (according to author))
          
          Nick Sullivan - not in favor of requirement because different domains
          will have different suites and forcing them to normalize will hurt size
          of anonymity set
          
          Chris Woo this is mostly a text issue
          
          Subodh Iyengar - hrr generator should not be able to be different than
          entity that creates server hello. We should fix this more generally
          
          Ekr - possible to not require, but it definitely leaks information
          
          Ben Kaduk - HR vs SH generation was a design decision. ESNI may constrain
          you.
          
          Erik Nygren - more documentation, less enforcement on q1
          
          Kyle Nekritz - possibility to use a fate sharing secret with client.
          
          (HPKE vs ESNI Encryption (See Materials))
          
          MT - size of packet is already starting to get pretty big
          
          Chris Wood - esni keyshare is already separate from ch keyshare
          
          David Benjamin - lets revisit after sorting the binding
          questions. e.g. does HPKE allow same additions to Key Schedule
          
          Ekr - lets sort out what we need and talk with CFRG if HPKE is close
          but not quite right
          
          (Split mode - continue to include? (See Materials))
          
          Ekr - documents take a soft shoe approach to this by describing it rather
          than adding mechanism.
          
          Chris Wood - would you be OK with referencing Ben's draft
          
          Ekr - with respect to ridiculous stuff at bottom, yes
          
          Daniel Kahn Gillmor - This is an important use case. Please keep it.
          
          Stephen Farrell - Might be more than 1 way to do backend. Keep requirement
          but maybe not mechanism as only mechanism.
          
          ## Connection ID
          
          MT - beyond presentation the other thing to consider..
          
          MT - the quic work has looked at this. the return check does not cover
          all these cases adequately (see eric kinnear's quic work)
          
          Hannes - that's part of the work we have a seaprate doc for return
          routability check so they can proceed independently
          
          Ekr - propose we say in CID drafts what the machinery is and DTLS should
          not automatically respond to this. It is the responsibility of a future
          specification to tell you how to deal with it.
          
          Sean - does that mean pr 70 goes away
          
          Ekr - no, needs some refinement. take the 1.3 text and harmonize the pr
          70 text. need discussion about general conditions where it would be safe,
          and a prohibition on the DTLS stack itself taking action.
          
          Sean - hannes and ekr need to talk it out
          
          Eric Kinnear - duplicate packets is an important vector
          
          MT - move all migration pieces into other draft
          
          Sean - we have our marching orders
          
          ## cTLS (See meeting materials)
          
          Christian Huitema - removing legacy session ID affects the transcript.
          
          Ekr - yes, this does not for legacy mode.
          
          Scott Fluhrer - recreating 1.3 keeps proofs in place
          
          Adam Langley - could we both transcript and compress? (yes). The benefits
          seem underwhelming.
          
          Ekr - primarily IOT use cases. More like 150 -> ~55, not a 10 byte saving.
          
          Ben Schwartz - benchmark against plain compression, possibly with a
          tuned dictionary.
          
          Subodh - Does compression apply to messages beyond ClientHello? (yes)
          
          Roberto Peon - Is the intention to show isomorphism? (yes)
          
          Ben Kaduk - Assumes in order reliable transport?
          
          Ekr - Yes, though compact DTLS is possible too.
          
          Ben Kaduk - If this is TLS 1.4 takes advantage of non backwards
          compatibility.
          
          (Unknown) - Is this completely new or can it be done compatibly? there
          are some angles (unexplored) to work it into existing frameworks.
          
          Adam Langley - Implementing this as untrusted shims helps convince you
          this is transport irrelevant and does not affect security.
          
          Richard Barnes - that's how it was implemented in mint.
          
          Gary (Qualcomm) - what is a server expected to do if a client presents
          a ciphersuite it has never heard of it would fail.
          
          Richard Barnes - this experiment used as much compression as possible,
          though less (negotiable) options are possible.
          
          ## Hybrid Key Exchange in TLS 1.3
          
          Jonathan Hoyland - Opposed to key schedule changes. Adhoc changes to
          key schedule harm formal analysis. Let's standarize how to do that first.
          
          Adam Langley - Perfers option 2 from next steps slide.
          
          Ben Kaduk - In terms of trade off if you think everyone is doing similar
          combinations its different than a lot of variety.
          
          Watson Ladd - We aren't going to have a large number of algorithms that
          are going to be combined. Generally 2.
          
          Martin Thomson - Candidate 2 and option 2 please. Also concatenation is
          not quite the right term.
          
          Mark Owen - Option 1 is useful. Also keep designs as general as possible
          including more than 2 algorithms and classical ones too.
          
          Scott Fluhrer - Each algorithm has a parameter set which will increase
          the combinations.
          
          Adam Langley - +1 to Watson.
          
          Martin Thomson - CFRG should look into reducing parameter set issues as
          per use cases.
          
          ## TLS MetaData for Load Balancers (see meeting materials)
          
          Stephen Farrell - is full split mode something new. never considered
          partial split mode an esni use case
          
          Ekr - also thinks esni deals with full split mode as ben describes it
          
          Ben Baduk - it sounds like everyone wants full mode - so lets move on
          
          Jonathan Hoyland - Wrapping TLS does not give clear cryptograrphic
          properties. Need to bind them, possibly with exporter keys, to get
          desired properties.
          
          Christian Huitema - What about the QUIC LB work?
          
          Ben Schwartz - Largely they are different issues.
          
          Roberto Peon - Look at intermediary assisted packet loss.
          
          Ben Schwartz - We can do better than proxy protocol so this work should
          be done in IETF.
          
          Martin Thomson - Where does work like this happen? QUIC WG straddles
          the question. SecDispatch or Dispatch perhaps.
          
          Ekr - Generally enthusiastic about this. How much of this is a security
          protocol? May be a security protocol based on Jonathan's comments,
          or perhaps those questions are isolated.
          
          Ben Kaduk - IAB and IESG should determine where this work should happen.
          
          Jonathan Hoyland - There are several adopted drafts that bind stuff into
          TLS. As a WG we should look at importer uses not just exporter.
          
          Stephen Farrell - Yes, should standardize.
          
          Erik Nygren - This was a past HTTP workshop topic too. Lack of
          standards around proxy protocol but the lack of security makes it
          inappropriate. Efficiency matters.
          
          Chairs - We will talk to ADs to determine next steps.
          
          ## HTTPSSVC DNS RR (See Meeting Materials)
          
          Allesandro Ghedini - Does this require 2 serial resolutions?
          
          Erik Nygren - If things go right that's not true. open question does it
          make sense to inline a/aaaa as esni is doing? performance and complexity
          are tradeoffs.
          
          Allesandro Ghedini - The double resoultion thing is serious
          
          Erik Nygren - Much of this can be done in parallel
          
          Ekr - More than happy to have DNS work done in DNS groups if it meets
          requirements
          
          Nick Sullivan - What is specific to https here?
          
          Erik Nygren - Makes sense to generalize this.. specifics are alt-svc
          formatting and underscore handling for wildcard cases.. and hsts style
          handling
          
          Adam Langley - Why is the redirect name mandatory
          
          Erik Nygren - Need to get addresses to bind the esnikeys (or names)
          
          Adam Langley - May not apply to me without multi cdn,
          
          Erik Nygren - It's already optional via a .
          
          Tommy Pauly - This should be generic. really consider what needs to be
          included by ref vs what needs to be inlined
          
          Lorenzo Colitti - More generic means not httpbis. +1 to addresses being ok
          
          Mike Bishop - Outgrowth of altsvc dns rr proposal. altsvc could be
          applicable to more than https
          
          Dan York - CNAME at apex is important. are you talking with clients
          
          Erik Nygren - More browsers than generic clients, but yes.
          
          Dan York - Beware of scope creep.
          
          



Generated from PyHt script /wg/tls/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -