Re: [TLS] Confirming consensus: TLS1.3->TLS*
At this point, my personal opinion is to move on from TLS 1.3 to either TLS 4/4.0 or TLS 2017. After 15 years, everyone but us still calls it SSL. We need to admit that we lost the marketing battle and plan for a world where everyone calls “TLS X” “SSL X”. Even “new” implementations call themselves “LibreSSL” and “BoringSSL” rather than “LibreTLS” or “BoringTLS”. As SSL is removed from products, we’re likely to get more and more questions “why am I using SSL 1.2, when I thought SSL 3 was broken?” This is a *legitimate* question by a user who is educated enough to know that “SSL 3 is bad” but has more important things to remember than the distinction between SSL and TLS. As others have noted, TLS 4 fixes this when users call it SSL 4, which they definitely will. Tim On 11/25/16, 6:43 AM, "TLS on behalf of Dan Brown" wrote: I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, it seems simple and clear. In my opinion, the whole SSL vs TLS confusion needs better education to confront, version numbers (even dates) alone might not be enough. Renaming *SSL products to *TLS should help. Avoiding "SSL/TLS" might help. Since others have proposed new options, how about TLS 2.017? Using the date has benefits, but the actual crypto changes are much more important, so the decimal makes that point. An old crypto principle is that older is better (among equally unbroken options) -- but naming new stuff is just not enough to rid us of broken old stuff, so putting dates in names might not undermine this principle. For future naming, on minor changes (or even pre-scheduled reviews with no changes), update the date part, on major changes, start from scratch (as in 3.2024, or even use different letters ... ). By the way, I'm sorry if my opinion diverges from the currently forming consensus. Just my $0.02. Dan PS Just to be clear, if votes are to be tallied, my vote on this issue should be weighted quite low (i.e. 0, unless other votes are weighted low too, and some kind of tie-breaker is needed), for at least three reasons: I have not followed the TLS 1.3/2.0 spec closely (i.e., I had no part in building the shed); I have nearly zero experience dealing with user interpretation (i.e. marketing) of protocol names; my preference is weak. (Enough to deserve a negative weight, if that were not cheatable;) PPS I've said before that I prefer TLC(rypto) to TLS(ecurity), but that's unlikely to fly, and it may be okay to grandfather this tradition. (I hope names of future crypto protocols (that TLS WG might work on) can be more specific and realistic.) -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, November 22, 2016 5:07 PM To: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* (replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the result here. That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth version of TLS" message. It makes a kind of messy sense that's kind of fitting for TLS. I'm no longer against it. I've also suggested highlighting the year in the past, but only in the context of the title and messaging, not actually replacing the version number itself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and changing it to 2017, wholesale. That just feels even more confusing. Lastly, I am vehemently against the suggestion of ditching the TLS name in favor of SSL again, as was also brought up in this thread. SSL is dead and insecure, and that message needs to stay. We need to get people to stop conflating the two and making this worse, not accepting it. Dave On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote: > I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the > major version number we should abandon the minor one). > TLS 2017 strikes me as quite bad; we're certainly not planning to do a > TLS 2018. I am strongly opposed to TLS 2017. > > -Ekr > > > On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG > > should rebrand TLS1.3 to something else. Slides can be found @ > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_97_slides_slides-2D&d=DwICAg&c=N0Urj2691w_G_RMcId8BFO255JhwY1mUG9mQ4wCsdg4&r=NdXACqSCqnic2vXFj2sB1wqEOVaLJ9XgezFa4hmJAmA&m=aVqgPEkStnO8wlSeHRSGdkuqYUHHonOaRl-oH5L2N2A&s=6yJGiNGx2nAPsm7AaZ_G7L5Z-k0foqrnehHcwnU5MiA&e= > > 97-
[TLS] Point validation (PR#763)
https://github.com/tlswg/tls13-spec/pull/763 Barring technical objections (e.g., this is incorrect), I intend to merge this PR requiring point validation on Wednesday. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merging pre_shared_key and psk_key_exchange_modes extensions
Eric: > On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley wrote: > Only the client ever sends the "psk_key_exchange_modes” extension. In fact, > the server MUST NOT send a "psk_key_exchange_modes" extension. > > The "pre_shared_key” extension is already divided into the structures used by > the client and the server. Why not add the ke_modes to the client part of > the "pre_shared_key” extension? > > This version allows you to tell the server that you would support a specific > set of modes (so it knows whether to send you a ticket or not) without the > need to allow an empty PSK list (with the small side effect that you can > check the minimum 1 requirement at the syntax level. I see. Thanks. Russ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merging pre_shared_key and psk_key_exchange_modes extensions
On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley wrote:
> Only the client ever sends the "psk_key_exchange_modes” extension. In
> fact, the server MUST NOT send a "psk_key_exchange_modes" extension.
>
> The "pre_shared_key” extension is already divided into the structures used
> by the client and the server. Why not add the ke_modes to the client part
> of the "pre_shared_key” extension?
>
This version allows you to tell the server that you would support a
specific set of modes (so it knows whether to send you a ticket or not)
without the need to allow an empty PSK list (with the small side effect
that you can check the minimum 1 requirement at the syntax level.
This would have the advantage that the ke_modes would be integrity
> protected by the HMAC carried in the PskBinderEntry.
>
It already is protected.
-Ekr
>
> If I am not missing something, then the following would be one way to
> accomplish this change:
>
> enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
>
> struct {
> opaque identity<0..2^16-1>;
> PskKeyExchangeMode ke_modes<1..255>;
> uint32 obfuscated_ticket_age;
> } PskIdentity;
>
> opaque PskBinderEntry<32..255>;
>
> struct {
> select (Handshake.msg_type) {
> case client_hello:
> PskIdentity identities<6..2^16-1>;
> PskBinderEntry binders<33..2^16-1>;
>
> case server_hello:
> uint16 selected_identity;
> };
>
> } PreSharedKeyExtension;
>
> ___
> 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] Merging pre_shared_key and psk_key_exchange_modes extensions
Only the client ever sends the "psk_key_exchange_modes” extension. In fact,
the server MUST NOT send a "psk_key_exchange_modes" extension.
The "pre_shared_key” extension is already divided into the structures used by
the client and the server. Why not add the ke_modes to the client part of the
"pre_shared_key” extension?
This would have the advantage that the ke_modes would be integrity protected by
the HMAC carried in the PskBinderEntry.
If I am not missing something, then the following would be one way to
accomplish this change:
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
opaque identity<0..2^16-1>;
PskKeyExchangeMode ke_modes<1..255>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
struct {
select (Handshake.msg_type) {
case client_hello:
PskIdentity identities<6..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
case server_hello:
uint16 selected_identity;
};
} PreSharedKeyExtension;
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
On Sun, 2016-11-27 at 15:13 +, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS. I will submit a draft > > as soon > > as I have a working prototype. > > FWIW I too have started working on a prototype for gzip compressing > certificates > based on BoringSSL: > https://github.com/ghedo/boringssl/tree/cert_compress > > It's not complete yet and I only implemented compression so far based > on what > Chromium does with QUIC. I also haven't really tested it yet (but at > least it > builds AFAICT :) ). I guess one could use the certificate type negotiation mechanism from RFC7250 to negotiate a compressed certificate, instead of a normal one. That would require registering an ID at: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > I'd like to do some tests as well to measure the benefits of this > (e.g. > download certificates from CT logs and see how effective the > compression is). > > I also started working on a draft for gzip compression of > certificates at: > https://github.com/ghedo/tls-certificate-compression Have you considered lz4 instead of zlib? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
