> 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
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
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
> 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
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
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
>
>
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
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:
>
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
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
> 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.,
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.,
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,
13 matches
Mail list logo