Re: [TLS] Draft 18 certificate signature algorithm requirements

[Viktor Dukhovni]

> On Nov 30, 2016, at 10:51 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni  
> wrote:
> 
> The current text reads:
> 
>Section 4.4.1.2 ( 
> https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )
> 
>All certificates provided by the server MUST be signed by a signature
>algorithm that appears in the "signature_algorithms" extension
>provided by the client, if they are able to provide such a chain (see
>Section 4.2.3).  Certificates that are self-signed or certificates
>that are expected to be trust anchors are not validated as part of
>the chain and therefore MAY be signed with any algorithm.
> 
> [...]
> 
> It's "MUST if... ". That's different from SHOULD unless because it
> means that the unless clause is that only reason for violating it, and then
> if that condition obtains it SHOULD do X but could presumably do
> other things.

Yes, I see.  The stretch of text between the "MUST" and the "if" just happened
to overflow my stack limit when I was rereading this today...  Please pardon
the short attention span.  So all is well, unless there is merit it trying
to word-smith the text to bring the "MUST" and "if" closer together

The good new is that the intent is already just right.

> I don't see any difference between "MUST whenever possible"
> and the current language.

Yes, fair enough...

> On a related note, is there in the current draft anything that
> requires ECDSA certificates to bear ECDSA issuer signatures?
> 
> No. Nor has that been true since TLS 1.2. See:
> https://tools.ietf.org/search/rfc5246#section-7.4.2

Great.  Thanks.

-- 
Viktor.

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Peter Gutmann]

Nick Sullivan  writes:

>I took a very unofficial Twitter poll on this subject:
>https://twitter.com/grittygrease/status/80364408215424

Given the lack of context for the question (an out-of-the-blue query
to a random bunch of people on Twitter), I think the inevitable TLSy 
McTLSface (given as Crypty McCryptFace in one response) is kind of 
representative of the quality of responses...

I actually completely agree with Timothy Jackson's recent posting:

  After 15 years, everyone but us still calls it SSL. We need to 
  admit that we lost the marketing battle and plan for a world where 
  everyone calls “TLS X” “SSL X”. Even “new” implementations call 
  themselves “LibreSSL” and “BoringSSL” rather than “LibreTLS” or 
  “BoringTLS”.

Spurred by that, I've been watching out for any uses of $protocol-
name that I come across in news, books, journals, blogs, whatever.
It's pretty clear cut: What we call TLS, the rest of the world calls
SSL.  The only place where it was referred to specifically as TLS
was in IETF WG postings and in conference papers.  To the rest of
the world, the protocol is SSL.  So given that the world will know 
it as SSL , it had better have a number that makes 
explicit what precedence it takes, either 4 or 2017.  Whatever it
is, it needs to be something that can be ranked against "SSL" and
"SSL 3" and be an obvious improvement.

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Nick Sullivan]

I took a very unofficial Twitter poll on this subject:
https://twitter.com/grittygrease/status/80364408215424

Nick

On Tue, Nov 29, 2016 at 5:47 AM Raja ashok  wrote:

> I feel we can go ahead with TLS 1.3.
>
> Or else TLS 3.4, because anyway we send 0x0304 on wire for TLS 1.3.
>
>
>
> I hope all other three options (TLS 2.0, TLS 2 and TLS 4) will make
> confusion with SSL versions for end user.
>
>
> --
>
> Raja Ashok VK
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> [image: image001.jpg]
>
> Phone:
> Fax:
> Mobile:
> Email:
> Huawei Technologies Co., Ltd.
> Bangalore, India
>
> http://www.huawei.com
> --
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
>
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner
> Sent: 18 November 2016 07:43
> To: 
> Subject: [TLS] Confirming consensus: TLS1.3->TLS*
>
>
>
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf
> .
>
>
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
> on the list so please let the list know your top choice between:
>
>
>
> - Leave it TLS 1.3
>
> - Rebrand TLS 2.0
>
> - Rebrand TLS 2
>
> - Rebrand TLS 4
>
>
>
> by 2 December 2016.
>
>
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Martin Thomson]

Asking ALL TLS implementations to change to accommodate these things
is a pretty blunt instrument.  I want to be sure that this is
necessary.  (FWIW, I think that this is a reasonable request, I would
probably be OK with a smaller maximum by default even.)

On 1 December 2016 at 00:22, Hubert Kario  wrote:
> On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
>> On 30 November 2016 at 05:54, Thomas Pornin  wrote:
>> > Any comments?
>>
>> I'm ambivalent on this generally: though I think that the general
>> notion is OK, I'm not sure about the details.
>>
>> In particular, you need to be clearer in your motivations: the point
>> is to ensure that little things (really little things) can talk to any
>> other TLS implementation.  That seems inherently good, but it might
>> pay to dig into that some more: why is that good?
>
> because if they can't use TLS, they will create a bespoke protocol, and those
> have a tendency of being completely broken, on conceptual level, let alone
> implementation
>
> combine it with the fact that "trusted network" doesn't exist any more and you
> end up with solutions that are insecure with nobody using them knows they are
> insecure, especially in IoT space
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

[Bill Frantz]

On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote:


Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" -- 
see https://en.wikipedia.org/wiki/Zip_bomb

