Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On 14 July 2015 at 12:30, Andrei Popov wrote: > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern for > the opportunistic TLS community? I raised the concern about this previously. Opportunistic MitM happens, and providing a strong signal that the connection won't be (or couldn't be) authenticated somehow is a problem for that. I'd rather have opportunistic security be indistinguishable from "real" security. It also means that you don't have separate code paths to support. The anonymous modes serve a different purpose. For instance tcpinc could use them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On 14 July 2015 at 13:08, Viktor Dukhovni wrote: > Yes, and informs the server that the client is skipping authentication, > which is often useful information on the server end. The problem here is that the server isn't the only recipient of that signal. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL wrote: > I'd rather not lose the 571 curve. I'd like to understand why you think it's worth keeping. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 04:04, Eric Rescorla wrote: > - The client indicates configuration ID and cryptographic configuration, > including the cipher suites and cryptographic extensions. This > MUST replicate the server's selection from a previous handshake That's not going to work if there was no previous session. For instance, if the configuration was learned out of band. It also implies that the selection can come from ANY previous session, where I think that it only makes sense to identify the session where the configuration was learned. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 04:12, Eric Rescorla wrote: > > Yes, that's an issue. Not entirely sure what to do about other than > have the server provide its negotiation preferences out of band > in that case. I think that we could handle that at the point we define an out-of-band configuration priming mechanism. I don't think we need a full negotiation model for the server. A simple option would list the server's preference order for suites and so forth in its configuration advertisement; the client would then pick from that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 06:08, Ilari Liusvaara wrote: > Well, if it is about supported ciphers, there could be multiple, and > the proposal has slot for only one. The proposal is for what the client selects and uses for its first flight. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 08:17, Ilari Liusvaara wrote: >> > *deadlock*. >> >> >> Is this the case where the server is accepting 0-RTT or rejecting it? > > Apparently, only for accepting case. > > (If the server rejects, it can reply immediately, avoiding this > deadlock). I don't think that this is a concern. You only have to say that the server should not wait for the 0-RTT data before continuing with the handshake. At some level, you can safely consider 0-RTT data as being streamable/equivalent to application data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] 4492bis table 1
Is table 1 correct? +---+-++ | Symmetric | ECC | DH/DSA/RSA | +---+-++ | 80| 163 |1024| |112| 233 |2048| |128| 283 |3072| |192| 409 |7680| |256| 571 | 15360| +---+-++ Aren't we dropping 571? Can we use values that match up. Or, drop the table. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] 4492 ECDH_anon
I have never understood why 4492 doesn't claim forward secrecy for ECDH_anon suites. Can someone explain why this doesn't have an 'E'? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
On 22 July 2015 at 01:50, Kyle Rose wrote: > I'd like to see the bits of the cipher suite associated entirely with > ephemeral data tied together roughly by security margin I've seen this argument several times, but there are reasons why you might want a non-homogenous strength profile. The argument for consistency is appealing, but given that the design of TLS is historically[1] vulnerable to the weakest *supported* algorithm as opposed to the weakest *used* algorithm, I am not concerned about ensuring consistency. [1] ... and likely in future, despite our best efforts > The one thing I'm having trouble pinning down is PSK. I fear it's not > a separate dimension, because it replaces both signature and KEX. Yes, this is a problem. I like to think of PSK as KEX with null auth. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 02:20, Yoav Nir wrote: > They both provide forward secrecy. The draft specifically excludes ECDH_anon from the following statement, implying otherwise: The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. It might be a good idea to revise that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 02:29, Yoav Nir wrote: > PR at > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml > ? https://github.com/tlswg/rfc4492bis/pull/6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 19:07, Dave Garrett wrote: > Could the cipher suite names be officially changed to add the 'E' to them? > It'd make things simpler to be consistent. I'd be OK with that. I didn't do it in the PR, but would be happy to make a new one. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 19:12, Yoav Nir wrote: > I’d like to hear from the chairs if it’s OK to rename stuff in the IANA > registry. > > That has some implications for implementations that use these names. > > Not to mention that the same issue applies to DH(E)_anon I believe that renaming entries in the IANA registry is possible. I don't think that it affects implementations, though it might cause some minor usability issues if people attempt to configure them using the IANA names. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Review of PR #209
Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209 The first expands the ways in which a server can identify certificates. This is fine. I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately). The second is worrisome. I don't like that a handshake message now has two different potential locations that it might appear in. That seems like a hazard. I think that we need a new content type for a new message that can be used after the handshake completes. Then there are two options: a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses) b) use CertificateRequest within the handshake, and the new content type outside of it ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On 25 July 2015 at 16:13, Eric Rescorla wrote: > The only question is whether it's legal to concurrently offer RC4 with TLS > 1.3 > for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC > even though TLS 1.3 does not support it.) I am trying to work through this > myself, as the interactions with browser fallback are very complex. And the strategies vary. It might be that we don't need to worry about this, because we might have widely disabled RC4 by the time TLS 1.3 ships. https://ipv.sx/telemetry/rc4.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On 25 July 2015 at 17:48, Salz, Rich wrote: > "we" meaning browsers. "we" not being everyone who will use TLS 1.3 > > Ekr has pointed out a problem; if you connect with a protocol range and > proffer RC4, can we do anything about it except point out multiple times that > 1.3 servers MUST NOT accept it? Agreed. But I'll point out that other users of TLS will likely not be doing fallback either, so they have to deal with offering what they support straight up. Prohibiting RC4 probably won't do anything more than what our existing efforts are doing already. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On 3 August 2015 at 17:21, Andrei Popov wrote: >> use CertificateRequest within the handshake, and the new content type >> outside of it > > Would the client then also use this new content type for Certificate and > CertificateVerify messages (when these are sent after the handshake is > complete)? Yeah, I think that's best. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos wrote: > Is there any support for > switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for > TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the > redundant bytes redacted as the draft is now [1]. Personally, I would rather see the nonce construction follow the form defined in the respective TLS version. That means including redundant bytes in TLS 1.2 and only getting the full advantage when we move to TLS 1.3. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 4 August 2015 at 10:24, Wan-Teh Chang wrote:
> The consistency you want to see seems to be
> consistency with the AES GCM cipher suites, rather than with TLS 1.2.
Yes, this is correct.
RFC 5288:
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
RFC 6655:
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS
only (if I'm reading it correctly).
Either way, I think that we should attempt to be consistent with
these. Which suggests that perhaps we can adopt a zero-length
explicit nonce and borrow the 6655 DTLS construction.
As for the wasted bytes, I don't care for that. We will fix that later.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 5 August 2015 at 11:13, Wan-Teh Chang wrote:
> Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.
>
>struct {
>opaque nonce[12];
>} ChaChaNonce;
>
> 1. The 64-bit record sequence number is padded to the left with
> zeroes to 96 bits (12 octets).
> 2. The padded sequence number is XORed with either the
> client_write_IV (when the client is sending) or the
> server_write_IV (when the server is sending)
> 3. Store the XOR result in ChaChaNonce.nonce.
This looks fine. Note that the general construction in TLS 1.3 should
be, more formally:
assert(N_MAX > 64bits)
nonce = {client|server|_{read|write}_IV[0..N_MAX] XOR lpad0(seq_num)
Of course, ChaChaX sets N_MAX to 96 bits, so what you described was correct.
--Martin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
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. 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). I'm not sure that I like the lack of both negotiation and signaling for the hashes that are used here. 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. 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.) On 6 August 2015 at 10:24, Joseph Salowey wrote: > Hi Folks, > > This is the Working Group last call for draft-ietf-tls-cached-info-19. This > document has undergone modification since last WGLC so another WGLC is > appropriate. This document is a dependency for the DICE working group > TLS/DTLS profile. Please send your comments to the TLS list by September 2, > 2015. > > Thanks, > > J&S > > ___ > 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] Commentary on the client authentication presentation slides
Before people get too far down that road, here: https://tools.ietf.org/html/draft-thomson-httpbis-cant-01 https://tools.ietf.org/html/draft-thomson-tls-care-00 Andrei has made it clear that these do not work for his use case (I'm not yet convinced that they are inadequate, but I am convinced of the fact that Andrei thinks that they are inadequate ;). Also: https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9 This is well-trodden ground. On 10 August 2015 at 23:05, Dave Garrett wrote: > On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: >> > What sort of usecase you have in mind for this? >> >> This is to support a fairly common website design where the landing page >> does not require client auth, but subsequent request to a protected resource >> triggers client authentication within an existing TLS connection. >> In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no >> renegotiation, so we need an alternative solution if we want to support >> these existing sites over TLS1.3. > > This is just an idea, but what about just allowing a renegotiation-like > mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or > HTTP response code? The rough idea would be like this: > > 1) client connects to server and fetches public resources > 2) client requests restricted resource; server sends auth required response > (TLS alert or HTTP code) > 3) client creates a replacement connection using PSK-based resumption and > early data in the first flight for the request along with the client cert. > > There's a 1 roundtrip cost in there for a new TCP connection, which could > possibly be optimized away by using TCP fast open. > > This general concept is relatively simple in comparison to doing something > mid-connection. Instead of attempting to renegotiate on an existing > connection, just make creation of resumed connections cheap enough to start > over with client auth in the handshake from the start. > > It's a very rough idea, but I'm wondering if it sounds like something worth > discussing. > > > Dave > > ___ > 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] TLS and KCI vulnerable handshakes
On 11 August 2015 at 11:25, Karthikeyan Bhargavan wrote: > No, a regular ECDSA certificate would do. > That is, the attack would work as long as > - a client has an ECDSA certificate, and > - it enables any static TLS_ECDH_* cipher suite, and > - its ECDSA private key has been stolen (or chosen) by an attacker. I don't see how that would work. A client that understands the cert to be ECDSA won't pair the key with the server's ECDH share, they will sign the session transcript with it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS and KCI vulnerable handshakes
On 11 August 2015 at 12:05, Ilari Liusvaara wrote: >> I don't see how that would work. A client that understands the cert >> to be ECDSA won't pair the key with the server's ECDH share, they will >> sign the session transcript with it. > > a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is > no ECDSA-specific keytype in X.509. Maybe I should have been clearer. The certificate might not include a (strong) signal that allows the client to distinguish between ECDSA and fixed ECDH, but the client might be configured with that knowledge. I checked NSS and there doesn't seem to be any way that it could be coerced into using the (EC)DH pair from a client certificate in a key exchange. Even though it supports some fixed (EC)DH suites. NSS (incorrectly) adopts the posture that _ECDH_ suites are half-static: the server share is in the certificate, but the client side is fully ephemeral. This is clearly in violation of RFC 5246, Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about that right now :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS and KCI vulnerable handshakes
On 11 August 2015 at 16:38, Clemens Hlauschek wrote: >> Maybe I should have been clearer. The certificate might not include a >> (strong) signal that allows the client to distinguish between ECDSA >> and fixed ECDH, but the client might be configured with that >> knowledge. > > There is no difference between an ECDH and an ECDSA, apart from > (possibly) the KeyUsage Extension. I'l try again. Even if the certificate does not include that signal, the software that accepts that signal might make assumptions or have configuration that cause it to only be used in one way or another. See NSS. >> NSS (incorrectly) adopts the posture that _ECDH_ suites are >> half-static: the server share is in the certificate, but the client >> side is fully ephemeral. This is clearly in violation of RFC 5246, >> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >> that right now :) > > Please elaborate. I do not see how this half-static behaviour > constitutes any violations of the mentioned RFCs. Both the above cited sections say very clearly that for fixed (EC)DH cipher suites the client where the client has a fixed (EC)DH certificate, the client MUST send an empty ClientKeyExchange. Of course, you might say that this is simply a consequence of not supporting fixed (EC)DH for client authentication, and then it's not technically in violation. The value of the ClientCertificateType from the CertificateRequest is likely important here, but that field is systematically ignored in practice (NSS ignores it). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 comments
On 17 August 2015 at 05:02, Ilari Liusvaara wrote: > > Actually, I think both should be 256 (256-byte expansion from AEAD > is already quite much). Pull request or it didn't happen ;) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 comments
Expect? No. That you sent an email is already highly useful. A PR makes feedback even more useful. For truly trivial stuff, rolling them up into a single PR is probably even more so. On Aug 17, 2015 12:01 PM, "Yaron Sheffer" wrote: > My original mail had some 15 comments, some trivial, some not. Do you > expect 15 PRs? > > Thanks, > Yaron > > On 08/17/2015 10:37 AM, Martin Thomson wrote: > >> On 17 August 2015 at 05:02, Ilari Liusvaara >> wrote: >> >>> >>> Actually, I think both should be 256 (256-byte expansion from AEAD >>> is already quite much). >>> >> >> >> Pull request or it didn't happen ;) >> >> ___ 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
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] Headerless records (was: padding)
On 24 August 2015 at 21:04, Dave Garrett wrote: > uint16 length = TLSPlaintext.length; You can't recover the plaintext without knowing how long it is. This part at a minimum needs to be in the clear. At which point you need it to be based on TLSCiphertext.length ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
On Aug 25, 2015 7:26 AM, "Kyle Rose" wrote: > > >> uint16 length = TLSPlaintext.length; > > > > You can't recover the plaintext without knowing how long it is. This > > part at a minimum needs to be in the clear. At which point you need > > it to be based on TLSCiphertext.length > > Is that really true? You could decrypt the first block/few bytes to > get the length (without authentication, of course) and then decrypt > the remainder according to this candidate length. Then authenticate > the entire record to make sure the candidate length was correct. That depends on the aead - and the implementation. GCM can - maybe - be broken apart that way*, but I can't think that going to all the trouble of formulating an aead just to break it open at the first point that it becomes inconvenient. You could imagine an aead that made that difficult or impossible (just reverse the order of the bytes...). Or, without imagining at all, you can have hardware module that enforce authentication before releasing plaintext. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
On Aug 25, 2015 7:42 AM, "Viktor Dukhovni" wrote: > SSH now has ciphersuites where the payload length is encrypted, > IIRC via a key that is different from the payload key. Yeah, I'm not that enthusiastic about that feature, but if you want more complexity, it is possible. The authentication properties are interesting there, of course. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On 26 August 2015 at 14:11, Joseph Salowey wrote: > "Because certificate validation requires that trust anchors be distributed > independently, a self-signed certificate that specifies a trust anchor MAY > be omitted from the chain, provided that supported peers are known to > possess any omitted certificates they may require." I always thought that the primary reason for omitting a certificate was that you had a good reason to expect that clients had the certificate already. Whether the certificate is self-signed seems like a poor proxy for that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] MUST or what?
I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless. To pick on a recent changeset:
> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).
> All implementations MUST use the "signature_algorithms" extension when
offering and negotiating certificate authenticated cipher suites.
> All implementations MUST use the "supported_groups" extension when
offering and negotiating DHE or ECDHE cipher suites.
This isn't good. "MUST" language MUST have consequences or you are
left with all sorts of variations. If you don't stipulate
consequences, then people violate the MUST and you get interop issues.
I propose that we don't do this in future without due consideration.
In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.
The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons. For TLS 1.3, I think
that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello. I think only the ClientHello.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
The opposite in fact. NSS checks extensions first. That is how we filter
out ECC cipher suites if the named_groups extension doesn't list anything
we support.
On Aug 27, 2015 12:26 PM, "Eric Rescorla" wrote:
>
>
> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
> wrote:
>
>> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
>> > I've been looking at the latest TLS 1.3 spec and there are a lot of
>> > MUSTs that are completely toothless. To pick on a recent changeset:
>> >
>> > > The signature algorithm and hash algorithm MUST be a pair offered in
>> the
>> > "signature_algorithms" extension (see {{signature-algorithms}}).
>>
>> Some changes to this are now in this PR:
>> https://github.com/tlswg/tls13-spec/pull/231/files
>> (language based on list discussion)
>>
>> > > All implementations MUST use the "signature_algorithms" extension when
>> > offering and negotiating certificate authenticated cipher suites.
>>
>> Actually, I did get a strict requirement in there for that one:
>>
>>
>> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
>> > All clients MUST send a valid "signature_algorithms" extension in their
>> ClientHello when offering certificate authenticated cipher suites. Servers
>> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher
>> suites without this extension MUST send a "missing_extension" alert message
>> and close the connection.
>>
>> I think it warrants repeating in the MTI section as well.
>>
>> > > All implementations MUST use the "supported_groups" extension when
>> > offering and negotiating DHE or ECDHE cipher suites.
>>
>> My initial draft had similar language, however ekr says the WG doesn't
>> have consensus to be more strict. I would like to consider all of these
>> extensions as mandatory to send, and malformed if not present when
>> offering/negotiating any applicable cipher suites:
>> signature_algorithms, supported_groups, client_key_share, pre_shared_key,
>> server_name (though, I'm fine with a SHOULD error on lack of SNI when
>> applicable
>
>
> My problem is precisely the conflation of offering with negotiating. The
> way that
> many stacks work (for instance NSS) is that they negotiate the cipher suite
> *first* and then they check for the presence or absence of the relevant
> extensions.
> It's not clear to me that it's an improvement to require them to check for
> error
> conditions that are not otherwise relevant.
>
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
The statement I'd like to see is something like this... An endpoint that receives an illegal combination of "things" MAY choose to treat that as a fatal error. In this case, that means that if you include an ECDHE suite without an ECDHE named_group, don't expect to have the connection succeed. On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote: > On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > > My problem is precisely the conflation of offering with negotiating. The > way that > > many stacks work (for instance NSS) is that they negotiate the cipher > suite > > *first* and then they check for the presence or absence of the relevant > extensions. > > It's not clear to me that it's an improvement to require them to check > for error > > conditions that are not otherwise relevant. > > I'm not fundamentally opposed to having a hard requirement of an error > check on negotiation, and basically a soft expectation on mere offering > (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That > said, categorizing the cipher suites and just doing a quick check for which > categories are there and what extensions came with it is not a very > complicated requirement. I'm philosophically in the "do it right or explode > so it can be found and fixed immediately" camp when it comes to very clear > requirements like this, but I'm aware that this is sadly not always the > dominant thought process. :| > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
This seems fine to me, though I'll note that 7250 only really saves you space when it comes down to it. You can wrap your raw public key in a certificate, just like we do in WebRTC, and then you don't need 7250 support in your library. Noting you can only do any of these variations in a context where there is some preexisting understand that what you choose to use is acceptable to the other side. Regarding the explicit nature of having an explicit DH_anon signal, I tend to think that (on balance) removing this signal does more good than harm. I expect certain others to disagree, of course, but we can talk about why a vigorous defense of the cipher suite signal isn't a good use of their energy later. On 28 August 2015 at 10:35, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/233 > > Folks, > > We presently have some support for DH_anon cipher suites. I agree that this > is a useful use case, but it's yet another mode. > > I would like to suggest that we instead deprecate it and instead always use > Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that > the client would simply indicate support for a raw public key and the > server could then either (a) spin a new key for this use or (b) use a > long-term > one. To my mind this has three advantages: > > 1. Complexity: It means that we have one less operational mode. And all the > public key > modes would look cryptographically similar. > > 2. It resolves the question of how you bind to the server's identity in > 0-RTT mode > (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key > that goes in the Certificate message. > > 3. It makes it easier to do an SSH-style leap-of-faith mode since the server > can > use the same signing key for a long time while maintaining PFS. > > It seems to me that the two major counterarguments are: > > 1. Extra computational cost from the signature. I'm not worried too much > about that since generally the anonymous contexts don't do a lot of > connections > and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes > anyway. > > 2. It's less explicit that this is unverified. Arguably this is a feature > rather than > a bug. > > Thoughts? > -Ekr > > > > > ___ > 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] Deprecate DH_anon in favor of raw public keys?
On 28 August 2015 at 11:36, Eric Rescorla wrote: > How does anon-DH have different privacy properties than doing > RFC 7250 with a fresh signing key for each connection? Or what we do in WebRTC, which uses a certificate that has no good information in it? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On 28 August 2015 at 11:33, Viktor Dukhovni wrote: > On the other hand, it allows servers to detect that a > client is not planning to authenticate the server, which has forensic > value, and can be used to grant appropriately restricted access. I think that these are potentially useful properties, but I don't think that we need to use the cipher suite signaling to get that information. What if you could (for example) include a signal at the application layer "oh, by the way, I didn't authenticate you". Or you could have an extension that said up front that you don't intend to check. Those are superior in the sense that it allows for all the benefits of ekr's proposal, without losing the properties you care about. ___ 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, I've followed a similar chain of thought myself. I think that the right answer here is similar to what you describe: the security of TLS does not depend on the presence of the certificate at all, rather it depends on the use of a private key that the client trusts. That most clients rely on the certificate for getting the information they need to make that trust decision and that the certificate happens to be carried in TLS in most cases is largely consequential. On that basis, I would be happy then to accept any hash, even a truncated hash in both directions. In most cases, I suspect that 8 bits would be plenty, though I imagine that clients will want to send a few more than that just to reduce the odds of having to receive a certificate. --Martin On 10 September 2015 at 04:14, Hannes Tschofenig wrote: > Hi Martin, > > thanks for your feedback. I have discussed the topic with my co-worker > Manuel. > > Another way of seeing the use of the hash by the client is to help the > server to select the pick certificate (or other cached data). It does > not have a security purpose as such, it is only a way to prevent the > server accidentally including the wrong information. For example, this > can happen when the server has multiple certificates to choose from then > it should pick the right one (and I am not talking about the SNI case > here). > > Without the possibility for picking the wrong value we could have as > well omitted the hash altogether. The actual function used to compete > the fingerprint isn't that important as long as it helps to make sure > that the correct value can be chosen with a reasonable probably. In the > worst case, the wrong value is chosen and the exchange failed. The > client will then have to re-start the exchange without the cached info > feature. > > As such, you are certainly right that the hash does not need to be long > since the changes of selecting the wrong information is very low. In > case of the certificate the security actually comes from the private > key: the server needs to demonstrate that it knows the privacy key in > the exchange. > > Regarding the use of the TLS PRF I am not sure that this will work since > the actual function is the result of the negotiated cipher and not known > at the time when the client and the server exchange their hello messages. > > Ciao > Hannes > > PS: Additing extra text with information about what is included in the > hash will be added to make sure that implementers compute the hash over > the correct fields of the message. > > > On 08/24/2015 08:35 PM, Martin Thomson wrote: >> 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 d
Re: [TLS] Should we require implementations to send alerts?
On 12 September 2015 at 13:49, Eric Rescorla wrote: > "Nobody must ever be required to send an alert. Any requirement for sending > an alert should be SHOULD, at most." This was a point of debate for HTTP/2 as well. The conclusion there was that you had to be prepared to have the connection disappear without warning for various reasons, so requiring that an error be sent was silly. After all, what are you going to do when the connection drops without a GOAWAY? Drop the connection? That only applies to fatal alerts of course, but I don't see a lot of use of the warning level, in fact, they might be a bad thing to support (but that's a separate subject). My suggestion is that we require that endpoints treat certain errors as fatal and maybe suggest a particular alert. However, also note that they MAY drop the connection without sending the alert OR that even if they do send the alert, it might get lost. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
This seems like the right set of options... On 12 September 2015 at 14:26, Eric Rescorla wrote: > 1. Require termination and say nothing else I think the mere existence of alerts suggests that this isn't really a good option. > 2. Require termination and suggest an alert. > 3. Require termination and say that if you send an alert it must be X. I think that the distinction between these relies on the suggestion that we think that lying about causes would be desirable in some cases. I think that the latter would be better. > 4. Require termination and say that you must send alert X. As Geoff indicates, maybe this makes sense in cases where the information the alert carries is especially valuable. I can accept that argument. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On 15 September 2015 at 15:03, Andrei Popov wrote: >> That is, how does the server identify whether this is unilateral or in >> response to its own request? > > The model I'm thinking of is where the server receives a request from the > client, determines that the request requires authentication, then queries > session state to see whether a suitable client credential is available. > If such client credential is not available, the server sends > CertificateRequest. In this model, it does not matter whether the client > volunteered a credential or responded to the server's request. I'm concerned that this produces an indeterminate state on the server. Say that the server receives a Certificate after it sends CertificateRequest. What if that Certificate doesn't conform to the request in some way: was the Certificate just a unilateral offer that was sent before the client received the CertificateRequest, is the client unable to understand the CertificateRequest, or is the client in error? Depending on which of these is really the case, the server is unable to decide whether it should continue awaiting a Certificate or not. It's not a huge issue, but I'd be happier if we nailed this sort of thing down. >> How does a client determine if the NewSessionTicket that it receives >> includes its authentication? That is, how can a client know whether a >> resumed session will need a certificate or not? (I'm not sure about this >> one, but the first thought that occurs is that the server could include an >> indicator in the NewSessionTicket message.) > > I'd say the client should send the latest ticket it has, assume that it has > all session context including client identity, and the server will request > creds if this is not the case. That doesn't work for clients that send credentials without prompting. >> What value do you see in having a spontaneous NewSessionTicket messages? Is >> this just a case of not wanting to bind it more formally to something that >> the client sends? > > The reason I want to allow NewSessionTicket messages in mid-stream is to > allow the server to include newly obtained client creds in the session state. > If the server wants to do this, it can send NewSessionTicket after processing > the client's CertificateVerify. Would you be OK with saying that NewSessionTicket can only be sent in response to CertificateVerify or Finished? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
On 15 September 2015 at 20:12, Karthikeyan Bhargavan wrote: > I assume the client hello extension still has the certificate digest, yes? > This means that the analysis probably relied on agreement of the certificate > hash from the client hello. This was only in the 1.3 context, and the certificate digest was completely removed from the handshake... It was pointed out to me separately that this doesn't work for static RSA because you need to include the public key in the transcript there to avoid having an attacker impose a PMS (one of the components of triple-handshake). That means that we need a strong hash for that case. However, if this is only used for PFS modes, then the analysis suggests that we are OK to remove or truncate, assuming session-hash. > For example, is it possible for a website to use the same public key on two > certificates for two different purposes? Is it possible for an attacker to > obtain a certificate from a CA for a public key even though it does not know > the corresponding private key? Does any of the existing analyses of TLS permit these changes? If the same key is used for two different purposes, then the risk of reaching a state where the purposes are confused seems to be too easy. Similarly, if I can obtain a certificate for a key without demonstrating proof of possession, then we're in a bad state. I would hope that the ACME protocol does not permit that, certainly this is a fundamental part of the certificate signing request. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 16 September 2015 at 08:02, Peter Gutmann wrote: >>HTTP-2 did this kind of thing, and IIRC are the first to do so. > > Some PKI standards have done it too, but mostly because the base standard was > such a mess that you needed a profile just to sort out what needed to be > implemented for anything to work (for some level of "work"). They're such a > design counterexample that I didn't want to mention them in my original > message :-). Yes. I wouldn't recommend following this path to others; it's not easy and the return on that investment isn't all good. The mess we were attempting to clean up with HTTP/2 was the state of TLS deployment on the web, not so much the spec itself. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Sep 21, 2015 7:02 AM, "Ilari Liusvaara" wrote: > Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If > one additionally assumes causality, dynamic reauth in non-pipelined > HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with > pipelining) is still unsafe. What do you mean when you say "safe" and "unsafe" here? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 4 October 2015 at 21:06, Eric Rescorla wrote: > > Yes, if the attacker can provide their own data, it makes matters worse, > but as the reference I provided indicated, there are potential security > issues even if the attacker is not able to do so, provided that the data > is sufficiently redundant. Sometimes, it's OK. Sometimes, not. Agreed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On 16 October 2015 at 12:22, Brian Smith wrote: > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there > something specific about TLS 1.3 that makes the downgrade worse? Given that we can't expect TLS 1.2 servers to implement the hack, I'm not sure that this is of great utility, but if we can bake a version number in there, I'm not opposed to the notion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On 16 October 2015 at 13:39, Brian Smith wrote: > That would be especially true for an implementation that does False Start > for TLS 1.2. I don't see how false start plays into this. We could have clients reject false start if they see this sentinel value. But don't we want to just treat this as an attack and abort instead? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On 17 October 2015 at 12:03, Eric Rescorla wrote: >> Just a single >> fixed patter signalling ">= 1.3" would then suffice. > > > If you wanted to cover 1.2 -> 1.1, then you would want this. The observation is still valuable in the sense that prohibiting values > 1.3 would reduce the likelihood of a false positive by some miniscule amount. In other words, I agree with ekr here, though we could cap the value to 1.3. Maybe we could just define two values: one for TLS 1.3 (and greater, presumably) and one for TLS 1.2. I don't see any value in protecting 1.1 or 1.0 from downgrade any more given relative prevalence of those protocols and their age. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On 19 October 2015 at 08:08, Eric Rescorla wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n} chance of collision.
Yes, this is right. The marginal gain is that the proportion of
servers that generate a time here are immune to collisions. If
servers all servers did that, we wouldn't have to worry about
collisions at all. Unfortunately, we do know that some generate random
values.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Version in record MAC
On 19 October 2015 at 09:28, Eric Rescorla wrote: > 1. Don't MAC the version at all. > 2. MAC the negotiated version (which should be clear at > this point). 3. Nothing The version is implicit in the key derivation (yeah, there are lots of rounds of HMAC between, but it's there. The sequence number is fed into the nonce. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Version in record MAC
On 19 October 2015 at 11:12, Eric Rescorla wrote: > > > On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson > wrote: >> >> On 19 October 2015 at 09:28, Eric Rescorla wrote: >> > 1. Don't MAC the version at all. >> > 2. MAC the negotiated version (which should be clear at >> > this point). >> >> >> 3. Nothing >> >> The version is implicit in the key derivation (yeah, there are lots of >> rounds of HMAC between, but it's there. >> >> The sequence number is fed into the nonce. > > > How is this different from #1? #1 implies the sequence number is covered by the MAC. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Version in record MAC
On 19 October 2015 at 11:17, Eric Rescorla wrote: > Yeah, I think that's riding the nonce far too hard. On what basis? Any change in the nonce will cause the record decryption to fail. That's the property we're looking for here, isn't it? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Offline configurations
This is an exploration of what it might take to bootstrap 0RTT without a prior TLS connection. https://tools.ietf.org/html/draft-thomson-tls-offline-config-00 There are two important lessons I've learned from this: 1. authentication is important (and hard to get right) 2. TLS implicitly includes a bunch of stuff in the server configuration, these are explicitly manifest here as extensions to the server configuration On this latter point, I believe that this identifies the additional state that needs to be considered as part of a server configuration by clients. These are implicitly included in the regular 0RTT setup and don't get entered into the 0RTT handshake hash. I don't think that's a problem, but it might be worth thinking about some. For instance, if a CertificateRequest alters how the client behaves for a second connection, should that be covered by the handshake hash for that connection? Similar concerns might apply to cipher suite selection and supported groups. For an offline configuration, the entire configuration is included both under a signature and as part of the handshake transcript for the new connection. That means that the certificate is covered twice. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Controlling use of SHA-1
The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass indefinitely. Since we expressly forbid the use of SHA-1 for signing in TLS itself, we can just permit clients to include it in "signature_algorithms" and use that to determine whether SHA-1 is acceptable. That means that clients that want to disable SHA-1 (real soon now, we promise), can signal that preference cleanly. I've opened PR #317 for this, but the commit is probably more useful to review, since I built this on top of ekr's client authentication changes (to avoid messy rebases): https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HelloRetryRequest and stateless reject
On 21 October 2015 at 12:29, Ilari Liusvaara wrote: > Bit crazy idea: Have vector of causes handshake went wrong > (e.g. required share missing, cookie required). Then the > client verifies that that: > - There is at least one cause > - All causes are known (can't retry with unknown error) > - All causes are proper (e.g. actual missing share). The client doesn't need this information, though the server might. That is, if it doesn't want to try several options to see which one passes the MAC, noting that there aren't that many options. Given that, I don't think we need to specify anything. Note that absence of cookie is the only valid starting state, so you don't need a bit for that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On 21 October 2015 at 12:56, Viktor Dukhovni wrote: > Each peer MUST try to send a chain that matches an advertised > signature algorithm if it has a choice of chains, but otherwise > MUST send whatever it has. Do, or do not. There is no try. It's not like any of this is ambiguous in any way. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
On 21 October 2015 at 13:43, wrote: > RFC 7685 > > Title: A Transport Layer Security (TLS) > ClientHello Padding Extension That took longer than I expected. Nice work. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Remove extra 0-RTT content types
I'm not sure that I follow. Are all the records in 0RTT going to use a content of handshake, or just the Certificate/CertificateVerify/Finished? I assume that you meant just the handshake messages, in which case yes, this is OK. It does make identification of what goes into the handshake hash marginally more difficult. With your client authentication changes, you could just concatenate up everything with content type of handshake. Now you have to be a little more selective. On 21 October 2015 at 15:44, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/311 > > I initially added this to make it easier to determine the end of the 0-RTT > handshake if the server had forgotten the key, but with content type > encryption > this is no longer relevant. I propose we remove this and simply use > Handshake here, allowing the keying material to differentiate these. > > -Ekr > > > ___ > 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] Remove extra 0-RTT content types
On 21 October 2015 at 15:52, Eric Rescorla wrote: > I don't think this will make the implementation that hard :) Yeah, you have to actually pay attention to the early_data extension. That might not be a bad thing in the end. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Allow NamedGroups from the server?
2b. encrypted extensions over ServerHello If we make this like signature_algorithms, then I think that I prefer option 1. I don't like that signature_algorithms is built that way, I think that it's repulsive, but there are some advantages to doing it that way, especially if we accept the fact that the client can authenticate multiple times, so I'm willing to live with that. On 21 October 2015 at 16:56, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/292 > > Presently, RFC 4492 only specifies the EC points it can support in > ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, this means that there's > no way for the server to indicate what groups it would support. > > That seems less than ideal. There seem like three options here: > > 1. Put it in CertificateRequest > 2. Send it in ServerHello > 3. Do nothing. > > Thoughts? > -Ekr > > > > ___ > 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] Controlling use of SHA-1
On 22 October 2015 at 09:19, Benjamin Kaduk wrote: > > % a certificate that specifies a trust anchor MAY be omitted from the chain > > The client cannot decide that the signature on the root cert the server > sent is bad, if the server does not send the root cert. Yes, that was my thinking. I expect that if a certificate is sent, then it might have to be checked. As opposed to the roots, which are rarely sent or checked. Maybe it would help if Victor could describe the situation in which he thinks that it would be appropriate to send a certificate that is signed by MD5. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Allow NamedGroups from the server?
On 22 October 2015 at 10:11, Andrei Popov wrote: > Then my argument would be: why send extra bytes in each ServerHello when TLS > client auth is not used most of the time? In this case, CertificateRequest > seems to be a better place. I think that this is the best argument for CertificateRequest. We can prohibit the inclusion of the extension in ServerHello (or Server EncryptedExtensions) as we please then. I would argue for prohibiting it, since it has no purpose. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On 22 October 2015 at 11:17, Watson Ladd wrote: > Ideally, yes. Applications never cared about what was happening, but wanted > a "secure this channel" magic call. I think that this is conditionally true. If you are using TLS 1.2 with reasonably modern practices, then getting TLS 1.3 should be easy. However, if you are relying on MD5 working, or limiting cipher suites to RC4, then expect some pain. For NSS, we probably won't turn TLS 1.3 on by default straight away, but once it is stable, I expect that we will. Applications that use the defaults will get 1.3 at that point and not have to worry about breakage. Of course, we will be careful not to use 1.3 if things aren't configured correctly (PFS disabled = no 1.3, etc...) This might not be easy to perfect, but I believe that this is a goal that is worth the extra effort. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: [pkix] Updated elliptic curve drafts
It's not entirely clear what you are asking for here, but have you looked at the key derivation in TLS 1.3? On 16 October 2015 at 01:27, Phillip Hallam-Baker wrote: > > I strongly oppose any new crypto that does not include a fix for the > ephemeral keygen. > > The reason logjam is possible is that the key negotiation is essentially > > 1) Negotiate a shared secret S1 using the strong, long term server key. > 2) Use the shared secret to authenticate ephemeral key parameters Ec, Es > 3) Derive the session keys S2 from the ephemeral key parameters only > and throw away the output from the strong long term keys. > > It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also > weak: > https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ > > If we are changing the crypto suites we can and should fix this > instead of S2 being a function of Ec, Es alone, add in the original S1 > as a salt. e.g. S2 = SHA512 (S1 + f(Ec, Es)) > > This ensures that no matter how broken the ephemeral crypto is, the > key exchange is always at least as secure as either the long term or > the ephemeral key. > > > Logjam isn't the only way that the system can be compromised. > > Oh and damn right I think BULLRUN might have had a part in keeping the > spec broken. > > > There is a right way to design an ephemeral key exchange and it is to > 'Do no harm'. Logjam shows that our current key negotiation mechanism > has a hole that makes it possible for the ephemeral to do harm. > > The move to the CFRG curves will mean a backwards incompatible change > to the deployed infrastructure so this is a perfect time to fix > ephemeral key establishment. > > I am going to keep raising this until the issue is fixed. > > > > On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson > wrote: >> Hi, >> >> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer >> to the CFRG-Curves and CFRG-EdDSA drafts. >> >> The following document adds new EdDSA key/signature OIDs directly: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 >> >> The following document adds new namedCurve OIDs, thus going indirectly >> through the existing ECDSA 3279 route: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 >> >> These two drafts take different approaches to including the new curves >> into PKIX, and currently both lack applicability statements. There is >> potential for overlap and conflict right now. It recently came up that >> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX >> Certificates, it may be that the first direct approach is preferrable. >> The former lack the possibility of encoding keys for DH. I believe each >> approach can be useful on its own, but we need to include text adressing >> use-cases that can be resolved by both documents to avoid conflicts. >> >> /Simon >> >> ___ >> pkix mailing list >> p...@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > ___ > 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] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt
On 3 November 2015 at 08:02, Brian Smith wrote: >> The major change in this version is that the nonce is constructed >> using the scheme that's currently in TLS 1.3. > > > Would it be possible to do something similar for the additional data, so > that there is no additional data in TLS 1.2, just like in TLS 1.3 for > application_data records? The construction in TLS 1.3 will have no AAD. I believe that the rationale is: seq_num is masked into the nonce TLSCompressed(sic).type is under encryption TLSCompressed.version is covered by key derivation via the handshake hash TLSCompressed.length was included in the AAD in 1.2 in error Unfortunately, I don't believe that all of the above is true for TLS 1.2. Your proposed construction covers some of these things. If you are willing to rely on session hash, you might drop the version, which leaves this with the type. We have to authenticate the content type somehow, and I like your hack for that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating tls-unique for TLS 1.3
On 4 November 2015 at 11:16, Yoav Nir wrote: > Can’t we just say that all previous uses of tis-unique will instead get an > exporter generated with the label “tis-unique” ? That was my thought here: redefine what it means to generate tls-unique. That's part of why I asked about the size. We should ensure that clients are not made sad if they receive a tls-unique that is longer than 96 bits. We could backport this to 1.2, but I'm not sure whether this is a new feature or whether it's a bug fix. If it is the former, I'm not that enthusiastic about a backport. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating tls-unique for TLS 1.3
What is wrong with getTlsUnique2() or getBetterTlsUnique() ? It's not a drop-in replacement, but it indicates that the app understands the change. Otherwise, we might have to signal this in TLS 1.2 proper. 1.3 can just be fixed. On 4 November 2015 at 15:42, Alexey Melnikov wrote: > On 04/11/2015 11:13, Eric Rescorla wrote: >> Can you expand on this a bit? Perhaps propose some text. > > So, tls-unique is defined in RFC 5929 as: > >Description: The first TLS Finished message sent (note: the Finished >struct, not the TLS record layer message containing it) in the most >recent TLS handshake of the TLS connection being bound to (note: TLS >connection, not session, so that the channel binding is specific to >each connection regardless of whether session resumption is used). >If TLS renegotiation takes place before the channel binding >operation, then the first TLS Finished message sent of the latest/ >inner-most TLS connection is used. Note that for full TLS >handshakes, the first Finished message is sent by the client, while >for abbreviated TLS handshakes (session resumption), the first >Finished message is sent by the server. > > This is currently independent of the version of TLS used. This is also > broken for TLS 1.2 due to the triple handshake vulnerability. > > I don't think we can just redefine this for TLS 1.3 and expect this to > work, because APIs for getting this information out of TLS libraries are > going to be different if Exporters are used. > Also, if "tls-unique" is redefined, an old implementation of > "tls-unique" would be unable to talk to a new implementation. For > example if one end is IMAP client using SCRAM or GS2 against IMAP server > implementing the same. > > I think there is desire to fix this for both TLS 1.2 and 1.3. I think > the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03 > (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I > think conceptually what Simon did is very similar to what was proposed > in the TLS meeting today. > > >> -Ekr >> >> >> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov >> mailto:alexey.melni...@isode.com>> wrote: >> >> Just to clarify, I think it is fine to define TLS 1.3 replacement >> for tls-unique using Exporters. But I suggest for interoperability >> this should be defined as a new channel binding with a new name, as >> opposed to just redefining tls-unique. > > ___ > 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
[TLS] SHA-1 patch updated with Russ' suggestion
Nitpicks accepted, pull requests preferred: https://github.com/tlswg/tls13-spec/pull/317 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Review of https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00
This is good. I have an editorial comment: can someone please go through and reconcile all the use of bits and bytes throughout. It actually seems like someone did a coin flip on every occurrence to decide which one to use. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On 5 November 2015 at 15:53, Dave Garrett wrote: > "Trusted self-signatures SHOULD be validated before adding to a trust store > and SHOULD NOT be re-checked at runtime." But we're getting slightly out of > scope here, which is why I'm thinking that elaborating on this topic exactly > as suggested is not needed in the document. A trust anchor is a container for a public key and maybe some ancillary information. You don't actually need to check the signature because the process by which you determine that the information is correct doesn't depend on the signature. For example, the certificates that are in the Mozilla trust store all rely on the fact that you downloaded a valid version of Firefox and the mechanisms by which we safeguard that process. The signatures on trust anchors could be garbage and everything would still be fine. The intent of the change is to point this out. I'll rebase it and maybe add the pointer Russ provided, then we can double check that it's right. Right now, it's all dependent on other PRs and hard to follow. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#346: Individual traffic key generation
I have to ask why the continued insistence on calling the thing that forms part of the nonce an "IV". I find it to be misleading. Also, it might be worth noting that the string "early data key expansion, server write " is never needed. On 16 November 2015 at 17:25, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/346 > > As discussed in Seattle and Yokohama, I've broken out the traffic key > generation > into individual values. This makes life somewhat easier for those dealing > the > cryptographic modules, because some of this data needs to be public and some > of it needs to be secret. > > This general change already had consensus, so I plan to merge it on > Wednesday > modulo major objections. Please advise here or on Github if you find any > errors > or you violently object. > > -Ekr > > > > ___ > 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] PR#346: Individual traffic key generation
On 16 November 2015 at 19:52, Eric Rescorla wrote: >> I have to ask why the continued insistence on calling the thing that >> forms part of the nonce an "IV". I find it to be misleading. > > > This is the historical terminology that TLS has used. It was actually accurate when we were using CBC modes, but now it's just confusing. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Issue #348: 32bit timestamp in ServerConfiguration
>From the issue: <<< As far as I can see, the only timestamp used is expiration_date in the ServerConfiguration (apart from X.509 validity checks which require synchronised clocks). This is defined as seconds since UNIX epoch, and will overflow sooner than later. Maybe either use a relative amount of seconds here, or expand to a 64bit value!? I suggest to use 32bit network byte order (same as ticket_lifetime_hint), which value are the seconds how long this configuration is valid, and thus may be cached for at most this amount of seconds. >>> I don't want to see this change to a relative time. That will mess with our ability to create ServerConfiguration objects that live outside of the handshake. I have no real objection to expanding this to 64bit though. (I'm personally OK with stating that this is modulo 2^32, but recognize how that might result in problems.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration
On 23 November 2015 at 10:56, Ilari Liusvaara wrote: > I got the idea of using 32-bit sequence number arithmetic there too > (window is -2G to 2G seconds around current time). I don't suppose > any key will need to have TTL of over ~68 years... I did too, but decoded that 2^64 is just easier. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On 23 November 2015 at 12:56, Yoav Nir wrote: > It’s been suggested that as long as the CFRG signature curves document is not > finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything > in any draft is subject to change up to the time it’s published [...] In your opinion, do you see the semantics of the codepoints changing in any meaningful way? It's one thing to say "accept the risks", but if anyone thinks that there are necessary changes forthcoming, that would give me pause. If everyone says that it's highly unlikely, I'm supportive of the notion that we get a codepoint. Are we happy that we will only be needing the PureEdDSA variants and that no-one will be asking for the HashEdDSA versions? I ask because I've heard it suggested (I think Karthik mentioned this) that we might want to sign the transcript directly in TLS 1.3 rather than rely on collision-resistance of the selected hash function. That would be harder without access to HashEdDSA. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On 23 November 2015 at 14:08, Ilari Liusvaara wrote: > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > plus I consider interfaces that let one use this dangerous (IUF > signing is dangerous!). That suggests that the construction of CertificateVerify is dangerous in the same way, doesn't it? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3
On 26 November 2015 at 18:38, Xuelei Fan wrote: > What's the consideration to place selected_group out of the extensions filed > in HelloRetryRequest? An extension would work, except that I believe that extensions in HelloRetryRequest are going to carry somewhat different semantics to those in other Hello messages. If we go to dynamically generated groups, then we can easily define a new FFDHE code point to signal the use of a dynamic group. Though I think that I'd be sad about having to always spend an extra round trip if it came to that. Also, it's not much, but the explicit field keeps the message (a tiny bit) smaller and easier to process. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
On 1 December 2015 at 08:22, Bryan A Ford wrote: > The 2-byte length field in each record's header no longer indicates > the length of the *current* record but instead indicates the length of > the *next* record. Ensuring that you know the length of the *next* record is difficult and could dramatically degrade latency, or adding extra bogus padding or extra bogus records. For instance, I can always send in bursts of two packets, a one octet packet that promises the remainder of the burst and one that promises a single octet packet. At that point, I get to do what I've always done and you have gained little other than an increase in packet size of around 19 octets (best case). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
There are a lot of inaccuracies in that presentation, so I wouldn't pin too much on it. In any case, before we all get too excited about this, there are some solutions, I've seen a write-up of one of them, but it was a little hard to follow first time around. Some of the things that are described as impossible aren't that hard to fix. On the flip site, it doesn't provide a fully general solution. Expect to see something very soon. Until then, I don't think that an in-depth on what isn't even at a straw-man level of detail is that helpful. We need details before we can say whether the cost-benefit makes sense. On 3 December 2015 at 14:38, Jacob Appelbaum wrote: > On 12/2/15, Dave Garrett wrote: >> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >>> Encrypted SNI doesn't give you the kind of protection you think that it >>> does. We (me and a colleague) did a pretty thorough analysis that showed >>> this. It was not a conclusion we expected, or wanted, to reach. It was >>> presented at the TLS Interim before the IETF in Toronto. Slides should be >>> online. (For example, the adversary will know the IP address or might not >>> care about false positives, etc.) >> >> URL from Rich's previous email citing this: >> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view >> > > I've read these slides. I'm... at a bit of a loss. The entire slide > deck seems so flippant as to be not worth addressing. It just doesn't > even pass the giggle test. > > Though upon reading it, I am struck by two core points: > > One is that big companies will be pressured by governments. > Ironically, Akamai isn't one of those as they're willingly in bed with > governments around the world. But I guess as the slides say, the > author isn't speaking on behalf of Akamai. That said - good, I want > governments to have to go to a company rather than to the user - the > company may have a legal team, the user may have hidden or otherwise > protected themselves. Hopefully the company is in a position to do > nothing or will take action to protect the user's basic liberties. > > The second is a constant security nihilism. Yeah, a lot of stuff is > broken - so lets acknowledge it bit by bit and then fix it all. > > I would encourage everyone to read the slides as the conclusion in the > presentation simply do not follow. If I had been in the audience when > they were presented, I would have been at the microphone objecting. > The idea that this convinced anyone is baffling. > > It is clear that privacy concerns exist in many many different > protocols and that many protocols need to be fixed. Many people point > at other protocols as a way to punt on the issue for their own > protocol. The cycle continues and the privacy violations continue > without end. > >> Please don't brush this argument off in favor of the "obvious" answer that >> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a >> lot of risk for virtually no gain. I was quite in favor of encrypted SNI >> before reading it, and I had to concede the point after. If we can come up >> with a way to do it easily, ok, but it's not an avenue worth spending too >> much time on. >> > > The idea of splitting the world, as the slides do, into three basic > camps (liberal democracy with good traffic analysis, liberal democracy > with bad traffic analysis and horrible dangerous places) is simply not > serious. The idea that our liberal democracies do perfect traffic > analysis and so we should ensure *everyone* including *non-NSA* > attackers can do it for *free* is just bizarre to me. It is incorrect > as a conclusion to do nothing because some people somewhere *may* be > good at traffic analysis. The logic of the slides suggest that raising > the cost from a kid-in-a-cafe to NSA is proof that we shouldn't > bother. Again, the security nihilism monster appears. We should reject > this nihilism and fix the problem. > > Encrypted SNI makes sense as it makes traffic analysis harder. > Encrypting DNS queries makes sense too. Composing it with other > systems may or may not make sense. Even when TLS is composed with a > tool to do traffic analysis resistance, the exit node of the > TA-resistance network can still do selective attacks based on SNI. In > that case the DNS is likely to be resolved at a different exit point. > Thus if we want to punt again and say, hey, traffic analysis > resistance is better left to Tor or something else, please consider > that plaintext selectors make Tor's job harder. > > These changes make it more expensive and in some cases, it will stop > attackers who would otherwise be able to make an attack happen > undetected. It requires an attacker to spend more money on CPU, memory > and on other resources to do correlation across multiple collection > points. > > Kicking the can down the road doesn't even begin to summarize why > leaving SNI unencrypted is incorrect. Metadata is a serious problem > and reducing
Re: [TLS] [Editorial Errata Reported] RFC7568 (4561)
On 8 December 2015 at 14:49, RFC Errata System wrote: > TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, > TLS 1.2 was drafted in 2006, but not published until 2008. The date on the documents are indeed wrong. I recommend holding for document update. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 and OCSP stapling
I think that the best way to deal with the status_request_v2 extension is to make it a proper part of the TLS 1.3 messages, probably Certificate or CertificateVerify. This is a fairly heavily important extension. On 12 December 2015 at 05:52, Ilari Liusvaara wrote: > When looking at stuff some more, I noticed that extension > status_request_v2, which is used by OCSP stapling and is not deprecated > [1]. > > Now, that extension uses additional handshake message type > (certificate_status), which is specified to go between Certificate > and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is > server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ > Finished are supposed to form a block? Where it is supposed to go? > > Then there are other supported extensions that add messages. > Specifically the following messages: > > - certificate_url: This can replace client certificate, whic is > straightforward (if causing security issues by its sheer nature). > - supplemental_data: There's ladder diagrams placing this just > before Certificate. Where should this go in TLS 1.3 (there are > undeprecated extensions that would use it)? > > > [1] Unlike status_request, which is listed as deprecated. Was > that intentional or mistake (if intentional, cert_type would also be a > good to deprecate as superceded). > > > -Ilari > > ___ > 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] Data volume limits
On 16 December 2015 at 08:14, Eric Rescorla wrote: > > I wanted to get people's opinions on whether that's actually what we want > or whether we should (as is my instinct) allow people to use ChaCha > for longer periods. Whatever the actual limits are, I think that implementatios should be encouraged to rekey more strongly. If 2^36 is the number, then I can see that being reached in some applications. That means that we need the rekey feature to exist. If we are going to have that feature, then we need to make sure that it works. And suggesting a stupidly high limit (e.g., ChaCha being greater than 2^96) leaves people thinking that they can skip implementation and testing of the rekey facility; or it just goes unused. If it's not in use, then we'll have a good chance of creating a protocol feature we can't rely on if it really is needed. In light of that, the actual limits don't matter that much to me. As David McGrew suggested, set a limit at 2^32 and avoid having to think too hard about how close to the failure point you might be. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 16 December 2015 at 14:01, Brian Smith wrote: > Martin Thomson wrote: > Why? If there were a stupidly high limit, then I would argue for no rekeying facility. But the numbers Watson ran suggested that GCM starts to look shaky at 2^36. That's too low for some applications. For the rest of the argument I suggest you reread my last mail. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 16 December 2015 at 14:57, Dave Garrett wrote: > In fact, if we're OK with setting this rather low threshold, then we could > even get rid of the rekey signal entirely and just have an automatic rekey > after every 4GiB for all ciphers. That'd be one less complexity to deal with. > Rekeys would be routine. I don't like automatic rekey (though I almost like the per-record rekeying that I think was semi-facetiously suggested by someone). An explicit rekey allows for two things: - testing - reducing the limit if we find that the cipher is more busted than we originally thought (with respect to key overuse) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 16 December 2015 at 15:08, Dave Garrett wrote: > We could just make the threshold a configurable parameter, with > default/maximum at 2^32 bytes. Each endpoint could just provide its threshold > in a new extension. Both get to specify what they want and it could be > lowered arbitrarily for testing or panic fix. That sounds more complex than the current option. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)
So the actual impact here is that an attacker who has compromised a key can introduce a gap. Aren't there other options available to such an attacker? Scarier options? On 18 December 2015 at 07:01, Cedric Fournet wrote: > > We propose to revert this change (that is, to reset the sequence > number each time a new key is installed, as in TLS 1.2). If the > chaining is still required for some other reason, one could instead > include the old sequence number in the new key derivation (or the new > key's additional data, but we believe this is no longer an option). Even with my question above, this seems reasonable to me. I'll note that chaining in the way you describe would require that the rekey message (the last message of the previous epoch) would need to be retransmitted in DTLS. That seems more brittle, but we probably want to retransmit anyway, since that would let use remove the explicit epoch from DTLS packets. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
On 22 December 2015 at 13:25, Christian Huitema wrote: >> Unless I'm confused (which is possible given the time of night), >> the intention, as you say, is to separate out the 0-RTT handshake >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations. > > OK. That does not simplify implementations using running hashes... It does if you consider the possibility of having to drop the 0-RTT data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 23 December 2015 at 08:51, Watson Ladd wrote: > Textbook DH does not ensure contributory behavior. Applications don't > implement the required checks for poorly designed protocols. If we insert > checks, applications which fail to make those checks will be vulnerable, > while fixing protocols closes the hole. I've done a fair bit of reading into this issue as well, finding Thai's blog posting and a few other things. As Watson says, the protocol can be designed so that it doesn't depend on the DH exchange providing contributory behaviour. We should definitely do that either way. I understand that the checks are considered onerous by some, but I still don't understand why anyone might refuse to do them. Checking that you don't get a bad output from the DH computation is a tiny piece of code that takes almost no time at all, even if you have to worry about doing it in constant time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 23 December 2015 at 10:23, Brian Smith wrote: > It may be the case that TLS requires contributory behavior and point > validation is still unnecessary. Or, it may be the case that TLS doesn't > really require contributory behavior (though, it seems obvious to me that it > does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS > requires contributory behavior and a check is necessary. The draft should > make it clear which case we are dealing with, with a reference to the > reasoning that gave us whatever conclusion is reached, but currently that is > missing. My understanding is that with session hash TLS 1.2 is OK, as is 1.3. Like Watson and Thai, I think that 1.2 without session hash is not OK. That suggests that the 25519 draft should require session hash in 1.2. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 23 December 2015 at 11:09, Brian Smith wrote: > If an implementation only implements ECDHE cipher suites then implementing > the session hash extension is not necessary, according to RFC 7627. I It doesn't really say that as far as I can see, though I guess that you could infer that from this statement: Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 30 December 2015 at 22:16, Ilari Liusvaara wrote: >> Would it make sense to have session hash as a requirement in TLS >> 1.2 when you want to use Curve25519? > > I don't think that is reasonable. I think that is entirely reasonable. TLS 1.2 relies on contributory behaviour. 25519 doesn't provide that unless you do some extra checking that we know many implementations don't do. I'd be OK with either requiring session hash, some checking of values, or both. Otherwise we create a situation where the shared secret can be forced by an attacker. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 31 December 2015 at 17:54, Ilari Liusvaara wrote: > Zero checks can already be unit-tested/interop-tested just as well. What ekr said applies, but also this: Yes, you can test that a given implementation does the right checks, but you won't be checking during normal operation. If you require session-hash, then every handshake includes that check and if someone messes up, the handshake just fails. That far more visible. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On 5 January 2016 at 05:03, Eric Rescorla wrote: > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing > > "Following that padding is a context string used to disambiguate signatures > for different purposes. > The context string will be specified whenever a digitally-signed element is > used. A single 0 byte is > appended to the context to act as a separator." You call this NUL in the following paragraph, without context. This might need to be tied together better. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
On 12 January 2016 at 05:30, Kurt Roeckx wrote: > After the SLOTH paper, we should think about starting to deprecate > TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS > 1.2. Let's be clear about this: TLS 1.0 represents far too high a proportion of our usage to remove it at this point. TLS 1.2 growth is still solid, but it really isn't that long ago that we turned on TLS 1.2. The encouragement we give people to upgrade will remain our best option until TLS 1.0 usage drops an awful lot. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 0-RTT, server Application Data, and client Finished
This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402 My understanding is that the server is able to send any data that does not depend on client authentication at t=0.5 and any data that depends on client authentication at either t=0.5 if it successfully consumes the client authentication in the 0-RTT flight, or t=1.5 failing that. On 27 January 2016 at 11:46, David Benjamin wrote: > It's possible I'm reading the draft wrong, so this thread may be a very > short one. > > (t here is in units of RTT, so t=0 is when the client sends ClientHello and > t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is > when the client receives ServerHello, etc.) > > Looking at the Zero-RTT exchange here: > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 > > Is the intention that the client, even in the successful 0-RTT case, send > two Finished messages (one at t=0 and one at t=1) and that the server not > send application data until receiving the second of these at t=1.5? If so, > does this not defeat the purpose of 0-RTT? Although the client now eagerly > sends at t=0, it will not see the response until t=2, which is no better > than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send > until t=1. > > David > > ___ > 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] 0-RTT, server Application Data, and client Finished
On 27 January 2016 at 12:58, David Benjamin wrote: > If the server needs to send a CertificateRequest (i.e. the client > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a > 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but > useless because the first authenticated byte of the response is delayed to > t=1.5. We should just say that 0-RTT accept + CertificateRequest is > forbidden. I believe that is a choice that an implementation could make, rather than have a stipulation in a spec. You are free to simplify in your implementation as much as you like. Refusing 0-RTT and delaying the "completion" of a handshake if you find that you need to send a CertificateRequest (either because you don't have 0-RTT client auth or the 0-RTT client auth is bad/indecipherable) is a pretty good choice. I might even be happy to recommend it to others. But do you have a security property you are looking to preserve? Because otherwise, I think that I might take the optimization. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Backwards-compatibility of 0-RTT data
On 27 January 2016 at 13:11, Eric Rescorla wrote: > Well, I think we're generally encouraging people to have to explicitly > enable 0-RTT. I think that the key point was that you would have to explicitly enable 0-RTT AND that also meant a commitment not to choke on 0-RTT data for at least as long as your 0-RTT configurations were valid. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
