2.7.17 Transport Layer Security (tls)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-17

Chair(s):

Eric Rescorla <ekr@networkresonance.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Technical Advisor(s):

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: tls@lists.ietf.org
To Subscribe: ietf-tls-request@lists.ietf.org
Archive: http://www.imc.org/ietf-tls/mail-archive

Description of Working Group:

The TLS Working Group was established in 1996 to standardize a
'transport layer' security protocol. The working group began with SSL
version 3.0, and in 1999, RFC 2246, TLS Protocol Version 1.0 was
published as a Proposed Standard. The working group has also published
RFC 2712, Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS) as a Proposed Standard, and two RFCs on the use of TLS
with HTTP.

The primary purpose of the working group is to advance the TLS
Protocol to Internet Standard. In addition, the working group will
publish documents defining new ciphersuites for use with TLS as
needed.

Goals and Milestones:

Done  Agreement on charter and issues in current draft.
Done  Final draft for Secure Transport Layer Protocol ('STLP')
Done  Working group 'Last Call'
Done  Submit to IESG for consideration as a Proposed Standard.
Feb 2001  First revised draft of TLS specification
Jun 2001  Submit specification to IESG for consideration as Draft Standard

Internet-Drafts:

  • draft-ietf-tls-ecc-12.txt
  • draft-ietf-tls-srp-10.txt
  • draft-ietf-tls-rfc2246-bis-13.txt
  • draft-ietf-tls-psk-09.txt
  • draft-ietf-tls-rfc3546bis-02.txt

    Request For Comments:

    RFCStatusTitle
    RFC2246 PS The TLS Protocol Version 1.0
    RFC2712 PS Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
    RFC2817 PS Upgrading to TLS Within HTTP/1.1
    RFC2818 I HTTP Over TLS
    RFC3268 PS AES Ciphersuites for TLS
    RFC3546 PS Transport Layer Security (TLS) Extensions
    RFC3749 Standard Transport Layer Security Protocol Compression Methods
    RFC4132 Standard Addition of Camellia Cipher Suites to Transport Layer Security (TLS)

    Current Meeting Report

    --------------------------------------------------------------
    
    
    IETF64 Transport Layer Security (TLS) Working Group
    Tuesday 2005-11-08, 15:10-
    
    Chair: Eric Rescorla
    Scribe: Pasi Eronen
    
    Eric Rescorla: Introduction
    ---------------------------
    
    Eric bashed the agenda and described current document status.
    
    Trevor Perrin: draft-ietf-tls-srp-10
    ------------------------------------
    
    Trevor: The draft has been around for quite a while. The authors think
    it's in a pretty good shape, so we should decide how to go forward
    with it.
    
    Russ Housley: As the current AD, I think we have much more clarity
    about the IPR situation. So the WG has to decide whether to take this
    as informational or standars track.
    
    Eric: I will call for opinions on the mailing list.
    
    Nagendra Modadugu: draft-modadugu-tls-ctr-00
    --------------------------------------------
    
    Russ: Has the WG accepted this document as WG item?
    
    Eric: No, this is something we have to decide. Who supports this?
    (maybe half a dozen people) Anyone against? (nobody)
    
    David McGrew: I provided some comments by email already. But it seems that it's
    even more important than currently that the sequence number never
    repeats. Have you thought about this?
    
    Nagendra: The draft mentions that the sequence number must not wrap,
    but it's 64 bits. So probably not a concern.
    
    McGrew: Another question, have you thought about doing a combined mode 
    like CCM?
    
    Russ: That topic will come up later.
    
    Mohamad Badra: draft-badra-hajjeh-mtls
    ---------------------------------------
    
    How many people have read this? (maybe four or five)
    
    Tero Kivinen: I haven't read this, but how is this different from the
    secure shell channel layer? There are lot of details you have to get
    right, like handling blocking of one stream. Have you considred this
    in the draft?
    
    Mohamad: (...)
    
    Tero: I probably have to read draft.
    
    Stefan Santesson: I'm worried we're introducing a whole new way of 
    seeing the security context of a session. I haven't read the draft,
    but I'd like to review this before deciding how to continue.
    
    Eric: It's not clear to what degree we should specify VPN-type 
    applications in TLS.
    
    Mohamad Badra: draft-hajjeh-tls-sign
    ------------------------------------
    
    Stephen Kent: A couple of things I find puzzling about this.  Signing
    things for non-repudition is usually an application-layer issue, while
    TLS is below the application.  When doing non-repuditiation, the
    recipient has to hold on to those bits so they can be showed to
    someone later. But in TLS we usually pass the plaintext to the
    application and throw away the rest after integrity verification and
    decryption. Also, there has to be expression of intent when signing,
    so you usually integrate it to application and there's a button to
    press.  But TLS is usually placed below the application transparently.
    So there are big problems in doing non-repudiation in this layer.
    
    Eric: Anyone read this document and wants to say something more?
    
    Stefan: Agrees with Stephen.
    
    Pasi: I also agree with Stephen, for several reasons doing 
    non-repudiation at this layer might not very useful.
    
    Stefan Santesson: User mapping
    ------------------------------
    
    Eric: TLS extension requires IETF consensus, new handshake message
    require standards action. Why not put the data in the extension?
    
    ?: I don't recall all the reasons why we did it this way, but one
    reason was to allow future extensibility.
    
    Eric: Handshake messages have only 255 codepoints, extensions
    have more.
    
    Eric: You should submit the internet-draft so people can read
    it and form an opinion.
    
    Stefan: One reason to use a handshake message is that we've
    already implemented this.
    
    Eric: Getting standard track is up to IESG, not the WG. Russ, 
    do you want to say something?
    
    Russ: (...)
    
    Eric: This should be an individual draft first, then we can
    decide whether to adopt it as WG item.
    
    Hao Zhou: draft-salowey-tls-ticket
    ----------------------------------
    
    Eric: As a background, the authors want to submit this as individual
    standards track, but I have asked the WG to review it.
    
    Russ: When?
    
    Hao: I think version -05 handles all the comments received, so soon.
    
    Eric: Everyone who commented should check that the comments
    have been taken into account, we should allow some time for this.
    
    Russ: There will be still AD review, IETF last call and IESG
    evaluation.
    
    Eric Rescorla: Hash functions, MACs, and PRFs, oh my!
    -----------------------------------------------------
    
    Pasi: I think we could do about 75% percent of this with TLS 1.1, by
    definining new ciphersuites, using extensions, etc. But to fix the
    Finished message problem, we do need 1.2.
    
    Grigory Chudov: When we created the GOST ciphersuites, we had some problems,
    had to get rid of all instances of SHA-1.
    
    Russ: We have to do something about the Finished message. Doesn't have
    to be done this week, this year, or next year, but probably has to be
    done within next two or three years. I think we should get started so
    we have time for transition.  We should probably keep changes to
    minimum, but authenticated encryption modes is something we might want
    to add.
    
    Joshua Ball: I support this, combinatorial explosion of ciphersuites
    is going to get out of hand if we introduce new algorithms. We might
    want to reconsider how we handle ciphersuites.
    
    Eric: How many people think TLS WG should work on this? (maybe 10-20)
    Anyone against? (nobody) How many actually willing to read the whole
    document and comment it? (maybe 5)
    
    Russ: If Eric is going to be the editor of this specification, we
    should have another WG chair to declare consensus. Or we need someone
    else as the editor.
    
    Pasi: We should stick to changes that absolutely need to be done; if
    we change all the details that might look nicer some other way, this
    will take forever.
    
    (end)
    

    Slides

    Eric Rescorla's presentations
    Nagendra Modadugu -- TLS CTR
    Mohamed Badra -- MTLS and TLS Sign
    Stefan Santesson -- User Hints
    Hao Zhou -- TLS Tickets