Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

Hiya, Thanks for reading the draft! On 19/08/18 00:45, Artyom Gavrichenkov wrote: > On Mon, Jul 9, 2018 at 7:42 PM Kathleen Moriarty > wrote: >> Stephen and I posted the draft below to see if the TLS working group >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has >> been a

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

Yeah, adopt it. I'll review. S On 25/07/18 03:16, Joseph Salowey wrote: > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft to > become

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

r any kind of data that I might be able to provide. > Having said that, I completely understand (and share) your distrust of > anonymous data. I am at a loss as to how to proceed. > > I am open to any constructive suggestions. > > Thanks, > Nalini > > > On Wed,

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

they may not. S. > > > Please let me know if this will be of use & if you have suggestions for > improvement. > > Thanks, > Nalini > > > > > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell > wrote: > >> >> Hi Nalini, >> >> On 10/07/18

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

Hiya, On 10/07/18 19:04, Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote: > >> I didn't have time before the I-D cutoff but have since >> added a section on mail to the repo pre-01 version. (See >> [1] section 3.2.) I'd love

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

Hi Nalini, On 10/07/18 04:50, nalini elkins wrote: > It would be nice to see some of this reflected in the draft rather than > only statistics on browsers. The real usage of these protocols is far > more complex. I didn't have time before the I-D cutoff but have since added a section on mail

Re: [TLS] DNS-based Encrypted SNI

Hiya, Just on this bit... On 04/07/18 18:20, Eric Rescorla wrote: > The structure started a bit simpler and got new features to > deal with new issues. Specifically: > > - The checksum is intended to deal with corruption I'm not sure I see why that's needed, but I believe you if you say it

Re: [TLS] DNS-based Encrypted SNI

Hiya, On 03/07/18 00:39, Eric Rescorla wrote: > Hi folks, > > I just submitted: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 Thanks for writing that up. I think it's an interesting addition to the set of potential solutions. > > This draft describes a DNS-based approach to

Re: [TLS] TLS@IETF101 Agenda Posted

Russ, On 15/03/18 17:29, Russ Housley wrote: >>> Nalini, why don't you (the consortium) define the standard, >>> then? > >> Indeed, if a “TLS13-visibility” standard has to be defined, it >> would make sense for the consortium (rather than the TLS WG) to >> define it. > > In fact, my mistake

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:16, Stephen Farrell wrote: > Of course some people who are used to MitMing connections will > have problems and will have to change. I got an offlist message correcting me about the above. I do agree that it's odd to describe post-facto decryption of a TLS session that us

Re: [TLS] TLS@IETF101 Agenda Posted

On 15/03/18 00:05, nalini elkins wrote: > There is no question of a smokey back room. I'm sorry to disagree so bluntly, but while I was an AD some of the people involved here requested that I meet them in private to discuss this topic before it had been raised on the list, and without telling

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:32, nalini elkins wrote: > But, it is a very difficult issue. If I can use a different analogy, if > the City of Monterey built a new sewer system and told me that to connect > to it, I had to build a new house, I would scream! Analogies cannot be used to draw conclusions,

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:00, nalini elkins wrote: > The simple explanation is that people think they will have serious > issues with TLS1.3 and actually, TLS1.2 when it is DH only. Of course some people who are used to MitMing connections will have problems and will have to change. But that does not

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

Hi Rich (and Tony Rutkowski == hot_middlebox I assume?) On 14/03/18 22:17, Salz, Rich wrote: > * The requirements for visibility exist in an array of regulated > environments worldwide. It is one of the presentation areas in the Hot > Middlebox Workshop. >

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

Russ, On 14/03/18 03:03, Russ Housley wrote: > Stephen: > >>> I do not know if the TLS WG will want to adopt this approach. I >>> would like to find out. >> >> Did you read the list traffic from Oct/Nov? I have no idea how you >> can be in doubt if you did. It's readily apparent that your

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

Hi Russ, On 13/03/18 21:49, Russ Housley wrote: > The Prague discussion was about draft-green-... Much more was discussed than just that one dead draft. In particular see the minutes for the more general question posed by the chairs. > Nick Sullivan summarized four concerns with that approach.

Re: [TLS] TLS@IETF101 Agenda Posted

ou (chairs) don't start to impose that kind of (normal actually) discipline on these efforts, we risk an endless round of iterations of this overall discussion. S. > > > On Tue, Mar 13, 2018 at 7:21 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >&

Re: [TLS] TLS@IETF101 Agenda Posted

