Hiya,
On 20/10/2024 22:27, tojens.i...@gmail.com wrote:
We welcome your feedback!
I had a read and have a couple of questions:
1. Is the "authenticate to me or I won't let you get to malware"
thing actually real? I don't know of any such recursive and it'd
seem pretty odd. Recursives that d
On 20/02/2024 17:40, Andrea Vesco wrote:
Hi Stephen, before contacting UTA WG we have shared the I-D with TLS WG
chairs, and they explained that typically defining a new credential type
is not something that has been of interest to the TLS WG.
Interesting. Not sure I'd agree with that (not
Hiya,
I had a quick flick look at the draft. ISTM that's
one that'd need processing by the TLS WG and not
UTA. (Even if you disagree with that, you may agree
that it'll be better to give the TLS WG a heads-up
as someone there is bound to dislike this and it'll
be better to know that sooner rathe
On 30/07/2022 23:24, Rob Sayre wrote:
I agree with the authors on leaving the draft as-is.
+1
S
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
Uta mailing list
Uta@iet
On 14/07/2022 06:42, Rob Sayre wrote:
Sure, mandate TLS 1.2 support. That seems like a really good idea.
FWIW, I believe a significant majority of implementations
and deployments are not near ready to turn off or deprecate
TLS1.2. It'd be dim of us to not mandate support for it at
this stage
Hiya,
I had a read of this. Seems to me to be in fine shape but
a couple of comments below. If those have already been
discussed, apologies, and do ignore 'em.
I don't think any of my comments need addressing before
publication, but figured it was no harm sending 'em
anyway:-)
- section 3.2: I
Hiya,
During the UTA session it occurred to me it might make sense
to have a sentence something like:
"Ongoing development of TLS continues so implementers ought
not assume that they can depend on specific content of TLS
messages. For example, experiments like ECH [1] mean that
the ClientHello
Hiya,
On 23/07/2021 19:32, Peter Saint-Andre wrote:
The authors of rfc7525bis have noticed that the Commercial National
Security Algorithm Suite (CNSA) contains some strong recommendations
regarding topics of interest, including 3072-bit RSA, 3072-bit DHE, and
ECDHE with secp384r1. These recomm
Hiya,
I like the text below as a starter. I'd suggest it also
include something to take into account the ECH issue
mentioned on the dpriv list [1]
S
[1]
https://mailarchive.ietf.org/arch/msg/dns-privacy/3xL59_1P0ZHOUEYsDJ1Q22ZZVvo/
On 30/04/2021 07:46, Martin Thomson wrote:
On Fri, Apr 30,
I had a look at the draft and the text is just that of
the current BCP195 for now.
I support adoption - now that TLS1.3 is done it seems a
good time to start on this. I'll review and comment as
it goes.
S.
On 26/04/2020 10:35, Valery Smyslov wrote:
> Hi,
>
> during the last virtual interim mee
On 24/03/2020 15:47, Suresh Krishnan wrote:
> It actually is :-). I was worried I might have to hand this over.
Excellent! Enjoy no longer pushing those buttons!
Thanks for clear that so quickly,
Cheers,
S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description:
Hi Suresh,
(Possibly just in time for this to be the last discuss you
clear:-) I updated this draft to add in text updating the
bit of 8314 you spotted. Hopefully that'll allow you to
clear. The diff is at [1].
Thanks,
Stephen.
PS: I only addressed the discuss point, I didn't yet check
over the
Hiya,
On 20/02/2020 01:34, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-uta-tls-for-email-04: Abstain
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines.
FWIW, that looks like a good suggestion to me.
Cheers,
S.
On 16/02/2020 16:25, Julien ÉLIE wrote:
> Hi all,
>
>> The IESG has received a request from the Using TLS in Applications
>> WG (uta) to consider the following document: - 'Use of TLS for
>> Email Submission and Access'
>> as Proposed
Hiya,
As is probably obvious I don't agree with this. But I can raise
it when the draft gets to IETF LC, so we don't need to bang on
about it.
On 26/01/2019 17:40, John R Levine wrote:
> After reading all the discussion I posted an -02 which takes out all
> mention of ESNI. Here's why.
>
> The
Hiya,
On 25/01/2019 22:11, Viktor Dukhovni wrote:
> Like John, I am very skeptical about the applicability of ESNI to
> SMTP.
I also agree with John and you that ESNI doesn't seem compelling
for SMTP. Nonetheless, I'm often wrong, and maybe in this case too,
so if ESNI is seen to be used then ha
Hiya,
On 25/01/2019 18:08, John R Levine wrote:
> I've uploaded a new version that reflects the recent discussions.
>
> Because I am a grumpy old guy I will not tell you what it says so if you
> want to know, you will have to read all four pages of it:
Sorry to have made you (more:-) grumpy, bu
On 25/01/2019 17:15, John R Levine wrote:
>
> How about this?
>
> sni domain.name
> esni yes
Works for me. With the "esni yes" otpion as a SHOULD level thing,
a MUST is maybe too much (just in case the MTA code can't determine
that ESNI was used).
Thanks,
S.
0x5AB2FAF17B172BEA.asc
Descrip
On 25/01/2019 16:50, John R. Levine wrote:
>
> The cert names are tied to the MX which is tied to the recipient.
Says who? That's common and sensible but not mandatory.
The cert names could be all sorts of flakey things, incl
having wildcards. E.g. ESNI could be "secret.example.com"
while the
On 25/01/2019 16:36, John R Levine wrote:
>
>> But, if someone has decided to setup ESNI for an MTA (which will
>> need them to take action to do that), then I'd assume they have
>> a reason. At that point, exposing the ESNI value in the message
>> is what I'm arguing to not recommend.
>
> Naah
Hiya,
On 25/01/2019 15:00, John R Levine wrote:
>
> More to the point, though, I think you're overlooking two fundamental
> differences between SNI in SMTP and in HTTP. On the web, only the
> client making the request knows what web page she's looking for, and the
> log info is saved on the ser
On 25/01/2019 02:37, John R Levine wrote:
>> Even if this isn't a big leak, I think it's still worth preserving
>> a way in which SNIs don't leak - if the TLS client and server and
>> TLS client's DNS setup (and maybe the TLS server's too) are all
>> such that we've not leaked the SNI in any of t
I suggest calling out ESNI specifically as a reason to not log the
SNI in the security considerations, e.g. via:
OLD:
In a few
circumstances, a new Additional-registered-clause might disclose
information to a recipient that was otherwise unavailable.
NEW:
In a few
circumstances,
On 15/01/2019 19:27, Viktor Dukhovni wrote:
> The information is only available to readers of the message.
> The fact the handshake used X25519 or ECDSA (P-256) does not
> look sensitive to me. An MSA can choose to not log it, while
> MTA to MTA traffic really has nothing to hide here.
Well, no
Hiya,
Great. One of us'll do that in the net couple of days,
Cheers,
S.
On 23/11/2018 13:49, Valery Smyslov wrote:
> Hi,
>
> several comments were received supporting adoption of the draft
> and no one was against. It seems that we have a clear consensus
> that the draft is interesting to thi
Hiya,
On 18/04/18 21:13, Peter Saint-Andre wrote:
> On 4/17/18 3:37 PM, Stephen Farrell wrote:
>>
>>
>> On 17/04/18 16:22, Peter Saint-Andre wrote:
>>> During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized
>>> that just pointing to RFC 752
On 17/04/18 16:22, Peter Saint-Andre wrote:
> During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized
> that just pointing to RFC 7525 might not be enough anymore, now that the
> TLS 1.3 spec has been approved for publication. 7525bis, anyone?
I also think it's a bit early, but no
Dear,
I've been looking for a few products when by chance I came across that! It's
so unfortunate, please read ant notify me what you think
http://www.moldremovaloakville.ca/concert.php?UE91dGFAaWV0Zi5vcmc-
Thanks for your consideration, Steph
Hiya,
On 29/06/17 14:02, Viktor Dukhovni wrote:
>
>> On Jun 28, 2017, at 6:54 PM, Stephen Farrell
>> wrote:
>>
>> While I understand and sympathise with Viktor's argument
>> for kv, I don't think that argument ought be blocking as
>> the di
On 28/06/17 23:45, Leif Johansson wrote:
> sticking with json
FWIW, as a non-implementer who has chatted with folks
currently implementing sts, I think json is good enough.
While I understand and sympathise with Viktor's argument
for kv, I don't think that argument ought be blocking as
the diff
On 02/09/16 15:42, Daniel Margolis wrote:
> On Tue, Aug 9, 2016 at 4:49 PM Stephen Farrell
> wrote:
>
>>
>> - 3.3: I forget why "policy.mta-sts" is what's prepended to the
>> policy domain. Personally, I dislike the two-level thing there
>> a
Hiya,
The authors were hassling me (nicely:-) to do a review of
this and since I'm no longer the AD for the WG I figured
that'd be a good idea, as I'm very supportive of this, so
long as we (the WG/IETF), figure out how to do this without
that damaging deployment of DANE/TLSA. Overall, my take is
On 01/05/16 02:26, John Levine wrote:
>>> We talked about this at great length over dinner in Buenos Aires.
>>> Demanding a web server at the same domain name used in e-mail
>>> addresses is operationally a non-starter for large organizations.
>>
>> STS is primarily for the large email providers
Hi Jeff,
On 27/04/16 00:33, =JeffH wrote:
> On 4/11/16, 1:45 PM, "Stephen Farrell" wrote:
>>
>> With no hats, I'd like to argue that the WG should pursue
>> the "webby" STS proposal, ...
>
> just to ensure this thread is ped
Hiya,
With no hats, I'd like to argue that the WG should pursue
the "webby" STS proposal, but should also ensure that we
do not damage progress made by those who are deploying the
DANE/DNSSEC approach to securing MTA-MTA connections.
I think we can do that by requiring that outbound MTAs
that im
I had to do some bean counting over the last few days
(of the existence justification kind;-) and I noticed
that RFC7525 is being referenced a lot - about 50 [1]
IETF docs referencing a 6 month old RFC seems like a
lot to me anyway.
I think that means a bunch of folks think you all did
a fine job
On Tue Nov 24 08:40:50 2015 GMT, JORDI PALET MARTINEZ wrote:
> Speaking as sergeant-at-arms.
>
> There is any real need to cross-post to the general area explorer ?
The document is in ietf last call so it is entirely appropriate to send to
i...@ietf.org.
S.
>
> Unless I don’t see a goo
On 20/11/15 14:18, Kathleen Moriarty wrote:
>>>
>>> - section 3, 2nd list, bullet 4 - afaik, CN is what is mostly
>>> actually used. Shouldn't we recognise that reality with more
>>> than a MAY? It's been more than a decade since PKI folks started
>>> to want to not use CN and that's just not
On 20/11/15 13:10, Eliot Lear wrote:
> Hi Stephen,
>
> Just on this point...
>
> On 11/20/15 1:53 PM, Stephen Farrell wrote:
>> - I think the answer is "no," but I'll ask anyway:-) Many mail
>> service providers use names like mail.example.com, smtp.e
Hiya,
Sorry for being slow getting this done. My AD review of this
is below. Please consider my comments as last call comments.
I have requested last call for this one so you should see the
announcement of that shortly.
- section 3, first list, bullet 1: what's option (c) there mean?
wasn't clea
I just want to disagree with what I think is a false dichotomy
that you presented.
On 02/08/15 17:07, John C Klensin wrote:
> However,
> we shouldn't make arguments for good-quality link encryption
> that have the effect of convincing people (even the fairly
> naive) that it makes either end-to-
On 29/06/15 02:26, Ralph Holz wrote:
> Hi everyone,
>
> I think this should be recorded as verified - peer-reviewed attack, valid
> erratum.
Done.
S.
>
> Ralph
>
> On 28/06/15 22:28, RFC Errata System wrote:> The following errata report
> has been submitted for RFC7457,
>> "Summarizing Know
th v2 draft ;)
>
> https://www.ietf.org/mail-archive/web/ietf-announce/current/msg09796.html
>
> spt
>
>
> On Apr 20, 2015, at 19:48, Stephen Farrell wrote:
>
>>
>> Top quoting: thanks all - let's do that. I'll add to the
>> downref registry before the
Top quoting: thanks all - let's do that. I'll add to the
downref registry before the telechat unless someone else
on the IESG yells.
Cheers,
S.
On 21/04/15 00:42, joel jaeggli wrote:
> On 4/20/15 4:08 PM, Stephen Farrell wrote:
>>
>>
>> On 20/04/15 23:59, Barry
On 20/04/15 23:59, Barry Leiba wrote:
>> To wit, I am not ignoring the process.
>>
>>Once a specific down reference to a particular document has been
>>accepted by the community (e.g., has been mentioned in several Last
>>Calls), an Area Director may waive subsequent notices in the La
On 20/04/15 23:21, joel jaeggli wrote:
> 3. look at precident,
>
> http://datatracker.ietf.org/doc/rfc4949/referencedby/
>
> decide that it's within your power to approve the downref and add it to
> the registry
>
That'd work for me, if the IESG are ok with it. Barry has a
DISCUSS so we'll di
Hiya,
It was pointed out to me that RFC4949 as a normative
reference here is a downref, and I didn't call that
out during the IETF LC for this document. (Sorry about
that.) Oddly, 4949 hasn't previously been added to the
downref registry. [1]
So, the choices are:
1. make 4949 an informative ref
Hiya,
Those seem fine. I guess the best is to see out the IETF LC
and then re-spin the I-D,
Thanks,
S.
On 03/04/15 21:05, Peter Saint-Andre - &yet wrote:
> Hi Stephen, thanks for the review and my apologies about the delayed reply.
>
> On 3/28/15 9:30 AM, Stephen Farrell wrot
Hiya,
As your non-shiny new helper AD I've reviewed draft-ietf-uta-xmpp-05.
I have some comments (below), none need hold up IETF LC I think so
please treat these as you would IETF LC comments.
I'll request IETF LC momentarily.
Thanks,
S.
- 3.4: I'm not clear what the last paragraph is telling
Richard's, Pete's or Peter's takes on this are all fine. Let's ship it!
S.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
FWIW, I could live with the current text or with Richard's (modulo
one thing below). Or with stuff in-between.
On 20/02/15 16:23, Richard Barnes wrote:
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet
> wrote:
>
>> On 2/20/15 3:45 AM, Ralph Holz wrote:
>>
>>> Hi Viktor,
>>>
>>> B
On 19/02/15 04:57, Richard Barnes wrote:
> On Wed, Feb 18, 2015 at 11:19 PM, Peter Saint-Andre - &yet > wrote:
>
>> Hi Richard, thanks for the thoughtful review. Comments inline.
>>
>> On 2/18/15 8:34 PM, Richard Barnes wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>
On 18/02/15 22:05, Peter Saint-Andre - &yet wrote:
> If the community that uses such an application protocol wishes to
>modernize its usage of TLS or DTLS to be consistent with the best
>practices recommended here, it needs to publish a document that
Someone might have e.g. an IANA regis
Stephen Farrell has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Yes
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 http
Hiya,
On 07/12/14 12:09, Leif Johansson wrote:
> I believe the CFRG is expected to come up with curve recommendations for
> the IETF. I believe We should wait for them and decide if we want to
> rev. the BCP at that time but this is one of those areas where I'd
> like the sec area ADs to chime in
Hiya,
Following up on the presentation at IETF-91 on this topic, [1]
we've created a new list [2] for moving that along. The list
description is:
"This list is for discussion of proposals for doing better than bearer
tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.
The specifi
Hi Brian,
I'm not seeing what part of your email is new and not
something already discussed by the WG. Can you clarify?
Thanks,
S.
On 03/12/14 01:59, Brian Smith wrote:
> Peter Saint-Andre - &yet wrote:
>> On 11/11/14, 9:10 PM, Brian Smith wrote:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
On 26/11/14 02:46, Peter Saint-Andre - &yet wrote:
>
>
>Some devices have hardware support for AES-CCM but not AES-GCM.
>There are even devices that do not public key cryptography at all.
>This BCP does not cover such devices.
That'd work for me.
S.
__
On 22/11/14 13:16, Leif Johansson wrote:
> On 2014-11-21 17:24, Paul Hoffman wrote:
>> On Nov 20, 2014, at 9:40 PM, Joseph Salowey wrote:
>>> "The named curve registry contains 160-bit elliptic curves which are
>>> considered to be roughly equivalent to only an 80-bit symmetric key
>>> [ECRYPT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/14 22:37, Aaron Zauner wrote:
> I don't see a pressing reason to do so right now.
That's also fair. (And I'd prefer to get an answer about
curves from 'em first anyway;-)
S
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/14 19:40, Aaron Zauner wrote:
>> AES128 should suffice for the
>>> timeframe of this WG and the current documents that we should
>>> - really - get out of the door soon.
+many^many and I also agree with Steve K's opinions here.
> Also; isn
Hi all,
For some reason Joe's post didn't get to the list so I'm just
forwarding that whilst someone figures out what is/was up. Please
cc' Joe on responses just in case he's not seeing list traffic.
Cheers,
S.
>From j...@stsauver.com Fri Nov 14 13:14:42 2014
Date: Fri, 14 Nov 2014 13:14:42 -0
With no-hats, I'd be against this change.
Adding a note that CCM is common in some hardware environments
would be good though.
Delaying this to try to solve the unsolvable problem that we have
CCM and GCM both deployed would be just as bad. So I'd say add a note
that ciphersuite foo is the best
On 13/11/14 04:30, Leif Johansson wrote:
>
>> Your clarifications seem helpful to me, thanks!
>>
>>> I am content with all my other feedback being ignored, as it is less
>>> important.
>>
>> OK. But I for one will look at it more closely soon.
>>
>
> Since we are out of WGLC I would like to see
This is good enough.
comments..
1) a nit in 4.3:
OLD:
Servers SHOULD authenticate using at least 2048-bit certificates.
NEW:
When using RSA servers SHOULD authenticate using certificates with
at least a 2048-bit modulus for the public key.
I didn't spot the same thing elsewhere bu
On 22/10/14 16:49, Paul Hoffman wrote:
> I strongly disagree with not addressing OE here. This BCP has one
> shot at getting attention, and ignoring OE now makes it look like OE
> is still not ready to be addressed. Let's not miss the opportunity to
> say "TLS works great with full authentication
On 22/10/14 09:53, t.p. wrote:
> Count me in that minority too. Unauthenticated/Opportunistic is a
> potential can of worms that can only delay or detract from the benefits
> that this I-D will bring.
FWIW, I also agree that this BCP ought not address OS, but I
very much disagree with the "can
On 15/10/14 21:21, Orit Levin (LCA) wrote:
> If the list agrees with Victor's technical assessment of "O" TLS,
> then I join those who think that it doesn't make much sense to
> include any of the specific "O" TLS recommendations in the baseline
> BCP.
Apologies, I've not read Viktor's comments
Stephen Farrell has entered the following ballot position for
draft-ietf-uta-tls-attacks-04: Yes
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 http
Hiya,
Do we already have a BCP saying that IMAP without TLS
is uncool these days? If not, was someone here drafting
something that says that for progression here or in
appsawg? (I've lost track of where the mail work is
likely heading sorry.)
Reason to ask is that on another list [1] there are s
, Key Sizes and Parameters Report
> 2013 recommendations,
> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport
>
> [4] RFC 6367 Addition of the Camellia Cipher Suites to Transport Layer
> Secur
Hiya,
Having had this discussion a few times over the last
couple of years my take on it is:
- there is some but not huge interest a backup cipher
for AES and the interest-level varies by protocol
as do the set of possible backups
- we are very unlikely to get an easy consensus on which
t
On 07/08/14 10:38, Leif Johansson wrote:
>> > But I guess we jumped the gun by recommending Brainpool as the primary
>> > curve. I would like to remove this recommendation, and retain the NIST
>> > curve - which is all we have now. What do you think?
>> >
> As an individual I think thats fine. A
gt; Thanks,
> Yaron
>
> On 07/06/2014 10:35 PM, Ivan Ristić wrote:
>> On 06/07/2014 20:31, Stephen Farrell wrote:
>>>
>>>
>>> On 06/07/14 20:29, Yaron Sheffer wrote:
>>>> Adding some data to my previous mail:
>>>>
>&g
On 06/07/14 20:29, Yaron Sheffer wrote:
> Adding some data to my previous mail:
>
> As of Jan. 2014, 65% of the top 1M Web servers did not speak TLS 1.1 or
> 1.2 [1]. So while we should move implementations to TLS 1.2 (as we do in
> this draft), it is probably too early to mandate against the fa
Nice! Something like this could be very helpful, thanks.
Some comments ...
- You don't mention OCSP, which in fairness is an issue
(but do include pinning - is that included in the 4-7kB
in section 2?)
- More generally section 2 could do with some more detail,
and being based on some measu
On 23/06/14 00:02, Christian Huitema wrote:
> This may be the current practice, but is it something that we want to keep
> or encourage? "Just starting TLS" is clearly simpler and more robust than
> first going through a "STARTTLS" negotiation. I think it would make perfect
> sense to allocate TL
On 27/05/14 12:26, Johannes Merkle wrote:
>> > Also, it seems to me that it will be difficult, and maybe confusing* to
>> > come up
>> > with a single set of recommendations that applies uniformly to all forms of
>> > curves. So maybe even in the long term it's better to focus on reduced
>> > We
78 matches
Mail list logo
