Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Mon, Jul 13, 2015 at 9:28 AM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote: > > Dave Garrett wrote: > > > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: > > >> Section 7.4.1.4 Hello Extensions and its subsections are clearly > > >> IRRELEVANT for a client that does not use Hello Extensions. > > > > > > If you want to put it that way, sure, however they are NOT irrelevant > > > for a _server_ that does use hello extensions. This is a direct part > > > of the TLS 1.2 spec, > > > > That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible > with > > rfc2119 section 6. As it can be easily verified, the behaviour > > described in rfc5246 is detrimental to interoperability and security. > > I don't see such conflict (except with TLS 1.0/1.1 client with TLS 1.2 > server). The scenarios where that sort of behaviour would cause actual > interop trouble (meaning it could have worked otherwise, assuming non- > buggy client/server) are: > > - TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2 > server. Or > Hmm... TLS 1.2 servers shouldn't be following this section if the client is claiming to be TLS 1.0 or 1.1. I don't think that this section says that you should (since in that case the TLS 1.1 or TLS 1.0 spec would control) but in any case, it shouldn't say that and I never interpreted it that way. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
We absolutely should have harmony between 1.3 and 4492bis. Since Uri objected, i'll let the chairs decide if/when we have consensus. -Ekr On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir wrote: > > > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche < > benjamin.beurdou...@inria.fr> wrote: > > > > Hey, > > > > Except if someone has a real need for it, > > I would favour removing p571 and keep secp521r1 as the maximum … > > +1 > > It should be noted that I have removed it from RFC4492bis. In terms of > real-world use secp256r1>>secp384r1>>secp521r1 and everything else is lost > in the noise. > > At any rate, if the group decides to keep it, I might as well bring it > back to 4492bis as well. > > Yoav > > ___ > 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] sect571r1
I don't feel really strongly about this, but I'd prefer to keep P-521. I suggest we remove sect571tr1 now and then we can debate P-521 later. -Ekr On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > >> I agree, except that I think we should get rid of P-521 too. >> > > I'd be fine with that > > -- > Tony Arcieri > > ___ > 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] Let's review: draft-ietf-tls-tls13-07 (abridged)
Ilari, Thanks for your detailed comments. > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. This was updated in a recent PR by Dave Garrett. > > 1. (Introduction) > > DSA should be replaced by ECDSA (DSA is pretty much obsolete)? Yes, I can do that. I'm happy to remove DSA entirely if the chairs declare consensus on this. > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It's just a changelog. I'll eventually make it a real list in the final version. > > 4.9.1. (Digital Signing) > > I think someone wanted randoms back here in order to support privilege > separation (which I think is important to support, I consider it much > more important than being "HSM friendly")? I think it was Nikos. Nikos, if you'd like to submit a PR that we can discuss, that would be great. > Reading what current draft of 4492-bis says, the hash function used is > determined by signature_algorithms (or presumably the corresponding > mechanism in CertificateRequest for client certs). Well, it's negotiated by that, but indicated in the message. > Also, to my knowledge, there is no mechanism to indicate in ECDSA > certificate what hash algorithms are allowed. I am also unaware of one. > > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) > > The example looks like it belongs to section 4.9.1, as it is about > signatures, not AEAD construct. > Oops. Yeah, I'll fix that. > > 5. (The TLS Record Protocol) > > Documenting the security properties of TLS would be useful... Agreed. I intend to rewrite the entire security analysis soon. > The lack of record length hiding may be problematic in protocols that > have no place for cover traffic (e.g. can DNS requests contain padding, > DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > > > 5.2.1. (Fragmentation) > > Zero-length fragments of application data are very much visible in > ciphertext (unless record padding is added), so those are not currently > useful as traffic analysis countermeasure. Agreed. We have PRs for adding padding, but they haven't been merged yet because I wanted to get key management squared away. See: https://github.com/tlswg/tls13-spec/pull/147 > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). Yes. As you can see there is an open issue marker here. If you wanted to submit a PR, that would be great. > > 6. (The TLS Handshaking Protocols) > > Are encryption keys, finished value (tls-unique) and exporter secret > part of session or not? I'm planning to remove/rewrite this entire section, as I don't think it's useful. > > 6.1.1. (Closure Alerts) > > The semantics of closure alerts seem incompatible with half-closes, > which some protocols actually use. True, but this has been in TLS since the beginning, so there presumably should not be any TLS-using apps which depend on it. Do you think this is a feature which we should add. > > 6.1.2. (Error Alerts) > > Could use another example of warning alert, now that no_renegotiation > is not a warning anymore? Will see what I can find. > > 6.2.1. (Incorrect DHE Share) > > EncryptedExtensions is marked optional in Figure 2, but not Figure 1? It's not optional. I just got confused. Thanks. > The relationship between session hash and handshake restarts seems > like a hairy problem. > > Also, I figured out a downgrade attack that works against careless > _server_ (not requiring client to do anything else than have weak > crypto enabled). Continuing hashes looks to block that attack. > > It involves attacker sending ClientHello with arbitrary parameters > that triggers a retry (very easy to trigger a retry), eating the > reply, followed by sending client's original ClientHello. That > could trigger crypto downgrade in some badly made servers. Do you think you could walk through this in more detail? I'm having trouble understanding the issue. > > 6.2.2. (Cached Server Configuration) > > Issue #184 manifests here too. I think both accepting and provoding > configuration in the same handshake is sensible (key rollover), and > later the draft talks about exactly that case. I agree. > Also, maybe note that provoding the message does not alter the > configuration hash (even if there is no existing one) could be useful. Agreed. Will see what I can do. > > 6.2.3. (Zero-RTT Exchange) > > No EncryptedExtensions? Pilot error. > How would the server know when 0-R
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 > > The goal is to provide a simple way for either endpoint to request that > the master secret be forgotten ASAP to provide a greater assurance of > confidentiality. > > I've written up a short proposal with idea about how I'd suggest going > about this: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify > > The idea is to simply add a new "reset_notify" alert (generally a warning) > which may be sent by either endpoint as soon as record protection is > available, after which both endpoints would stop caching shared secrets > after completion of traffic key completion. This could be sent right from > the start, at the end of a connection just prior to a standard > "close_notify", or at any point in between. > > This seems like a simple route that does what is specified in issue #137 > without the creation of any new extensions or messages; just one new alert > value. > > Comments? Suggestions? Any reason this would break everything? > I don't think this is that useful or practical with the current structure of TLS 1.3. - Unless I've missed something, this is primarily an issue of PFS for the original connection, since compromise of either endpoint probably allows impersonation attacks going forward. - Because the resumption master secret is cryptographically independent of the master secret that initiated the connection, its existence in the server's database or in a ticket isn't a threat to the originating connection. - The server can opt not to allow resumption by declining to provide a NewSessionTicket message. - The client has the option of never initiating a new connection with the provided ticket (assuming that the server opts to supply one). Note also that because the ticket is encrypted with the original traffic keys, if the client never tries to resume the connection, the ticket never appears on the wire (which is relevant for self-encrypted tickets, but not so much for tickets which are database lookup keys). - Because many implementations use self-encrypted tickets, it's not practical to require them to delete keying material once it's been established. Once such a ticket has been transmitted on the wire, the server can't really forget it without deleting the ticket encryption key (it can of course mark the ticket invalid in some local database, but that doesn't reduce the risk from compromise of the ticket encryption key.) -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
I'm not seeing a lot of value here. Remember that servers are not required (and have never been required) to do session resumption, but much of the overhead of doing it (having to have a database, session ticket machinery) is associated with being willing to do session resumption at all, so if a small fraction of clients would tell you that they're not interested in resumption, it's not clear that buys you much. Are there any server operators who think this is a useful feature and can explain why? -Ekr On Sun, Jul 19, 2015 at 2:50 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote: > > On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > > > This is not really what I was intending when I suggested the feature. > I was > > > intending for their to be an indication, in the ClientHello, that the > > > server should not do any of the work that it would normally do to make > the > > > session resumable. > > > > Ok, I might as well write up the generic solution then: > > > > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest > > Are the features besides "don't bother making resumable session, I won't > resume." needed? > > E.g. For what would client hinting session lifetime be useful for? > > > -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] A la carte handshake negotiation
On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard wrote: > Hi, > > sorry for resurecting an old message on a fairly tangential point. > > On 6/12/15 10:31, Ilari Liusvaara wrote: > >> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for >> both DHE (via ciphersuites) and ECDSA (via (possibly implicit default) >> signature_algorithms). >> >> (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA) >> >> Either we're not talking about the same thing, or we don't read RFC 5246 > in the same way. Section 7.4.2 (pages 47-48) says: > >- The end entity certificate's public key (and associated > restrictions) MUST be compatible with the selected key exchange > algorithm. > > Key Exchange Alg. Certificate Key Type > [...] > DHE_RSARSA public key; [...] > > To me that clearly means that if the server selects a DHE_RSA ciphersuite, > it MUST NOT use a certificate that contains an EC key, even if the client > offered ECDSA in the signature_algorithm extension. However, in that case > the certificate may be signed using ECDSA, which is not the same. > > Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is >> quite clear about interaction of signature algorithms in ciphersuites >> and explicit signature negotiation (explicit negotiation always takes >> percedence). >> >> I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about > what it says, which is ironic :) My understanding is that, regarding the > key in the server's certificate, there is indeed double negotiation, with a > clear rule that the set of allowed choices is the intersection of what is > allowed by the ciphersuite and what is allowed by the signature_algorithms > extension. > >If the client has offered the "signature_algorithms" extension, the >signature algorithm and hash algorithm MUST be a pair listed in that >extension. Note that there is a possibility for inconsistencies >here. For instance, the client might offer DHE_DSS key exchange but >omit any DSA pairs from its "signature_algorithms" extension. In >order to negotiate correctly, the server MUST check any candidate >cipher suites against the "signature_algorithms" extension before >selecting them. This is somewhat inelegant but is a compromise >designed to minimize changes to the original cipher suite design. > > To me, the "MUST check against" does not suggest "may still pick the > DHE_DSS suite and use an RSA cert with it if signature_algorithms contains > acceptable RSA pairs". > > Regarding other signatures in the certificate chain, only > signature_algorithms apply, so there is no "double negotiation" indeed. This is how I understand the situation as well. I am sad to hear that we didn't manage to make the document clear on this point. -Ekr > > Of course, I wouldn't be surprised if there was fair bit of software >> that got those rules wrong... >> >> Regardless of whether your interpretation or mine is correct, I'm pretty > sure various implementations will do things in different ways here. Anyway, > a large proportion of servers deployments only have one cert, in which case > the RFC says "it [the server] SHOULD attempt to validate that it [the > certificate] meets these criteria", which may be interpreted as an > indication that the server may try to send its only certificate anyway and > let the client decide how to deal with it. > > Manuel. > > > ___ > 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 1.3 - method to request uncached shared secrets
On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith wrote: > On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni > wrote: > >> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote: >> >> > I'm not seeing a lot of value here. Remember that servers are not >> > required (and have never been required) to do session resumption, but >> > much of the overhead of doing it (having to have a database, session >> > ticket machinery) is associated with being willing to do session >> > resumption at all, so if a small fraction of clients would tell >> > you that they're not interested in resumption, it's not clear that >> > buys you much. >> > >> > Are there any server operators who think this is a useful feature >> > and can explain why? >> >> These days, I'm operating servers that only support session tickets >> (no server-side cache). If the client does not send the session >> ticket extension, no session is cached. >> >> So for servers that elect the same strategy, there's no need for >> a separate means to signal the client's intentions. >> > > First, I think that there should be only one way to do resumption in TLS > 1.3 anyway. All I'm asking for is that the client have some way of > indicating whether or not it supports resumption. Viktor's method seems > fine with me. > > Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft > actually contains a regression here. It seems like it is no longer possible > for the server to indicate how long a PSK should be held by the client to > resume a session, > Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint value. http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 and it seems like it is no longer possible for the server to indicate that > it doesn't support resumption. > Well, it can't indicate it, but if it doesn't supply a session ticket, there's no way for the client to do it. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith wrote: > Eric Rescorla wrote: > >> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith >> wrote: >> >>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft >>> actually contains a regression here. It seems like it is no longer possible >>> for the server to indicate how long a PSK should be held by the client to >>> resume a session, >>> >> >> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint >> value. >> >> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 >> >> and it seems like it is no longer possible for the server to indicate >>> that it doesn't support resumption. >>> >> >> Well, it can't indicate it, but if it doesn't supply a session ticket, >> there's no way for >> the client to do it. >> > > Great. I was misunderstanding. Here's the part that is not is still not > clear to me: Is the SessionTicket extension still to be used or not? It > seems not, AFAICT. If the SessionTicket extension were to be used, then > everything would work perfectly as Viktor suggested in his message: the > absense of the SessionTicket extension in the ClientHello would be the way > that a client can indicate that it doesn't want the session to be cached. > No, it's not used. It seems weird that the server can supply a lifetime hint but the client > can't, especially in cases like WebRTC where there is no functional > difference between the two. But, that's a smaller issue than the lack of an > indication that resumption machinery isn't wanted at all. > I don't think it's *that* odd, since tickets have at least two fundamental asymmetries: - The client needs to actually keep state and the server does not (that being the point of tickets) - The client (because they speak first) gets to offer the ticket for resumption and the server can accept it or reject it. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni
wrote:
> On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:
>
> > Here's the part that is not is still not
> > clear to me: Is the SessionTicket extension still to be used or not?
>
> While we now have
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4
>
>In TLS 1.2 and below, this functionality was provided by "session
>resumption" and "session tickets" [RFC5077]. Both mechanisms are
>obsoleted in TLS 1.3.
>
> at the same time we also have:
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11
>
>After the server has received the client Finished message, it MAY
>send a NewSessionTicket message. This message MUST be sent before
>the server sends any application data traffic, and is encrypted
> under
>the application traffic key. This message creates a pre-shared key
>(PSK) binding between the resumption master secret and the ticket
>label. The client MAY use this PSK for future handshakes by
>including it in the pre_shared_key extension in its ClientHello
>(Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.
>
> struct {
> uint32 ticket_lifetime_hint;
> opaque ticket<0..2^16-1>;
> } NewSessionTicket;
>
>ticket_lifetime_hint
> Indicates the lifetime in seconds as a 32-bit unsigned integer in
> network byte order. A value of zero is reserved to indicate that
> the lifetime of the ticket is unspecified.
>
>ticket
> The value of the ticket to be used as the PSK identifier.
>
> and
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4
>
>The pre_shared_key extension is used to indicate the identity of the
>pre-shared key to be used with a given handshake in association with
>a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).
>
> opaque psk_identity<0..2^16-1>;
>
> struct {
>select (Role) {
> case client:
>psk_identity identities<0..2^16-1>;
>
> case server:
>psk_identity identity;
>
> } PreSharedKeyExtension;
>
>identifier
> An opaque label for the pre-shared key.
>
> So indeed it is no longer possible for the client to signal the
> ability/desire to resume sessions, and servers will generate session
> tickets absent any indication that the client intends to use them.
>
> This does not impose a space penalty on the server, but some CPU
> and bandwidth may be wasted on clients that don't or can't resume.
Yes.
So my question is whether there are an appreciably large number of servers
each of which have an appreciably large fraction of *both* caching and
non-caching clients to make an optimization like this worthwhile (servers
which only have non-caching or only caching clients can just send
or not send a ticket as appropriate)
-Ekr
>
> > It seems not, AFAICT. If the SessionTicket extension were to be used,
> then
> > everything would work perfectly as Viktor suggested in his message: the
> > absense of the SessionTicket extension in the ClientHello would be the
> way
> > that a client can indicate that it doesn't want the session to be cached.
>
> In the current 1.3 draft, there is indeed no client signal.
>
> > It seems weird that the server can supply a lifetime hint but the client
> > can't, especially in cases like WebRTC where there is no functional
> > difference between the two. But, that's a smaller issue than the lack of
> > an indication that resumption machinery isn't wanted at all.
>
> The client lifetime is not that useful with session tickets anyway,
> whether the client caches at all, could be, but it is not clear
> that the resulting "inefficiency" needs to be fixed. The fix would
> be for the client to send an empty extension of some sort to signal
> its desire to elicit a session ticket.
>
> --
> Viktor.
>
> ___
> 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 1.3 - method to request uncached shared secrets
On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett wrote: > On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote: > > It depends on how the server implements tickets. The server could > implement > > tickets the same way that it implements session ID-based resumption. > That's > > not a good idea, but I don't think the spec should prohibit that type of > > implementation either since it unenforceable. Thus, because of that > > possibility, it is valuable to have the client be able to say "don't > cache > > the session" and/or limit the session's lifetime, so the client can help > > direct the level of forward secrecy for the session. Right now, only the > > server has a say in how long a session will be forward-secret. > > > > Note also that the NewSessionTicket extension precedes any application > > data, so without a way to prevent an unwanted NewSessionTicket message > from > > being sent, the client has to waste effort and time to consume the > > NewSessionTicket before it can do anything useful. > > If the general ticket lifetime request route is not needed, here's the > simplest route: just don't drop the Session Ticket extension. > > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension > > This keeps it with the same semantics for requesting a ticket, thus > allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 > servers with no additional effort. TLS 1.3 sessions would be resumed using > the new PSK-based method and TLS 1.2 sessions would be resumed using the > old session ticket extension. > > Should I submit this as a PR? It seems like the obvious route if all we > want is to just keep the ability for a client to not request a ticket. No > need to write a new extension at all. As I said initially, I'm having trouble seeing why this is particularly useful. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith wrote: > Eric Rescorla wrote: > >> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith >> wrote: >> >>> It seems weird that the server can supply a lifetime hint but the client >>> can't, especially in cases like WebRTC where there is no functional >>> difference between the two. But, that's a smaller issue than the lack of an >>> indication that resumption machinery isn't wanted at all. >>> >> >> I don't think it's *that* odd, since tickets have at least two fundamental >> asymmetries: >> >> - The client needs to actually keep state and the server does not >> (that being the point of tickets) >> > > It depends on how the server implements tickets. The server could > implement tickets the same way that it implements session ID-based > resumption. That's not a good idea, but I don't think the spec should > prohibit that type of implementation either since it unenforceable. > I don't think that the current spec does so. > Thus, because of that possibility, it is valuable to have the client be > able to say "don't cache the session" and/or limit the session's lifetime, > so the client can help direct the level of forward secrecy for the session. > Right now, only the server has a say in how long a session will be > forward-secret. > > Note also that the NewSessionTicket extension precedes any application > data, so without a way to prevent an unwanted NewSessionTicket message from > being sent, the client has to waste effort and time to consume the > NewSessionTicket before it can do anything useful. > > Anyway, I don't understand why you keep directing your question to server > vendors. The people that would be interested in such a feature are client > software vendors, for client software that wants to control the level of > forward secrecy for a session. > I think perhaps you have misunderstood the forward secrecy properties of the current draft. Unlike TLS 1.2 and previous, the current draft has a separate resumption master secret which is independently derived from the master secret used for the connection keys in the original connection. This means that if you don't resume the connection, you have forward secrecy for the original connection regardless of whether the server stores the session in the session cache or sends the client a ticket. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)
On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett wrote: > On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: > > I think perhaps you have misunderstood the forward secrecy properties of > the > > current draft. Unlike TLS 1.2 and previous, the current draft has a > separate > > resumption master secret which is independently derived from the master > > secret used for the connection keys in the original connection. This > means > > that if you don't resume the connection, you have forward secrecy for the > > original connection regardless of whether the server stores the session > in > > the session cache or sends the client a ticket. > > We've got lots of keys and secrets now. Could you please clarify the exact > points where these are each to be discarded? If I am understanding it > correctly, the master_secret, prior intermediate secrets, and > finished_secret are to be discarded as soon as the keys, resumption_secret, > and possibly exporter_secret (which currently has no explanation in the > doc) are derived, the handshake is finished, and we're ready for > application traffic? It would help if you provided a table/chart laying out > the timeline of secret & key lifetimes, from derivation to discard. It > should state in the spec explicitly what needs to be kept around for how > long and require things be discarded as soon as viable. > Yes, I can do something along these lines. > I think these various values need to be named more consistently in the doc > to make searching for them easier. For example, "resumption_secret" is used > in the computation part but the words "resumption master secret" are used > when actually using this value. (also noted in issue #191 by Martin > Thomson) I've pushed a small PR to correct this case along with a few > tweaks that I think makes it a bit clearer. > https://github.com/tlswg/tls13-spec/pull/205 > > Also, some other questions about various computations: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 > https://tlswg.github.io/tls13-spec/#key-schedule > > HKDF(,,,) doesn't seem to be fully defined here, just > HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. > Could you please clarify this? > Yes. > Why is finished_secret derived from extracted static secret instead of > master_secret? The rationale here is that the Finished message also serves to authenticate the server's ephemeral DH share (when in known_configuration mode) and because the master secret depends on the ephemeral DH keys, this creates an odd authentication logic. Hugo can expand on this some more, perhaps. > Are there two finished_secret in the event that the client sends a > certificate? > No, this shouldn't be necessarily. You just use the first one. I'll try to clarify. > The computation of verify_data could probably be moved up to the same > section so this is all in the same place. Am I correct in reading that it > could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, > finished_label, handshake_hash, L) without the extra HMAC currently defined > for verify_data) See above. -ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Negotiating with known_configuration
The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This has the advantage of keeping things
short but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). After some thought,
I think this is a bad plan.
Here's what I propose (and what's in my slides for today):
- 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
- The server verifies the client's ClientHello and
(a) Checks that configuration ID is valid
(b) Verifies that client's parameters are what it would negotiate
Accordingly, this would change the extension to something like:
struct {
select (Role) {
case client:
opaque identifier<0..2^16-1>;
CipherSuite cipher_suite;// NEW
Extension extensions<0..2^16-1>; // NEW
case server:
struct {};
}
} KnownConfigurationExtension
The server would just need one configuration for each public key and
woudldn't need to have any client-specific state. It also has the
benefit that it makes PSK work with 0-RTT.
Thoughts? Improvements?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson wrote: > 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. 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. 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. > I agree with this point. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
Yeah, or it could just have the semantics "this is my most preferred configuration and if you send me anything compatible with it, I will pick it" -Ekr On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson wrote: > 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 Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > > 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. > > > > > Yeah, or it could just have the semantics "this is my most preferred > > configuration and if you send me anything compatible with it, I will > > pick it" > > What cipher this is about? The cipher used for protecting 0RTT/Early > handshake data? The cipher used for protecting main connection? > The former. For main connection, the server can pick from ciphersuites advertized > by client (assuming client gives ciphers that are acceptable and > are usable with configurations, i.e. GDHE_CERT-type things). > Agreed. > For 0-RTT/Early handshake data you want cipher that the server > supports and accepts. If it is about this, there could be multiple > allowed ciphers. > In principle this is true. However, there are two complications, ISTM: 1. The client has no way of knowing which ciphers the server would support other than the one it negotiated with the client previously (assuming in-band) 2. I'm trying to avoid questions about the security of the negotiation for the 0-RTT data, and we already have negotiated parameters. I haven't done any analysis of what happens if the server doesn't check that it would negotiate the parameters that the client provides. That might be fine, but I'm trying to be conservative. Thanks, -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: > > 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. > > Oh darn, mislooked what message it was. > > > Also, with regard to ending 0RTT, even without encrypted content > types. Either I am misunderstanding something, or: > > - Client: Send ClientHello. > - Server: Read ClientHello. > - Client: Send 0-RTT & client cert. > - Server: Read 0-RTT & client cert. > - Client: Wait for server reply. > - Server: Wait for handshake message to end 0-RTT. > *deadlock*. Is this the case where the server is accepting 0-RTT or rejecting it? -Ekr > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote: > > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > > > I thought that Brainpool curves weren't removed (even if those aren't > > > explicitly in), which are random prime curves. > > > > > > Also, the security of binary curves seems quite questionable. > > > > Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited > either. > > > > If there's no strong objection, I'd like to add them to the list, if > > just to document the current NamedGroup registry. I could add a > > recommendation to stick to standards track, for those worrying about > them. > > Related: There's the following draft: draft-iab-crypto-alg-agility > (currently in IETF LC) which contains the following: > > 3.4 National Cipher Suites > > "The default server or > responder configuration SHOULD disable such algorithms; in this way, > explicit action by the system administrator is needed to enable them > where they are actually required." > > While the thing is about cipher suites, it also goes for curves. > > Also, Brainpool is much slower than the special prime stuff, > so I think the defaults should be high-performance where it is > not known to hurt security. > > > This could also be applied to some actual ciphersuite stuff, namely > ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers). I would be comfortable with taking a hard look at these. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson wrote: > 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. > This is what I have been assuming. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote: > One of the topics of discussion at the WG discussion was whether > ServerConfiguration.expiration_date should be an absolute or relative > value. Subodh (CC) dug into our production data and found that nearly half > of the TLS errors we see in production (end user to edge/origin) are due to > date mismatch. This often occurs when people intentionally reset the clock > on their phone, or for other various reasons. > > Due to the high rate of date mismatch errors we see, my preference would > be that ServerConfiguration.expiration_date be a relative value instead of > an absolute one. This provides the client an opportunity to correctly use a > monotonic (or other similar) clock to minimizing exposure, without losing > the value of the ServerConfiguration. Using an absolute value means that > ServerConfiguration, for clients with invalid clocks, would essentially > never be cacheable. These clients wouldn’t benefit from ServerConfiguration. > > Thoughts or feedback? Can you provide a sense of the range of clock skew you are seeing? I'm trying to figure out how many of these clients are going to start choking with OCSP must-staple, short-lived certs, etc. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
I guess what I'm trying to get at is the following: Are there a lot of people whose clocks are accurate enough that they will be able to connect to the server and check the certificate/OCSP but not accurate enough to process ServerConfiguration if it is in absolute time. On Wed, Jul 22, 2015 at 10:54 PM, Blake Matheny wrote: >On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote: > >> One of the topics of discussion at the WG discussion was whether >> ServerConfiguration.expiration_date should be an absolute or relative >> value. Subodh (CC) dug into our production data and found that nearly half >> of the TLS errors we see in production (end user to edge/origin) are due to >> date mismatch. This often occurs when people intentionally reset the clock >> on their phone, or for other various reasons. >> >> Due to the high rate of date mismatch errors we see, my preference would >> be that ServerConfiguration.expiration_date be a relative value instead of >> an absolute one. This provides the client an opportunity to correctly use a >> monotonic (or other similar) clock to minimizing exposure, without losing >> the value of the ServerConfiguration. Using an absolute value means that >> ServerConfiguration, for clients with invalid clocks, would essentially >> never be cacheable. These clients wouldn’t benefit from ServerConfiguration. >> >> Thoughts or feedback? > > > Can you provide a sense of the range of clock skew you are seeing? I'm > trying to > figure out how many of these clients are going to start choking with OCSP > must-staple, short-lived certs, etc. > > > Well, our public cert is set to expire in ~1 year. The errors I’m seeing > are “certificate has expired” and “certificate not yet valid”. I don’t have > client timestamp vs server timestamp, but the clock in these cases is off > by a year-ish? > > -Blake > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz wrote: > One place we may run into a lot of those clients are on machines like the > Raspberry Pi and Beaglebone machines. These boards do not include clock > chips, so the machines must get the current time via NTP every time they > power on. If there is a problem with NTP, or if the shell script to set the > clock is not run, then the date will probably be 20 or 30 years back in the > last millenium. > That's definitely a problem, but not a specific problem for ServerConfiguration since those implementations will also have problems with certificates (and ironically, will accept ServerConfiguration just fine) -Ekr Cheers - Bill > > On 7/22/15 at 2:14 PM, bmath...@fb.com (Blake Matheny) wrote: > > Ahh. I can't tell, the data I have is only clients with very very broken >> clocks who failed validation as a result. My assumption would be that there >> is a much larger number of clients that fit what you described (cert/OCSP >> check passes, but ServerConfiguration would not be). Since I don’t have the >> data, I can’t say that for sure, but anecdotal evidence would indicate that >> this is the case. >> >> -Blake >> >> >> >> >> On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: >> >> I guess what I'm trying to get at is the following: >>> Are there a lot of people whose clocks are accurate enough that they >>> will be able to connect to the >>> >> server and check the certificate/OCSP but not accurate enough to process >> ServerConfiguration if it is in absolute time. >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> --- > Bill Frantz| Ham radio contesting is a| Periwinkle > (408)356-8506 | contact sport. | 16345 Englewood Ave > www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell wrote: > > > On 23/07/15 16:43, Dave Garrett wrote: > > We should just get more serious about banning old crap entirely to > > make dangerous misconfiguration impossible for TLS 1.3+ > > implementations. > > > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ > > compatible with TLS 1.2, if available > > A suggestion - could we remove mention of anything that > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > and then have someone write a separate draft that adds a > column to the registry where we can mark old crap as > deprecated? > > Not sure if it'd work though. > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a vehicle for telling people how to configure use of TLS 1.2, and I think it might be better to move all that stuff out. -Ekr > 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] new error alerts?
It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.
-Ekr
On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett
wrote:
> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and
> added a fix for that as well. The Server Hello section said that lack of
> acceptable group would result in an "insufficient_security" error, which is
> incorrect. That error is clearly defined to be for lack of acceptable
> cipher suite. The Negotiated Groups section says lack of acceptable group
> is a “handshake_failure” error. I changed the text to state the error for
> suites, as the other is already noted elsewhere. (this change is now in PR
> #201) This brings up a problem, however: there is no distinct error for
> lack of group support. The “handshake_failure” is a bit of a catchall, so
> there's no way for a client to really know what's wrong if this happens.
> This is also why I don't want to change the definition of the
> "insufficient_security" error. Clients rely on these being relatively
> precise in order to show error messages that are hopefully meaningful
> enough to get them fixed. As such, I'd like to propose adding a new error
> just for this and renaming the old one to focus precisely on its long
> defined meaning. While we're at it, a failure of client authentication
> doesn't have its own error alert code either.
>
> enum {
>handshake_failure(40),
>unsupported_cipher_suites(71), /* formerly insufficient_security */
>unsupported_dh_groups(72), /* new */
>client_authentication_failure(73), /* new */
>(255)
>} AlertDescription;
>
> Pretty straightforward. Are there any other errors that can't be clearly
> identified by the returned code? Debugging shouldn't be guesswork. ;)
>
>
> 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] ban more old crap
To be clear: TLS 1.3 does not support RC4. 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. -Ekr On Sat, Jul 25, 2015 at 3:41 PM, Benjamin Beurdouche < benjamin.beurdou...@inria.fr> wrote: > > > On 25/07/15 06:46, Viktor Dukhovni wrote: > >> I hope, that by ~2017, RC4 will no longer be required either, and > >> we'll be able to disable RC4 in Postfix at that time. > > > > Seems to me that should be a reasonable match for expecting to see > > TLS1.3 getting deployed in lots of parts of the mail infrastructure, > > so that date would argue to not support rc4 at all in TLS1.3 in my > > conclusion (not that I know much about mail deployment trends). > > > > And if we have any support for rc4 in TLS1.3 it'll end up a footgun > > that'll damage many toes, so count me amongst those arguing for no > > rc4 (or similar) at all in TLS1.3. > > +1, though, my understanding was that RC4 was already out of TLS 1.3.. > In general I think we could all agree that we should never keep broken > stuff in TLS even if it is used a lot… > > Best, > B. > > > ___ > 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 & resumption
On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett wrote: > I'm pretty sure some/all of this was likely mentioned elsewhere, but I > don't see any discussion on-list. (it was mentioned in part of the IETF 93 > recording I watched as this whole topic needing to go to the list, as well) > There's also related TODOs in the draft on this topic. Here's a start to > this discussion. > > Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT > connections using the known configuration extension & PSK-based session > resumption. I don't think their roles are well defined yet. > > 1) There is no 0-RTT resumption. The point of resumption is to get back > into the session quick, but it's arguably slower than not doing it, > currently. > > 0-RTT can do first flight (repeatable) requests: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 > but PSK-based resumption needs 1-RTT: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 We agreed on how to do this in Prague. The sticking point was establishing the cipher suite. I have WIP text on my machine for both of these which I will be sending early next week, once I get enough sleep to be able to clean it up, so I'd ask people to sit tight till then. 2) There's not yet specifics on what cipher suite to use for PSK-based > resumption. The consensus in Prague was that you should have to use a matching symmetric cipher suite. I don't see a point in doing PSK-based resumption with anything other than > plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work > for DH, just go straight to normal 0-RTT to get more benefit/flexibility > with a similar amount of work. The goal is really to get forward secrecy on > the session, not necessarily every single connection within it. (not that > it wouldn't be nice) As long as the resumption is within a reasonably short > window (e.g. few minutes), not doing another DH is fine. After this window, > normal 0-RTT should be the preferred route. > I don't think this is correct. The reason is that resumption also resumes the client's authentication state, and client authentication often involves user interaction, which is undesirable from the site's perspective. So, it's actually quite attractive to do resumption with (EC)DHE. It's also significantly faster if you have an RSA certificate. > 3) Just to state the obvious: If a client is going to do PSK resumption > with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not > really going to be negotiated for anything else, I don't really like the > feel of this. I think it'd also be cleaner if the offered suites didn't > have to change for resumption. One idea would be to rename the groups > extension, again, to "supported_key_shares" and mark point 0 (or some other > if we want to leave 0) as PSK-resumption, specifically. Yeah, we discussed this internally, but I think it's clumsy. I'd rather just offer two separate cipher suites. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS epoch and resume session/handshake
The epoch is set to 0 at the start of each connection and then incremented with each handshake on that connection. -Ekr On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard wrote: > Hi, > > I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when we > start a resume handshake, or if we keep the last used value, or the last > used value+1 ? I can not any clue of that in the spec. > Any idea ? > > Thx > Simon > > ___ > 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] Fwd: Summary of today's discussion on server-side signing
On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk wrote: > I am ok with whatever the WG decides, particularly when the reasons are > non-cryptographic but rather based on implementation considerations. > > Still, for the record, I'd like to correct the statement " > > KnownConfiguration is only useful with 0-RTT. > ". > > KnownConfiguration could be used with 1-RTT even if the client does not > send early application data in the first flight. > This would have allowed to save a signature also in the 1-RTT case > whenever the client has cached a KnownConfiguration. > Saving a signature is a major performance benefit with RSA signatures (are > they really going away soon?) but is a benefit also with ECDSA as it avoids > the need to send a certificate chain (shortening the handshake) and the > need to verify these certificates. ECDSA also has a cost for the client. > This was very bad writing on my part. What I was trying to say was that once you commit to signing every transaction, then it's not helpful to use the KnownConfiguration mechanism with 1-RTT because you've already given up the optimizations you quite rightly point out. Sorry for the confusion. Lastly, the protocol would be secure without the signature (in the case the > client uses a known configuration), a property that enables the use of the > protocol with offline signatures (to-be-specified). > Thanks for pointing this out. Best, -Ekr Hugo > > On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner wrote: > >> All, >> >> I asked ekr to write a brief summary of the server-side signing issue. >> The summary provided matches the WG consensus as judged by the chairs. >> Please let us know if you object to the way forward by August 3rd. >> >> J&S >> >> Begin forwarded message: >> >> > From: Eric Rescorla >> > Subject: Summary of today's discussion on server-side signing >> > Date: July 22, 2015 at 08:52:31 EDT >> > To: Sean Turner >> > >> > Sean, >> > >> > Here's a summary of today's discussion on signing and >> KnownConfiguration. >> > >> > SUMMARY >> > The WG agreed that the server must sign whenever certificate >> authentication >> > is used (even if the KnownConfiguration is used). >> > >> > >> > BACKGROUND >> > The current draft requires the server to send a >> Certificate/CertificateVerify >> > whenever either: >> > >> > (a) The KnownConfiguration option is not in use. >> > (b) The server sends a ServerConfiguration >> > >> > but it does not need to sign if the KnownConfiguration option is in >> > use but no new ServerConfiguration is provided. Several people (most >> > recently Martin Thomson) have suggested that it would be simpler to >> > just require the server to sign any time certificate-based >> > authentication is in use. The penalty for this is an extra sign/verify, >> > as shown in the following table: >> > >> > Scenario Client Server >> > -- >> > 1-RTT 1 (EC)DHE + Verify 1 (EC)DHE + Sign >> > >> > 0-RTT (current, 2 (EC)DHE2 (EC)DHE >> > no new config) >> > >> > 0-RTT (current,2 (EC)DHE + Verify 2 (EC)DHE + Sign >> > new config) >> > >> > 0-RTT (proposed) 2 (EC)DHE + Verify 2 (EC)DHE + Sign >> > >> > >> > So, the performance difference here is between line 2 and line 4, >> > since whenever you provide a new config (line 3) you have to sign >> > anyway. The benefit is that it makes the server side of the handshake >> > essentially identical in both 0-RTT and 1-RTT, which is nice from an >> > implementation and analysis perspective. >> > >> > >> > SUMMARY OF WG DISCUSSION >> > During the WG discussion today, there was rough consensus to adopt >> > this change (i.e., always sign). A number of arguments were advanced >> > in favor of this change. >> > >> > (1) It's significantly simpler for implementors and (at least informal) >> > analysis. A side benefit is being able to merge the extension >> > logic for 0-RTT and KnownConfiguration, since >> >> KnownConfiguration >> > is only useful with 0-RTT. >> > >> > (2) It extends the properties we were shooting for with online-only >> >
Re: [TLS] 0-RTT & resumption
On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: > > > > > > We agreed on how to do this in Prague. The sticking point was > establishing > > the cipher suite. I have WIP text on my machine for both of these which I > > will be > > sending early next week, once I get enough sleep to be able to clean it > up, > > so I'd ask people to sit tight till then. > > > > Okay, now the PR (#211) seems to be up, let's review Oops. It wasn't supposed to be done. I meant to make it a PR against my own branch so that I could get early comments from MT, but obviously that didn't work out. Regardless, thanks for your comments. - Lacks client-driven client authentication[1]. All client auth is server > driven, which I think isn't very useful in real world (there are all > sorts of bad hacks[2] trying to work around lack of client-driven auth). > This is just extending existing practice for 1-RTT handshakes. I tend to agree with you that it would be good to change that, but I didn't want to do that in this PR, because it would be a big semantic change in TLS. I suggest you start a new thread on this topic, or perhaps add it to Andrei's client auth thread? - EncryptedExtensions looks to be mandatory in some exchanges, optional > in others. I agree it should be mandatory in all (issue #213). > Me too. That's just editing error. > - "The client's cryptographic determining parameters match the parameters > that the server has negotiated based on the rest of the ClientHello." > ... Does that mean the client has to guess what ciphersuite the server > will choose (more than pure-PSK vs. GDHE, which is unvaoidable with > just one encrypted block)? > The client knows what the server selected based on his previous offer and the server's configuration (which by hypothesis is still extant) so the server should choose the same value again. > - Am I reading the syntax wrong, or does the extensions field in server > configuration only allow exactly one extension (shouldn't it be zero > or more)? > Yes. good catch. Also, regarding issue #212, unless the Certificate is handled specially, > it would mean that the signature does not cover certificate. And not > signing the certificate (esp. the public key within) causes problems > in some exotic cases (I don't know if any of those cases pop up in TLS > 1.3). > This seems like a good argument. > I think it would simplify the security analysis a bit if CertificateVerify > was always immediately before Finished and covered everything before that > point. > Isn't this always the case presently? Are you just thinking we should say it's a rule? -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comments on the TLS 1.3 draft
On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) wrote: > I recently reviewed the most recent TLS 1.3 draft, and I must say that I > am impressed; the protocol appears to be a significant improvement. In > particular, you simplify the protocol significantly, and as we all know, > complexity is the enemy of security. You also drop many of the weak > options, such as RC4 and the export ciphers; that sounds like an excellent > idea. > > > > That said, I do see a few things that puzzle me: > > > > - When dealing with ECDSA signatures, the default hash algorithm > is SHA1, and any other hash function needs to be specified explicitly. > Might I ask why that is? No one has demonstrated a SHA1 collision yet; > however people are creeping closer. If you ask me (which you didn’t, but > I’ll give my opinion anyways), the default should be (at least) SHA-256; > you should allow SHA-1 as a downgrade option only if someone makes a strong > case that they can implement ECDSA and the rest of TLS 1.3, but > implementing SHA-256 is just too hard. Otherwise, it should be discarded > just like the other known weak cryptographical primitives (such as RC4). > > - You also allow the provision of someone using MD5 as the hash > algorithm. Take the above comments about how SHA-1 is not a good idea, and > multiply it by a factor of about 10. I see no justification for allowing > someone to use a known broken hash algorithm. > This is just a transient state. We have patches in progress to remove both of these. - Given the general theme of simplification, I was a bit puzzled > by something; you appear to provide two different solutions to “how do I > quickly reestablish a TLS tunnel”; you have both 0-RTT and session > resumption. While both appear to have minor advantages over the other, I > don’t immediately see any real justification for including the complexity > of both. Now, it might be that I’m catching a draft in the middle, and > that you fully intend to combine them. Alternatively, there might be > strong reasons to have both (and it just doesn’t occur to me). In either of > those two cases, “never mind” > Each of these has some benefit, though I agree that it would be nice to combine them. The big issue is: - For security reasons it's much easier to work with 0-RTT DH exchanges. - For performance reasons it's nice to have resumption. -Ekr > > > However, despite these minor nits, I would end with saying that the > working group has done good work on this draft; I look forward to the end > product. > > > > Thanks! > > ___ > 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 & resumption
I've updated the PR based on feedback from Dave, Ilari, and Martin. https://github.com/tlswg/tls13-spec/pull/211 I'll merge this PR on 8/11 unless there are serious objections. As usual please send minor changes as github comments and/or PRs. -Ekr On Tue, Aug 4, 2015 at 5:40 AM, Eric Rescorla wrote: > > > On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > >> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: >> > >> > >> > We agreed on how to do this in Prague. The sticking point was >> establishing >> > the cipher suite. I have WIP text on my machine for both of these which >> I >> > will be >> > sending early next week, once I get enough sleep to be able to clean it >> up, >> > so I'd ask people to sit tight till then. >> > >> >> Okay, now the PR (#211) seems to be up, let's review > > > Oops. It wasn't supposed to be done. I meant to make it a PR against my > own branch so that I could get early comments from MT, but obviously that > didn't work out. Regardless, thanks for your comments. > > > - Lacks client-driven client authentication[1]. All client auth is server >> driven, which I think isn't very useful in real world (there are all >> sorts of bad hacks[2] trying to work around lack of client-driven auth). >> > > This is just extending existing practice for 1-RTT handshakes. > > I tend to agree with you that it would be good to change that, but I > didn't want > to do that in this PR, because it would be a big semantic change in TLS. > I suggest you start a new thread on this topic, or perhaps add it to > Andrei's > client auth thread? > > > - EncryptedExtensions looks to be mandatory in some exchanges, optional >> in others. I agree it should be mandatory in all (issue #213). >> > > Me too. That's just editing error. > > > >> - "The client's cryptographic determining parameters match the parameters >> that the server has negotiated based on the rest of the ClientHello." >> ... Does that mean the client has to guess what ciphersuite the server >> will choose (more than pure-PSK vs. GDHE, which is unvaoidable with >> just one encrypted block)? >> > > The client knows what the server selected based on his previous offer and > the server's configuration (which by hypothesis is still extant) so the > server > should choose the same value again. > > >> - Am I reading the syntax wrong, or does the extensions field in server >> configuration only allow exactly one extension (shouldn't it be zero >> or more)? >> > > Yes. good catch. > > > Also, regarding issue #212, unless the Certificate is handled specially, >> it would mean that the signature does not cover certificate. And not >> signing the certificate (esp. the public key within) causes problems >> in some exotic cases (I don't know if any of those cases pop up in TLS >> 1.3). >> > > This seems like a good argument. > > > >> I think it would simplify the security analysis a bit if CertificateVerify >> was always immediately before Finished and covered everything before that >> point. >> > > Isn't this always the case presently? Are you just thinking we should say > it's > a rule? > > -Ekr > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS epoch and resume session/handshake
Please see RFC 6347 S 4.2.8 -Ekr On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard wrote: > I'm sorry to insist, but What did you mean by transport level connection ? > For me UDP was a connectionless protocol. > > Simon > > > Le 31/07/2015 18:53, Eric Rescorla a écrit : > > > > On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard > wrote: > >> Thx. >> What did you mean by connection ? >> > > transport level connection. > > > >> A resume handshake is a new connection ? > > > You can also resume when you renegotiate. > > -Ekr > > >> Le 31/07/2015 16:54, Eric Rescorla a écrit : >> >>> The epoch is set to 0 at the start of each connection and then >>> incremented >>> with each handshake on that connection. >>> >>> -Ekr >>> >>> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >> <mailto:cont...@simonbernard.eu>> wrote: >>> >>> Hi, >>> >>> I search in DTLS RFC 6347 if the epoch should be (re)set to 0 >>> when we start a resume handshake, or if we keep the last used >>> value, or the last used value+1 ? I can not any clue of that in >>> the spec. >>> Any idea ? >>> >>> Thx >>> Simon >>> >>> ___ >>> TLS mailing list >>> TLS@ietf.org <mailto: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] DTLS epoch and resume session/handshake
On Mon, Aug 17, 2015 at 9:20 AM, Simon Bernard wrote: > I re-readed this paragraph and it's still not clear, what did you mean by > connection at transport layer for UDP. > > I well understand that if a server receive a clientHello with epoch=0, > this means that a new handshake should be done. > > But I still don't know what happends in a ResumeHandshake use case. > > In fact, my use case is a client behind a NAT which communicate > periodically. at each period, its IP/Port could changed (because of NAT), > so we would like to resume handshake each time. > 1) Does it make sense ? > 2) If yes, should we do the resume handhsake with epoch = 0 or continue > with previous epoch ? > Resumption isn't relevant here. If you are renegotiating (i.e., the ClientHello will be encrypted under a previous cipher suite) then you have epoch > 0. Otherwise, epoch = 0. -Ekr > > Le 17/08/2015 16:24, Eric Rescorla a écrit : > > Please see RFC 6347 S 4.2.8 > > -Ekr > > > On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard > wrote: > >> I'm sorry to insist, but What did you mean by transport level connection >> ? For me UDP was a connectionless protocol. >> >> Simon >> >> >> Le 31/07/2015 18:53, Eric Rescorla a écrit : >> >> >> >> On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard >> wrote: >> >>> Thx. >>> What did you mean by connection ? >>> >> >> transport level connection. >> >> >> >>> A resume handshake is a new connection ? >> >> >> You can also resume when you renegotiate. >> >> -Ekr >> >> >>> Le 31/07/2015 16:54, Eric Rescorla a écrit : >>> >>>> The epoch is set to 0 at the start of each connection and then >>>> incremented >>>> with each handshake on that connection. >>>> >>>> -Ekr >>>> >>>> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >>> <mailto:cont...@simonbernard.eu>> wrote: >>>> >>>> Hi, >>>> >>>> I search in DTLS RFC 6347 if the epoch should be (re)set to 0 >>>> when we start a resume handshake, or if we keep the last used >>>> value, or the last used value+1 ? I can not any clue of that in >>>> the spec. >>>> Any idea ? >>>> >>>> Thx >>>> Simon >>>> >>>> ___ >>>> TLS mailing list >>>> TLS@ietf.org <mailto: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] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > TLS 1.3 encrypts both the client's and server's certificates already. The server's certificate is secure only against passive attack. The client's is encrypted with a key that the client can authenticate as belonging to the server. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters wrote: > On Mon, 24 Aug 2015, Eric Rescorla wrote: > > TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. >> > > Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > CAs they trust, so unless you receive a hash of a known CA to you, you > can withold your own certificate from being sent. > > Is a similar mechanism not planned for TLS 1.3? Well, TLS already permits the server to indicate the DN of CAs which should be in the path. I have not heard of any plan to add a digest indication. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < >> viktor.s.wold.e...@gmail.com> wrote: >> >>> Hi, >>> >>> I am looking for a way to achieve identity hiding for DTLS 1.2, which >>> also hopefully can be used in (D)TLS 1.3, when available. >>> >>> From what I understand, for (D)TLS 1.2 it would be possible to perform >>> an anonymous unencrypted handshake and then to renegotiate the connection >>> with authentication within the encrypted channel, e.g., according to the >>> expired draft [1]. From the latest TLS 1.3 draft [2] it appears that >>> renegotiation will be removed in the upcoming 1.3 version. >>> >>> What is likely to be the recommended way to achieve identity hiding for >>> (D)TLS 1.3, if any? >>> >>> [1] Transport Layer Security (TLS) Encrypted Handshake Extension, >>> draft-ray-tls-encrypted-handshake-00, expired in 2012 >>> [2] The Transport Layer Security (TLS) Protocol Version 1.3, >>> draft-ietf-tls-tls13-07 >>> >>> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > Thanks a lot for the clarification. > > Would it be reasonable to include your answer or something similar into > the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" > section? > Sure. It's mostly a changelog now, but I'll try to add something. -Ekr > Best regards > Viktor S. Wold Eide > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > > It's good to see that both the client's and the server's certificates are > encrypted in TLS 1.3, providing protection against passive eavesdropping. > > For some use cases it might be worthwhile to reduce the information made > available to an active attacker also. Are there any suggestions in this > direction for TLS 1.3? > > One might think of a multi stage approach, something like: > - Anonymous connection establishment, resulting in a secure channel. > - Authentication by means of group certificate. > - Authentication by means of a host specific certificate. > > The purpose of the second step above is to first only provide the group > identity to an active attacker, and then to reveal the host identities > (certificate information) only after group membership has been mutually > authenticated > I don't think this matches most TLS use cases very well, since the client generally isn't authenticated at all, so there's no point in the server progressively revealing more. -Ekr Does something like this seem reasonable for TLS 1.3 or are there any other > ways for providing protection of identities against an active attack? > > Best regards > Viktor S. Wold Eide > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 11:48 AM, 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}}).
>
I note that we had a very extensive discussio n
> > 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 is an example of a MUST that is not always easy to enforce. Consider
what happens if you have a client which offers both ECDHE and PSK
(for resumption) and omits supported_groups. If the server picks
PSK it's a pain to check for supported groups and I'm not sure that
the world is improved by that code.
> 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.
>
I agree consideration of this question is good.
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.
As noted above, I don't think that this is the only exception.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
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?
On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson
wrote:
> 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.
>
Well, yes and no. We don't for instance check for the *absence* of the
extension.
-Ekr
> 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?
On Thu, Aug 27, 2015 at 1:06 PM, Martin Thomson wrote: > 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. > This seems totally reasonable. -Ekr > 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
[TLS] draft-ietf-tls-tls13-08 and plan for future drafts
Folks, I've just posted draft-08 which includes the changes discussed on-list to require digital signatures from the client even if you are re-using a previous configuration in 0-RTT (per WG discussion). This version also includes a bunch of other cleanup, as detailed below: - Remove support for weak and lesser used named curves. - Remove support for MD5 and SHA-224 hashes with signatures. - Revise list of currently available AEAD cipher suites. - Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. - Require digital signatures even when a previous configuration is used. - Merge EarlyDataIndication and KnownConfiguration. - Change code point for server_configuration to avoid collision with server_hello_done. As usual, comments welcome. If you think I missed something important please let me know and/or file a github issue so I don't forget it this time. I thought it might be useful for people to know what's coming in upcoming drafts. 1. As I mentioned in Prague, I plan to do a fairly significant restructuring/editorial effort to make things easier to read. This will include: - Reordering the text to put the overview first. - Cleaning up or removing obsolete/redundant material (e.g., the now really old security analysis) - General editorial cleanup. 1. The intention is to produce a cleaned-up draft that doesn't have any major technical changes (optimally no technical changes) but is significantly easier to read. I'm targeting that for early September. I'll keep a github branch up to date on this in case people want to see how it's going. 2. In parallel I'll be starting threads on the list to try to resolve a number of open technical issues. Hopefully we can deal with a bunch of this on the list and get the rest on-deck for the interim in SEA. Depending on the timeline and the number of issues we resolve, I may do a -09 and then have -10 be the rewrite, or -09 may just be the rewrite. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Deprecate DH_anon in favor of raw public keys?
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
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson wrote: > 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. It also removes the need to parse the cert. > 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. > SG. > 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 Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni wrote: > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > > 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. > > Indeed that's effectively what you get with DANE TLSA "3 1 1", when > the client, the server or at present typically both don't support > RFC 7250. > > > 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. > > The signal has pros and cons. Absent channel-binding at the next > layer up, it makes it clear to adversaries that active attacks are > "safe". 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. > > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. > How does anon-DH have different privacy properties than doing RFC 7250 with a fresh signing key for each connection? -Ekr ___ 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 Mon, Aug 31, 2015 at 9:13 AM, Nico Williams wrote: > On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote: > > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > Furthermore, anon-DH has strong privacy properties, the server > > sends no identity information, not even a public key. Any > > channel-binding at the next layer is privacy protected. > > Using raw public signature keys doesn't change that. It just requires > generating a signature key every time. > > For devices/protocols where DH_anon is common (perhaps because they do > channel binding) the proposal at hand is annoying and CPU-wasting, but > hardly fatal. > > I'm not sure how I feel about this. The idea that we always do a DH key > exchange and always have a server signature means we can greatly reduce > the number of ciphersuites, so that's quite helpful. We'd have to apply > this to PSK too to make it really worthwhile. Certainly it would be nice to get rid of PSK too but just getting rid of DH_anon makes a non-trivial difference. -Ekr ___ 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 Mon, Aug 31, 2015 at 9:45 AM, Nico Williams wrote: > On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > > wrote: > > > I'm not sure how I feel about this. The idea that we always do a DH > key > > > exchange and always have a server signature means we can greatly reduce > > > the number of ciphersuites, so that's quite helpful. We'd have to > apply > > > this to PSK too to make it really worthwhile. > > > > Certainly it would be nice to get rid of PSK too but just getting rid of > > DH_anon makes a non-trivial difference. > > How would we get rid of PSK [without DH]? What would the impact be on > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > it easy on IoTs? I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm saying that even if we still have PSK, removing DH_anon as an explicit mode makes things simpler. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
> > > As Alissa, I was wondering why it wasn’t easier to fix the one > implementation instead. > > Because it's widely fielded, and browsers don't know in advance what kind of server they are talking to. > The shepherd wrote: "Since then it has been found that this extension can > server (sic) to alleviate issues with issues in several vendor's > products. There was good consensus to move forward with this document as > it may find further applicability in the future.” So it looks like the > problem is not just one implementation… > There's another potential future application for DTLS to allow the client to pad out the ClientHello to MTU size (or rather for the server to insist on it) thus reducing the risk of amplification. -Ekr > If the WG now thinks that this extension may be valuable for other things > besides fixing bugs, then it might be nice to reword some of the document > to not focus on what seems to be one bug and just present the extension > for what it is: padding. > > > ___ > 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] RC4 cipher with NNTP (RFC 4642)
Note: RFC 4642 does not seem to have been a work product of the TLS WG, so you probably want to raise this in UTA. -Ekr On Wed, Sep 2, 2015 at 7:53 AM, Salz, Rich wrote: > > Maybe a new RFC obsoleting RFC 4642 (which could at the same time > > become a standard instead of a proposed standard)? > > Is there any reason why NNTP cannot just use the UTA specifications? > (It's been awhile since I "dabbled" in NNTP :) > > /r$ > > > -- > Senior Architect, Akamai Technologies > IM: richs...@jabber.at Twitter: RichSalz > ___ > 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 1.3 Key Schedule
See: http://www.ietf.org/mail-archive/web/tls/current/msg17184.html On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > In Section 7.1, the document says: > > 4. finished_secret = HKDF-Expand-Label(xSS, > "finished secret", > handshake_hash, L) > > 5. resumption_secret = HKDF-Expand-Label(master_secret, > "resumption master secret" > session_hash, L) > > Why don't we use the master_secret in both the finished_secret and the > resumption_secret formula? > > Russ > ___ > 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 1.3 Key Schedule
On Fri, Sep 4, 2015 at 8:58 AM, Russ Housley wrote: > Eric: > > I looked at Hugo's message in the context of the table in Section 7.1: > > Key ExchangeStatic Secret (SS)Ephemeral Secret (ES) > --- > (EC)DHE Client ephemeral Client ephemeral > (full handshake) w/ server ephemeral w/ server ephemeral > > (EC)DHE Client ephemeral Client ephemeral > (w/ 0-RTT)w/ server static w/ server ephemeral > > PSK Pre-Shared Key Pre-shared key > > PSK + (EC)DHE Pre-Shared Key Client ephemeral > w/ server ephemeral > > If I understand Hugo's message correctly, he is saying that in the second > row, the SS must be part of the key derivation. I think we need to > consider the bottom row as well. > > It seems to me that using the master_secret capture the benefits of both > the SS and the ES. This meets Hugo's requirement for the second row, and > gets the benefits of the ephemeral values for the bottom row. > I don't think you are reading that correctly. The point is that in the case where SS is authenticated (e.g., a PSK or a static DH), then the Finished MAC authenticates the ServerKeyShare. If you include ES in the Finished key, then you are using ES to authenticate ServerKeyShare, which apparently makes analysis harder. -Ekr Russ > > > On Sep 4, 2015, at 11:33 AM, Eric Rescorla wrote: > > See: > http://www.ietf.org/mail-archive/web/tls/current/msg17184.html > > On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > >> In Section 7.1, the document says: >> >> 4. finished_secret = HKDF-Expand-Label(xSS, >> "finished secret", >> handshake_hash, L) >> >> 5. resumption_secret = HKDF-Expand-Label(master_secret, >> "resumption master secret" >> session_hash, L) >> >> Why don't we use the master_secret in both the finished_secret and the >> resumption_secret formula? >> >> Russ >> > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PR for PSS support
https://github.com/tlswg/tls13-spec/pull/239 Based on the WG discussion, I've created a PR for adding support for PSS. The basic tactic I took is: - All in-protocol RSA signatures (i.e., in CertificateVerify) are PSS - You must use MGF1 with the same hash as you used for the content. - I added a rsa_pss SignatureAlgorithm field. The impact of this is that endpoints can sunset support for RSASSA-PKCS1 by omitting it from SignatureAlgorithms. Note that I didn't deprecate SHA-1 (something Hanno suggested) but I expect to in another PR based on WG consensus. Please take a look. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Should we require implementations to send alerts?
Issue: https://github.com/tlswg/tls13-spec/issues/242 In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: "Nobody must ever be *required* to send an alert. Any requirement for sending an alert should be SHOULD, at most." As Dave Garrett notes in the same thread, this is a common requirement throughout the specification and we recently have had requests to add more of these requirements. This is a global specification issue, so seems appropriate to discuss on-list. FWIW, I would note that the just approved session-hash draft contains such requirements as well: https://tools.ietf.org/html/draft-ietf-tls-session-hash-06#section-5.2 "In the following, we use the phrase "abort the handshake" as shorthand for terminating the handshake by sending a fatal "handshake_failure" alert." so it could be argued that this reflects recent WG consensus. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 2:13 PM, Martin Thomson wrote: > 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. > It seems like there are the following options: 1. Require termination and say nothing else 2. Require termination and suggest an alert. 3. Require termination and say that if you send an alert it must be X. 4. Require termination and say that you must send alert X. As you say, implementations can always terminate without sending alerts, however (at least in TLS 1.2) alerts served three purposes: 1. A secure indication of close (and for orderly close in the case of close_notify). 2. Session cache invalidation. 3. An indication to the other side of what went wrong. At least in the third cases, even if implementations can in principle close without sending alerts, they still serve a function and one might argue that that's a reason to encourage/require them. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 3:18 PM, Viktor Dukhovni wrote: > On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote: > > > "Nobody must ever be *required* to send an alert. Any requirement for > > sending an alert should be SHOULD, at most." > To be clear, you're quoting me quoting Brian Smith. This isn't my position. > Interoperability problems are hard enough to debug even when alerts > are sent, and they are *very* useful. If the peer just hangs up, > we don't know whether it crashed, refused service, enforced some > protocol or policy constraint, ... > > I help many users debug TLS connectivity issues, and would be > considerably hampered in this without alert information. > > -- > Viktor. > > ___ > 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] WGLC for draft-ietf-tls-cached-info-19
Sorry it's taken me so long to respond, but I'm not convinced that it's not necessary to have a secure digest here. Do you have a security analysis that demonstrates that that's the case? -Ekr On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson wrote: > 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 < > hannes.tschofe...@gmx.net> 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.
Re: [TLS] Review of PR #209
I think the potential issue here is needing a way for the server to tell the client "don't bother sending me data until you've authenticated" (though, as MT says, you could argue that the client's signature retroactively authenticates, which does seem like the simplest way to think about things). One might imagine dealing with that by a simple signal in a ServerHello extension that said "authentication will be required, sit tight..." -Ekr On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov wrote: > Martin's point makes sense to me: applications that need to do > authentication upfront can still do that immediately after the handshake. > > Cheers, > > Andrei > > -Original Message- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: Wednesday, September 16, 2015 10:48 AM > To: Ilari Liusvaara > Cc: Andrei Popov ; tls@ietf.org > Subject: Re: [TLS] Review of PR #209 > > On 16 September 2015 at 08:30, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly like > it does today, only the order has changed. > > > As then the application needs to ensure that the authentication occurs > > between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you have > no problem. I think that claim is reasonable, but I'm happy to discuss it. > > >> 2. The client can send Certificate and CertificateVerify at any time > >> application data is permitted, regardless of whether the server had > >> previously sent CertificateRequest. > > > > CertificateRequest contains the permitted signature algorithms for the > > PoP signature, which TLS library needs to verify before dumping the > > certificate chain on application (which can then figure out things > > like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms are > > acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll grant > that certificate chain validation often happens in a separate component to > the TLS stuff. > > > Basically, one must clear the pipeline before changing identities, and > > with protocols like HTTP/2, this is extremely expensive (seemingly > > even more expensive than establishing a new connecion). > > There's been some confusion about this with HTTP/2. I think that if you > adopt the position that authentication applies to the entire session - even > retroactively - then the only remaining concern is the correlation one. If > you have three tabs to the site open where all of them are making requests > and you see a certificate request, which one do you pop the dialog on? > > > Also, it should sign the certificate, to avoid possible weirdness due > > to signatures not properly binding the key (some schemes do, most > > don't). > > I agree with this. > ___ > 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] Review of PR #209
I should add: I do think this general line of consolidating all the client auth modes is a good idea, assuming we can work out the details. -Ekr On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla wrote: > I think the potential issue here is needing a way for the server to tell > the > client "don't bother sending me data until you've authenticated" (though, > as MT says, you could argue that the client's signature retroactively > authenticates, which does seem like the simplest way to think about > things). > > One might imagine dealing with that by a simple signal in a ServerHello > extension that said "authentication will be required, sit tight..." > > -Ekr > > > On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov > wrote: > >> Martin's point makes sense to me: applications that need to do >> authentication upfront can still do that immediately after the handshake. >> >> Cheers, >> >> Andrei >> >> -Original Message- >> From: Martin Thomson [mailto:martin.thom...@gmail.com] >> Sent: Wednesday, September 16, 2015 10:48 AM >> To: Ilari Liusvaara >> Cc: Andrei Popov ; tls@ietf.org >> Subject: Re: [TLS] Review of PR #209 >> >> On 16 September 2015 at 08:30, Ilari Liusvaara < >> ilari.liusva...@elisanet.fi> wrote: >> > Problem with pulling client auth out of the handshake is that it >> > complicates applications that can't change identities involved with >> > active connection. >> >> Why would that be unsupported here? The server can still send >> CertificateRequest immediately after its Finished. That looks exactly like >> it does today, only the order has changed. >> >> > As then the application needs to ensure that the authentication occurs >> > between TLS handshake and actually starting up the protocol. >> >> I'm not sure that is necessarily a problem. If the claim is that the >> authentication attests to everything prior to its appearance, then you have >> no problem. I think that claim is reasonable, but I'm happy to discuss it. >> >> >> 2. The client can send Certificate and CertificateVerify at any time >> >> application data is permitted, regardless of whether the server had >> >> previously sent CertificateRequest. >> > >> > CertificateRequest contains the permitted signature algorithms for the >> > PoP signature, which TLS library needs to verify before dumping the >> > certificate chain on application (which can then figure out things >> > like trust anchors). >> > >> > Without CertificateRequest, one has little idea what algorithms are >> > acceptable there. >> >> Arguably, signature_algorithms covers that adequately. Though I'll grant >> that certificate chain validation often happens in a separate component to >> the TLS stuff. >> >> > Basically, one must clear the pipeline before changing identities, and >> > with protocols like HTTP/2, this is extremely expensive (seemingly >> > even more expensive than establishing a new connecion). >> >> There's been some confusion about this with HTTP/2. I think that if you >> adopt the position that authentication applies to the entire session - even >> retroactively - then the only remaining concern is the correlation one. If >> you have three tabs to the site open where all of them are making requests >> and you see a certificate request, which one do you pop the dialog on? >> >> > Also, it should sign the certificate, to avoid possible weirdness due >> > to signatures not properly binding the key (some schemes do, most >> > don't). >> >> I agree with this. >> ___ >> 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] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 11:35 AM, Andrei Popov wrote: > To clarify, the proposal includes removing ECDH_anon, right? > Yes. > If it does, I support it. > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Joseph Salowey > *Sent:* Tuesday, September 15, 2015 6:01 PM > *To:* tls@ietf.org > *Subject:* [TLS] Call for consensus to remove anonymous DH > > > > There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. > > > > 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] Call for consensus to remove anonymous DH
In addition, they are already part of TLS, so the question would be if we have consensus to remove them -Ekr On Wed, Sep 16, 2015 at 2:01 PM, Nico Williams wrote: > On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote: > > I think it is a good idea to remove DH_anon_* and similar ECDH_anon_* > > cipher suites. > > > > This isn't an endorsement of the raw public key modes. > > Sure, one can always use self-signed certs (at an even higher cost to do > anonymity). If we're going to raise the cost of anonymity for the sake > of simplicity in TLS 1.3, do let's try to keep that cost from > escalating. Raw public keys are not a large additional complexity cost. > > ___ > 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] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 2:25 PM, Brian Smith wrote: > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > >> In addition, they are already part of TLS, so the question would be if we >> have >> consensus to remove them >> > > This thread is about the removal of DH_anon_*, not about raw public keys. > Yes, I'm aware of that. The point I was making was that presently we have: - Certificates - Raw keys - Anon This proposal is to remove Anon, thus making things strictly simpler, since Raw keys can replace Anon but not the other way around. One might imagine a proposal to remove Raw keys, but that's not the question here and even if that failed (as I expect it would) things will still be simpler if we remove Anon. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 2:24 PM, Nico Williams wrote: > On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote: > > On Wednesday, September 16, 2015, Eric Rescorla wrote: > > > > > In addition, they are already part of TLS, so the question would be if > we > > > have > > > consensus to remove them > > > > > > > I see a bunch of +1s and zero -1s. Just saying... > > I think Eric meant raw public keys. > Yes. I'm in favor of removing Anon, which is why I proposed it a few weeks ago. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 4:07 PM, Dave Garrett wrote: > On Wednesday, September 16, 2015 06:55:02 pm Nico Williams wrote: > > On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote: > > > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > > > > In addition, they are already part of TLS, so the question would be > if we > > > > have consensus to remove them > > > > > > This thread is about the removal of DH_anon_*, not about raw public > keys. > > > > Yes, but you implied that you might not support keeping raw public keys. > > > > I'm not in favor of removing the anon cipher suites if we also remove > > raw public key support. This is important. I don't want the cost of > > doing anon with TLS to escalate piecemeal. All cards on the table > > please. > > This appears to just be a miscommunication. > > On Wednesday, September 16, 2015 05:38:05 pm Eric Rescorla wrote: > > This proposal is to remove Anon, thus making things strictly simpler, > since > > Raw keys can replace Anon but not the other way around. One might imagine > > a proposal to remove Raw keys, but that's not the question here and even > if > > that failed (as I expect it would) things will still be simpler if we > > remove Anon. > > The current poll is to remove anon ciphers in favor of raw public keys. > We're not considering removing raw public keys, as far as I know, and I > think most of us would be against that. Isn't this what I said? -Ekr > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 5:31 PM, Daniel Kahn Gillmor wrote: > --dkg > > [0] I do not think that clients engaged in a DH key exchange should be > uniformly required to claim an identity at the TLS layer :) I agree with this and that's not the intention. -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
[TLS] Key Hierarchy
https://github.com/tlswg/tls13-spec/pull/248 Folks, Hugo Krawczyk, Hoeteck Wee, and Bjorn Tackmann suggested a revision to the key hierarchy that separates out the computation of the MS from the computation of the keys that are derived from ES and SS. Specifically, xES and xES are to be used to derive their respective traffic keys and intermediate values mES and mES which are then used with HKDF-Extract to generate MS. Aside from some analytic advantages, this also allows us to use the HKDF-Extract and HKDF-Expand APIs from RFC 5869 which is convenient (it's also compatible with all-in-one HKDF APIs). The PR is at: https://github.com/tlswg/tls13-spec/pull/248 I think this is a good change, but comments welcome. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Key Hierarchy
On Sun, Sep 20, 2015 at 6:56 PM, Brian Smith wrote: > On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/248 >> >> Aside from some analytic advantages >> > > What are the analytic advantages? > As I said, a clearer separation between the input keying material used to make traffic keys and that used to make keys which are then input into HKDF. > Also, a question that applied even to the older design: I remember the an > HKDF paper and the HKDF paper stating that before it is safe to use a value > as an HKDF salt, it must be authenticated. But, in both the old and new > designs it seems like an authenticated value is being used as the salt in > the HKDF-Extract(mSS, mES) operation. What does this mean for the security > analysis? > I'm going to defer this to Hugo and Hoeteck. > One of the notes in the new design draws some attention to the strange > fact that we compress the output of the ECDHE operation to the length of a > digest function that is independent of the length of the ECDH keys used. > For example, if we used P-256 in the ECDHE operation for a AES-128-GCM > cipher suite, we'd compress the output to 256 bits using HKDF-Extract with > SHA-256. But, if we used P-521 in the ECDHE operation for the same cipher > suite, we'd still compress the output to 256 bits using HKDF-Extract with > SHA-256. That seems wrong. > Why? Note that the next thing we are going to do is use this keys to generate keys which are generally <= 256-bits. It's also worth noting that previous versions of TLS behaved this way as well. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
"Versions of TLS prior to 1.3 had limited support for padding. This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types. The design also enforces all-zero padding octets, which allows for quick detection of padding errors. " On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett wrote: > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > That has this: > > > For padding, we reached a very rough consensus to start with the content > type followed by all zeros (insert reasons why) over the explicit length > option (insert reasons why). DKG to propose a PR that we'll then fight out > on the list. See PR #253. > > The "reasons why" that were discussed were not inserted. ;) > > > 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] '15 TLS Fall Interim Minutes
On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote: > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > Minutes: > > > ## Issue 223 - absolute or relative time > > > > Leave as-is because a) switching to relative time is painful and it's > > not standalone, b) it's not entirely clear what > benefit we get from > > this, and c) we're already using absolute time for other things like > > certificates & OCSP. > > One thing to note: The time is 4 octets, and 32 bit time since unix > epoch runs out a good bit faster than what I would like. > I will fix this. > > ## Client Authentication > > > > We agreed that we need to support this in TLS 1.3. > > > > ### How > > > > 2. We will modify the data that's signed to conform with what Andrei > > is proposing provided we also terminate the transcript for key > > derivation before the CC/CCV. > > Oh yay, Server 0-RTT? > Yes, the server can send immediately after receiving the first flight. > investigate: using the same construct for server/client sigs. > > Huh? Don't both currently use the same construct, except for the > context string? Are you proposing to remove the context string or > what? > The idea on the table was to use an exported value to match Token binding. Input needed here. > > 5. We agreed to take out the ClientCertificatType from > CertificateRequest. > > Yeah, that one is not needed for anything. > > > 6. We want a consolidated certificate message and certificate verify. > > Just be careful that certificate is still signed, as many signature > algorithms fail to even properly bind the key, and nothing binds the > certificate. > Yes, there was consensus to include the certificate. > # Include randoms directly in digital signatures > > > > Issue 224 > > > > Consensus at the interim was that this has straightforward to do by > > just having the authentication server supply the ServerRandom was > > enough since it can search through the handshake transcript. > > This assumes that authentication server receives full handshake and > not just handshake To-Be-Signed. > There was a lot of confusion at the interim about whether the concern here was an auth server at the attesting party or the relying party. > > # PRF designation in server certificate verify > > > > Issue 227 > > > > Consensus was to leave as-is. A hash identifier isn't the way to > > solve this. What you really need is contributory behavior to solve > > this issue. > > Huh? This is about collisions between different hash algorithms. I > don't see how contributory behavior would help there (which is severly > limited by 1RTT maximum there). > > Now, the issue is probably entierely theoretical and thus would not > need solving. There was confusion about this too. Could you provide a (perhaps contrived) example of the attack you are concerned about and a mechanism which would defend against it? Thanks, -Ekr > > > -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] '15 TLS Fall Interim Minutes
On Fri, Sep 25, 2015 at 6:13 PM, Dave Garrett wrote: > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of > it in the minutes. (it's a suggestion from Karthik to generate a new client > random on retry) > > Did this get discussed? > > https://github.com/tlswg/tls13-spec/issues/185 > > No. -Ekr ___ 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 Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote: > > > 1) We know CRIME threat, but it can not be risk for everyone. > > e.g., CVSS v2 Base Score: 2.6 (LOW) > > CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called > it 7.5 > > > Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > > They are equivalent. If you use AES-GCM and ECDHE, and you don't need > 0RTT, then there is no compelling reason to use TLS 1.3. I don't want to take a position on what's compelling or not, but there are a number of other reasons to use TLS 1.3, including support for real padding, encrypted content types, privacy for client authentication, etc. -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] TLS 1.3 - Support for compression to be removed
On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito wrote: > > On 2015/10/02, at 22:59, Roland Zink wrote: > > > Browsers are not a concern as they already have their own comp/decomp > codes. HTTP/1 can compress content (Content-encoding and transfer-encoding) > and HTTP2 has additional header compression. > > > > Regards, > > Roland > > > > I see, > but contrary, > tls is only for browser? > > And more, > if you kick out comp/decomp from tls, > can we be safer when we use tls? > If you know the paper, please teach me. > > Or, rfc or good teacher should notify us, > "When you use TLSv1.3, you never use compression, sorry!" > That is what the document says: "Versions of TLS before 1.3 supported compression and the list of compression methods was supplied in this field. For any TLS 1.3 ClientHello, this field MUST contain only the “null” compression method with the code point of 0. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST generate a fatal “illegal_parameter” alert. Note that TLS 1.3 servers may receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS." -Ekr > I know it may be out scope, > but we have to estimate the risk. > > regards, > > > > > > Am 02.10.2015 um 15:08 schrieb takamichi saito: > >>> Do we know how many protocols currently suffer from CRIME? > >>> > >>> > >>> Maybe a best practice could be suggested by UTA for the implementation > of TLS in software, to disable compression if vulnerable. And for the > others, to implement a way to enable/disable compression in case one day a > vulnerability is found. > >> I agree. > >> > >> Again, > >> > >> 1) We know CRIME threat, but it can not be risk for everyone. > >> e.g., CVSS v2 Base Score: 2.6 (LOW) > >> > >> 2) If we need to have comp/decomp in an application layer, > >> clients such like browser need their own comp/decomp codes. > >> > >> 3) If there is no comp in tls1.3, some people may continue to use > tls1.2. > >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > >> > >> That's why we explore the way to keep compression in TLSv1.3. > >> How about making an option only in server-side? > >> The spec has the compression but default is off, and also provides the > suggestion. > >> > >> > >>> -- > >>> Julien ÉLIE > >>> > >>> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. » > >>> > >>> ___ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >> ;; takamixhi saito > >> c2xhYWlidHNvcw > >> > >> ___ > >> 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 > > > ;; takamixhi saito > > ___ > 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 1.3 - Support for compression to be removed
On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote: > >> Typically compression is used to lower the overall size of data, > working on > >> a wide class of inputs. In the perceptual coding case the class of > inputs > >> is constrained, and the goal is to keep the data rate constant, not > >> optimally small. > > > > Yep. You could do this in bursts with different caps each time to get it > to work with bursty things like HTTP & other general data transfer > protocols. Without a really good modern compression algorithm, though, it > isn't that appealing. Once these caveats and tweaks start getting added to > the simple concept, it starts treading into the territory that is better > handled by the application protocol that actually *knows what it's > sending*. This seems to be the logical wall we keep hitting, which is why > TLS doesn't seem like the place to do this. > > > I think two concepts are blending into one You appear to be > arguing for efficiency, and I'm more concerned with safely/securely. > > I'm fairly certain the internet community at large would benefit from > "compression done safely/securely", even if its not the most > efficient. If the application layer wants to provide a more efficient > implementations, then that's fine too. > > I think this I where things now stand (if I am surveying correctly): > (1) TLS WG did not fix the problem (bad); (2) users don't have a > choice (bad); (3) applications will have to provide their own > compression when desired, which will likely increase overall risk for > users (bad). For (3) keep in mind browsers are not the only user > agents or consumers of web services. > The problem is that we don't know how to generically provide compression safely. To take a concrete example: HTTP2's solution to header compression, HPACK, is extremely limited compared to a generic compression system like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet we still know that there are potential security problems [0]. Doing something generically secure is much harder. If you have a solution to this problem, then great. But the mere fact that it's desirable doesn't mean we have an answer. -Ekr [0] Specifically, that the attacker can confirm specific guesses about the contents of a header field. > All-in-all, I think its a win for NSA, GCHQ and other miscreants; and > an overall loss for user. > > Jeff > > ___ > 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 1.3 - Support for compression to be removed
On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton wrote: > On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich wrote: > >> There are many lessons to be learned from this: that a bearer token > that is > >> repeated many times is not a good idea; that the trust model in the web > is > >> not great; but also that blindly compressing content with no regard to > its > >> structure and sources is dangerous and reveals information about the > >> cleartext. A security protocol should not do that. > > > > This is a great note, and excellent explanation. > > I'm not sure about some of it (I'm not trying to be argumentative). > > If compression leaks information from a structured message, then > surely an uncompressed message leaks the same information. No, not when they are encrypted. Consider the trivial case of ASCII text. Each character takes up the same amount of room, but if you compress (as an intuition pump, think of a simple Huffman code), then more common characters take up less room than less common characters. For a more complicated case, see: http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf -Ekr > As Kurt > eloquently put it, only the density of the information changed. > Naively, that means the encryption services are defective, and not > compression. > > Or maybe I should back pedal and ask: when is it safe to use TLS with > a structured message? Is it safe to use with HTTP? How about SMTP? If > HTTP always sends the cookie in the same position in unique messages, > then wouldn't that mean its not safe to use with HTTP over TLS? > > Perhaps I'm missing something obvious > > Jeff > > ___ > 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 1.3 - Support for compression to be removed
On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson wrote: > On 4 October 2015 at 19:26, Eric Rescorla wrote: > > Consider the trivial case of ASCII text. Each character takes up the > > same amount of room, but if you compress (as an intuition pump, > > think of a simple Huffman code), then more common characters > > take up less room than less common characters. > > This is right, but it's also not the case that revealing information > like that is necessarily bad. I didn't say it was. But it's also leaking information that the encryption didn't, which is intended as a simple counterexample to Jeffrey's claim. HPACK for instance compresses base64-encoded data unevenly. But the > study that was run in 2013 determined that it wasn't especially > interesting. [32] shows ~2 bits regained from a 30 character word. Of > course, you should examine the conditions on that claim; such a result > is not generally applicable. Mixing attacker-controlled data with > secrets has shown to make protecting those secrets extremely > difficult. > 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. -Ekr ___ 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 Wed, Oct 7, 2015 at 9:51 PM, Martin Rex wrote: > Eric Rescorla wrote: > > > > That is what the document says: > > "Versions of TLS before 1.3 supported compression and the list of > > compression methods was supplied in this field. For any TLS 1.3 > > ClientHello, this field MUST contain only the ?null? compression method > > with the code point of 0. If a TLS 1.3 ClientHello is received with any > > other value in this field, the server MUST generate a fatal > > ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 > or > > prior ClientHellos which contain other compression methods and MUST > follow > > the procedures for the appropriate prior version of TLS." > > The quoted wording calls for a fatal handshake failure when ClientHello > offers > > TLSv1.2+compression _or_ TLSv1.3 > > while at the same time the last requirement asserts that a ClientHello with > > TLSv1.2+compression > > is perfectly OK. To me, this looks quite odd. > That's not how I read this text. Rather, I read it as: If ClientHelloVersion >= TLS 1.3 then the compression field must be empty else: the compression field is dictated by other versions This doesn't seem inconsistent to me. If you still think that the paragraph reads differently, can you help me by diagramming it? > If you want compression removed from TLSv1.3, how about something like > this: > > > "Versions of TLS before 1.3 supported compression and the list of > compression methods was supplied in this field. > All TLS protocol > versions require the "null" compression method MUST be included/present > in the compression_methods list of ClientHello. A TLSv1.3 server that > is offered and selects/negotiates protocol version TLSv1.3, MUST select > the "null" compression method, and MUST ignore all other compression > methods that might appear in the compression_methods list of ClientHello. > > > Btw. for the last requirement, I would appreciate an additional > recommendation > for a configuration option to disable compression, maybe something like > > This document does not impose restrictions on the use of compression > with TLS protocol versions prior to TLSv1.3. However, it is RECOMMENDED > that implementations which support compression provide a configuration > option allowing consumers to disable the use of compression in TLS. > > > -Martin > ___ 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 Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > >> Eric Rescorla wrote: > >>> > >>> That is what the document says: > >>> "Versions of TLS before 1.3 supported compression and the list of > >>> compression methods was supplied in this field. For any TLS 1.3 > >>> ClientHello, this field MUST contain only the ?null? compression method > >>> with the code point of 0. If a TLS 1.3 ClientHello is received with any > >>> other value in this field, the server MUST generate a fatal > >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS > 1.2 > >>> or prior ClientHellos which contain other compression methods and MUST > >>> follow the procedures for the appropriate prior version of TLS." > >> > >> The quoted wording calls for a fatal handshake failure when ClientHello > >> offers > >> > >> TLSv1.2+compression _or_ TLSv1.3 > >> > >> while at the same time the last requirement asserts that a ClientHello > with > >> > >> TLSv1.2+compression > >> > >> is perfectly OK. To me, this looks quite odd. > > > > That's not how I read this text. > > > > Rather, I read it as: > > If ClientHelloVersion >= TLS 1.3 > >then the compression field must be empty > > else: > >the compression field is dictated by other versions > > > > This doesn't seem inconsistent to me. If you still think that the > paragraph > > reads differently, can you help me by diagramming it? > > What you describe would be considerable worse that what I understood, > because it would mean that a TLSv1.3 ClientHello will be unconditionally > invalid for a TLSv1.2 server. > >https://tools.ietf.org/html/rfc5246#page-42 > >compression_methods > This is a list of the compression methods supported by the client, > sorted by client preference. If the session_id field is not empty > (implying a session resumption request), it MUST include the > > Dierks & Rescorla Standards Track[Page 41] > > RFC 5246 TLSAugust 2008 > > *>compression_method from that session. This vector MUST contain, > *>and all implementations MUST support, CompressionMethod.null. > Thus, a client and server will always be able to agree on a > compression method. Sorry, I spoke carelessly. It must contain solely the null method. -Ekr ___ 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 Wed, Oct 7, 2015 at 11:28 PM, Short, Todd wrote: > However, for those ClientHello’s that support older versions, the > compression_method field may contain other values. This means that if a > TLSv1.3 client happened to support compression for TLSv1.2, it would be > unable to negotiate that via a single ClientHello. There’s no way to > attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a > single ClientHello. > > In effect, the document is stating that a TLSv1.3 client MUST NOT support > compression, regardless of the protocol version that may be negotiated. > Yes, this is what I believe it says and what I believe the WG had consensus on, the reasoning being that we really wished to just remove the feature entirely. If the chairs declare consensus on something else, I will of course edit it to say something else. -Ekr -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Oct 7, 2015, at 5:15 PM, Eric Rescorla wrote: > > > > On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote: > >> Eric Rescorla wrote: >> > Martin Rex wrote: >> >> Eric Rescorla wrote: >> >>> >> >>> That is what the document says: >> >>> "Versions of TLS before 1.3 supported compression and the list of >> >>> compression methods was supplied in this field. For any TLS 1.3 >> >>> ClientHello, this field MUST contain only the ?null? compression >> method >> >>> with the code point of 0. If a TLS 1.3 ClientHello is received with >> any >> >>> other value in this field, the server MUST generate a fatal >> >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS >> 1.2 >> >>> or prior ClientHellos which contain other compression methods and MUST >> >>> follow the procedures for the appropriate prior version of TLS." >> >> >> >> The quoted wording calls for a fatal handshake failure when ClientHello >> >> offers >> >> >> >> TLSv1.2+compression _or_ TLSv1.3 >> >> >> >> while at the same time the last requirement asserts that a ClientHello >> with >> >> >> >> TLSv1.2+compression >> >> >> >> is perfectly OK. To me, this looks quite odd. >> > >> > That's not how I read this text. >> > >> > Rather, I read it as: >> > If ClientHelloVersion >= TLS 1.3 >> >then the compression field must be empty >> > else: >> >the compression field is dictated by other versions >> > >> > This doesn't seem inconsistent to me. If you still think that the >> paragraph >> > reads differently, can you help me by diagramming it? >> >> What you describe would be considerable worse that what I understood, >> because it would mean that a TLSv1.3 ClientHello will be unconditionally >> invalid for a TLSv1.2 server. >> >>https://tools.ietf.org/html/rfc5246#page-42 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5246-23page-2D42&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=IxUTnzF6SN6y6C4zTXXfgQmiV1FojXWtLZ0S8hS5eGY&s=Uu3NPBs1t52N_fGVGPqXazTAStG7cPUeCfNh6eCTtkk&e=> >> >>compression_methods >> This is a list of the compression methods supported by the client, >> sorted by client preference. If the session_id field is not empty >> (implying a session resumption request), it MUST include the >> >> Dierks & Rescorla Standards Track[Page 41] >> >> RFC 5246 TLSAugust 2008 >> >> *>compression_method from that session. This vector MUST contain, >> *>and all implementations MUST support, CompressionMethod.null. >> Thus, a client and server will always be able to agree on a >> compression method. > > > Sorry, I spoke carelessly. It must contain solely the null method. > > -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] tls-unique
On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson wrote: > The notes from the interim meeting mentions 'tls-unique' and points to > issue #228 on github. I want to get your attention on the draft below. > Doesn't it do what you are looking for? There is a little in the way of > a problem statement in the TLS interim meeting notes, so it is hard to > tell what the perceived problem with 'tls-unique' is in this context. > Does my draft need to be updated for TLS 1.3 in any way? It might serve > as a starting point for future work. > > https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. With that said, I don't really understand the structure of your draft: Instead of referencing the PRF and session_hash directly, why not instead use RFC 5705 exporters and require the use of the session_hash extension? Then TLS 1.3 can just define exporters for 1.3 and we'll be done. -Ekr > /Simon > > ___ > 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-unique
On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson wrote: > Eric Rescorla writes: > > > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson > > wrote: > > > >> The notes from the interim meeting mentions 'tls-unique' and points to > >> issue #228 on github. I want to get your attention on the draft below. > >> Doesn't it do what you are looking for? There is a little in the way of > >> a problem statement in the TLS interim meeting notes, so it is hard to > >> tell what the perceived problem with 'tls-unique' is in this context. > >> Does my draft need to be updated for TLS 1.3 in any way? It might serve > >> as a starting point for future work. > >> > >> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 > > > > > > Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. > > > > With that said, I don't really understand the structure of your draft: > > Instead of referencing the PRF and session_hash directly, why not instead > > use RFC 5705 exporters and require the use of the session_hash > > extension? > > The introduction says: > >There exists a TLS extension [I-D.ietf-tls-session-hash] that modify >TLS so that the definition of 'tls-unique' [RFC5929] has the intended >properties. If widely implemented and deployed, the channel binding >type in this document would not offer any additional protection. The >purpose of this document is to provide an alternative channel binding >that offers the intended properties without requiring TLS protocol >changes. However, keep in mind that TLS implementations needs to >offer the appropriate APIs necessary to be able to implement the >channel binding described in this document. > > I agree that one alternative is to require session_hash for all > connections. Given that you need to modify *some* software in any case, it seems like one ought to adopt session-hash. > But then what is the problem with use of 'tls-unique'? > The general consensus is that 96 bits is too short. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] tls-unique
On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote: > > > The introduction says: > > > > > >There exists a TLS extension [I-D.ietf-tls-session-hash] that > > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the > > > intended properties. If widely implemented and deployed, the > > > channel binding type in this document would not offer any > > > additional protection. The purpose of this document is to provide > > > an alternative channel binding that offers the intended properties > > > without requiring TLS protocol changes. However, keep in mind that > > > TLS implementations needs to offer the appropriate APIs necessary > > > to be able to implement the channel binding described in this > > > document. > > > > > > I agree that one alternative is to require session_hash for all > > > connections. > > > > > > Given that you need to modify *some* software in any case, it seems > > like one ought to adopt session-hash. > > The problem is if you want to resolve this at the application level and > don't have sufficient control over the TLS layer to influence it to > negotiate session-hash. This is the situation for many SASL > applications. > > If universal adoption of session-hash is a prio, then there is no > problem. While RFC 7627 updates 5246 it does not talk a lot about what > it actually updates in 5246, or I missed it, and I haven't seen > session-hash functionality back-ported to deployed code. > I'm not sure what you mean by "backported", but I believe that BoringSSL presently has session-hash, SChannel has it soon or does already, and the next version of NSS (3.21) will have it. My current approach works with or without session-hash negotiated, but > requires that you can get the session_hash value out of the TLS stack. > I am not aware of a stack which has this function. Are you? -Ekr Another approach is to say that if session-hash is in use, it uses a > simple TLS exporter API call, and if it is not, it has to use TLS > exporter API on the session_hash value. This would secure all cases. > > > > But then what is the problem with use of 'tls-unique'? > > > > The general consensus is that 96 bits is too short. > > I agree -- I used 256 bits. > > /Simon > ___ 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 Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Short, Todd wrote: > >> > >> However, for those ClientHello?s that support older versions, the > >> compression_method field may contain other values. This means that if a > >> TLSv1.3 client happened to support compression for TLSv1.2, it would be > >> unable to negotiate that via a single ClientHello. There?s no way to > >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a > >> single ClientHello. > > Yup, that is the problem with the current text. Thanks for clarifying this. > > > > > >> In effect, the document is stating that a TLSv1.3 client MUST NOT > support > >> compression, regardless of the protocol version that may be negotiated. > > > > Yes, this is what I believe it says and what I believe the WG had > consensus > > on, the reasoning being that we really wished to just remove the feature > > entirely. If the chairs declare consensus on something else, I will of > > course edit it to say something else. > > The current text is trying to force a specific policy in a fashion > that is in the worst conceivable violation of rfc2119 section 6 that > is possible. > > A ClientHello with > > ClientHello.client_version = (3,3) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. > > > ClientHello.client_version = (3,4) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, > but TLSv1.3 servers that follow the stupid idea will choke and > abort with an "illegal_parameter" alert. > > Essentially, the current wording is calling for a newly creating what > must be called a "compression method intolerance" -- but essentially > it is indistinguishable from a "TLS version intolerance" Hmm... I'm not sure I follow this argument. We have a bunch of rules for how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if they don't. This doesn't create any present interop problem and only creates a problem if in future we wish to reintroduce compression. Is that your concern? > For a number of years, it seemed to have been consensus in the IETF TLS WG > that TLS version intolerance is an implemenattion defect and a real > problem. > It would be sad if the current TLS WG would confirm that recklessly adding > handshake failure causing new intolerances into TLSv1.3 is the new > engeneering approach. As I said, I edited the document in conformance with what I believed the chair declaration of WG consensus was. If the WG consensus is to remove this requirement, then I will of course do so. So, rather than going back and forth, I would suggest that the best way for you to proceed here is to: 1. Ask the chairs to re-state the previous consensus. If I misunderstood, then that's easy. 2. If you're still not happy, then you could ask the chairs to re-assess the currnet consensus. 3. If you're still not happy, and you believe this violates 2119, then you can of course appeal. This of course also goes for people who think we should re-allow compression. Best, -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PR for anti-downgrade mechanism
Hi folks, Please take a look at the following PR which documents a suggestion made by Karthik Bhargavan about how to prevent protection against downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. https://github.com/tlswg/tls13-spec/pull/284 The idea is that if a TLS 1.3 server receives a TLS 1.2 or below ClientHello, it sets the top N bits of the ServerRandom to be a specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below ServerHello check for this value and abort if they receive it. This allows for detection of downgrade attacks over and above the Finished handshake as long as ephemeral cipher suites are used (because the signature on the ServerKeyExchange covers the random values). No protection is provided for static RSA cipher suites, but this still has some value if you have an attack which only affects (EC)DHE. I've written this up with 48 bits and a specific fixed value (03 04 03 04 03 04) but that's just a strawman and we can bikeshed on that if people think this is a good idea. Thanks, -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > > > For reference, the version field in the TLS premaster secret is not > checked by many servers, IIRC some of them have large market shares. > > That’s good to know. It would be tempting to recommend that TLS 1.3 > servers disable RSA (encryption) ciphersuites for all protocol versions, > but I guess this is not likely to happen for backwards compatibility > reasons? This seems like RFC 6919 Territory: https://tools.ietf.org/html/rfc6919#section-1 -Ekr > > > -- > > Sincerely, > > Yngve N. Pettersen > > > > ___ > > 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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd wrote: > > > On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan < > karthik.bharga...@gmail.com> wrote: > > - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will > be dropped by >TLS 1.3 clients, because of this proposal. This only happens for > servers that do not >use the unix timestamp (the current timestamp is greater than 0304). >Still, we need to carefully choose N so that this risk of connection > dropping is acceptable. > > > I’m thinking this chance can be reduced to 0. > Wouldn’t a TLSv1.3 client be able to recognize that it’s connecting to a > TLSv1.2 server, and not parse the first N bits of the server random? > The idea is to distinguish this case from the case where they are connecting to an attacker pretending to be a TLS 1.2 server. -Ekr -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
It's largely arbitrary, but the reasoning is as follows. There are
apparently
some TLS 1.2 servers which randomly generate the entire server random
(and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would
encourage more to do so). The chance of a false positive between such
a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high.
-Ekr
On Fri, Oct 9, 2015 at 10:15 PM, Dave Garrett
wrote:
> On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/pull/284
> >
> > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> > ClientHello, it sets the top N bits of the ServerRandom to be a
> > specific fixed value.
> [...]
> > I've written this up with 48 bits and a specific fixed value (03 04 03
> > 04 03 04) but that's just a strawman and we can bikeshed on that if
> > people think this is a good idea.
>
> I support this, though I would like to know why 6 bytes was chosen instead
> of just 4. I don't object; I would just like to know the reasoning here.
>
>
> Dave
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recognize sentinel values from all future versions,
> not just this one. Thus, for future proofing, (just) using the version
> number isn't a great idea. It's probably safest to just pick one static
> value and be done with it forever.
>
That may be true, but then this value is as good as any other.
An alternative would be to burn N-8 bits on a sentinel and then
8 bits on the version number. E.g.,
01 02 03 04 05 34 [0]
BTW, I'm basically indifferent between 48 and 64 bits.
-Ekr
[0] I didn't use 00 00 00 00 00 as the sentinel because I have some vague
memory
that there are implementations which use 0s in the timestamp.
And now, for my proposed bikeshed color:
>
> 0x0b501e7e5e1ec7ed
> ("obsoleteselected"; 64-bit value)
>
> I'd like to say I was clever enough to come up with neat hex words, but I
> Googled for a list and found 2 to put together. ;)
>
>
> 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] banning SHA-1 in TLS 1.3, a new attempt
On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett wrote: > In light of completely unsurprising recent events [0], I think it's time > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. > Currently, it's allowed if needed by servers that have nothing better [1]. To be clear, the only thing that's allowed is SHA-1 in *certificates*. It's forbidden in CertificateVerify. -Ekr > I propose we stop playing around and just prohibit it under TLS 1.3+. > Implementations that can negotiate nothing better would be permitted to > fall back to TLS 1.2 with the security restrictions currently in the draft > [2] (which is still a concession I'd rather not make, but it's currently > needed). I have submitted a PR [3] to this effect in order to have specific > text to discuss here, though WG consensus and chair approval is of course > required to change the current status. > > Please note that TLS 1.3 is not coming out tomorrow, nor will its > deployment be instant. By the time servers even decide to consider an > upgrade, SHA-1 will be in an even less secure state than it already is. > > To answer the obvious question: Prohibiting it in new versions reduces the > risk of mistakes, draws a clear line where support is killed, and puts an > actual impetus on PKI to transition faster. TLS 1.2 is potentially > vulnerable, depending on configuration (nothing new there), but TLS 1.3 > should be known to be secure in all valid configurations. The discussion to > have with non-experts should not be about specific algorithms to pick and > choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, > etc. etc.); we should be able to point at the current version and say "use > this, not the old thing", or we can't expect it to be understood and taken > seriously. > > [0] https://sites.google.com/site/itstheshappening/ > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 > [2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3 > [3] https://github.com/tlswg/tls13-spec/pull/287 > > > 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] I-D: CipherSuites for Kerberos + DH
This seems like a good approach. -Ekr On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: > > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > >> > *From:* internet-dra...@ietf.org > >> > > >> > Name: draft-vanrein-tls-kdh > >> > Revision: 00 > >> > >> Hello TLS WG, > >> > >> I would like to propose new CipherSuites for TLS. The cryptography is > >> founded on Kerberos authentication and DH encryption, cryptographically > >> bound together. The mechanism uses mutual authentication, although > >> clients may use anonymous tickets. > >> > >> Any feedback that you may have (technical, or WG-procedural) is kindly > >> welcomed. I will also send this to the Kitten WG. > > > > Some quick comments: > > - The signed DH share does not look to be bound to anything (crypto > > parameters negotiation, randoms, server key exchange, etc..). I can't > > offhand say what that would lead to, but it looks even worse than > > TLS ServerKeyExchange, which has known vulernabilities due to > > lack of binding to things like ciphersuite. > > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > > - Even use of DH is questionable. > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > > Sincerely, > Watson > > ___ > 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] TRON workshop
On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote: > > Hiya, > > > > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're > > all aware that this is important stuff that needs to be, and is being, > > done carefully with due attention to security analysis. > > > > Early in the process we had some brief discussion of pausing towards > > the end of the work to give folks a chance to do analyses of the > > security and other properties of TLS1.3 just before publication of > > the RFC. > > > > Chatting with the chairs in Prague and with various others since, we > > think we've reached the point where we need to start executing that > > bit of the plan, since doing such analyses also takes time and we > > don't want to add a big delay if we can avoid it. So we're organising > > a workshop on just that topic to be co-located with NDSS in San Diego > > in late February 2016. > > aren't we still missing the 0-RTT mode? It's in the current draft though there are a few details that we're going to need to nail down over the next few weeks and in Yokohama. -Ekr - > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > ___ > 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] TRON workshop
On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara wrote: > On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > > > > > aren't we still missing the 0-RTT mode? > > > > It's in the current draft though there are a few details that we're > > going to need to nail down over the next few weeks and in Yokohama. > > IMO, that should be nailed rather quick, given that that what there > is right now isn't really sufficient to analyze it. > Yes, that's the plan, as noted above. > However, some comments about 0-RTT: > > > 1) It seems to me that if server key is compromised, MITM can > substitute 0-RTT data with its own (at least if original and modified > one have the same number of records). And such modification will not > be detected by handshake, which will complete successfully. > > Perhaps the comment about impersonation with compromised server key > was about this (I can't get more usual types of attacks to work)? > Yes, that's the idea. 2) If static client authentication is used with 0-RTT data, the client > authentication always preceeds 0-RTT data (it is first in early > handshake, and using 1-RTT client auth is forbidden). This seems to > imply 0-RTT data should be interpretted in an authenticated context, > which seems dangerous given the replayability of the 0-RTT data. > Well remember that applications already have this problem because they send cookies and the like in their HTTP requests. So, I don't know how much this alters the analysis. And yes, we do have settings where we need this 3) The document talks about making 0-RTT data unreplayable by using > extra identifier agreed out-of-band. Does that actually work, given > the likely auto-replay by the client? I'm assuming that in these cases the server has global state and so doesn't have a problem. -Ekr > > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New curves work and TLS
On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett
wrote:
> On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> > Ed448ph. And keys MUST NOT be mixed between those.
> >
> > I propose the following:
> > - EdDSA uses one SignatureAlgorithm value (5?[1]).
> > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and
> > another for Ed448/Ed448ph
> > - If there is ever EdDSA instantiation with Edwards448 curve (the same
> > one Ed448 uses) with another KDF, it gets a new curve distinct from
> > Ed448/Ed448ph.
> > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or
> > value matching the prehash (but the prehash is always done once[2]).
> > [TBD: resolve this]
>
> I've been thinking about the issue of how to handle
> SignatureAndHashAlgorithm values better. I think this time, I'd like to
> propose going the opposite way we'd normally want to move: let's consider
> enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of
> having independent values. We're moving to signature algorithms that don't
> have arbitrary hashes, so the current system isn't really ideal anymore.
>
> Current draft:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1
> (text)
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88 (full
> registry)
>
> enum {
> none(0),
> md5_RESERVED(1),
> sha1(2),
> sha224_RESERVED(3),
> sha256(4), sha384(5), sha512(6),
> (255)
> } HashAlgorithm;
>
> enum {
> anonymous_RESERVED(0),
> rsa(1),
> dsa(2),
> ecdsa(3),
> rsapss(4),
> (255)
> } SignatureAlgorithm;
>
> struct {
> HashAlgorithm hash;
> SignatureAlgorithm signature;
> } SignatureAndHashAlgorithm;
>
>
> Proposed replacement backwards-compatible registry:
>
> struct {
> anonymous_RESERVED(0x),
> rsa_nohash(0x0001),
> dsa_nohash(0x0002),
> ecdsa_nohash(0x0003),
> rsapss_nohash(0x0004),
> md5_RESERVED (0x0100..0x01FF),
> rsa_sha1(0x0201),
> dsa_sha1(0x0202),
> ecdsa_sha1(0x0203),
> rsapss_sha1(0x0204),
> sha224_RESERVED (0x0300..0x03FF),
> rsa_sha256(0x0401),
> dsa_sha256(0x0402),
> ecdsa_sha256(0x0403),
> rsapss_sha256(0x0404),
> rsa_sha384(0x0501),
> dsa_sha384(0x0502),
> ecdsa_sha384(0x0503),
> rsapss_sha384(0x0504),
> rsa_sha512(0x0601),
> dsa_sha512(0x0602),
> ecdsa_sha512(0x0603),
> rsapss_sha512(0x0604),
> (0x)
> } SignatureAndHashAlgorithm;
>
>
> New values could be assigned specific combinations as needed. This would
> also let hashes & signatures be deprecated independently easily, e.g. allow
> rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from
> the start).
I am not in favor of this change. Because we can already indicate
combinations, this
doesn't seem to add significant new value. If we need to indicate
"signature algorithm
without a hash" then a "none" hash is the simplest solution.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
Trying to close the loop on this, I think people are generally in favor of this mechanism, so we just need a concrete construction. I propose we use an N bit field divided as follows - N - 8 bits of fixed sentinel. - 8 bits of version number with the semantics being the highest TLS version number supported by the server, encoded with the high nibble being the major version and the low version being the minor version. So, concretely a TLS 1.3 implementation would use 0x34 here. I imagine people have opinions about N and the sentinel, but for concreteness I suggest that N = 64 bits, and that we use the ASCII string 'DOWNGRD' as the sentinel. Let the bikeshedding begin! -Ekr On Fri, Oct 16, 2015 at 11:23 PM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2 > implementations to signal each other about their preferred connection > parameters. > > To make most use of the bytes provided, one could use the sentinel value > to indicate > support for an extension, which then carries a signed server configuration > of arbitrary size. > The attacker would then be unable to downgrade the connection by deleting > this extension. > > False Start is an interesting use case, because > (a) it sends data before the server has confirmed the chosen > version/ciphersuite/etc and > (b) it already tries to prevent downgrades by whitelisting versions and > ciphersuites. > Some downgrade attacks fail because of (b), but others are easier to > exploit because of (a). > For example, Logjam was easier to mount on False Start clients since the > attacker could > collect the False Start data and decrypt it at leisure. > > Extended master secret (EMS) provides some additional protection to False > Start, because the encryption > keys implicitly include the full handshake transcript and, so if the MitM > tampers with the connection, > the False Start data would not be accepted by a server. (However, that > this would not have prevented Logjam.) > Moreover, even the EMS extension can be deleted by a MitM. > The current proposal could protect EMS from downgrade by indicating > support for it in the server hello. > > To sum up, we’re focusing on TLS 1.3 because we have a chance to bake in > strong downgrade protection > into its implementations from the very beginning. I think this could be > useful for older versions too, as an optional > mechanism which protects clients and servers that both implement it, and > does not affect others. > > -Karthik > > On 17 Oct 2015, at 00:34, Brian Smith wrote: > > On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson > wrote: > >> 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? >> > > Yes. The client needs the sentinel to know to abort the connection, if its > willing to false start with TLS 1.2 when it also support TLS 1.3, right? > > Cheers, > Brian > -- > https://briansmith.org/ > > > > ___ > 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 for anti-downgrade mechanism
On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni wrote: > On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote: > > > Trying to close the loop on this, I think people are generally in favor > of > > this > > mechanism, so we just need a concrete construction. > > > > I propose we use an N bit field divided as follows > > > > - N - 8 bits of fixed sentinel. > > - 8 bits of version number with the semantics being the highest TLS > version > > number supported by the server, encoded with the high nibble being > > the major version and the low version being the minor version. So, > > concretely a TLS 1.3 implementation would use 0x34 here. > > > > I imagine people have opinions about N and the sentinel, but for > > concreteness > > I suggest that N = 64 bits, and that we use the ASCII string > > 'DOWNGRD' as the sentinel. > > > > Let the bikeshedding begin! > > IIRC for TLS >= 1.3 the entire server hello (as part of a session > transcript digest that includes it) is signed with the key exchange. > So TLS 1.3 already protects against rollbacks from 1.4 to 1.3. > Hopefully, yes. If so, is it necessary to have a variable high octet? Note: I am proposing this in the low octet. Not that it's that important either way. > 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. -Ekr > I must admit to not have looked closely, so perhaps wrong end of > the stick... If the above is however correct, I think simpler is > better, over-engineering this work-around "side-channel" is I think > unwise. This seems to be a protection against rollback to TLS < > 1.3, for TLS >= 1.3, the protocol should solve any issues more > naturally than by overloading the server-random. > > -- > Viktor. > > ___ > 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 for anti-downgrade mechanism
On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett wrote: > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > 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. > > Two values seems like a good compromise to me if one isn't considered > sufficient. I don't particularly want them changing in the future so old > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to > worry about seeing something new here and making a mistake. Checks would be > for one of two 64-bit values, rather than 56-bit values with a byte with a > possibly unknown value My assumption here was that the client would do the following: 1. Look to see if the server negotiated its highest version. If so, then all is good. 2. If the server did not negotiate the highest version, then look for the sentinel. If it's set, you have a downgrade. 3. (Optional) If you have a downgrade, parse the last byte to see the server's actual version. In any case, abort. What have I missed? -Ekr > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> > wrote:
> >
> > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > > 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.
> > >
> > > Two values seems like a good compromise to me if one isn't considered
> > > sufficient. I don't particularly want them changing in the future so
> old
> > > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to
> > > worry about seeing something new here and making a mistake. Checks
> would be
> > > for one of two 64-bit values, rather than 56-bit values with a byte
> with a
> > > possibly unknown value
> >
> >
> > My assumption here was that the client would do the following:
> >
> > 1. Look to see if the server negotiated its highest version. If so, then
> > all is good.
> > 2. If the server did not negotiate the highest version, then look for the
> > sentinel.
> > If it's set, you have a downgrade.
> > 3. (Optional) If you have a downgrade, parse the last byte to see the
> > server's actual version.
> > In any case, abort.
> >
> > What have I missed?
>
> A 64-bit sentinel can be trivially checked as a 64-bit uint.
And a 56-bit value can be trivially checked by masking off the last byte.
Or, memcmp().
If we have an open-ended series, we could have implementations checking for
> a set of 64-bit integers,rather than a 56-bit followed by another byte to
> be inspected.
As noted, nobody is making you check it.
> I'm being paranoid, yes, but it's simpler just to have a round number bits
> value or two and I don't think you get much by encoding further information.
>
> It also has a slightly better collision risk, though it's already down
> quite low
Given that the TCP checksum has a false negative rate far higher than
2^{-56} and
any TCP errors cause TLS handshake failures, this doesn't seem like much of
an argument.
-Ekr
>
> Dave
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
>
> > > It also has a slightly better collision risk, though it's already down
> > > quite low
> >
> > Given that the TCP checksum has a false negative rate far higher than
> > 2^{-56} and
> > any TCP errors cause TLS handshake failures, this doesn't seem like much
> of
> > an argument.
>
> This argument is not complete. The false negative rate from TCP
> is not by itself sufficient to determine the observed error rate.
> One needs to combine that with the undetected error rate from
> underlying network to obtain the frequency of TCP errors that
> percolate up to the TLS layer.
>
A bit old but see:
http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf
"After an analysis we conclude that the checksum will fail to detect
errors for roughly 1 in 16 million to 10 billion packets".
-Ekr
> The question is not so much whether 48, 56 or 64 bits is the right
> amount of protection against random false positives, though if 64
> bits is way overkill and the original 48 is more than enough, we
> could look more closely at that. Rather, I think the question is
> whether this work-around should be as simple as possible, or should
> be a more feature-full new sub-protocol. I'm in the keep it simple
> camp (if we should do this at all).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
>
> > > This argument is not complete. The false negative rate from TCP
> > > is not by itself sufficient to determine the observed error rate.
> > > One needs to combine that with the undetected error rate from
> > > underlying network to obtain the frequency of TCP errors that
> > > percolate up to the TLS layer.
> >
> > A bit old but see:
> > http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf
> >
> > "After an analysis we conclude that the checksum will fail to detect
> > errors for roughly 1 in 16 million to 10 billion packets".
>
> That's all fine and good, but my point is that this is a distraction.
> Though the specific numbers depend greatly on the underlying layer-2
> networks traversed by the TCP frame, let's accept the 1:10^10
> estimate, in which case anything better than ~2^{-40} is quite
> enough. If so, send a shorter sentinel.
Sure, that's fine. I'm simply dispensing with arguments that we need to
avoid sending a version because we need the bits to avoid false
positives.
> > The question is not so much whether 48, 56 or 64 bits is the right
> > > amount of protection against random false positives, though if 64
> > > bits is way overkill and the original 48 is more than enough, we
> > > could look more closely at that. Rather, I think the question is
> > > whether this work-around should be as simple as possible, or should
> > > be a more feature-full new sub-protocol. I'm in the keep it simple
> > > camp (if we should do this at all).
>
> However, the question of simplicity still remains... I would go
> with at most a 1 bit field for "TLS 1.2" vs. "TLS 1.3" in whatever
> length sentinel is used.
I don't feel strongly about this, but I don't see how what you suggest
is any simpler than the version number encoding I proposed. Arguably,
it's more complicated since you can't implement the sentinel check with
memcmp().
-Ekr
> VIktor.
>
> ___
> 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 for anti-downgrade mechanism
On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
> Does the sentinel have to be the first N bytes?
>
> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
> value and 28 random bytes.
>
> Rather than risk breaking backwards compatibility by changing the
> definition of the first 4 bytes, perhaps the sentinel can be moved to
> another location within the ServerRandom field? Either the second set of N
> bytes or the last set of N bytes? Where the sentinel is located shouldn’t
> really matter. Subsequently, the sentinel can be chosen with more freedom.
> As I recall, one reason (but not the only reason) the length was extended
> to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still
> needed if it’s not overlapping the gmt_unix_time (yes, I’m concerned about
> a reduction of entropy by 25%)?
>
Maybe it's because I haven't had my coffee yet, but ISTM that 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.
> In extending this, should the ClientHello random value also include the
> sentinel? (Yes, I know this again reduces entropy.) A MITM can implement a
> downgrade attack in either direction. The server can terminate the
> connection that much earlier
>
How does this help? The attacker will just rewrite the ClientHello.random.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Directly signing randoms
Folks, https://github.com/tlswg/tls13-spec/issues/224 At the interim we discussed whether it was worth having digital signatures explicitly include the client and server random values rather than just the transcript to enable privilege separation, as proposed by Nikos. We had a little trouble getting clarity on the desired use case, but the two we understood were: 1. Having a separate module which is signing for authentication and wants to explicitly provide a random value to ensure that it's not signing arbitrary data. 2. Having a separate module which is verifying the peer's authentication and wants to explicitly provide a challenge to be signed by the peer. The general feeling was that you could achieve both cases by simply the unprivileged portion of the system provide the module with the handshake transcript and allow it to verify that the random was present in the correct location (or at all in case #2) and so that no change was needed. As I said, there was some confusion on the exact scenario, so if I've misunderstood please clarify. Otherwise, I think we have consensus to close this as WONTFIX. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
