Re: [TLS] PR#345: IANA Considerations

On Tuesday, November 17, 2015 02:14:00 pm Ilari Liusvaara wrote: > All current registered/proposed ciphersuites that work in TLS 1.3 are > *-GCM or *-POLY1305 ones (with DHE or ECDHE). DHE AES CCM is still in the list, even after the changes in the current proposal. ECDHE AES CCM is not as it's n

Re: [TLS] Record header size?

Short, Todd writes: >To be honest, it’s always kinda bugged me that SSL/TLS uses a 5-byte header, >coming from my embedded network system background. > >[...] +1. I wrote about this problem years ago in "Performance Characteristics of Application-level Security Protocols", https://www.cs.auckla

Re: [TLS] Record header size?

Eric Rescorla writes: >The concern here is backward compatibility with inspection middleboxes which >expect the length field to be in a particular place. Given that the rest of TLS 1.3 is going to break compatibility with pretty much everything everywhere, I can't see this as a big concern, may

Re: [TLS] Record header size?

On Tue, Nov 17, 2015 at 09:26:57PM +, Short, Todd wrote: > Embedded systems don�t have the luxury of mbuf-type of buffer scheme (as > you describe for NSS). Many have ethernet-frame sized buffers in > locked/pinned memory that read in a whole ethernet frame, and then strip > off headers by adv

Re: [TLS] PR#345: IANA Considerations

I prefer to see two categories: recommended and “no comment” MUST or SHOULD are recommended and everything else is “no comment” Having one pool, from which we can cherry-pick, as opposed to finer levels of gradation, seems simpler. If and when we’re ready to move Goldilocks/448 to recommended,

Re: [TLS] Record header size?

Eric, To be honest, it’s always kinda bugged me that SSL/TLS uses a 5-byte header, coming from my embedded network system background. I’ve had dealings with cryptographic hardware (SafeNet at Altiga, and Cavium Nitrox at Cisco), and they have to go through hoops to deal with unaligned access.

Re: [TLS] Record header size?

Can you expand on the alignment issues some more? Thinking through how typical software stacks work, you first read the record header into some buffer to figure out how long the record is and then you read the record payload into a buffer, which may not even be the same buffer. For instance, in NS

Re: [TLS] Record header size?

I would say that 32-bits would be optimal, since that is the typical word-size of processors that need alignment. 2-bytes isn’t much better than 5-bytes in this regard. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On

Re: [TLS] Record header size?

Indeed. It doesn't seem useful to carry around two fixed bytes for alignment reasons -Ekr On Tue, Nov 17, 2015 at 12:45 PM, Daniel Kahn Gillmor wrote: > On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > > The concern here is backward compatibility with inspection middleboxes > which > >

Re: [TLS] Record header size?

On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > The concern here is backward compatibility with inspection middleboxes which > expect the length field to be in a particular place. We agreed in Seattle to > wait for early deployment experience before modifying the header to move > the lengt

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 09:14:00PM +0200, Ilari Liusvaara wrote: > > Where does that leave ciphersuites that are "Recommended" for TLS > > 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify? > > None of block ciphers (nor stream ciphers) work in TLS 1.3 at all. > > All cur

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 11:06 AM, Viktor Dukhovni wrote: > On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > > > - Mark all the cipher suites tha

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 07:06:52PM +, Viktor Dukhovni wrote: > On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > > > - Mark all the cipher su

Re: [TLS] PR#345: IANA Considerations

I personally favor the B-name you used at the meeting, but IANA might have a problem with it☺. if the distinction is that certain code points are assigned to TLS features that are not IETF-reviewed or endorsed, for collision avoidance only, I think the marker name should specifically say so. F

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > My proposal is that we: > > - List all the Standards Track cipher suites that are compatible with TLS > 1.3 in Appendix A. > > - Mark all the cipher suites that are listed in Appendix A as "Recommended" Where does that leave cipher

Re: [TLS] PR#345: IANA Considerations

I would be fine with any name people want to use here :) -Ekr On Tue, Nov 17, 2015 at 10:56 AM, Andrei Popov wrote: > This is a good intention. Can we then choose a stronger, more definitive > term? E.g. “non-standard”, “vendor-specific”, “private”, “not > IETF-reviewed” or something better. >

Re: [TLS] PR#345: IANA Considerations

This is a good intention. Can we then choose a stronger, more definitive term? E.g. “non-standard”, “vendor-specific”, “private”, “not IETF-reviewed” or something better. I feel that “recommended” will change over time, and also that cipher suites and extensions “recommended” for TLS1.3 are dif

Re: [TLS] PR#345: IANA Considerations

Here is my understanding - Recommended things are things which the IETF has reviewed and thinks are good. - Not recommended things are things which the IETF has not reviewed and may be fine but may also be bad. The intention is to break the binding between code point assignment and endorsement.

Re: [TLS] PR#345: IANA Considerations

What is the intended use of the "Recommended" list? I.e. how is an implementer supposed to think about this marker? Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, November 17, 2015 10:01 AM To: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerat

Re: [TLS] PR#345: IANA Considerations

+1. This seems like a reasonable way forward. Russ On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > 1. MUST or SHOULD cipher suites. > 2. Standards track cipher suites (or ones we are making ST, like > the ECC

Re: [TLS] PR#345: IANA Considerations

On 11/17/2015 10:46 AM, Joe Salowey wrote: > I think the TLS 1.3 IANA considerations should just deal with setting up the > recommended column and marking it for the cipher suites/extensions that are > described in the 1.3 document. Other cipher suites/extensions can be marked > as recommended

Re: [TLS] PR#345: IANA Considerations

There are presently four categories of cipher suites vis-a-vis TLS 1.3. 1. MUST or SHOULD cipher suites. 2. Standards track cipher suites (or ones we are making ST, like the ECC ones). 3. Non standards track cipher suites 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. I thi

Re: [TLS] Record header size?

The concern here is backward compatibility with inspection middleboxes which expect the length field to be in a particular place. We agreed in Seattle to wait for early deployment experience before modifying the header to move the length. -Ekr On Tue, Nov 17, 2015 at 7:25 AM, Short, Todd wrote:

Re: [TLS] PR#345: IANA Considerations

I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document. Other cipher suites/extensions can be marked as recommended through other documents. On 11/17/15, 6:54 A

Re: [TLS] Record header size?

Plaintext is still limited to 2^14 octets, so there is no need to have the length be 3 bytes. Having the version start with 4 will purposely indicate the size of the record header. One could go out on a limb and use it to actually indicate the length of the header (i.e. 5 bytes, 4 bytes, 8 bytes

Re: [TLS] Record header size?

Short, Todd writes: >Has there been any consideration to changing the record header for encrypted >traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and >some processors do not handle odd byte offsets well (it was a complaint I >heard from Cisco router/switch engineers). Not

[TLS] Record header size?

Apologies if this has been brought up before. Has there been any consideration to changing the record header for encrypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and some processors do not handle odd byte offsets well (it was a complaint I heard from Cisco router/

Re: [TLS] PR#345: IANA Considerations

On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > > > 1. The Cipher Suites "Recommended" column was populated based on > > the Standards Track RFCs listed in the document (and I removed the > > others). > > Isn’t it just the MTI suites listed in s8.1? > > Maybe I need to go check the mi

Re: [TLS] PR#345: IANA Considerations

On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > > > > On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner wrote: > > > On Nov 17, 2015, at 01:18, Eric Rescorla wrote: > > > > Double-checking, I see that some of the entries in the "TLS 1.3" column > > for Extensions are wrong. Will be updating sho

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner wrote: > > > On Nov 17, 2015, at 01:18, Eric Rescorla wrote: > > > > Double-checking, I see that some of the entries in the "TLS 1.3" column > > for Extensions are wrong. Will be updating shortly. > > > > On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla

Re: [TLS] PR#346: Individual traffic key generation

On Mon, Nov 16, 2015 at 10:29 PM, Martin Thomson wrote: > On 16 November 2015 at 19:52, Eric Rescorla wrote: > >> I have to ask why the continued insistence on calling the thing that > >> forms part of the nonce an "IV". I find it to be misleading. > > > > > > This is the historical terminology

Re: [TLS] PR#345: IANA Considerations

> On Nov 17, 2015, at 01:18, Eric Rescorla wrote: > > Double-checking, I see that some of the entries in the "TLS 1.3" column > for Extensions are wrong. Will be updating shortly. > > On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/345 > >

Re: [TLS] A new encryption "impossible to break"

Ismail, These posts are off-topic for this mailing list. The WG list is concerned with the design of TLS not the cryptographic algorithms used by TLS. Other should feel free to provide comments, but please send those response directly to Ismail not to this list. spt wg chair hat on > On Nov