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 <hka...@redhat.com> wrote:
> > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
> >> On 30 November 2016 at 05:54, Thomas Pornin <por...@bolet.org> 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

Attachment: signature.asc
Description: This is a digitally signed message part.

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

Reply via email to