Eric Rescorla & Pasi Eronen, co-chairs
ECMQV Cipher Suites for TLS
TLS-DTLS AES-CTR
Interop issues
TLS providing supplemental data to applications
Transport Layer Security Authorization Extensions
RTSP 2.0 TLS handling
TLS 1.2
Brian Minard – draft by himself & Dugal
Brian provided an overview of the draft. The approach is to use X9.63 implicit signatures; use ECC cipher suites for TLS; use an ephemeral key instead of a static key for unauthenticated clients. The changes since 00 draft include (a) an added explanation of ECMQV scheme; (b) proposed alternative wording in section 4.5.
Questions to be answered: support for DSA certificates; can this become a WG item?
Russ Housley asked what the IPR status of this is. Brian said that Certicom submitted an IPR statement in
January; it has been up on the IETF site since 2 Feb. They have offered
non-exclusive, royalty free patent license for implementers of the protocol.
This statement does not apply to CA's.
Eric asked whether the license applied if you use self-signed keys. And is it the user's responsibility to ensure that a CA has a valid license? Brian replied that if you have self-signed certs for test mode, no one cares. If you're selling those certs, it's a license violation. If you're using self-signed certs for operational TLS but not selling them, he's not sure.
Phill Hallam-Baker asserted that this license should be described as "reasonable and Non-discriminatory" vice "royalty free". Also, since there are unencumbered technologies available; wants to see a compelling use case for this particular version of EC before taking it on as a work item.
Brian stated that this would be useful for supporting Suite B. This led to a discussion of what Suite B is. David McGrew said that his understanding is that MQV is not required for Suite B compatibility. EC is, but not MQV, and therefore EC may be preferable for IPR reasons. Russ stated that he had arranged a description of NSA's EC license at a previous SAAG. That was a prelude to the Suite B announcement shortly thereafter. Suite B is NSA's preferred way of using EC; it initially was the only way of using EC. Russ pointed out MQV is incompatible with IKE; NSA said they would accept MQV and others (on a case-by-case basis) if there were compatibility issues with IKE.
Charlie Kaufman asked whether the license covers certificates that are signed with this signature algorithm, or certificates that contain this type of public key but are signed with RSA? Brian's answer was "both".
Eric concluded this discussion item by noting that there would be no WG answer on this until the IPR questions are answered.
Nagendra Modadugu, Eric Rescorla
Counter mode is a charter item now, so this update was provided. Not much has changed since this was briefed at last IETF. Nagendra provided an overview for those not familiar with the technology. The motivation is to save bytes (plus random access for DTLS). This counter design is similar to the one for IPsec.
There were a number of questions on the draft from the mailing list. These include:
- is 48-bits of IV sufficient? A: IPsec uses 32 bits & that's sufficient, so this should be okay
- editorial comments
- security considerations section
Pasi Eronen stated that this draft is ready; we need people to volunteer to review during WG Last Call? Russ, David McGrew; Charlie Kaufman volunteered to do so. Russ noted that the security considerations section is required BEFORE last call. Pasi closed this discussion by saying that once the author has a new version with the security considerations section, it will move to WG last call.
Yngve Petterson, Opera software
In theory, SSL/TLS is forward compatible, and SSL/TLS implementations will be able to work with implementations of newer protocol versions. In reality, many SSL/TS server implementations are broken WRT forward compatibility. Specific problems found include:
- SSL v3 Servers will not talk to TLS 1.0 clients
- TLS 1.0 server will not accept TLS extensions
- TLS 1.0 servers will not talk to 1.1. clients
- TLS 1.0 servers use wrong field to negotiate version with 1.1 clients
Details of each type of problem were provided. It was pointed out that it's difficult to tell whether some of these problems are caused by TLS server implementations, or by firewalls.
Pasi asked if there are plans to write an I-D describing some of this stuff. It would provide a better distribution method for this data. Yngve said that he can think about it, but may not have the server identification data handy right now. Also, Opera has already implemented the work-arounds for this; it would be harder for them to delete those changes and do the tests again. Eric offered to connect Yngve to Ben Laurie, who will probably be interested in this, too.
In response to Yngve's slide bullet about how the working group can handle non-compliant implementations, Charlie Kaufman said only two ways come to mind: public humiliation of specific sites, or an RFC containing a list of common configuration errors.
Yngve said that the only other option he knows is for all client vendors to agree not to implement version rollbacks.
Russ Housley, VigilSec
The concern is that several proposed TLS extensions are being defined that provide supplemental information to the application. Maybe we should think about whether this is something that needs a common architectural solution, rather than letting every new draft re-invent the wheel.
The proposal is to develop independent hello message extensions to negotiate what data will appear; but place all of the data that will be passed to the application in a single handshake protocol message. Types will allow data associated with more than one extension to appear in the handshake message without confusion
Russ described the proposed syntax. It would require a standards-track RFC for the supplemental data formats extension. Also, IANA needs to establish a registry for TLS Supplemental Data Formats.
As a way forward: Russ believes that this resolves the IETF last call comments from Eric on draft-santesson-tls-ume. If the TLS WG likes this approach, action is needed immediately: somebody needs to write a full draft; then extend IETF Last Call on draft-santesson-tls-ume document plus the new document. Assuming that there are no issues, IESG will hold a ballot on the two documents.
Eric explained his rationale for asking Russ to go with this approach. Eric wants to keep the TLS architecture as simple as possible, but people are going to do these extensions anyway. This seems to be the simplest way to give them what they wanted.
Stefan Santesson stated that this is a reasonable and good way to go.
Sam Hartman said that architecturally this seems like a great way to go. He sees no issues.
Uri Blumenthal – Architecturally this makes good sense. Are there any planned implementations? A: at least 2, yes.
Action: Stefan Santesson will take over as author of this document and write the full draft (Russ can't because he's the shepherd of this document). The WG will wait for that document.
Russ Housley, VigilSec
I-D by Russ & Mark Brown
Russ described a way to carry authorization information in TLS exchanges. The intent is to work with both TLS 1.0 and 1.1. This would allow the client to provide authorization information to the server; & the server to provide authorization information to the client
The -01 draft is on server now; it will be changed greatly by the results of Russ' last talk and that decision.
The problem of exchanging sensitive information is solved by double handshake – which, incidentally, is not explained in any current RFC. After the "finished" message, start another handshake which is all encrypted. The sensitive authorization data is passed in the second handshake if the authorizations themselves need to be protected.
Russ believes that this approach is more efficient with resumption – except it doesn't work with current specs because of the way resumption works.
An open issue is the need to allow an empty AuthorizationData extension – resolved by technique from previous briefing
Way forward: should this become a TLS WG document? If not, it will proceed as standards-track individual submission.
A show of hands indicated that while a number of people are interested in this item, only two were interested enough to agree to review the document and comment. Thus, this item will continue as an individual item.
Magnus Westerlund
The Real-Time Streaming Protocol (RTSP) is the "network remote control" – the signaling protocol for controlling steaming session. The streaming media normally goes in its own transport session over UDP. RTSP uses RFC 2818 guidelines.
The new TLS-related material in RTSP is how to handle proxies. If the proxy is trusted, it can handle multiple TLS hops by either having the proxy relay the next hop server certificate to the client for the clients decision; let the proxy determine which certificates to accept; accept any certificate (for debugging only)
Magnus walked through the TLS connect process:
1 client connects with TLS & send Request to proxy
2 proxy connect with TLS to server & gets server cert
3 proxy responds to request with 470 (Connection authorization required) and include cert
4 client chances cert, and accepts it by including a hash of the certificate and proxy URE in the Accept-Credential header
5 proxy matches hash with connection and forwards request in
TLS.
Open Issues include:
- the Accept-Credential header is sent as part of the request when needed
- each entry within the Accept-Credential headers has an intended proxy
- should that proxy remove the entry indeed for itself before forwarding the request?
- Doing the above procedure rather than having certs go end to end would reduce bandwidth in request, slightly increase processing load; hide earlier TLS hops from later RTSP agents; the Via header shows route, however it allows for a proxy to hid topology
- Any security implications?
Eric Rescorla and Stephen Farrell volunteered to reviewed this.
Eric Rescorla
Background: TLS 1.1 (RFC 4346) is waiting for the RFC-Editor to push it out. Recent attacks on MD5 and SHA-1 don't immediately threaten TLS, but The working group was rechartered to do a TLS 1.2 to do hash function fixes. The first output is draft-ietf-tls-rfc4346bis.
Changes in this draft:
- merged in TLS extensions and AES cipher suites
- extension for client to indicate which hash functions are supported in certificates
- replacement of MD5/SHA-1 in PRF
- Replacement of D5/SHA-1 in the digitally-signed element.
Eric noted that he got a lot of pushback on the mailing list; so we really need to decide whether we really want to do this or not.
Eric explained how the draft handles PRF and digitally-signed element. The finished message provides downgrade protection, but it's only as strong as the weakest common hash function. If we take a particular approach, we're now in the business of approving/disapproving algorithms, which is not good. It's hard to get around this.
To frame the discussion, Eric noted that:
- certificate selection can be done by extension
- the main reason for a TLS 1.2 is to replace the PRF and digitally –signed elements
o there is no currently known threat to these
o but it seems ugly to be tied to hashes that don't meet their design goals
- so, should we be making a proactive change like this?
Eric: is this worth the effort? He wanted to get the sense of the room here, then push it to the list.
Pasi Eronen stated that there are good reasons to do this. Selection of hash functions involves a lot of politics; security is only part of it. So it's good to support negotiating hash function vice just pushing to SHA-256, e.g.
Uri Blumenthal – this is something that should be done. Picking another pair of functions and using them in tandem is not a good idea, but ambivalent about negotiating hash functions because it's more secure but more expensive
The issue of non hash-based PRFs was raised. Support for these is desired by some, but it makes the protocol more complex.
Russ Housley: (Channeling several Russian posters on mail list.) For us to sell TLS to protect banking transactions in Russia, we must support GOST. They have a different KDF as well as a different hash function. Bottom line is that that motivation for change is enhancement for a particular jurisdiction, vice the current motivation for change being purely security.
Sam Hartman: We have heard complaints about using hash functions for PRF/KDR before; might be able to change at some point in time. He would rather be in a position where that could be handled in the protocol, rather than needing to mod TLS again then.
Russ explained the repeated references to NIST 800-56. For people who want to sell to the US Government, the KDF's in the document are based on NIST-approved hash functions. However, there's a transition time – they will accept applications of TLS implementations for evaluation until 2010.
After taking a sense of the room, Eric decided that there was enough support for the ideas here (supporting negotiation of hash functions, replacing the current hash functions/KDFs) to take the issue to the mailing list.
The meeting was adjourned at 2:35.