The risks of uncompressing data sent from a counterparty who has not yet been 
authenticated, do not outweigh the gains.


There is a long history of successful attacks on systems through 
zip decompressors.


In general, adding complexity to a security system makes it 
harder to understand, easier to compromise and less secure.


If the problem is that certificates are too big, fix that 
problem at the source.


Cheers - Bill

---
Bill Frantz| Privacy is dead, get over| Periwinkle
(408)356-8506  | it.  | 16345 
Englewood Ave
www.pwpconsult.com |  - Scott McNealy | Los Gatos, 
CA 95032


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

[TLS] The TLS WG has placed draft-thomson-tls-tls13-vectors in state "Candidate for WG Adoption"

[IETF Secretariat]

The TLS WG has placed draft-thomson-tls-tls13-vectors in state 
Candidate for WG Adoption (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/

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

Re: [TLS] PR#800: Clarify supported versions

[Salz, Rich]

>  I think if we're going to change this we should just make it an error to hav 
> supported_versions and legacy_version != 0303. My preference would be to 
> leave as-is, however.

I think making it a MUST NOT is enough and gives the server freedom to do what 
it wants, including hunt down and forcibly upgrade the client software...


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

[TLS] PR#800: Clarify supported versions

[Eric Rescorla]

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

In Seoul we had rough consensus (or at least apathy) to leave the supported
versions
semantics alone but tighten up the language. The above PR does that.

One point I notice we didn't discuss is whether we should require the
server to check
that ClientHello.legacy_version == 0303. NSS (and I believe BoringSSL)
currently
ignore it which i believe is the best reading of -18 and is what is in this
PR.

I think if we're going to change this we should just make it an error to
have
supported_versions and legacy_version != 0303. My preference would be to
leave
as-is, however.

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

Re: [TLS] Maximum Fragment Length negotiation

[Raja ashok]

Hi Thomas



Your idea of defining a new similar extension is the only choice for us. 
Because as per existing max_fragment_length extension in RFC 6066, client 
should fail if it receives different value from server.

And also your idea of making the new extension as mandatory for TLS1.3 is good, 
as it will be more useful for constraint server.



Earlier in our team also we were discussing about defining new extension 
specially for constraint client and server. I suggest we should include the 
below points for new fragment length extension

  1) As per RFC 6066, if 512 is negotiated then both entity should keep 
buffer of size 805 bytes (5 byte - record header, 512 bytes - data, 256 bytes - 
padding, 32 bytes - MAC). I think we should change this in our new fragment 
extension. If 512 is negotiated then both entity should not send any [D]TLS 
record of size more than that (includes record header and payload).  Because 
the control overhead of 256 bytes padding and 32 bytes MAC are not applicable 
for recent AEAD algorithms. That too in AES_CCM there is no need of padding.

  2) Currently least value supported by max_fragment_length is 512. I 
prefer we should add support for 256 and 128 also. If AES_CCM_8 is used, the 
control overhead on application record is 21 bytes (5 byte - record header, 8 
byte - IV and 8 byte - MIC). If its DTLS record, overhead is 29 bytes. So if 
max fragment length is 128, we get 99 bytes for data. This is more than 
sufficient for a constraint protocol like CoAP.

  Note : Existing max_fragment_length extension cannot be extended to 
support new values like 128 and 256.

  3) If a client sends both old and new extension, then priority should be 
given to new extension. Server MUST not send both the extension.



I feel the current IoT world needs this kind of new extension. This is the time 
to do.



Regards,

Ashok




Raja Ashok VK
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!





-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Thomas Pornin
Sent: 30 November 2016 00:25
To: Fossati, Thomas (Nokia - GB)
Cc: tls@ietf.org
Subject: Re: [TLS] Maximum Fragment Length negotiation



On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB)

wrote:

> I like your proposal, but I'm not convinced that overloading the

> semantics of an already existing extension when used in combination

> with a specific version of the protocol is necessarily the best

> strategy.  Besides, I'd like to be able to deploy a similar mechanism

> in 1.2.



Defining a new extension is certainly possible. However, it would then require 
deciding on the intended behaviour when both that new extension and the RFC 
6066 extension are present.



Tentatively, one could try this:



  - The new extension documents the maximum record length supported

by whoever sends it. Encoding is as in RFC 6066: one byte of

value x for a maximum record plaintext length of 2^(x+8) bytes).

We extend that to the whole 1..8 range so that larger records

may be used by implementations who can afford them and obtain

some performance increase by doing so (actual maximum plaintext

length will be slightly less than 65535 bytes becose the length

header is 16-bit and there must be some room for the MAC).



  - If a client sends both the RFC 6066 extension and the new extension,

and the server supports the new extension, then the RFC 6066

extension is ignored and only the new extension is used. A server

MUST NOT send both extensions.



  - All implementations that support the extension MUST have the

ability to apply a shorter size limit than their maximum limit

(this is for _sending_ records).



  - The length sent by the server is the one that will be applied to

subsequent records on the connection, in both directions. This

applies to the whole connection, including subsequent handshakes

(renegotiations), unless both client and server send the new

extension again in a renegotiation (in which case the new length

appplies).



  - If using TLS 1.3, then the following extra