Hiya, Just to be clear: I'm still waiting for the chairs and/or AD to explain how the proposed discussion of this draft is consistent with IETF processes, given the results of the discussion in Prague (a very clear lack of consensus to even work on this topic), and the discussion of the -00

Re: [TLS] TLS@IETF101 Agenda Posted

Hiya, On Saturday, 10 March 2018, Melinda Shore wrote: > On 3/9/18 12:57 PM, Kathleen Moriarty wrote: > > The hummed answer to that question was very close to 50/50 in the > > room, inconclusive. > > From the perspective of consensus decision-making that's > actually very clear - there's no

Re: [TLS] TLS@IETF101 Agenda Posted

Kathleen, On 09/03/18 21:57, Kathleen Moriarty wrote: > Hello, Stephen. > > On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> Hi Joe, >> >> I'm sorry, but I gotta say that answer seems to me both unresponsive

Re: [TLS] New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt

With no dis-respect to Russ or Ralph (but with zero acceptance/respect for the main concept espoused by this draft)... I request that the WG chairs not waste yet more time on agenda items dealing with proposals for breaking TLS - a working group that spends so many f2f hours (yes, hours,

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

Just on the 0-RTT thing: As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely argued too btw.) I do believe we'll live to regret 0-RTT when implementation issues and unsuitable application uses emerge over time but neither that nor general dislike of 0-RTT are IMO sufficient reasons to

Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-04.txt

Hiya, On 15/02/18 13:12, Sean Turner wrote: > Kathleen and Stephen, > > This version incorporates the WGLC issues. The authors believe this is now > ready for IETF LC. As shepherd, I concur that this seems to address all the issues raised as per list discussion. This is a clearly non-crazy

Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt

/tls/current/msg25279.html On 15/01/18 21:34, Stephen Farrell wrote: > > Hiya, > > Kathleen's a bit busy at the moment so asked that, as shepherd, > I kick off the WGLC for this one (as the two chairs are authors). > The idea is that I'll summarise the WGLC thread to her and she

[TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt

Hiya, Kathleen's a bit busy at the moment so asked that, as shepherd, I kick off the WGLC for this one (as the two chairs are authors). The idea is that I'll summarise the WGLC thread to her and she can then decide if this is ready to move forward. So this starts a 2-week WGLC, ending on

Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt

On 04/01/18 16:51, Sean Turner wrote: > > As we discussed in Singapore, Stephen Farrell has graciously offered to > Shepherd this draft; write-up can be found at: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/ Gracious? Me? Well, I

Re: [TLS] access_administratively_disabled v2

On 04/01/18 14:22, Eric Rescorla wrote: > I am not in favor of this change at this time. Same here. > > I suspect I'm not in favor of the mechanism, but i'm definitely not in > favor of > adding a placeholder alert for some mechanism which isn't specified. I'm fairly sure I'm against

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

On 02/01/18 20:08, Mateusz Jończyk wrote: >> I'm not really enthusiastic about any of these ideas for any of the >> administratively prohibited >> use cases because the information being provided to the user is unverifiable. >> I.e., this >> just tells you that someone on the network didn't like

Re: [TLS] Additional TLS 1.3 results from Chrome

Hiya, On 19/12/17 13:56, Salz, Rich wrote: > “dropped as a bad idea” is an interesting end-state. Also “on hold > for now” (which is how I want to see the TLS-breaking proposals). > > Having more I-D workflow options seems like something the IESG should > take up. > Well, TBH I doubt it'd be

Re: [TLS] Additional TLS 1.3 results from Chrome

Hiya, On 19/12/17 01:59, Salz, Rich wrote: > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. > >> I think this would be fine, but not imperative. > > I think it would almost be hypocritical if we did not do it. > I'm

Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

s are worth having available at the > current time), tat would be awesom> > On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> Hiya, >> >> I just posted a draft shepherd write-up for this [1]. (The >> write-up text

[TLS] question for the WG about draft-ietf-tls-iana-registry-updates

Hiya, I just posted a draft shepherd write-up for this [1]. (The write-up text was mostly written by Sean as it happens - for which he has my thanks as it's boring as hell to do that:-) There are nits but only one substantive question that I don't recall the WG discussing before (but maybe I'm

Re: [TLS] network-based security solution use cases

Hiya, On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > Please see below: > > On 11/7/17, 4:08 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > > On 07/11/17 23:53, Nancy Cam-Winget (

Re: [TLS] network-based security solution use cases

taking an initial look at the document Stephen - please > see below for responses so far > > On 11/7/17 4:13 AM, Stephen Farrell wrote: >> Hiya, >> >> On 07/11/17 02:48, Flemming Andreasen wrote: >>> We didn't draw any particular line, but the use case scenari

Re: [TLS] network-based security solution use cases

Hiya, On 07/11/17 23:27, Flemming Andreasen wrote: > Thanks for taking an initial look at the document Stephen - please see > below for responses so far > > On 11/7/17 4:13 AM, Stephen Farrell wrote: >> Hiya, >> >> On 07/11/17 02:48, Flemming Andreasen wrote: >

Re: [TLS] network-based security solution use cases

Hiya, On 07/11/17 02:48, Flemming Andreasen wrote: >> > We didn't draw any particular line, but the use case scenarios that we > tried to highlight are those related to overall security and regulatory > requirements (including public sector) I had a quick look at the draft (will try read

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

Hi Joe, On 06/11/17 01:57, Joseph Salowey wrote: > I'm not sure what use cases you are targeting, but this type of solution > can be dangerous for application security. Most application security models > assume that TLS will provide both confidentiality and authenticity. > Breaking

Re: [TLS] TLS@IETF100: Agenda Requests

Hiya, On 05/11/17 13:09, Ted Lemon wrote: > Consensus isn't about number of votes. However, I think we can say that > although there seems to be some interest in making sure this use case is > addressed, there are known ways of addressing it, and little interest in > inventing a new way that

Re: [TLS] Draft RHRD

On 01/11/17 14:18, Salz, Rich wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, > Nick Sullivan concluded: > >> - on the other hand using draft-rhrd is safer than allowing >> organizations to hack single-key escrow into TLS 1.3 or continue to >> use TLS 1.2 with

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Hi Owen, On 31/10/17 21:03, Owen Friel (ofriel) wrote: >> Interesting. One bit puzzles me: wouldn't the new content-type >> give the game away and cause middleboxes to block this? >> >> S. >> > [ofriel] The intention isn’t to try and obscure the fact that there > is an ATLS session. Even if

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Hiya, > Hasn’t this been the whole point of the discussion?! The proposal to > separate PRNGs into those that supply publicly-visible randomness > (nonces, etc), and those that supply “secret” randomness (keying > material and such)? Thus, having *two* PRNGs, each (hopefully) > properly seeded?

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 23:58, Peter Bowen wrote: > So, to be completely clear, no one is arguing that Nick's three > options (quoted below) are wrong or do not work. The objection is > that the IETF should not be publishing a RFC that documents them, is > that right? No, it's not that simple. For

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 23:37, Richard Barnes wrote: > Sorry, what? The current draft proposes an extension, literally the > opposite of a standard, supported feature. It's explicitly optional. Optional is not the opposite of standard. See the intended status below. > I don't really have a dog in this

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 25/10/17 17:11, Ackermann, Michael wrote: > And if this is not a feature that everyone wants, then so be it. > But at least it was an attempt by a small number of people to try to > find common ground and make any form of progress. I do not accept that there is an onus on IETF participants

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

David, I'll go back over your mails tomorrow but was struck by this... On 24/10/17 23:39, David A. Cooper wrote: > I haven't even gotten into the question of what does it mean for a connection > to > be MiTM'd. If Company X decides to have its web site operated by Hosting > Provider Y is the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Michael, What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry. Thanks, S. On 25/10/17 01:41, Ackermann, Michael wrote: > Excellent

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 24/10/17 20:31, Ted Lemon wrote: > But it's delaying other work, because people who could be doing > useful work in the IETF are engaging on this topic instead. I'm not sure of the extent to which my work in the IETF is useful or not, but it is certainly the case that these repeated proposals

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph, On 24/10/17 20:36, Yoav Nir wrote: > > >> On 24 Oct 2017, at 22:27, Ralph Droms wrote: >> >> >>> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >>> >>> I use an airplane as an example of a “captive” population, substitute any >>> similar group

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Joe, On 24/10/17 17:49, Joseph Salowey wrote: > As is normal > IETF practice, we will be giving this topic agenda time in Singapore to see > if a consensus emerges one way or the other. I would ask that you, as chairs, reconsider that. While I do have strong opinions, the list traffic seems to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Sean/Joe, this is addressed to you... On 24/10/17 00:31, Ackermann, Michael wrote: > NO The objective is to be passively observe, out of band and not to > be a MitM or modify/inject text.Just as we all do today. So from the above we see that some of the proponents of breaking TLS

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 23/10/17 18:30, Ackermann, Michael wrote: > It is a huge proposition requiring change to virtually every platform > and application.Not to mention all the management, monitoring > and security platforms. It would be very expensive and time > consuming. And when they ask why this is

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hi Ted, On 23/10/17 00:35, Ted Lemon wrote: > On Oct 22, 2017, at 7:26 PM, Steve Fenter > wrote: >> I have been saying to anyone who will listen that the IETF needs a >> private forum for enterprises, to enable them to come forward and >> discuss their real

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 22/10/17 21:48, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is > that no one knows when a vulnerability will be discovered in TLS 1.2 > that forces enterprises to upgrade to TLS 1.3. We've had guarantees > that TLS 1.2 and the RSA key exchange are

Re: [TLS] Connection ID Draft

On 22/10/17 17:04, Eric Rescorla wrote: > On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> >> On 22/10/17 16:41, Eric Rescorla wrote: >>> >>>> Maybe the thing we could agree at this stage is

Re: [TLS] Connection ID Draft

On 22/10/17 16:41, Eric Rescorla wrote: > >> Maybe the thing we could agree at this stage is that the cid scheme >> has to be usable in that one-message-per-day scenario and needs to >> provide some way that such messages aren't easily linkable based on >> cids. > > I think that's a

Re: [TLS] Connection ID Draft

(Sorry for the slow response...) Two things below... On 13/10/17 16:58, Eric Rescorla wrote: > On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> Hiya, >> >> On 13/10/17 15:29, Eric Rescorla wrote

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 20/10/17 17:00, Ackermann, Michael wrote: > Expressly reacting to the viability of continuing to use TLS1.2 forever. Sorry, that's just misquoting. Rich asked "why do the WG need to debate this now" Darin said "we must, because we need snooping..." I said "no, you can use TLS1.2 and debate

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Minor clarification... On 20/10/17 14:44, Salz, Rich wrote: > Some members of the WG rose up and wanted explicit opt-in I don't think "wanted" is quite right. Some WG participants (e.g. me) wanted nothing like this to ever be done in the IETF. Others did comment that the lack of client opt-in

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I agree with Christian and Ben's points. I'd also add: On 19/10/17 23:30, Darin Pettis wrote: > The question has been raised: "Why address visibility now?" The answer is > that it is critical that the visibility capability is retained. It is > available today through the RSA key exchange

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 19/10/17 15:16, Paul Turner wrote: > > >> -Original Message- >> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell >> Sent: Thursday, October 19, 2017 09:07 >> To: Benjamin Kaduk <bka...@akamai.com>; tls@ietf.org >> Subjec

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hiya, On 18/10/17 18:41, Benjamin Kaduk wrote: > P.S. I agree with Rich; can we try to defer these conversations until > after 1.3 is actually published? FWIW, I also think it'd be a good plan if the chairs did that. I'm happy to oppose these ideas any time, but later is better than now, given

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 17/10/17 19:34, Ion Larranaga Azcue wrote: > If the extension is not sent, the client does not realize there is a > third party, but the third party does not have the session keys > either, and the server has to provide them in a different way (for > instance, using an OOB lookup as Florian

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 17/10/17 16:46, Ion Larranaga Azcue wrote: > The problem I see with a "server to third party" OOB look up or > export of the keys is that the client will not be notified of this > export taking place and so will lose the chance to reject > surveillance... IIUC, with the draft-rehired

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hiya, On 13/10/17 17:28, Hubert Kario wrote: >> So I think this ends up as bad as the design in draft-rehired. Which >> of them is more obviously bad is another question. > "draft-rehired"? Apologies. That's how I've been verbalising/pronouncing draft-rhrd. (*) I think it is useful to have a

Re: [TLS] Connection ID Draft

Hiya, On 13/10/17 15:29, Eric Rescorla wrote: > There are a number of cases where this is actually much harder to implement > than a design where one side dictates the connection ID. For instance, > consider a design where you have a pool of servers P1, P2, ... P_n with a > load balancer in

Re: [TLS] Connection ID Draft

Hiya, On 13/10/17 14:56, Eric Rescorla wrote: > I've seen a number of designs like these, but in general they > have quite poor scaling properties. Can you describe the precise > design you have in mind so that we can analyze it. Sure, I can try... What I'm suggesting is that we define a way

Re: [TLS] Connection ID Draft

On 13/10/17 00:13, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > Comments welcome. As a near-nit, I don't think "dismissed" is a good way to describe the analysis of some

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 13/10/17 12:05, Hubert Kario wrote: > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: >> (With the obvious caveat that I hate the whole >> idea... :-) > > to be clear: me too IMO the more we hear of that the better > 1. Alice sends a share to

Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues)

: > +1 to Stephen. > > Regards, > Uri > > Sent from my iPhone > >> On Oct 8, 2017, at 18:34, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: >> >> >> >>> On 08/10/17 23:22, Eric Rescorla wrote: >>> You seem to be re

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

en done, by any of the people proposing to break tls, at least afaik. S. > > Thank you in advance > >> Le 3 oct. 2017 à 00:48, Stephen Farrell <stephen.farr...@cs.tcd.ie> >> a écrit : >> >> >> Russ, >> >> On 02/10/17 22:43, Russ

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Russ, On 02/10/17 22:43, Russ Housley wrote: >> For starters, though, I'd be interested answers from the authors to >> two quick questions, though I suspect I can guess 'em: >> >> 1. TLS1.3 has had significant formal analysis. Did the authors or >> other proponents here do any such work and if

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Sigh:-( IMO the WG shouldn't touch this terrible proposal with a bargepole. And it remains outside the WG's charter I think. (It would be a good idea if the chairs would clarify that a re-charter would be needed were the WG to go bonkers and adopt a terrible idea like this.) I guess I'll need

Re: [TLS] WG adoption call: SNI Encryption

On 17/08/17 05:18, Martin Thomson wrote: > https://tools.ietf.org/html/rfc7858 > > I hear that there are even implementations and deployments. Yes, I used the resolver doing this at the last IETF meeting. It worked. Not "just worked," but pretty good. > > It's certainly time to have the

Re: [TLS] WG adoption call: SNI Encryption

On 04/08/17 14:21, Daniel Kahn Gillmor wrote: > On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: >> At our IETF 99 session, there was support in the room to adopt >> draft-huitema-tls-sni-encryption [0]. We need to confirm this support >> on the list so please let the list know whether you

Re: [TLS] 32 byte randoms in TLS1.3 hello's

p and q, >> generated independently leading to an attack... >> >> Here if the seeds to initialize the RNGS are related, or one is weak, or >> worst if the seed is a raw source that doesn’t change in the moments >> between the two CSPRNG inits, that'd be bad, even

Re: [TLS] 32 byte randoms in TLS1.3 hello's

I've suggested some text for this in a PR [1] based on what people have said in this thread. I'm sure that can be further improved. It might be no harm to add more pointers to that appendix from elsewhere in the spec, and/or to add a list of the various public/private random numbers that are

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On 25/07/17 04:53, Peter Gutmann wrote: > Colm MacCárthaigh writes: > >> I think the fix for this is really at the application level; if you >> want defense-in-depth against PRNG problems, it's probably best to use >> separate RNG instances for public data (e.g.

[TLS] 32 byte randoms in TLS1.3 hello's

Hiya, I'm guessing many folks interested in TLS may have been at the QUIC session in Prague and hence missed out on the excellent talk by Stephen Checkoway on the juniper dual-ec incident. (I highly recommend taking a peek at the slides [1] or reading the paper [2] or watching the video wherever

Re: [TLS] datacenter TLS decryption as a three-party protocol

It's fascinating that people cannot seem to stop picking at the scab remaining after draft-green. I really think we'd be wiser to just let the wound heal. (And get on with the work that this WG has been chartered to do, which does not include wiretapping.) On 23/07/17 18:17, Felix Wyss wrote: >

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote: > Ilari, > > I got your point. > > But in view of the request this WG is discussing now, I see only two > reasonable (IMHO) opinion: 1. Tell those requestors to go away > because TLS 1.3 has been designed to always be forward-secure; or

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 20/07/17 18:08, Colm MacCárthaigh wrote: > On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> On 20/07/17 17:43, Colm MacCárthaigh wrote: >>> that's the term that people keep applying, >> >> That term was appr

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 20/07/17 17:43, Colm MacCárthaigh wrote: > that's the term that people keep applying, That term was appropriate for draft-green as justified in [1] That's disputed by some folks but it's the correct term. Claiming that current browsers "support" wiretapping is plain odd to me and not that

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 16:23, Paul Turner wrote: >> I'd assert there's no way TLS clients in general could know when to >> set or unset the "please wiretap me" evil bit in a ClientHello, >> regardless of how complex a configuration is used. > > > It seems like the guidance would be for all TLS clients

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 15:40, Paul Turner wrote: > I’m assuming that you’re referring to multiple nations being between > the TLS client and server. If a TLS client is set to not include the > extension, it seems the TLS client would simply close the connection. > It seems the client could choose whether

Re: [TLS] Is there a way forward after today's hum?

Hiya, On 20/07/17 13:04, Paul Turner wrote: > Let’s use the oppressive government institution that I believe you’ve > mentioned (pardon me if I got that wrong) with a connection over the > Internet in this case. Sorry, I'm not sure what you mean there, but guessing, yes, there can be multiple

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 12:44, Paul Turner wrote: > > I believe Russ was outlining a method where an extension would be > added to TLS 1.3 that would provide for delivery of a decryption key > to a third party during the handshake (correct me if I got that > wrong, Russ). Because it would be during the

Re: [TLS] SAAG TLS working group report

Hi Joe, On 20/07/17 09:54, Joseph Salowey wrote: > We had presentations on the pros and cons of a proposed mechanism > to decrypt TLS messages within the data center. A hum indicated that > there was roughly equal support on both sides. Therefore, well will > continue the discussion and it

Re: [TLS] datacenter TLS decryption as a three-party protocol

Just to note that Martin's mail contains specific examples and detailed argument. That should be the lowest bar that needs to be met in this discussion, not the arm-waving about "TLS as a DoS attack" or "what about grandma" nonsense that we heard today. The contrast between such non-argument and

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 19/07/17 18:45, Colm MacCárthaigh wrote: > For example, browser's > incognito modes may refuse to support such sessions, if they knew what was > going on. That is a perfect example of the hideous dangers of all of this. The implication in the above is that browsers would/should turn on

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 19/07/17 17:58, Benjamin Kaduk wrote: > On 07/19/2017 11:49 AM, Stephen Farrell wrote: >> >> On 19/07/17 14:09, Benjamin Kaduk wrote: >>> As Stephen noted in his presentation, a lot of the proposals for passive >>> decryption can be seen as trying to t

Re: [TLS] Is there a way forward after today's hum?

On 19/07/17 18:10, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind > sight, I wish the chairs had asked a second question. If the split > in the room was different for the second question, then I think we > might have learned a bit more about what people

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 19/07/17 14:09, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as trying to turn TLS from a two-party protocol > into a three-party protocol. Which is probably the right way to think > about it, even when all (three)

Re: [TLS] possible new work item: not breaking TLS

as draft-green:-) Cheers, S. [1] https://github.com/sftcd/tinfoil On 13/07/17 13:00, Stephen Farrell wrote: > > Hi again TLS WG chairs, > > I've done a bit more work on the collection of arguments > against the latest break-TLS proposal. [1] I plan to keep > working on that so mor

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Hiya, On 15/07/17 20:49, Roland Zink wrote: > TLS is a two endpoint protocol. It looks like many of the use cases > describe problems with more than two endpoints but are using TLS because > it is commonly available. So should TLS be extended to be an n-party > protocol (or is this always

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Hiya, On 16/07/17 05:41, Colm MacCárthaigh wrote: > On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > >> On 15/07/17 23:55, Colm MacCárthaigh wrote: >>> So far responses on the mailing list have been saying "Don't

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 15/07/17 23:55, Colm MacCárthaigh wrote: > So far responses on the mailing list have been saying "Don't use > pcap, instead run proxies". Sorry, but that is incorrect. Some list participants have said "we need pcap" and others have said that "no, we do not need to use packet capture." And

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

Hiya, On 14/07/17 15:51, Sean Turner wrote: > Please let us know your thoughts. 80 minutes for wiretapping is too much. Zero would be better. But if not... I'd suggest: 10 minutes for draft-green, 10 minutes to describe issues with that (i.e. the slot for which I continue to ask) and then 10

[TLS] possible new work item: not breaking TLS

Hi again TLS WG chairs, I've done a bit more work on the collection of arguments against the latest break-TLS proposal. [1] I plan to keep working on that so more input is welcome. (Corrections where I've gotten stuff wrong are even more welcome.) I'd like to again request some time on the

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 12/07/17 21:01, Kathleen Moriarty wrote: > With no hat on... > > The difference with the WordPress & SMTP examples is that you know > content will sit in plaintext on the servers, whereas with POTS, you > need to wiretap to get the voice content. You only expect the log > that the call

<    1   2   3   4   5   >