Re: [TLS] Accepting that other SNI name types will never work.

Trying again... > Hi Adam, In CoRE we might need to allocate a new SNI NameType for non-DNS host names [1]. Removing SNI extensibility would make it unfeasible. Cheers, t [1] https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#section -3.3 >On 03/03/2016 18:49, "TLS on beha

Re: [TLS] Accepting that other SNI name types will never work.

Hi Adam, On 03/03/2016 18:49, "TLS on behalf of Adam Langley" wrote: >The Server Name Indication (SNI) extension in TLS has a provision to >provide names other than host names[1]. None have even been defined to >my knowledge, but it's there. > >OpenSSL (and possibly others) have had a long-stand

Re: [TLS] Accepting that other SNI name types will never work.

On 4 March 2016 at 12:43, Dave Garrett wrote: > Just adding a quick blurb for this in there somewhere seems like the simplest > solution to me. That doesn't fix it for 1.2, but I'd be OK with that. Define SNI as: struct { uint16 extension_tag = 0; uint16 extension_length = strlen(name) +

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

"Glen Knowles" : > To be pedantic wouldn't it be: > NamedCurve elliptic_curve_list<2..2^16-2> Arguably so, but that's not how the TLS RFCs use the presentation language in practice (see ClientHello.cipher_suites for just one example), and we'd want to be consistent with that, not extra nitpicky.

Re: [TLS] Accepting that other SNI name types will never work.

Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the simplest

Re: [TLS] Accepting that other SNI name types will never work.

If we actually have a volunteer for sni-bis, then that would be OK with me. However, I don't regard the errors as important. Any hope that they might be used in some automated fashion died a long time ago. Mainly due to this complete lack of consistency. I assume that the last error indicates t

Re: [TLS] Accepting that other SNI name types will never work.

If you're fixing that then maybe standardising the errors makes sense too. My fingerprinter sees the following: For an empty name: SNIEmptyName: *(301)alert:DecodeError:fatal| SNIEmptyName: *(301)alert:HandshakeFailure:fatal| SNIEmptyName: *(301)alert:IllegalParameter:fatal| SNIEmptyName: *(303)a

Re: [TLS] Accepting that other SNI name types will never work.

On 4 March 2016 at 05:49, Adam Langley wrote: > (I think the lesson here is that protocols should have a single joint, > and that it should be kept well oiled. For TLS, that means that > extensions should have minimal extensionality in themselves and that > we should generally rely on the main ext

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

> On 2 Mar 2016, at 10:59 PM, Bodo Moeller wrote: > > RFC Errata System >: > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security > (TLS)". > >

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On 4 March 2016 at 04:04, Ilari Liusvaara wrote: > Well, actually, it might be possible to compress everything except > ClientHello headers. ServerHello too, just to make it easy. Might as well include HelloRetryRequest at the same time, so that all unencrypted packets have the same header. __

Re: [TLS] Accepting that other SNI name types will never work.

I’m in favor, wearing both OpenSSL and Akamai hats. And wouldn’t it be a much kinder world if Adam wrote all posts on this list? ☺ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https

Re: [TLS] Accepting that other SNI name types will never work.

On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla wrote: > Note: it's already the case that it's forbidden to send >1 of any given type > of name. NSS does not presently enforce this rule but will do so soon. (We have enforced that for a while without issues.) Cheers AGL -- Adam Langley a...@im

Re: [TLS] Accepting that other SNI name types will never work.

On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley wrote: > The Server Name Indication (SNI) extension in TLS has a provision to > provide names other than host names[1]. None have even been defined to > my knowledge, but it's there. > > OpenSSL (and possibly others) have had a long-standing bug[2] (f

[TLS] Accepting that other SNI name types will never work.

The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will ca

Re: [TLS] RSA-PSS in TLS 1.3

PSS+SHAKE128/512+SHAKE128 or PSS+SHAKE256/512+SHAKE256 (as SHAKEs being used as MGF) would be more efficient options. NIST is working on a formal specification for the SHAKEs being used as fixed output-length hash functions such as SHAKE128/256, SHAKE128/512 and SHAKE256/512. Prepending a rand

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On Thu, Mar 03, 2016 at 04:44:30PM +, Salz, Rich wrote: > > > The unencrypted headers need to be kept for backward compatiblity. > > Even for a new protocol revision? Well, actually, it might be possible to compress everything except ClientHello headers. One should still avoid the 15 and 16

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

RFC Errata System : > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer > Security (TLS)". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata_search

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

> The unencrypted headers need to be kept for backward compatiblity. Even for a new protocol revision? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On Thu, Mar 03, 2016 at 09:48:00AM +1100, Martin Thomson wrote: > > [3] I actually hope that we can change DTLS 1.3 so that it won't mux > properly. That will have a size benefit that should outweigh the cost > of having to rev 5764 for 1.3. I thought about this a bit... It occurs to me that a

Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 15:29:37 + "Blumenthal, Uri - 0553 - MITLL" wrote: > Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let > alone available?  Yeah, more than 10 years before. It's more the other way found: PSS and other constructions showed the need for hash functions with a

Re: [TLS] RSA-PSS in TLS 1.3

Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let alone available?  It may be worth asking the authors what's their opinion of FDH vs PSS in view of the state of the art *today*. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   F

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

Hi, To be clear I will not continue with a publication request while we are having a discussion. I hope we can resolve this with an agreement on how to proceed. Den 2016-03-02 kl. 23:48, skrev Martin Thomson: On 3 March 2016 at 09:20, Marc Petit-Huguenin wrote: draft-ietf-avtcore-rfc5764-m

Re: [TLS] RSA-PSS in TLS 1.3

Hi Hanno, I think the PSS uses a random salt to get the hashing probabilistic. A customized version of a SHAKE can/may take a domain-separation string or/and a random salt. Quynh. From: TLS on behalf of Hanno Böck Sent: Thursday, March 3, 2016 8:49 A

Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 13:35:46 + "Dang, Quynh (Fed)" wrote: > Why don't we use an even more elegant RSA signature called " > full-domain hash RSA signature" ? Full Domain Hashing was originally developed by Rogaway and Bellare and then later dismissed because they found that they could do bette

Re: [TLS] RSA-PSS in TLS 1.3

Hi all, Why don't we use an even more elegant RSA signature called " full-domain hash RSA signature" ? As you know, a SHAKE (as a variable output-length hash function) naturally produces a hash value which fits any given modulus size. Therefore, no paddings are needed which avoids any potentia