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, SN
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., TLSPlaintext.length)?
> 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., TLSPlaintext.length)? That is,
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 sen
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
> > max_fragment_length extension.
> >
> > Does the limit apply to len(TLSInnerPlaintext) or does it apply to
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
>>> max_fragment_length extension.
>>>
>>> Does the li
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 https:
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:
>
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
> email addresses included in the
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
>
>max_fragment_length extension fro
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 of recent developments,
> 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 said that other hash functions may be used. We’v
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
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 be used.
>
> SGTM
The new text is much better
> 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
___
TLS mailing list
TLS@ie
> On 15 Mar 2017, at 3:07, Sean Turner wrote:
>
>
>> 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
And
16 matches
Mail list logo