--------------------------------------------------------------
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)
|