Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dave Garrett]

Yes, a proper "differences from TLS 1.2" section needs to be written to replace 
the draft changelog.


Dave


On Tuesday, March 14, 2017 05:31:18 am Yoav Nir wrote:
> Hi.
> 
> I will give the entire document a more thorough read, but I wanted to comment 
> on section 1.2 earlier. Its title is “Major differences from TLS 1.2”, but 
> the content is a change-log. The kind of change-log that usually gets deleted 
> by the RFC editor.
> 
> I hope we don’t plan to publish with sentences like “Allow cookies to be 
> longer”.  OTOH I think it will be useful to have an actual “major differences 
> from TLS 1.2” section, but AFAICT it’s not yet written.
> 
> Yoav
> 
> > On 13 Mar 2017, at 19:30, Sean Turner  wrote:
> > 
> > This is a working group last call announcement for draft-ietf-tls-tls13-19, 
> > to run through March 27.  Please send your reviews to the list as soon as 
> > possible so we can prepare for any discussion of open issues at IETF 98 in 
> > Chicago.
> > 
> > Thanks,
> > J
> > ___
> > 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] RFC 6066 - Max fragment length negotiation

[Hannes Tschofenig]

Hi Joe,

thanks for pointing this out. I will talk to our mbed TLS team to find
out what the status of this issue is.

Ciao
Hannes


On 03/18/2017 10:17 AM, Joseph Birr-Pixton wrote:
> On 17 March 2017 at 16:01, Hannes Tschofenig  
> wrote:
>> Here are my 5 cents: we implement this extension in our mbed TLS stack
> 
> With the greatest of respect, mbedtls *doesn't* implement
> max_fragment_length[1], because it doesn't fragment handshake messages
> as required by the spec. Attempts to use it with a conforming peer
> will fail to handshake.
> 
> When I came across this a year or so ago, I concluded that nobody
> could have actually deployed max_fragment_length using mbedtls.
> 
> Cheers,
> Joe
> 
> [1] https://github.com/ARMmbed/mbedtls/issues/387
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Martin Thomson]

On 18 March 2017 at 20:36, Peter Gutmann  wrote:
> Incidentally, has anyone else who's implemented this dealt in the weird
> omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512,
> 1K, 2K, and 4K?  In many cases 8K is just what you need, it halves memory
> consumption while being large enough to not have to worry about fragmenting
> handshake messages.

No matter how much of a good idea that is, you would risk handshake
failure by doing so.  Compliant server implementations are required to
send an "illegal_parameter" alert if you send that.

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