Viktor Dukhovni writes:
>Explicit profiles make some sense. They need not be defined by the TLS
>WG per-se, it might be enough for the TLS specification to reference an
>IANA profile registry, with the TLS-WG defining a "base" profile. Then
>other WGs (including the[ TLS WG) can define addit
On 9/16/15, Jeffrey Walton wrote:
> On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell
> wrote:
>>
>>
>> On 16/09/15 09:19, Peter Gutmann wrote:
>>> Jeffrey Walton writes:
>>>
Somewhat off-topic, why does TLS not produce a few profiles. One can be
"Opportunistic TLS Profile" with a compa
Profiles are out of scope for the currently-chartered WG and, as we've seen
from previous times these discussions have come up, they tend to overwhelm
everything.
Please take it off-list.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/
On 9/16/15 at 4:23 PM, n...@cryptonector.com (Nico Williams) wrote:
Whichever one is removed, I shall oppose the removal of the other.
On 9/17/15 at 5:21 PM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote:
The costs are likely noticeable for 4096-bit RSA keys. In the end
though, if dropping
Thanks to all who helped to get this published.
spt
On Sep 16, 2015, at 13:44, rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
>
>
>RFC 7627
>
>Title: Transport Layer Security (TLS) Session
>Hash
All,
For the purposes of TLS1.3 specification, it’s clear that there is WG consensus
to remove support for DSA the same way many curves from NamedGroup (s6.3.2.2)
were removed, i.e., we’re going to remove references, code, etc. If there is
interest documenting how to support DSA in TLS1.3, a s
On Wed, Sep 16, 2015 at 5:31 PM, Daniel Kahn Gillmor
wrote:
> --dkg
>
> [0] I do not think that clients engaged in a DH key exchange should be
> uniformly required to claim an identity at the TLS layer :)
I agree with this and that's not the intention.
-Ekr
>
On Wed 2015-09-16 20:21:11 -0400, Viktor Dukhovni wrote:
> The difference between raw public keys (RFC7250 RPK) and anon is:
>
> - PRO: Dropping anon simplifies the implementation and reduces
> cipher count.
>
> - PRO: Raw keys may facilitate TOFU pinning.
>
> - CON: Raw keys are
On Wed, Sep 16, 2015 at 08:31:41PM -0400, Daniel Kahn Gillmor wrote:
> For those worried about computational cost: the raw public key or
> certificate themselves do not have to be valid mathematical objects if
> the peer is not inclined to check them.
That's not generally possible. Many servers
On Wed, Sep 16, 2015 at 07:14:48PM -0400, Dave Garrett wrote:
> Yeah, we don't need to argue semantics. My point is that I'd agree with
> a more strict profile than what we have now as an addon, but not a more
> permissive profile, as was the initial suggestion.
I don't think that "permissive" vs
On Tue 2015-09-15 21:00:39 -0400, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described in
> https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this issu
On Wed, Sep 16, 2015 at 02:38:05PM -0700, Eric Rescorla wrote:
> The point I was making was that presently we have:
>
> - Certificates
> - Raw keys
> - Anon
>
> This proposal is to remove Anon, thus making things strictly simpler, since
> Raw keys can replace Anon but not the other way around. O
>> It's a profile. Call it what you will. The rest of us call this a
>> profile. All the more so when profiles are named in an IANA registry.
>> Applications can then very trivially select an appropriate TLS profile
>> using standard profile naming.
>
> Yeah, we don't need to argue semantics. My
On Wednesday, September 16, 2015 07:23:34 pm Nico Williams wrote:
> On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote:
> > This appears to just be a miscommunication.
>
> It is not.
>
> > The current poll is to remove anon ciphers in favor of raw public
> > keys. We're not considering
On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote:
> This appears to just be a miscommunication.
It is not.
> The current poll is to remove anon ciphers in favor of raw public
> keys. We're not considering removing raw public keys, as far as I
> know, and I think most of us would be ag
On Wed, Sep 16, 2015 at 4:07 PM, Dave Garrett
wrote:
> On Wednesday, September 16, 2015 06:55:02 pm Nico Williams wrote:
> > On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote:
> > > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
> > > > In addition, they are already part of TLS,
On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote:
> On Wednesday, September 16, 2015 05:38:27 pm Viktor Dukhovni wrote:
> > On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote:
> > > The suggestion that started this thread was to have a "Standard TLS
> > > Profile"
> > > that
On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote:
> On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
>
> > In addition, they are already part of TLS, so the question would be if we
> > have
> > consensus to remove them
> >
>
> This thread is about the removal of DH_anon_*, n
On Wed, Sep 16, 2015 at 2:24 PM, Nico Williams
wrote:
> On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote:
> > On Wednesday, September 16, 2015, Eric Rescorla wrote:
> >
> > > In addition, they are already part of TLS, so the question would be if
> we
> > > have
> > > consensus to rem
On Wed, Sep 16, 2015 at 2:25 PM, Brian Smith wrote:
> On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
>
>> In addition, they are already part of TLS, so the question would be if we
>> have
>> consensus to remove them
>>
>
> This thread is about the removal of DH_anon_*, not about raw
On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote:
> The suggestion that started this thread was to have a "Standard TLS Profile"
> that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels
> like a suggestion to keep allowance of obsolete junk as the norm with
> "defens
On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
> In addition, they are already part of TLS, so the question would be if we
> have
> consensus to remove them
>
This thread is about the removal of DH_anon_*, not about raw public keys.
Cheers,
Brian
On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote:
> On Wednesday, September 16, 2015, Eric Rescorla wrote:
>
> > In addition, they are already part of TLS, so the question would be if we
> > have
> > consensus to remove them
> >
>
> I see a bunch of +1s and zero -1s. Just saying.
On Wednesday, September 16, 2015, Eric Rescorla wrote:
> In addition, they are already part of TLS, so the question would be if we
> have
> consensus to remove them
>
I see a bunch of +1s and zero -1s. Just saying...
--
Tony Arcieri
___
TLS mail
In addition, they are already part of TLS, so the question would be if we
have
consensus to remove them
-Ekr
On Wed, Sep 16, 2015 at 2:01 PM, Nico Williams
wrote:
> On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote:
> > I think it is a good idea to remove DH_anon_* and similar EC
On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote:
> I think it is a good idea to remove DH_anon_* and similar ECDH_anon_*
> cipher suites.
>
> This isn't an endorsement of the raw public key modes.
Sure, one can always use self-signed certs (at an even higher cost to do
anonymity). If
A new Request for Comments is now available in online RFC libraries.
RFC 7627
Title: Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension
Author: K. Bhargavan, Ed., A. Delignat-Lavaud,
On Tue, Sep 15, 2015 at 6:00 PM, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described in
> https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this iss
On Wed, Sep 16, 2015 at 10:40:28AM -0700, Martin Thomson wrote:
> On 15 September 2015 at 18:00, Joseph Salowey wrote:
> > remove anonymous DH
>
> +1
>
> It's not like we're making the use case impossible, just that the
> solution will look different.
And will be more costly.
I'm neutral on th
On Sat, Sep 12, 2015 at 1:49 PM, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at
On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote:
> I'd be fine with phrasing it as: implementations MUST send all alerts
> when indicated, and SHOULD make a best-effort to ensure they get
> delivered to the peer.
+1.
Perhaps some text explaining the difficulty in the latter and offer
> The extension? IIRC, that is what _client_ can verify. This is about what
> _server_ can verify.
> Or the equivalent of current field that specifies that? That's inside
> CertificateRequest, which would be optional.
I don't necessarily buy Martin's argument that signature_algorithms covers t
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote:
> On 09/15/2015 06:29 PM, Nico Williams wrote:
> > But if you have a fatal error you'll be closing immediately anyways.
>
> I'm trying to explain that any requirement to send fatal alerts will be
> difficult to implement. With the BS
Remove it.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
> Sent: Wednesday, September 16, 2015 7:24 AM
> To: Florian Weimer ; Henrik Grubbström
>
> Cc: tls@ietf.org
> Subject: Re: [TLS] Should we require implementations to send alerts?
>
>
> > With full-du
On Wed, Sep 16, 2015 at 11:35 AM, Andrei Popov
wrote:
> To clarify, the proposal includes removing ECDH_anon, right?
>
Yes.
> If it does, I support it.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Joseph Salowey
> *Sent:* Tuesday, September 1
To clarify, the proposal includes removing ECDH_anon, right? If it does, I
support it.
Cheers,
Andrei
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey
Sent: Tuesday, September 15, 2015 6:01 PM
To: tls@ietf.org
Subject: [TLS] Call for consensus to remove anonymous DH
There ha
On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote:
> On 16 September 2015 at 08:30, Ilari Liusvaara
> wrote:
> > Problem with pulling client auth out of the handshake is that it
> > complicates applications that can't change identities involved with
> > active connection.
>
> Why wou
On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote:
> > Yes. I wouldn't recommend following this path to others; it's not
> > easy and the return on that investment isn't all good. The mess we
> > were attempting to clean up with HTTP/2 was the state of TLS
> > deployment on the web, n
I should add: I do think this general line of consolidating all the client
auth modes is a good idea, assuming we can work out the details.
-Ekr
On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla wrote:
> I think the potential issue here is needing a way for the server to tell
> the
> client "don
I think the potential issue here is needing a way for the server to tell the
client "don't bother sending me data until you've authenticated" (though,
as MT says, you could argue that the client's signature retroactively
authenticates, which does seem like the simplest way to think about things).
Martin's point makes sense to me: applications that need to do authentication
upfront can still do that immediately after the handshake.
Cheers,
Andrei
-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com]
Sent: Wednesday, September 16, 2015 10:48 AM
To: Ilari Liusv
> There has been some discussion to remove anonymous DH as described in
> https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this issue yet. Please respond on this message by Monday,
>
On 16 September 2015 at 08:02, Peter Gutmann wrote:
>>HTTP-2 did this kind of thing, and IIRC are the first to do so.
>
> Some PKI standards have done it too, but mostly because the base standard was
> such a mess that you needed a profile just to sort out what needed to be
> implemented for anyth
On 15 September 2015 at 20:12, Karthikeyan Bhargavan
wrote:
> I assume the client hello extension still has the certificate digest, yes?
> This means that the analysis probably relied on agreement of the certificate
> hash from the client hello.
This was only in the 1.3 context, and the certific
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote:
> I'm trying to explain that any requirement to send fatal alerts will be
> difficult to implement. With the BSD sockets API, the only way to do
> that reliable is *not* to close the socket immediately, which is
> apparently not what
On Tue, Sep 15, 2015 at 08:17:56PM +, Andrei Popov wrote:
> Perhaps we can simplify the protocol by pulling client auth out of the
> handshake as follows:
Problem with pulling client auth out of the handshake is that it
complicates applications that can't change identities involved with
active
Salz, Rich writes:
>> An actual profile of TLS would be something like MUST TLS 1.1 or above,
>> MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication
>> what isn't explicitly permitted is denied).
>
>HTTP-2 did this kind of thing, and IIRC are the first to do so.
Some PKI stan
Stephen Farrell writes:
>I'm not sure how to process that comment. You ask for X, I ask is Y==X and
>your answer is that Y doesn't exist? Seems odd. ;-)
There's a difference between "X/Y exists" (but no-one knows about it) and "X/Y
exists and is actively used". As I said, I've never seen the BC
On 16/09/15 12:18, Peter Gutmann wrote:
> Stephen Farrell writes:
>
>> We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a
>> draft [2] (current in IESG evaluation) for the embedded case. Are those the
>> kind of thing you're after?
>
> Sort of, but since they're not p
I’ve also uploaded a draft agenda:
http://ietf.org/meeting/interim/proceedings.html
As per usual, this interim is going to focus on TLS 1.3 related issues.
spt
On Sep 15, 2015, at 15:09, Sean Turner wrote:
> In case you’re planning on attending the f2f meeting next week please fill
> out t
> With full-duplex connections, it does not make a difference. TCP will still
> detect a data loss event, send the RST segment, and discard the queued fatal
> alert.
Yes, it might be hard(er) to do the right thing. We should not penalize
everyone because of that.
_
> An actual profile of TLS would be something like MUST TLS 1.1 or above,
> MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication
> what isn't explicitly permitted is denied).
HTTP-2 did this kind of thing, and IIRC are the first to do so.
___
On 09/16/2015 01:51 PM, Henrik Grubbström wrote:
> On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote:
>> On 09/15/2015 06:29 PM, Nico Williams wrote:
> [...]
>>>
>>> But if you have a fatal error you'll be closing immediately anyways.
>>> Does sending the fatal alert cause a problem other tha
On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote:
> On 09/15/2015 06:29 PM, Nico Williams wrote:
[...]
>>
>> But if you have a fatal error you'll be closing immediately anyways.
>> Does sending the fatal alert cause a problem other than increase the
>> likelihood of RSTs? What is the altern
Stephen Farrell writes:
>We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a
>draft [2] (current in IESG evaluation) for the embedded case. Are those the
>kind of thing you're after?
Sort of, but since they're not part of the TLS spec they essentially don't
exist (I've n
> This kinda begs the question, who should be responsible for high level TLS
> configurations to ease management, maximize security and minimize
> interoperability issues.
>
> For that, I'd argue it falls squarely within TLS WG purview.
The security area has a hand in reviewing all of them, as p
On 09/15/2015 06:29 PM, Nico Williams wrote:
> On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote:
>> On 09/12/2015 10:49 PM, Eric Rescorla wrote:
>>> Issue: https://github.com/tlswg/tls13-spec/issues/242
>>>
>>> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>>>
>
On Wed, Sep 16, 2015 at 4:10 AM, Tom Ritter wrote:
> On 15 September 2015 at 20:42, Tony Arcieri wrote:
> > +1 for removing anonymous DH
>
> +1.
>
+1.
Aaron
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 16/09/15 09:19, Peter Gutmann wrote:
> Jeffrey Walton writes:
>
>> Somewhat off-topic, why does TLS not produce a few profiles. One can be
>> "Opportunistic TLS Profile" with a compatible security posture and include
>> ADH. Another can be a "Standard TLS Profile" and include things like exp
On Tue, 2015-09-15 at 18:00 -0700, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described
> inhttps://www.ietf.org/mail-archive/web/tls/current/msg17481.html. ; I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this
Jeffrey Walton writes:
>Somewhat off-topic, why does TLS not produce a few profiles. One can be
>"Opportunistic TLS Profile" with a compatible security posture and include
>ADH. Another can be a "Standard TLS Profile" and include things like export
>grade crypto, weak and wounder ciphers SSLv3, e
62 matches
Mail list logo
