Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt

[Ted Krovetz]

An RFC for OCB was approved in 2014.

https://tools.ietf.org/html/rfc7253

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

[TLS] Last Call: (Transport Layer Security (TLS) False Start) to Experimental RFC

[The IESG]

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) False Start'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2016-04-20. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document specifies an optional behavior of TLS client
   implementations, dubbed False Start.  It affects only protocol
   timing, not on-the-wire protocol data, and can be implemented
   unilaterally.  A TLS False Start reduces handshake latency to one
   round trip.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ballot/


No IPR declarations have been submitted directly on this I-D.

The reference to RFC2616 should probably be updated to 7230.

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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Sean Turner]

On Apr 06, 2016, at 12:21, Aaron Zauner  wrote:
> 
> Hi,
> 
>> On 30 Mar 2016, at 03:53, Sean Turner  wrote:
>> 
>> Hi!
>> 
>> In Yokohama, we discussed changing the IANA registry assignment rules for 
>> cipher suites to allow anyone with a stable, publicly available, peer 
>> reviewed reference document to request and get a code point and to add an 
>> “IETF Recommended” column to the registry.  This change is motivated by the 
>> large # of requests received for code points [0], the need to alter the 
>> incorrect perception that getting a code point somehow legitimizes the 
>> suite/algorithm, and to help implementers out.  We need to determine whether 
>> we have consensus on this plan, which follows:
>> 
>> 1. The IANA registry rules for the TLS cipher suite registry [1] will be 
>> changed to specification required.
>> 
>> 2. A new “IETF Recommended” column will be added with two values: “Y” or 
>> “N”.  Y and N have the following meaning:
>> 
>> Cipher suites marked with a “Y” the IETF has consensus on
>> and are reasonably expected to be supported by widely
>> used implementations such as open-source libraries.  The
>> IETF takes no position on the cipher suites marked with an
>> “N”.  Not IETF recommended does not necessarily (but can)
>> mean that the ciphers are not cryptographically sound (i.e.,
>> are bad).  Cipher suites can be recategorized from N to Y
>> (e.g., Curve448) and vice versa.
>> 
>> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that 
>> matches the above so that the same information is available to those who 
>> don’t read the IANA considerations section of the RFC.
>> 
>> Please indicate whether or not you could support this plan.
> 
> I maintain the OCB draft and I do support this idea. Sorry for joining this 
> thread late. I did however vote on it during the meeting on monday.
> 
> What's still unclear to me from the discussion is what suites would get a Y 
> or N and which suites won't. Are we just talking about WG consensus or does 
> implementation-availability weigh in here? It's not perfectly clear to me how 
> this would be decided; just because the IANA registry flags a certain suite 
> as preferred doesn't mean it actually will be implemented, and vice-versa. 
> Library authors sometimes implement algorithms out of pure interest and love 
> for coding. I, too, think going beyond a simple Y/N would just further 
> complicate things for implementers and people trying to understand the IANA 
> registry.
> 
> Aaron

What we’re talking about is IETF consensus (i.e., it’s got to get through an 
IETF LC which is slightly higher than just a WGLC), but we’d do a one sentence 
tweak to the TLS WG charter to make the TLS WG be the entity that determine 
whether there’s a Y or N.

A “Y” does not guarantee that it will be implemented and that’s why we put "and 
are reasonably expected to be supported by widely used implementations such as 
open-source libraries.”  Those are pretty good weasel words, but since there’s 
no protocol police we can’t really say they will be implemented.  On the other 
hand, open source implementations also have their own pressures they have to 
deal with that I’m not sure should automatically impact the list.  I also am 
worried about just adding algorithms that are in an open source implementation 
because I believe just about everybody that’s requested a code point starts the 
conversation out with “I’ve got this OpenSSL patch …. "

spt


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Aaron Zauner]

Hi,

