[TLS] TLS WG Interim Meeting: 21-22 September 2015
The Transport Layer Security (tls) working group will hold a face-to-face interim meeting at Microsoft in Redmond, Washington, USA on 21-22 September 2015 from 9am-5pm. Date: 21-22 September 2015 Time: 9am-5pm Location: Redmond, Washington, USA Additional information, including agenda and more venue information will be announced on the TLS WG mailing list: https://mailarchive.ietf.org/arch/search/?email_list=tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
Hi Martin, thanks for your review. On 08/06/2015 10:33 PM, Martin Thomson wrote: > I've read this draft before, but this is considerably different to > what I read, and I haven't been following the discussion, so consider > this as a review with fresh eyes. > > First the high points. I think that this is useful, the right scope, > and reasonably well formulated. I have a couple of minor points > > Figure 2 is in error: it shows CertificateRequest instead of Certificate. Good catch. A copy-and-paste error. > > I'd like to see the document explicitly note that msg_type and length > from the handshake message are not covered by the hash. The > description of what is covered is a little too terse (and badly > formatted). There are multiple message type / message length fields included in the message and I am not sure which of those you rare referring to. The msg_type and msg_length from the record layer is not part of the fingerprint calculation. The spec only focuses on the certificate message in Section 4.1 and the CertificateRequest message in Section 4.2. These message do, however, also contain length information. I included an example into the document. See Appendix A: https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt > > I'm not sure that I like the lack of both negotiation and signaling > for the hashes that are used here. We had a negotiation capability in earlier versions of the document but it appeared to be an overkill. What is there now is essentially an indication of the hash algorithm based on what the client presents with the CachedInformationType structure. If you need support for a new algorithm then add a new type (and the implementation). We could make it easier to add new algorithms (via the expert review process). We could also register another algorithm already now, if found necessary. > Though I think the chances of a > collision being found, or that a collision would lead to an attack, > are slim, I would rather see this use the PRF hash so we have at least > that much flexibility. While there is indeed a possibility for hash collisions those will still lead to a failed exchange since the TLS server will not possess the correct private key that corresponds to the cached certificate. > If the current design is retained, I would > like to see a little discussion of this in the document. A little > analysis of the properties we expect the hash to provide would also be > good. > > I think that truncated hashes might be advantageous from the server > side. Given that the server only uses hashes to identify which of the > offered (available, known?) cached information is in use, is there any > reason you can't save additional space by arbitrarily truncating the > hash? In many cases I would imagine that the client would be offering > only one option and even if there were a small number of options > presented, a single byte would suffice to disambiguate. > > I'm trying to think why you might want the full-length hash on the > client side, but I believe that the only problem there is that there > might be a collision between the certificates that a server might > offer if you truncate too aggressively. The connection still relies > on the server presenting proof of knowledge of a key that the client > extracts from a certificate bound to the server identity, so I believe > that it would be equally secure if you removed all mention of > certificates from the protocol. And that makes me nervous, because > I'm fairly sure that Karthik will tell me that I'm wrong very shortly; > since we've put in a lot of work to cover key fields in the handshake > hash, and I'm concerned that this could be exploited somehow. > > The more I think about this, the more I think that we need a little > more analysis on this point (i.e., what properties the hash function > needs to provide and why). If it has already happened, mention of > that in the security considerations is needed. > > (I think that truncation on the server side is safe if the client uses > a strong hash function to identify the certificate, but I'm frequently > wrong about these things.) > There are three designs possible for referencing the cached state, namely 1) The client creates the reference. This is the current approach. The client creates a reference (via the use of the hash function) and tells the server that it has seen certain parameters before and that there is no need to re-transmit them. 2) The server creates the reference. In this design the server allocates the reference and sends it to the client. The client 3) There is no reference at all. The client just tells the server not to send certain payloads because it has cached something already previously. While the server does not get told what has been cached the worst thing that can happen is that the exchange fails (in which case the client has to fall back to a full exchange).
[TLS] I-D Action: draft-ietf-tls-padding-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : A TLS ClientHello padding extension Author : Adam Langley Filename: draft-ietf-tls-padding-02.txt Pages : 4 Date: 2015-08-24 Abstract: This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-padding-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-padding-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
Hi Hannes, On 24 August 2015 at 09:38, Hannes Tschofenig wrote: >> I'd like to see the document explicitly note that msg_type and length >> from the handshake message are not covered by the hash. The >> description of what is covered is a little too terse (and badly >> formatted). > > There are multiple message type / message length fields included in the > message and I am not sure which of those you rare referring to. > > The msg_type and msg_length from the record layer is not part of the > fingerprint calculation. The spec only focuses on the certificate > message in Section 4.1 and the CertificateRequest message in Section > 4.2. These message do, however, also contain length information. I refer to the msg_type and length from the handshake message, which are the only things with that name in the TLS spec. You use the name `CertificateRequest`, which leads me to conclude that you mean the struct identified as such, which is *inside* the handshake message. (I'm fine with hashing that part, I just want to have it be very clear.) > I included an example into the document. See Appendix A: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt This includes the msg_type and length. Which means that you should talk about hashing `Handshake` instead. >> I'm not sure that I like the lack of both negotiation and signaling >> for the hashes that are used here. > > We had a negotiation capability in earlier versions of the document but > it appeared to be an overkill. Yeah, that's why I'm thinking that this can use the PRF hash. > What is there now is essentially an indication of the hash algorithm > based on what the client presents with the CachedInformationType > structure. I don't see that anywhere. The algorithm seems to be fixed to SHA-256 in the current draft (and your copy). >> Though I think the chances of a >> collision being found, or that a collision would lead to an attack, >> are slim, I would rather see this use the PRF hash so we have at least >> that much flexibility. > > While there is indeed a possibility for hash collisions those will still > lead to a failed exchange since the TLS server will not possess the > correct private key that corresponds to the cached certificate. Right, this might be all that the analysis requires. >> If the current design is retained, I would >> like to see a little discussion of this in the document. A little >> analysis of the properties we expect the hash to provide would also be >> good. >> >> I think that truncated hashes might be advantageous from the server >> side. Given that the server only uses hashes to identify which of the >> offered (available, known?) cached information is in use, is there any >> reason you can't save additional space by arbitrarily truncating the >> hash? In many cases I would imagine that the client would be offering >> only one option and even if there were a small number of options >> presented, a single byte would suffice to disambiguate. >> >> I'm trying to think why you might want the full-length hash on the >> client side, but I believe that the only problem there is that there >> might be a collision between the certificates that a server might >> offer if you truncate too aggressively. The connection still relies >> on the server presenting proof of knowledge of a key that the client >> extracts from a certificate bound to the server identity, so I believe >> that it would be equally secure if you removed all mention of >> certificates from the protocol. And that makes me nervous, because >> I'm fairly sure that Karthik will tell me that I'm wrong very shortly; >> since we've put in a lot of work to cover key fields in the handshake >> hash, and I'm concerned that this could be exploited somehow. >> >> The more I think about this, the more I think that we need a little >> more analysis on this point (i.e., what properties the hash function >> needs to provide and why). If it has already happened, mention of >> that in the security considerations is needed. >> >> (I think that truncation on the server side is safe if the client uses >> a strong hash function to identify the certificate, but I'm frequently >> wrong about these things.) >> > There are three designs possible for referencing the cached state, namely > > 1) The client creates the reference. > 2) The server creates the reference. > 3) There is no reference at all. I'm not suggesting that you change the design, just provide a description of the properties that it provides - and those that it relies on. On the surface at least, it seems OK to rely on a weak guarantee of collision resistance from the hash. Failure only results in handshake failure, after which the client can fall back. That suggests that a truncated hash output could be used, potentially saving quite a few bytes in the client's first flight. I'd like to do that if it is possible. However, I'm concerned that e
[TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
Hi, I am looking for a way to achieve identity hiding for DTLS 1.2, which also hopefully can be used in (D)TLS 1.3, when available. >From what I understand, for (D)TLS 1.2 it would be possible to perform an anonymous unencrypted handshake and then to renegotiate the connection with authentication within the encrypted channel, e.g., according to the expired draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation will be removed in the upcoming 1.3 version. What is likely to be the recommended way to achieve identity hiding for (D)TLS 1.3, if any? [1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012 [2] The Transport Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07 Best regards Viktor S. Wold Eide ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > TLS 1.3 encrypts both the client's and server's certificates already. The server's certificate is secure only against passive attack. The client's is encrypted with a key that the client can authenticate as belonging to the server. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, 24 Aug 2015, Eric Rescorla wrote: TLS 1.3 encrypts both the client's and server's certificates already. The server's certificate is secure only against passive attack. Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash of a known CA to you, you can withold your own certificate from being sent. Is a similar mechanism not planned for TLS 1.3? Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters wrote: > On Mon, 24 Aug 2015, Eric Rescorla wrote: > > TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. >> > > Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > CAs they trust, so unless you receive a hash of a known CA to you, you > can withold your own certificate from being sent. > > Is a similar mechanism not planned for TLS 1.3? Well, TLS already permits the server to indicate the DN of CAs which should be in the path. I have not heard of any plan to add a digest indication. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
Hi, Another solution was approved for publication as experimental by IESG in 2009 but I declined to process with Pasi Eronen way (previous WG co-Chair) of publishing the document. It is available at https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and it works for TLS and DTLS Best regards, Mohamad On Tue, Aug 25, 2015 at 12:56 AM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > > Best regards > Viktor S. Wold Eide > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
On 22 August 2015 at 19:28, Dave Garrett wrote: > Toggling solves the undesired bandwidth use concern stated by Tom by making > it fully optional on both sides. The even simpler route of just having to > check if there's bytes in the encrypted fragment other than the payload would > avoid a little bit of complexity, but with no way for an endpoint to say no > to increased bandwidth usage that it doesn't want to or can't handle. Given > this constraint, I'd favor either easily toggleable or always-on, rather than > a middle-ground where implementations won't know what they're going to get > and can't do anything about it. > > A footnote: Negotiating via an extension is probably not a good idea because > client extensions will generally be in the clear. That's why I suggest a > simple message instead. (there's no need to pad the cleartext hello, so it's > fine to wait until record protection is available) Note that I don't think > allowing this to be decided after the handshake is a good idea. > > A more generalized way to handle throttling padding would be to set a low > default and require each endpoint to send a message with a different value, > in max bytes per record (or second, or both) of padding permitted, in order > to use a different amount. Each endpoint could easily arbitrarily throttle > its downstream padding bandwidth independently, if need be. I have a not-very-hidden motive in not having it be negotiable: I want to enable clients to want to send padding be able to do so to any server, even if that server does not want to pad. (They can just discard.) If it's negotiated, the server may say "I don't support padding" and clients who want to use it out out of luck. I do like solutions where the use or non-use of padding is hidden, but I think in many cases it will be obvious, so the above goal comes before this goal for me. I don't believe the topic of encrypting the content type is completely resolved, but that is a separate proposal: https://github.com/tlswg/tls13-spec/pull/51 > I'm curious as to how much of a range would actually be useful, though. For > actually good protection, you'd really want to pick a stable bandwidth and > essentially hold it; keep up/download rates constant or following some > consistent pattern with a combination of possibly throttled data and padding > such that the data length and time is completely protected and the stream is > 100% opaque to an observer. I wouldn't expect this to be all that popular, > though, as it would be a bandwidth hog in many cases. A middle-ground might > involve also specifying a max bytes allowed in between data bursts to hide > the peaks, but now we're getting more complicated than I think we want here > if we go any further. (and beyond what I know anything about) The current > proposal says that padding algorithms are outside of the scope here, but I > think adding this as a built-in feature without coming up with some easily > usable default (even if not particularly advanced) is a mistake that will > cause this feature t o be largely unused. In general, developing good padding approaches is relatively easy for well defined application protocols, and difficult for extremely generic ones like "Browsing the Internet". If one was developing an application for twitter, google maps, XMPP chat - developing a good padding mechanism to hide specific actions or data would not have the same issues. There's been a number of padding strategies developed by academic researchers studying traffic correlation/confirmation attacks - I don't expect any of them is drop-in-good-enough for a generic browser implementation... but it would be _amazing_ if browser vendors enabled browser extension authors to choose the padding strategy for individual origins. Then we can crowdsource the effort. -tom ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
On 25/08/15 00:22, Tom Ritter wrote: > it would be _amazing_ if browser vendors enabled > browser extension authors to choose the padding strategy for > individual origins. Then we can crowdsource the effort. Excellent idea! S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
On 24 August 2015 at 16:30, Stephen Farrell wrote: > > > On 25/08/15 00:22, Tom Ritter wrote: >> it would be _amazing_ if browser vendors enabled >> browser extension authors to choose the padding strategy for >> individual origins. Then we can crowdsource the effort. > > Excellent idea! I believe that this would be possible, but you would have to enumerate what information you might want to have available. At the TLS layer, we've lost a lot of the context. You might be better off with HTTP(/2) layer padding. The ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 05:33:18PM -0400, Paul Wouters wrote: > On Mon, 24 Aug 2015, Eric Rescorla wrote: > > >TLS 1.3 encrypts both the client's and server's certificates already. > >The server's certificate is secure only against passive attack. > > Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > CAs they trust, so unless you receive a hash of a known CA to you, you > can withold your own certificate from being sent. > > Is a similar mechanism not planned for TLS 1.3? This would break DANE, unless the mechanism also allowed the client to send a TLSA RRset instead, with the server then needing code to figure out which chains match which TLSA RRs. This is I think too complex. If the client is willing to live without any certificate at all, it can include anon-(EC)DH ciphersuites in its cipherlist at a higher preference than any ciphersuites that use certificates.. Otherwise, the server sends a suitable chain per SNI and closest match to supported signature algorithms. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Tue, 25 Aug 2015, Viktor Dukhovni wrote: Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash of a known CA to you, you can withold your own certificate from being sent. Is a similar mechanism not planned for TLS 1.3? This would break DANE, unless the mechanism also allowed the client to send a TLSA RRset instead, with the server then needing code to figure out which chains match which TLSA RRs. This is I think too complex. If you publish your public key in DNS you would also just always send your public key over TLS. There is no privacy issue there, so no reason to withhold it. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote: > >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > >>CAs they trust, so unless you receive a hash of a known CA to you, you > >>can withold your own certificate from being sent. > >> > >>Is a similar mechanism not planned for TLS 1.3? > > > >This would break DANE, unless the mechanism also allowed the client > >to send a TLSA RRset instead, with the server then needing code to > >figure out which chains match which TLSA RRs. This is I think too > >complex. > > If you publish your public key in DNS you would also just always > send your public key over TLS. There is no privacy issue there, > so no reason to withhold it. Not sure how this comports with your original proposal. What would a client have to send to convince the server to not withold its certificate? What does witholding it mean anyway, the client needs the public key at least if the server signs the key exchange. Is there something here worth pursuing in the context of TLS? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Headerless records (was: padding)
The topic of encrypting the content type came up again, and a core WG charter
goal is to encrypt as much as possible. To this end, I suggest we consider
going all the way in this area: headerless records. Each protected record would
contain nothing but an aead-ciphered struct with the bare minimum it needs,
namely ContentType & content, plus maybe padding. Nothing else is really
needed. The only thing that needs to know anything here is the peer with the
key.
struct {
aead-ciphered struct {
ContentType type;
uint16 length = TLSPlaintext.length;
opaque content[TLSPlaintext.length];
opaque padding[padding_length];
};
} TLSCiphertext;
Arbitrary padding can be added after the content, up to the total record
maximum size. If we even wanted to ditch the length field, we could do:
struct {
aead-ciphered struct {
if (padding_allowed) {
opaque padding<0..(2^14+256-TLSPlaintext.length)>;
}
ContentType type;
opaque content[TLSPlaintext.length];
};
} TLSCiphertext;
In which case content is just the remainder of the record after the type.
(without the explicit length field, padding needs to come first so it can have
its length in its vector first)
Cleartext records would of course be unchanged, as they need to stay as-is for
backwards compatibility.
With an encrypted record format like one of the above, everything after the
handshake is opaque and potentially padded.
The additional data fed to the AEAD cipher is just the sequence number at this
point. The version can easily be mixed into the keying material by adding it to
the HKDF label, and then we don't need to re-verify it after the fact if they
key depends on it.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
