Re: [TLS] Downgrade protection, fallbacks, and server time
On 2 June 2016 at 08:56, Eric Rescorla wrote: >> (Although, do we actually get the stronger protection if the client >> accepts plain RSA key exchange? I've never been very clear on that. >> Realistically, clients will be accepting plain RSA for a long while.) > > > Yes, that's correct. I don't believe we have a good plan for plain RSA. The best plan involves lots and lots of fire. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Downgrade protection, fallbacks, and server time
On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin wrote: > On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote: > >> 2% is actually pretty good, but I agree that we're going to need fallback. >> >> I'd be fine with moving the 8 bytes to the end, but I wonder if it would >> be better to >> instead have the *client* indicate its max version and the server check. >> That would >> have the advantage that it would leave more of the server random intact. >> > > That sounds reasonable to me. I'd probably suggest still putting it at the > end since there's no reason to risk things, but I'm not aware of anything > that uses the client timestamp. (None of the clients I maintain send it.) > Putting it at the end of the client gives the client options, so that would be fine. > >> -Ekr >> >> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the >> server. >> > > Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection > (otherwise the version fallback even loses that one). I only mean in terms > of mitigating the additional damage done by the fallback, not replacing the > entire mechanism. > > (Although, do we actually get the stronger protection if the client > accepts plain RSA key exchange? I've never been very clear on that. > Realistically, clients will be accepting plain RSA for a long while.) > Yes, that's correct. I don't believe we have a good plan for plain RSA. -Ekr > David > > >> >> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin >> wrote: >> >>> In case folks hoped we could bump the ClientHello version without those >>> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much >>> exists. (Maybe we should just give up on ClientHello.version and use an >>> extension? Extensions have rusted less.) >>> >>> I picked a large list of top sites and tried connecting to them. Just >>> under 2% of them could handle a TLS 1.2 ClientHello, but not the same >>> ClientHello with the version switched to 1.3 (no other changes, so I >>> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I >>> expect if you probe any top site list, you'll very quickly find some. >>> >>> Fortunately, the ServerHello.random trick fixes this. But it currently >>> clobbers the old server timestamp which tlsdate[1] uses for clock >>> synchronization. There really should be a less silly secure timestamping >>> protocol, but, today, tlsdate has users. Any servers which expect to be a >>> tlsdate target can't honor this MUST without tlsdate gone. >>> >>> (FALLBACK_SCSV works fine as well, but I gather people prefer the >>> ServerHello.random one and would be unhappy having to implement both in >>> clients with a fallback because not all servers do the latter.) >>> >>> I mentioned this before, but rather than clobbering the first 8 bytes, >>> the last 8 bytes seems as reasonable and avoids this unnecessary >>> complication to TLS 1.3 deployment. If folks agree now that the >>> fallback's resurrection is more certain, I'm happy to put together a PR. >>> >>> David >>> >>> [1] https://github.com/ioerror/tlsdate >>> >>> ___ >>> 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] tls - Update to a Meeting Session Request for IETF 96
An update to a meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: spt Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb httpauth httpbis dane cfrg cose acme uta curdle perc Second Priority: sacm oauth Special Requests: Please also avoid the quic BOF. - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Downgrade protection, fallbacks, and server time
On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need fallback. > > I'd be fine with moving the 8 bytes to the end, but I wonder if it would > be better to > instead have the *client* indicate its max version and the server check. > That would > have the advantage that it would leave more of the server random intact. > That sounds reasonable to me. I'd probably suggest still putting it at the end since there's no reason to risk things, but I'm not aware of anything that uses the client timestamp. (None of the clients I maintain send it.) > -Ekr > > P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the > server. > Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection (otherwise the version fallback even loses that one). I only mean in terms of mitigating the additional damage done by the fallback, not replacing the entire mechanism. (Although, do we actually get the stronger protection if the client accepts plain RSA key exchange? I've never been very clear on that. Realistically, clients will be accepting plain RSA for a long while.) David > > On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin > wrote: > >> In case folks hoped we could bump the ClientHello version without those >> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much >> exists. (Maybe we should just give up on ClientHello.version and use an >> extension? Extensions have rusted less.) >> >> I picked a large list of top sites and tried connecting to them. Just >> under 2% of them could handle a TLS 1.2 ClientHello, but not the same >> ClientHello with the version switched to 1.3 (no other changes, so I >> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I >> expect if you probe any top site list, you'll very quickly find some. >> >> Fortunately, the ServerHello.random trick fixes this. But it currently >> clobbers the old server timestamp which tlsdate[1] uses for clock >> synchronization. There really should be a less silly secure timestamping >> protocol, but, today, tlsdate has users. Any servers which expect to be a >> tlsdate target can't honor this MUST without tlsdate gone. >> >> (FALLBACK_SCSV works fine as well, but I gather people prefer the >> ServerHello.random one and would be unhappy having to implement both in >> clients with a fallback because not all servers do the latter.) >> >> I mentioned this before, but rather than clobbering the first 8 bytes, >> the last 8 bytes seems as reasonable and avoids this unnecessary >> complication to TLS 1.3 deployment. If folks agree now that the >> fallback's resurrection is more certain, I'm happy to put together a PR. >> >> David >> >> [1] https://github.com/ioerror/tlsdate >> >> ___ >> 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] Downgrade protection, fallbacks, and server time
2% is actually pretty good, but I agree that we're going to need fallback. I'd be fine with moving the 8 bytes to the end, but I wonder if it would be better to instead have the *client* indicate its max version and the server check. That would have the advantage that it would leave more of the server random intact. -Ekr P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the server. On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin wrote: > In case folks hoped we could bump the ClientHello version without those > dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much > exists. (Maybe we should just give up on ClientHello.version and use an > extension? Extensions have rusted less.) > > I picked a large list of top sites and tried connecting to them. Just > under 2% of them could handle a TLS 1.2 ClientHello, but not the same > ClientHello with the version switched to 1.3 (no other changes, so I > haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I > expect if you probe any top site list, you'll very quickly find some. > > Fortunately, the ServerHello.random trick fixes this. But it currently > clobbers the old server timestamp which tlsdate[1] uses for clock > synchronization. There really should be a less silly secure timestamping > protocol, but, today, tlsdate has users. Any servers which expect to be a > tlsdate target can't honor this MUST without tlsdate gone. > > (FALLBACK_SCSV works fine as well, but I gather people prefer the > ServerHello.random one and would be unhappy having to implement both in > clients with a fallback because not all servers do the latter.) > > I mentioned this before, but rather than clobbering the first 8 bytes, the > last 8 bytes seems as reasonable and avoids this unnecessary complication > to TLS 1.3 deployment. If folks agree now that the fallback's > resurrection is more certain, I'm happy to put together a PR. > > David > > [1] https://github.com/ioerror/tlsdate > > ___ > 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] Downgrade protection, fallbacks, and server time
In case folks hoped we could bump the ClientHello version without those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists. (Maybe we should just give up on ClientHello.version and use an extension? Extensions have rusted less.) I picked a large list of top sites and tried connecting to them. Just under 2% of them could handle a TLS 1.2 ClientHello, but not the same ClientHello with the version switched to 1.3 (no other changes, so I haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I expect if you probe any top site list, you'll very quickly find some. Fortunately, the ServerHello.random trick fixes this. But it currently clobbers the old server timestamp which tlsdate[1] uses for clock synchronization. There really should be a less silly secure timestamping protocol, but, today, tlsdate has users. Any servers which expect to be a tlsdate target can't honor this MUST without tlsdate gone. (FALLBACK_SCSV works fine as well, but I gather people prefer the ServerHello.random one and would be unhappy having to implement both in clients with a fallback because not all servers do the latter.) I mentioned this before, but rather than clobbering the first 8 bytes, the last 8 bytes seems as reasonable and avoids this unnecessary complication to TLS 1.3 deployment. If folks agree now that the fallback's resurrection is more certain, I'm happy to put together a PR. David [1] https://github.com/ioerror/tlsdate ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] tls - New Meeting Session Request for IETF 96
A new meeting session request has just been submitted by Joseph A. Salowey, a Chair of the tls working group. - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: J. Salowey Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb httpauth httpbis dane cfrg cose acme uta curdle Second Priority: sacm oauth Special Requests: - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
