Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Bill Frantz]

On 12/2/16 at 8:48 PM, rs...@akamai.com (Salz, Rich) wrote:


And also, the world will not care about a gap in numbering.  Nobody cared that 
there was no Windows 9.


If we go with 2017, we can tell the world that by using the year 
the standard was approved, instead of a confusing set of names 
and numbers, we are eliminating any confusion about which 
version is the most recent.


Cheers - Bill

---
Bill Frantz| gets() remains as a monument | Periwinkle
(408)356-8506  | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns. | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Salz, Rich]

> If we call the next one 4, we have to explain a gap in the versioning (1.0, 
> 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1.2 becomes even more inviting.

No we don't have to explain it.  Most of the world isn't OCD types like those 
of us in this field.

> Once SSL 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which is 
> a plausible numbering progression. There'll still be the mess with SSL being 
> the informal name for the protocol family, but that isn't a numbering problem.

Once SSL 3.0 falls away, the industry will still be calling the protocol SSL.  
Except now the common name and the real name have no relationship.

And also, the world will not care about a gap in numbering.  Nobody cared that 
there was no Windows 9.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Salz, Rich]

> In other words, the TLS WG and a small number of people who interact with
> it call it TLS 1.3.  That's hardly a strong argument when most of the rest of 
> the
> world doesn't even call it TLS.

Strongly agreed

> pretty much the only reasons I've seen for TLS 1.3 are
> inertia, "we've always called it that"/"I don't want to change"/etc.

Yes.

Think outside the community.  The world calls it SSL.  Many of the vendors in 
this industry also call it SSL.

SSL 4 or greater.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Peter Gutmann]

Tony Arcieri  writes:

>There's already ample material out there (papers, presentations, mailing list
>discussions, etc) which talks about "TLS 1.3".

In other words, the TLS WG and a small number of people who interact with it
call it TLS 1.3.  That's hardly a strong argument when most of the rest of the
world doesn't even call it TLS.

In fact that's something that's come up repeatedly in the bikeshedding so far,
there are some really good, sound arguments for calling it TLS/SSL 4 or
TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 are
inertia, "we've always called it that"/"I don't want to change"/etc.

Peter.

  
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Watson Ladd]

On Thu, Dec 1, 2016 at 6:16 PM, Tony Arcieri  wrote:
> On Wed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni 
> wrote:
>>
>> > I actually completely agree with Timothy Jackson's recent posting:
>> >
>> >   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”.
>>
>> I'll drink to that!
>
>
> I will also +1 this and add that if the goal is to reduce confusion, a last
> minute renaming of TLS 1.3 to something else probably won't accomplish that,
> but will rather create more confusion. There's already ample material out
> there (papers, presentations, mailing list discussions, etc) which talks
> about "TLS 1.3". Rebranding it now would add an additional bit of errata
> everyone needs to learn if they ever encountered the "TLS 1.3" version in
> any of these materials. And I think the whole SSL/TLS thing is errata
> enough.

So what should X be in above email? Clearly it should be \geq 4.

>
> --
> Tony Arcieri
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

On Wed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni 
wrote:

> > I actually completely agree with Timothy Jackson's recent posting:
> >
> >   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”.
>
> I'll drink to that!


I will also +1 this and add that if the goal is to reduce confusion, a last
minute renaming of TLS 1.3 to something else probably won't accomplish
that, but will rather create more confusion. There's already ample material
out there (papers, presentations, mailing list discussions, etc) which
talks about "TLS 1.3". Rebranding it now would add an additional bit of
errata everyone needs to learn if they ever encountered the "TLS 1.3"
version in any of these materials. And I think the whole SSL/TLS thing is
errata enough.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Hubert Kario]

On Thursday, 1 December 2016 09:43:54 CET Martin Thomson wrote:
> Asking ALL TLS implementations to change to accommodate these things
> is a pretty blunt instrument.  I want to be sure that this is
> necessary.  (FWIW, I think that this is a reasonable request, I would
> probably be OK with a smaller maximum by default even.)

for receiving those messages you don't have to do anything above what the 
specification already requires

for sending the implementations already have to be able to fragment their 
messages - the change is only to make the value that guards those sizes a 
variable instead of being hardcoded

that leaves the matter of negotiation of the value itself - which, while it is 
yet another extension that needs to be supported, it is not exactly complex or 
that requires convoluted logic


> On 1 December 2016 at 00:22, Hubert Kario  wrote:
> > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
> >> On 30 November 2016 at 05:54, Thomas Pornin  wrote:
> >> > Any comments?
> >> 
> >> I'm ambivalent on this generally: though I think that the general
> >> notion is OK, I'm not sure about the details.
> >> 
> >> In particular, you need to be clearer in your motivations: the point
> >> is to ensure that little things (really little things) can talk to any
> >> other TLS implementation.  That seems inherently good, but it might
> >> pay to dig into that some more: why is that good?
> > 
> > because if they can't use TLS, they will create a bespoke protocol, and
> > those have a tendency of being completely broken, on conceptual level,
> > let alone implementation
> > 
> > combine it with the fact that "trusted network" doesn't exist any more and
> > you end up with solutions that are insecure with nobody using them knows
> > they are insecure, especially in IoT space
> > --
> > Regards,
> > Hubert Kario
> > Senior 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


-- 
Regards,
Hubert Kario
Senior 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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 certificate signature algorithm requirements

[Ilari Liusvaara]

On Thu, Dec 01, 2016 at 04:36:17AM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >So I'd like to see the text in the first paragraph changed to a SHOULD or 
> >worst-case a qualified "MUST whenever possible".
> 
> Why is that whole thing even there in the first place?  From the previous 
> discussions where this came up, the pretty much universal consensus was that 
> people were ignoring the requirement because it served no obvious purpose 
> but broke interoperability.  Unless you're a server operator that chooses to 
> buy a whole bunch of $995 certs, one per algorithm, from a CA that allows 
> you to choose which algorithm gets used for signing, the whole thing is 
> completely inapplicable.  You send whatever cert chain the CA gave you to 
> the client, and it's up to them to decide whether they want to accept or 
> reject.  What would be lost by simply removing that entire block of text, 
> since it's being ignored by implementers anyway?  The solution is to remove
> it, not to fiddle with it until it becomes a no-op that matches what 
> everyone is doing anyway.

Using algorithms that are supported is kinda important for interop,
since if you send a non-(super-)TA certificate using algorithm the
client doesn't know, it is going to have trouble validating the
chain.

If you are referring to mixing RSA/ECDSA certs in one certificate
chain, that already works fine in TLS-1.2-as-of-spec (unless client
does something crazy[1]). TLS 1.3 removes the options for clients to
be crazy here.


[1] That's related to requirment of matching EE (not any CA) certificate
type and ciphersuite, causing client to be able to trip all sorts of bugs
and edge cases in ciphersuite selection.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls