Re: [TLS] RFC 6066 - Max fragment length negotiation

[Martin Thomson]

On 17 March 2017 at 14:35, Peter Gutmann  wrote:
> Why is it badly designed?  I can guess that some people would prefer to have a
> mechanism for client and server to debate endlessly what the most cromulent
> fragment size is, but that's about the only thing I can see.

I looked at implementing this for NSS with the idea that I would try
to be nice to embedded servers (because web servers are constrained
devices too).

I can't send a max_fragment_length extension that says I support
records of 2^14 octets in length.  Because I don't care and full-sized
fragments are valuable to me in some cases, but if a server is
constrained, it would be no trouble to send it smaller records.

And I can't fix that.  If I send a max_fragment_length extension with
a value other than the four values defined in RFC 6066, all I get for
my troubles is an "illegal_parameter" alert from any server that
implements the RFC correctly.

The design I would use is much simpler.  The extension would carry a
two octet value that is the maximum size of the plaintext that the
endpoint is willing to receive.  A client could say 2^14 and that
would allow the server to send that much if it were able.  The same
server could say 5 and the client would be forced to fragment like
crazy (ok, that last might be too far, we'd probably want to set a
lower bound on the value).

I'd happily implement and advertise that extension.

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann]

Martin Thomson  writes:

>In this case, max_fragment_length is so badly designed that you can actually
>argue that it has utility, but I don't consider that as a good argument for
>the general case.

Why is it badly designed?  I can guess that some people would prefer to have a
mechanism for client and server to debate endlessly what the most cromulent
fragment size is, but that's about the only thing I can see.

As a slight aside, the client-only nature of the extension seems to be another
example of the all-the-world's-the-web view of TLS, that servers have infinite
resources and it's clients who may be constrained.  In the embedded world it's
far more likely to be the exact opposite, the server (e.g. a PLC) is very
resource-constrained and the client connecting to it (e.g. a PC controller)
has all the resources it needs.

Incidentally, here's a picture of a $25 million web server:

http://www.abb-conversations.com/wp-content/uploads/2013/09/ABB_Phaseshifter_transformer.jpg

It's resource-constrained.

(Actually that one doesn't do SSL as far as I know, and the server runs NT 4).

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Eric Rescorla]

FWIW, this requirement is actually very old, dating back to RFC 3546. It's
not unique to TLS 1.2.

   Note that for all extension types (including those defined in
   future), the extension type MUST NOT appear in the extended server
   hello unless the same extension type appeared in the corresponding
   client hello.  Thus clients MUST abort the handshake if they receive
   an extension type in the extended server hello that they did not
   request in the associated (extended) client hello.

https://tools.ietf.org/html/rfc3546#section-2.3

-Ekr




On Thu, Mar 16, 2017 at 6:47 PM, Martin Thomson 
wrote:

> On 17 March 2017 at 11:22, Peter Gutmann 
> wrote:
> > Is that from actually trying it with clients, or just assuming that
> > implementations will do what the spec says?
>
> I know for certain that NSS explodes.  Not from trying, but from
> knowing that part of the code very well.  I'm fairly certain that
> boringSSL does too, knowing David.
>
> You say negative utility, but I've found that if you can get away with
> stricter policing of these things, it helps prevent servers from
> starting to do the wrong thing.  The odds that someone tests a new
> server implementation against major browsers is fairly good.
>
> In any case, what would you expect a client to do if they don't
> advertise the extension?  In this case, max_fragment_length is so
> badly designed that you can actually argue that it has utility, but I
> don't consider that as a good argument for the general case.
>
> ___
> 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] RFC 6066 - Max fragment length negotiation

[Martin Thomson]

On 17 March 2017 at 11:22, Peter Gutmann  wrote:
> Is that from actually trying it with clients, or just assuming that
> implementations will do what the spec says?

I know for certain that NSS explodes.  Not from trying, but from
knowing that part of the code very well.  I'm fairly certain that
boringSSL does too, knowing David.

You say negative utility, but I've found that if you can get away with
stricter policing of these things, it helps prevent servers from
starting to do the wrong thing.  The odds that someone tests a new
server implementation against major browsers is fairly good.

In any case, what would you expect a client to do if they don't
advertise the extension?  In this case, max_fragment_length is so
badly designed that you can actually argue that it has utility, but I
don't consider that as a good argument for the general case.

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann]

Martin Thomson  writes:
>On 17 March 2017 at 10:45, Peter Gutmann  wrote:
>> In which case it might be time to update the RFC, since there's no obvious
>> reason why you can't send it from the server.  Can any of the original 
>> authors
>> provide a reason why it shouldn't be done by the server?
>
>Most clients will explode if the server sends an extension that the client
>didn't offer.

Is that from actually trying it with clients, or just assuming that
implementations will do what the spec says?  It's another one of those bits of
TLS 1.2 that make no sense, so I've ignored the requirement in my code, you
have to add a whole pile of code to perform the check (more attack surface)
and the best possible outcome is that it has no effect, while the worst is
that it breaks things if a buggy server drops in an extension the client
wasn't expecting.  In other words implementing it has negative utility.

There's also the escape hatch of "server-oriented extensions", all you'd need
to do is define one that tells the server that the client will accept any
extensions the server cares to send, thus negating the "no server extensions"
requirement.

Given that this looks like an embedded-only sort of thing, I could even add it
to -LTS, since a primary target of that is embdded/SCADA/etc.

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Martin Thomson]

On 17 March 2017 at 10:45, Peter Gutmann  wrote:
>
> In which case it might be time to update the RFC, since there's no obvious
> reason why you can't send it from the server.  Can any of the original authors
> provide a reason why it shouldn't be done by the server?

Most clients will explode if the server sends an extension that the
client didn't offer.

You would have more luck getting clients to implement the extension.
I looked at this, and it's not impossible.  The spec contains some
frightening things in it though.

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

Re: [TLS] Updated DTLS draft

[Martin Thomson]

On 17 March 2017 at 10:58, Matt Caswell  wrote:
> In DTLS1.3 the cookie is now (potentially) much larger and appears much later 
> in
> the ClientHello, making it much more likely that it will not fall
> fully within the
> first fragment. This could mean a fully stateless solution is impossible.


I think that it is feasible to simply require that ClientHello be
contained in a single datagram.  QUIC does this and when we did the
sums it wasn't completely unreasonable, even assuming several key
shares and a big-ish cookie.  And then we made it possible to make the
cookie even smaller in -19.

That assumes that you are willing to assume a 1k MTU, which I know
IPv4 doesn't guarantee.  I'd be OK with adding a caveat on that point
in the form of "Consequently, DTLS might not work with a small MTU".

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Nitin Shrivastav]

Yoav

The constrained end point is server serving web pages to browsers. 

Nitin

> On Mar 16, 2017, at 4:59 PM, Yoav Nir  wrote:
> 
> 
>> On 16 Mar 2017, at 22:52, Nitin Shrivastav  
>> wrote:
>> 
>> Thanks Yoav. I am assuming it is true for TLS1.2 also?
> 
> RFC 5246 *is* TLS 1.2.  But it’s true for previous versions and for 1.3 as 
> well.
>> 
>> It would be nice to provide a mechanism for servers to do this as we are 
>> trying to run a web server in a constrained IoT end-points with only tens of 
>> KBytes of RAM and SSL/TLS based connection is important..
> 
> I don’t get if you mean that the constrained end-point is the client or the 
> server. But either way, both sides can be configured to use small records. 
> You only really need this extension when you both have large amounts of data 
> (so large records would be used without this extension) and the server is a 
> generic web server that responds to both constrained and non-constrained 
> devices. 
> 
> But even in that case, adding the extension to the ClientHello should not be 
> infeasible.
> 
> Yoav
> 
>>> On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir  wrote:
>>> Hi, Nitin.
>>> 
>>> In section 7.4.1.4 of RFC 5246 it says:
>>> 
>>>An extension type MUST NOT appear in the ServerHello unless the same
>>>extension type appeared in the corresponding ClientHello.
>>> 
>>> So the answer is no. Only the client may request this.
>>> 
>>> Yoav
>>> 
 On 16 Mar 2017, at 21:12, Nitin Shrivastav  
 wrote:
 
 Hello,
 
 This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a 
 question on RFC 6066 Maximum Fragment Length Negotiation section 
 
 The question i have is whether it is possible for a server to initiate the 
 Max fragment length negotiation. The RFC describes a scenario where a 
 constrained client can initiate this but in our product the server is very 
 tightly constrained on memory and we want to reduce the memory used for 
 SSL connections by forcing the clients to use reduce fragment length. We 
 don't have control over the clients in our scenario which are basically 
 the browsers like Chrome, IE etc.
 
 Thanks,
 Nitin
 ___
 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] Updated DTLS draft

[Matt Caswell]

On 13 March 2017 at 23:41, Eric Rescorla  wrote:
> I have just posted a new version of the DTLS 1.3 draft, updated for
> draft-19.
> It's still very rough with a lot of open issues (some of which are even
> noted
> in the draft), and no doubt contains egregious errors.
>
> https://tools.ietf.org/html/draft-rescorla-tls-dtls13-01
>
> As usual, comments welcome.

Section 5.1

The cookie mechanism is meant to be entirely stateless on the server side.
However as it is currently specified it is not (and in fact DTLS1.2 suffers from
the same issue). The problem is that the ClientHello may be fragmented. In order
to reassemble it the server must allocate state.

In OpenSSL 1.1.0 for DTLS1.2 we require that the cookie is entirely held within
the first fragment of the ClientHello. This way the cookie can be validated
without needing to fully reassemble the message (assuming the cookie validation
function does not need any information contained within a later fragment). Only
once the cookie is validated do we then attempt to reassemble the rest of the
ClientHello.

If the cookie is not held within the first fragment then we drop the packet.

OpenSSL prior to 1.1.0 can't handle a fragmented DTLS ClientHello at
all (when running
in stateless mode - we have the option of running stateful which does work).

We kind of get away with this for DTLS1.2. The cookie is relatively
early in the CH
message (i.e. prior to ciphersuites etc). So a CH would have to be fairly
significantly fragmented for it to be a problem.

In DTLS1.3 the cookie is now (potentially) much larger and appears much later in
the ClientHello, making it much more likely that it will not fall
fully within the
first fragment. This could mean a fully stateless solution is impossible.

Matt

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann]

Nitin Shrivastav  writes:

>Thanks Peter, seems like this extension is not an option.  

In which case it might be time to update the RFC, since there's no obvious
reason why you can't send it from the server.  Can any of the original authors
provide a reason why it shouldn't be done by the server?

Peter.

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Nitin Shrivastav]

Thanks Peter, seems like this extension is not an option.  I guess since our 
server is serving the web pages to browsers, we should be able to predict the 
max amount of data that will be pushed when user submits the data on the web 
page and tune the ssl buffer accordingly.

> On Mar 16, 2017, at 7:18 PM, Peter Gutmann  wrote:
> 
> Nitin Shrivastav  writes:
> 
>> We don't have control over the clients in our scenario which are basically
>> the browsers like Chrome, IE etc.
> 
> I think a more important question would be "does any browser support this"?
> Looking at:
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> it seems like the answer is mostly "no".
> 
> Peter.
> 

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann]

Nitin Shrivastav  writes:

>We don't have control over the clients in our scenario which are basically
>the browsers like Chrome, IE etc.

I think a more important question would be "does any browser support this"?
Looking at:

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

it seems like the answer is mostly "no".

Peter.


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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Yoav Nir]

> On 16 Mar 2017, at 22:52, Nitin Shrivastav  
> wrote:
> 
> Thanks Yoav. I am assuming it is true for TLS1.2 also?

RFC 5246 *is* TLS 1.2.  But it’s true for previous versions and for 1.3 as well.
> 
> It would be nice to provide a mechanism for servers to do this as we are 
> trying to run a web server in a constrained IoT end-points with only tens of 
> KBytes of RAM and SSL/TLS based connection is important..

I don’t get if you mean that the constrained end-point is the client or the 
server. But either way, both sides can be configured to use small records. You 
only really need this extension when you both have large amounts of data (so 
large records would be used without this extension) and the server is a generic 
web server that responds to both constrained and non-constrained devices.

But even in that case, adding the extension to the ClientHello should not be 
infeasible.

Yoav

> On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir  > wrote:
> Hi, Nitin.
> 
> In section 7.4.1.4 of RFC 5246 it says:
> 
>An extension type MUST NOT appear in the ServerHello unless the same
>extension type appeared in the corresponding ClientHello.
> 
> So the answer is no. Only the client may request this.
> 
> Yoav
> 
>> On 16 Mar 2017, at 21:12, Nitin Shrivastav > > wrote:
>> 
>> Hello,
>> 
>> This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question 
>> on RFC 6066 Maximum Fragment Length Negotiation section
>> 
>> The question i have is whether it is possible for a server to initiate the 
>> Max fragment length negotiation. The RFC describes a scenario where a 
>> constrained client can initiate this but in our product the server is very 
>> tightly constrained on memory and we want to reduce the memory used for SSL 
>> connections by forcing the clients to use reduce fragment length. We don't 
>> have control over the clients in our scenario which are basically the 
>> browsers like Chrome, IE etc.
>> 
>> Thanks,
>> Nitin
>> ___
>> TLS mailing list
>> TLS@ietf.org 
>> https://www.ietf.org/mailman/listinfo/tls 
>> 
> 
> 



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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Yoav Nir]

Hi, Nitin.

In section 7.4.1.4 of RFC 5246 it says:

   An extension type MUST NOT appear in the ServerHello unless the same
   extension type appeared in the corresponding ClientHello.

So the answer is no. Only the client may request this.

Yoav

> On 16 Mar 2017, at 21:12, Nitin Shrivastav  
> wrote:
> 
> Hello,
> 
> This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question 
> on RFC 6066 Maximum Fragment Length Negotiation section
> 
> The question i have is whether it is possible for a server to initiate the 
> Max fragment length negotiation. The RFC describes a scenario where a 
> constrained client can initiate this but in our product the server is very 
> tightly constrained on memory and we want to reduce the memory used for SSL 
> connections by forcing the clients to use reduce fragment length. We don't 
> have control over the clients in our scenario which are basically the 
> browsers like Chrome, IE etc.
> 
> Thanks,
> Nitin
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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

[TLS] RFC 6066 - Max fragment length negotiation

[Nitin Shrivastav]

Hello,

This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a
question on RFC 6066 Maximum Fragment Length Negotiation section

The question i have is whether it is possible for a server to initiate the
Max fragment length negotiation. The RFC describes a scenario where a
constrained client can initiate this but in our product the server is very
tightly constrained on memory and we want to reduce the memory used for SSL
connections by forcing the clients to use reduce fragment length. We don't
have control over the clients in our scenario which are basically the
browsers like Chrome, IE etc.

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

Re: [TLS] Uplifting 5289

[Yoav Nir]

Oh, sorry. I missed that it was Informational.

In that case there’s just the issue that it has ECDH ciphersuites at a time 
where 4492bis is deprecating all the other ones.  But some of the ciphersuites 
in there are in wide enough use that it shouldn’t remain Informational.

Yes, it should be uplifted then.

Yoav

> On 16 Mar 2017, at 21:23, Eric Rescorla  wrote:
> 
> This is actually uplift to PS.
> 
> On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir  > wrote:
> 
>> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com 
>>  wrote:
>> 
>> 
>> 
>> Please excuse typos, sent from handheld device
>> 
>>> On Mar 16, 2017, at 11:37 AM, Yoav Nir >> > wrote:
>>> 
>>> 
 On 16 Mar 2017, at 17:17, Eric Rescorla > wrote:
 
 Hi folks
 
 I note that we are proposing to uplift RFC 5289 to PS, despite the fact 
 that it
 standardizes some CBC cipher suites, which the WG is looking to move away
 from. I recognize that these are the only cipher suites you can use in TLS 
 1.0
 and 1.1, but we also want people to move away from them.
 
 This problem is probably solvable by marking the registry as Not 
 Recommended, but I wondered if anyone had other thoughts on this topic?
 
>>> 
>>> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch 
>>> of ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 
>>> 5246.
>> 
>> TLS 1.2 will be in use for a while unless major problems are found, so it's 
>> worthwhile IMO.
> 
> I understand that. I’m wondering what message we are trying to convey by 
> publishing or uplifting a full standard for a now-obsolete protocol.
> 
> The Internet works just fine on proposed standards (or even Internet Drafts)
> 
> Yoav
> 
> 



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

Re: [TLS] Uplifting 5289

[Eric Rescorla]

This is actually uplift to PS.

On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir  wrote:

>
> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote:
>
>
>
> Please excuse typos, sent from handheld device
>
> On Mar 16, 2017, at 11:37 AM, Yoav Nir  wrote:
>
>
> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
>
> Hi folks
>
> I note that we are proposing to uplift RFC 5289 to PS, despite the fact
> that it
> standardizes some CBC cipher suites, which the WG is looking to move away
> from. I recognize that these are the only cipher suites you can use in TLS
> 1.0
> and 1.1, but we also want people to move away from them.
>
> This problem is probably solvable by marking the registry as Not
> Recommended, but I wondered if anyone had other thoughts on this topic?
>
>
> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch
> of ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes
> 5246.
>
>
> TLS 1.2 will be in use for a while unless major problems are found, so
> it's worthwhile IMO.
>
>
> I understand that. I’m wondering what message we are trying to convey by
> publishing or uplifting a full standard for a now-obsolete protocol.
>
> The Internet works just fine on proposed standards (or even Internet
> Drafts)
>
> Yoav
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Uplifting 5289

[Yoav Nir]

> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote:
> 
> 
> 
> Please excuse typos, sent from handheld device
> 
>> On Mar 16, 2017, at 11:37 AM, Yoav Nir  wrote:
>> 
>> 
>>> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
>>> 
>>> Hi folks
>>> 
>>> I note that we are proposing to uplift RFC 5289 to PS, despite the fact 
>>> that it
>>> standardizes some CBC cipher suites, which the WG is looking to move away
>>> from. I recognize that these are the only cipher suites you can use in TLS 
>>> 1.0
>>> and 1.1, but we also want people to move away from them.
>>> 
>>> This problem is probably solvable by marking the registry as Not 
>>> Recommended, but I wondered if anyone had other thoughts on this topic?
>>> 
>> 
>> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch 
>> of ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 
>> 5246.
> 
> TLS 1.2 will be in use for a while unless major problems are found, so it's 
> worthwhile IMO.

I understand that. I’m wondering what message we are trying to convey by 
publishing or uplifting a full standard for a now-obsolete protocol.

The Internet works just fine on proposed standards (or even Internet Drafts)

Yoav



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

Re: [TLS] Uplifting 5289

[kathleen . moriarty . ietf]

Please excuse typos, sent from handheld device 

> On Mar 16, 2017, at 11:37 AM, Yoav Nir  wrote:
> 
> 
>> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
>> 
>> Hi folks
>> 
>> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that 
>> it
>> standardizes some CBC cipher suites, which the WG is looking to move away
>> from. I recognize that these are the only cipher suites you can use in TLS 
>> 1.0
>> and 1.1, but we also want people to move away from them.
>> 
>> This problem is probably solvable by marking the registry as Not 
>> Recommended, but I wondered if anyone had other thoughts on this topic?
>> 
> 
> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch of 
> ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 5246.

TLS 1.2 will be in use for a while unless major problems are found, so it's 
worthwhile IMO.

Kathleen 

> 
> Yoav
> 
> 
> ___
> 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] Uplifting 5289

[Yoav Nir]

> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
> 
> Hi folks
> 
> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that 
> it
> standardizes some CBC cipher suites, which the WG is looking to move away
> from. I recognize that these are the only cipher suites you can use in TLS 1.0
> and 1.1, but we also want people to move away from them.
> 
> This problem is probably solvable by marking the registry as Not Recommended, 
> but I wondered if anyone had other thoughts on this topic?
> 

5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch of 
ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 5246.

Yoav




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

Re: [TLS] Uplifting 5289

[Sean Turner]

ekr,

While we’re moving the entire document to PS, we’re also following it with 
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ that 
adds a “Recommended" column that is not (see s6) going to include marking “Y” 
for any of the CBC algorithms.  So, I think we’re okay.

spt

> On Mar 16, 2017, at 11:17, Eric Rescorla  wrote:
> 
> Hi folks
> 
> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that 
> it
> standardizes some CBC cipher suites, which the WG is looking to move away
> from. I recognize that these are the only cipher suites you can use in TLS 1.0
> and 1.1, but we also want people to move away from them.
> 
> This problem is probably solvable by marking the registry as Not Recommended, 
> but I wondered if anyone had other thoughts on this topic?
> 
> -Ekr
> 
> ___
> 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] RFC4492bis next steps