> On 30 Mar 2016, at 03:53, Sean Turner  wrote:
> 
> Hi!
> 
> In Yokohama, we discussed changing the IANA registry assignment rules for 
> cipher suites to allow anyone with a stable, publicly available, peer 
> reviewed reference document to request and get a code point and to add an 
> “IETF Recommended” column to the registry.  This change is motivated by the 
> large # of requests received for code points [0], the need to alter the 
> incorrect perception that getting a code point somehow legitimizes the 
> suite/algorithm, and to help implementers out.  We need to determine whether 
> we have consensus on this plan, which follows:
> 
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be 
> changed to specification required.
> 
> 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”. 
>  Y and N have the following meaning:
> 
> Cipher suites marked with a “Y” the IETF has consensus on
> and are reasonably expected to be supported by widely
> used implementations such as open-source libraries.  The
> IETF takes no position on the cipher suites marked with an
> “N”.  Not IETF recommended does not necessarily (but can)
> mean that the ciphers are not cryptographically sound (i.e.,
> are bad).  Cipher suites can be recategorized from N to Y
> (e.g., Curve448) and vice versa.
> 
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that 
> matches the above so that the same information is available to those who 
> don’t read the IANA considerations section of the RFC.
> 
> Please indicate whether or not you could support this plan.

I maintain the OCB draft and I do support this idea. Sorry for joining this 
thread late. I did however vote on it during the meeting on monday.

What's still unclear to me from the discussion is what suites would get a Y or 
N and which suites won't. Are we just talking about WG consensus or does 
implementation-availability weigh in here? It's not perfectly clear to me how 
this would be decided; just because the IANA registry flags a certain suite as 
preferred doesn't mean it actually will be implemented, and vice-versa. Library 
authors sometimes implement algorithms out of pure interest and love for 
coding. I, too, think going beyond a simple Y/N would just further complicate 
things for implementers and people trying to understand the IANA registry.

Aaron


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

Re: [TLS] Asymmetric TLS

[Rick van Rein]

Hello Phil,

> I have a use-case for allowing an MITM to monitor traffic, but not
> impersonate a server, and to allow MITM signing for replay of
> server-responses to support caching.
>
This sounds like attack monitoring (going beyond DoS for which SNI
frequencies might already be helpful).  This used to be possible by
passing certificate private keys, until we all embraced (EC)DHE.  This
is still an option for you of course, since you're violating the idea of
(EC)DHE anyway, at least between the monitor and its related TLS peer.

> As far as I'm aware, TLS currently only supports a shared-secret once
> session initialisation is complete, so I'd need to extend the protocol to
> support asymmetric encryption for the session.
>
I wonder if you'd need to extend the *protocol* or rather its
*implementation* to share private/secret key material.  You could
probably create a side-channel over which you communicate this
efficienctly, based on the random pieces in Hello, for instance.  Any
such implementation would sound the alarm bells for this option (and
probably not make it a default option) that the TLS protocol can't ring
because it is just a protocol.

My suggestion would be to let the monitor supply the private/secret key
material its related TLS peer, so it has more control; also, for TLS
implementations the import of key material is perhaps less scary than
the export (or more possible, if PKCS #11 is used).  Your monitor might
decide to let go of monitoring traffic, to monitor other traffic and
perhaps to share key material between certain sessions when under
attack.  Be careful with all of this though!

> Would there be interest in extending TLS to:
> - allow monitoring-with-consent (based on asymmetric encryption)?
> - allow re-signing from an authorised MITM to support caching?
>
Clearly, the WG does not like this idea.  Same with me.  But if you
tried something implementation-specific, or perhaps even standardise an
explicit side-channel protocol, you may be more likely to get the work
done because that would constitute an explicit and independent choice on
the part of the administrators.  TLS is so full of options that the eyes
of admins already glaze over -- what you are proposing is explicit
weakening of TLS, and it could slip into a configuration too easily as
part of the confusion that the complexity of the protocol already causes.

It could be interesting to let the WG know what your course of action
will be, so we can positively reference any such requests in the future.


Cheers,
 -Rick

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