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

___
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 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 be used.
> 
> SGTM

The new text is much better, thank you!
___
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 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 said that other hash functions may be used. We’ve upgraded it to a
>> SHOULD.
> 
> In light of recent developments, is there any reason we couldn't
> further upgrade this advice?

It might be better to rephrase the whole thing and eliminate the thing about a 
default. X9.62 has been revised in 2005. This newer version does mention the 
SHA-2 family in addition to SHA-1, so I don’t know it that is in any sense of 
the word still “the default”. I’d look it up, but as an ANSI standard, it’s 
behind a paywall.

We might just say:

OLD
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.
   The default hash function is SHA-1 [FIPS.180-2 
], and 
sha_size (see
   Section 5.4 
 and 
Section 5.8 
) is 20.  
However, an alternative hash
   function, such as one of the new SHA hash functions specified in FIPS
   180-2 [FIPS.180-2 
], 
SHOULD be used instead.

NEW
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.
   A secure hash function such as the SHA-256, SHA-384, and SHA-512
   [FIPS.180-4] MUST be used.





signature.asc
Description: Message signed with OpenPGP
___
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 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 of recent developments, is there any reason we couldn't
further upgrade this advice?

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

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
>
>max_fragment_length extension from [RFC6066], then the reduced limit
>
>applies to the full plaintext, including the padding.

Sounds good, I've created a PR.  I also changed the "may" to a  "MUST"
on the basis that this is an interoperability requirement.

https://github.com/tlswg/tls13-spec/pull/909

___
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 
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 To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for your work on this draft.  I just have one question:
> 
> In section 5.10, I see the following text:
>   The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
>   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
>   function, such as one of the new SHA hash functions specified in
> FIPS
>   180-2 [FIPS.180-2], SHOULD be used instead.

If we add the three lines before the ones you quoted, they say this:
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.

The default of using SHA-1 is from X9.62: 
https://www.security-audit.com/files/x9-62-09-20-98.pdf 

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.

> 
> Why are you setting the default to SHA-1 and then recommending that
> something else should be used?  Why not just start with a different SHA
> hash function as the default or at least for TLS 1.2?  I do see the prior
> text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended
> to go right to TLS 1.2 with the SSLv3 deprecation.  As such, I'm not
> clear on why the SHA-1 default.
> 
> 



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

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:
>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 by the presence of the 
>max_fragment_length extension from [RFC6066] then the reduced limit 
>applies to the full plaintext, including the padding.
>

That's probably fine, but maybe this one is better:

NEW:

   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 from [RFC6066], then the reduced limit 

   applies to the full plaintext, including the padding.


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

[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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/



--
COMMENT:
--

Thanks for your work on this draft.  I just have one question:

In section 5.10, I see the following text:
   The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
   function, such as one of the new SHA hash functions specified in
FIPS
   180-2 [FIPS.180-2], SHOULD be used instead.

Why are you setting the default to SHA-1 and then recommending that
something else should be used?  Why not just start with a different SHA
hash function as the default or at least for TLS 1.2?  I do see the prior
text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended
to go right to TLS 1.2 with the SSLv3 deprecation.  As such, I'm not
clear on why the SHA-1 default.


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

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
>>> 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,
>>> does is include the padding and content type, or not?
>>> 
>>> Including the padding would recognize the limitations apply to
>>> handling large blobs of encrypted data (see earlier email from Thomas
>>> Pornin).  That would be my preference.  I think that we need to say
>>> that though.  I guess the second-order question is whether to roll
>>> RFC6066-bis or patch these things in TLS 1.3 directly.
>>> 
>>> (BTW, RFC 6066 is quite poor.  It's not very precise in identifying
>>> what it is talking about, it also describes a negotiation design
>>> unlike anything else in TLS, one that can't be extended ever.)
>> 
>> Well, I can’t think of a single rational argument in favor of it
>> *not* including the padding, so I guess I agree that it does.
>> 
>> If it didn’t include the padding, then any record with length
>> greater than the max_fragment_length would be obviously padded.
>> Why leak that?
> 
> Actually, even worse, then the padding would require extra memory,
> which the endpoint presumably does not have.
> 
> If you limit padded plaintext length to 513 bytes (the minimum
> needed for 512 byte plaintext), with current ciphers, the record
> payload is at most 529 bytes (16 byte tag is added). Thus, you
> can receive the record into 529 byte buffer and decrypt in
> place.
> 

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:
   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 by the presence of the
   max_fragment_length extension from [RFC6066] then the reduced limit
   applies to the full plaintext, including the padding.


Yoav


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

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., TLSPlaintext.length)?  That is,
> does is include the padding and content type, or not?
> 
> Including the padding would recognize the limitations apply to
> handling large blobs of encrypted data (see earlier email from Thomas
> Pornin).  That would be my preference.  I think that we need to say
> that though.  I guess the second-order question is whether to roll
> RFC6066-bis or patch these things in TLS 1.3 directly.
> 
> (BTW, RFC 6066 is quite poor.  It's not very precise in identifying
> what it is talking about, it also describes a negotiation design
> unlike anything else in TLS, one that can't be extended ever.)

Well, I can’t think of a single rational argument in favor of it *not* 
including the padding, so I guess I agree that it does.

If it didn’t include the padding, then any record with length greater than the 
max_fragment_length would be obviously padded. Why leak that?

Yoav



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

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., TLSPlaintext.length)?  That is,
> does is include the padding and content type, or not?
> 
> Including the padding would recognize the limitations apply to
> handling large blobs of encrypted data (see earlier email from Thomas
> Pornin).  That would be my preference.  I think that we need to say
> that though.  I guess the second-order question is whether to roll
> RFC6066-bis or patch these things in TLS 1.3 directly.

I would think it would include the padding, because otherwise you
can not limit the size of buffers to store a record. And if you
have an encrypted record, you can decrypt it in-place anyway, so
limits on plaintext size post-depadding are not useful.

Furthermore, there is edge case in how max_fragement_length is currently
defined in TLS 1.3 (it isn't available when parsing ServerHello, but
ServerHello is also limited by it). Fortunately, that edge case is very
unlikely to be hit, as ServerHello is highly likely to be under the
limit[1], and ServerHello can't be coalesced with anything (since it has
flight or key boundaries on both sides).


[1] Base ServerHello is 42 bytes, pre_shared_key gives you 6. And
key_share gives you 8+size_of_share. So at maximum you have 56+
size_of_share. The minimum limit is 512, and to reach that you need
456 byte share. The only things that have shares of that size are
groups 258, 259 and 260. And none of those would seem to be likely
implemented by any device that uses max_fragment_length.

For 1024-byte limit, you have 968 bytes, which is only exceeded by
group 260. And for higher 2048 and 4096 byte limits, no current group
is big enough to blow the size limits.



-Ilari

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

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, SNI and all.

+1

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