[Stephen Farrell]

On 16/03/17 12:52, Yoav Nir wrote:
> OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s
> comments over the weekend.

Excellent, thanks,
S

> 
> Yoav
> 
>> On 16 Mar 2017, at 14:41, Stephen Farrell
>>  wrote:
>> 
>> 
>> 
>> On 16/03/17 06:20, Yoav Nir wrote:
>>> Hopefully I’ll be all done and ready to submit a new version as
>>> soon as submissions are re-opened on the 27th.
>> 
>> If we're ready sooner, I'd prefer try get that out of the way next
>> week. I can tell to secretariat to accept updates for this draft.
>> (I'll likely do that after the IESG telechat this afternoon)
>> 
>> Cheers, S.
>> 
> 



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

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-rfc4492bis-15: No Objection

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:
--

I would like to vote Yes on this document, but there are some minor
issues with this document which prevent me from doing so:

0) There is some general awkwardness in text talking about allowed points
formats, considering that only uncompressed form is now allowed. I don't
have recommendations about improving text, other than the following:

If no future formats are expected, it feels almost better to recommend
against inclusion of the Point formats extension, as lack of it means
uncompressed format anyway.

1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
moved to section 2.

2) In Section 6:

   Server implementations SHOULD support all of the following cipher
   suites, and client implementations SHOULD support at least one of
   them:

   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

GCM ciphers are not listed in the table earlier in the same section. They
are defined in RFC 5289. This document doesn't have any reference to RFC
5289 and GCM ciphers are not discussed anywhere else in the document.


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

Re: [TLS] RFC4492bis next steps

[Yoav Nir]

OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s comments 
over the weekend.

Yoav

> On 16 Mar 2017, at 14:41, Stephen Farrell  wrote:
> 
> 
> 
> On 16/03/17 06:20, Yoav Nir wrote:
>> Hopefully I’ll be all done and ready to submit a new version as soon
>> as submissions are re-opened on the 27th.
> 
> If we're ready sooner, I'd prefer try get that
> out of the way next week. I can tell to secretariat
> to accept updates for this draft. (I'll likely
> do that after the IESG telechat this afternoon)
> 
> Cheers,
> S.
> 



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

Re: [TLS] RFC4492bis next steps

[Stephen Farrell]

On 16/03/17 06:20, Yoav Nir wrote:
> Hopefully I’ll be all done and ready to submit a new version as soon
> as submissions are re-opened on the 27th.

If we're ready sooner, I'd prefer try get that
out of the way next week. I can tell to secretariat
to accept updates for this draft. (I'll likely
do that after the IESG telechat this afternoon)

Cheers,
S.



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

Re: [TLS] RFC4492bis next steps

[Sean Turner]

Thanks Yoav!

spt

> On Mar 16, 2017, at 02:20, Yoav Nir  wrote:
> 
> Hi.
> 
> There are now three PRs pending for this draft:
> https://github.com/tlswg/rfc4492bis/pulls
> 
> These all look fine to me.
> 
> There is also ekr’s review that requires some more changes:
> https://www.ietf.org/mail-archive/web/tls/current/msg22628.html
> 
> So unless there are objections, I will merge the three PRs over the weekend 
> so I can make the remaining changes without causing a bunch of conflicts.
> 
> Hopefully I’ll be all done and ready to submit a new version as soon as 
> submissions are re-opened on the 27th.
> 
> Yoav
> 
> ___
> 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] RFC4492bis next steps

[Yoav Nir]

Hi.

There are now three PRs pending for this draft:
https://github.com/tlswg/rfc4492bis/pulls 


These all look fine to me.

There is also ekr’s review that requires some more changes:
https://www.ietf.org/mail-archive/web/tls/current/msg22628.html 


So unless there are objections, I will merge the three PRs over the weekend so 
I can make the remaining changes without causing a bunch of conflicts.

Hopefully I’ll be all done and ready to submit a new version as soon as 
submissions are re-opened on the 27th.

Yoav



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