Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Sean Turner
> On Mar 14, 2017, at 18:57, Martin Thomson wrote: > > On 15 March 2017 at 09:05, Yoav Nir wrote: >> A secure hash function such as the SHA-256, SHA-384, and SHA-512 >> >> [FIPS.180-4] MUST be used. > > SGTM +1 spt

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread kathleen . moriarty . ietf
Please excuse typos, sent from handheld device > On Mar 14, 2017, at 6:57 PM, Martin Thomson wrote: > >> On 15 March 2017 at 09:05, Yoav Nir wrote: >> A secure hash function such as the SHA-256, SHA-384, and SHA-512 >> >> [FIPS.180-4] MUST

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Martin Thomson
On 15 March 2017 at 09:05, Yoav Nir wrote: >A secure hash function such as the SHA-256, SHA-384, and SHA-512 > >[FIPS.180-4] MUST be used. SGTM ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Yoav Nir
> On 14 Mar 2017, at 23:29, Martin Thomson wrote: > > On 15 March 2017 at 08:26, Yoav Nir wrote: >> That is the document that was referenced by RFC 4492 and it’s from 1998. It >> doesn’t mention any hash function other than SHA-1. >> >> RFC 4492

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Martin Thomson
On 15 March 2017 at 08:26, Yoav Nir wrote: > That is the document that was referenced by RFC 4492 and it’s from 1998. It > doesn’t mention any hash function other than SHA-1. > > RFC 4492 said that other hash functions may be used. We’ve upgraded it to a > SHOULD. In light

Re: [TLS] TLS 1.3 and max_fragment_length

2017-03-14 Thread Martin Thomson
On 15 March 2017 at 07:44, Benjamin Kaduk wrote: >The presence of padding does not change the overall record size >limitations - the full fragment plaintext may not exceed 2^14 octets. If > >the maximum fragment length is reduced, such as by the > >

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Yoav Nir
Hi, Kathleen. See inline. > On 14 Mar 2017, at 22:40, Kathleen Moriarty > wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-rfc4492bis-15: Yes > > When responding, please keep the subject line intact and reply to all

Re: [TLS] TLS 1.3 and max_fragment_length

2017-03-14 Thread Benjamin Kaduk
On 03/14/2017 06:26 AM, Yoav Nir wrote: > > > Seems we’re in agreement. So how about modifying the sixth paragraph > in section 5.4? > > OLD: >The presence of padding does not change the overall record size >limitations - the full fragment plaintext may not exceed 2^14 octets. > > NEW: >

[TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

2017-03-14 Thread Kathleen Moriarty
Kathleen Moriarty has entered the following ballot position for draft-ietf-tls-rfc4492bis-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [TLS] TLS 1.3 and max_fragment_length

2017-03-14 Thread Yoav Nir
On 14 Mar 2017, at 13:04, Ilari Liusvaara wrote: > On Tue, Mar 14, 2017 at 11:10:54AM +0200, Yoav Nir wrote: >> >>> On 14 Mar 2017, at 5:38, Martin Thomson wrote: >>> >>> When we added padding to TLS 1.3, we created an ambiguity with the

Re: [TLS] TLS 1.3 and max_fragment_length

2017-03-14 Thread Yoav Nir
> On 14 Mar 2017, at 5:38, Martin Thomson wrote: > > When we added padding to TLS 1.3, we created an ambiguity with the > max_fragment_length extension. > > Does the limit apply to len(TLSInnerPlaintext) or does it apply to > len(TLSInnerPlaintext.content) (i.e.,

Re: [TLS] TLS 1.3 and max_fragment_length

2017-03-14 Thread Ilari Liusvaara
On Tue, Mar 14, 2017 at 02:38:14PM +1100, Martin Thomson wrote: > When we added padding to TLS 1.3, we created an ambiguity with the > max_fragment_length extension. > > Does the limit apply to len(TLSInnerPlaintext) or does it apply to > len(TLSInnerPlaintext.content) (i.e.,

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-14 Thread Dave Garrett
On Friday, March 10, 2017 10:29:30 am Viktor Dukhovni wrote: > Instead of looking for a kludgey replacement SNI in DNS (that won't get > deployed, > and provides rather weak obfuscation) it seems more sensible to publish keys > in > DNS that make it possible to encrypt the entire client HELLO,