Re: [TLS] Tricking TLS library into crypto primitives library

[Melinda Shore]

On 6/25/23 9:21 AM, Soni L. wrote:
Python doesn't expose raw AES, etc. But it does expose a fairly rich TLS 
library.


If you're not comfortable using the Python cryptography hazmat module,
check out pycryptodome.

Melinda

--
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis



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

Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake

[Melinda Shore]

On 5/9/21 9:13 AM, Mohit Sahni wrote:> RFC6962 only talks about support
of CT to verify the server> certificates, however while working on zero
trust services that> require MTLS for each connection, I realized that
enabling CT for> client certificates can make the TLS handshakes with
Mutual TLS more> secure. (I don't want to go into details of how CT can
make it more> secure as those benefits are already mentioned in RFC6962).
Both approaches seem reasonable/obvious, although the OCSP-based
one seems to have a few potential issues (both around stapling and
around spotty implementation of the use of OCSP for client cert status
checking).  But I have to say, the core problem this proposal
faces would seem to be lack of demand on the part of folks who
consume client certificates.  In the seven years that trans has
been up and running this has received nearly no discussion, even
in passing, and if I recall correctly, no drafts and no agenda
time in meetings.

Melinda

-- 
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis

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

Re: [TLS] Network Tokens I-D and TLS / ESNI

[Melinda Shore]

On 6/25/20 3:29 PM, Erik Nygren wrote:
> One quick comment is that binding tokens to IP addresses is strongly
> counter-recommended.
> It doesn't survive NATs or proxies, mobility, and it is especially
> problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of
protocols, and for what it's worth I wrote up a mechanism for
using address tags and address rewrites, but unfortunately Cisco
decided to patent it.  Anyway, there are ways of dealing with this
problem that don't require binding the address to the token ("all
technical problems can be solved by introducing a layer of
indirection").

Melinda

-- 
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis



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

Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer

[Melinda Shore]

On Tue, Apr 9, 2019, at 10:57, Sean Turner wrote:
> At TLS@IETF104, there was consensus in the room to adopt 
> draft-wood-tls-external-psk-importer.  This message is to confirm that 
> consensus.  If you do not support adoption of 
> draft-wood-tls-external-psk-importer as WG item please say so by 
> 2359UTC on 22 April 2019 (and say why).

I support adoption.

Melinda

-- 
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis

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

Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

[Melinda Shore]

On 3/24/19 4:16 AM, Wang Haiguang wrote:
> We do plan to include an expire date in the identity design. The
> valid period is a decision that should be decide either by the user
> or the PKG manager.

The problem here is that you do not want to get into the
position of allowing a known compromised key to be treated
as valid for, say, a period of several years.  Even if you
replace the private key in the handset, a "compromise"
typically involves the existence of an uncontrolled instance
of the private key.  Consequently you need to either narrowly
constrain the key lifetime or provide a revocation mechanism.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

[Melinda Shore]

On 3/22/19 7:28 AM, Wang Haiguang wrote:
> [HG] Regarding the revocation, we did not mention it in the draft, but
> we have
> 
> considered it in the design. In practice, an
> 
> expiring time can be included in the identity for the IBC system.
> 
> In fact, in RFC 6507 page 7-8, authors have mentioned that expiration
> time may be included
> 
> in the identity. That’s the reason we have not discussed the revocation
> issue in our draft.  If experts in this
> 
> group think we should address this issue, we can provide more
> information and details in the next draft.
> 

I generally agree with EKR's comments but I do think this is a
particular problem that needs to be addressed.  The security of a
mechanism like this depends on the ability to revoke compromised keys.
Your draft does not, in fact, include a key lifetime in the identifier
(and note that the timestamp is a MAY in RFC 6507).  If you decide to
include one it will probably need to be notably short in order to
provide any robustness against key compromises, which means that
rekeying and provisioning are going to be a practical problem that
may not be in scope for the draft but which will need to be addressed
in implementation and deployment.

I'm unenthusiastic about this draft but to the extent that there's a
hope to progress it, revocation really must be dealt with.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Melinda Shore]

On 12/5/18 7:27 AM, Salz, Rich wrote:
> That’s not the way it works.  When deciding whether or not to adopt
> something as a WG item, unless there is consensus to DO it, then the
> consensus is DO NOT do it.  There is no tie.  A decision was made, and
> by not adopting this work, the WG decided to NOT DO IT.

I'm going to split hairs here, since there are a few participants
in the discussion who aren't experienced in the ways of the IETF:
If there's no consensus then there's no consensus.  However, the
outcome, in this case, is very much the same.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] OID for delegated credentials

[Melinda Shore]

On 8/8/18 9:07 PM, Subodh Iyengar wrote:
> So far we've been doing interop with Cloudflare's OID of
> 1.3.6.1.4.1.44363.44.  I'd be fine with putting that as the final OID
> the draft. Does anyone have any thoughts on whether we should / should
> not do this and use a different OID instead.

One thing we've found is that it's inevitable that when an OID
is chosen from a private arc, it's raised as an issue during
various last calls, but I've never seen it be a show-stopper.

Melinda


-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Melinda Shore]

On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished. 

I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft or ambiguity.  Unfortunately there doesn't appear to
be one, so compromise is necessary.

I also think there's been already been a pretty serious process abuse
here and tend to think that the new implication that we can go forward
in a timely way if everybody just agrees with you is additionally
problematic.  But as I said earlier, I'll go along with the working
group consensus and will not block a decision I don't happen to like.
That's the implicit contract we sign with the IETF when we decide to
bring work here.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Melinda Shore]

And to be clear, it's not that nobody is going to implement the extension
(it's already been done in an IETF hackathon and elsewhere), the work on
the extension was funded by Mozilla, and there's been an outstanding
request for this in Bugzilla.  What's not being implemented is the proposed
changes.

But, it's clear that those guys don't intend to compromise and we're going
to be deadlocked pretty much forever unless someone does something.  That's
not going to be Viktor and it's not going to be the chairs, so I guess it's
me.

Melinda

On Thu, May 17, 2018, 16:20 Tim Hollebeek 
wrote:

> I’m actually fine with that.  You have to consider P_{extension
> implemented and used}.
>
>
>
> Different people will disagree about the value of P.
>
>
>
> -Tim
>
>
>
> *From:* Paul Wouters [mailto:p...@nohats.ca]
> *Sent:* Thursday, May 17, 2018 8:18 PM
> *To:* Tim Hollebeek 
> *Cc:* James Cloos ; Ted Lemon ; <
> tls@ietf.org> 
> *Subject:* Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
>
>
>
>
>
> On May 17, 2018, at 19:44, Tim Hollebeek 
> wrote:
>
> Making things more complicated with no obvious benefit just makes things
> more complicated.
>
> I oppose adding two bytes for some nebulous future purpose.
>
>
>
> The consequence of this opinion would be this:
>
>
>
> https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00
>
>
>
> Which is a lot of complexity for one TLS extension to define the behaviour
> of another TLS extension. And it still adds two bytes in the 2nd extension.
>
>
>
> So if you believe more simplicity is better, then you made the wrong
> choice.
>
>
>
>
>
> Paul
> ___
> 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] TLS DNSSEC chain consensus text, please speak up...

[Melinda Shore]

On 5/16/18 2:20 PM, James Cloos wrote:
> The sixteen bit field harms no one, and when defined and used provides
> significant benefit to many.

It is one of the peculiarities of the IETF (and engineers
in general, I guess) that when we sit down to design a
protocol most people will start talking about data formats,
etc. rather than protocol semantics.  Allow me to suggest
that that's a mistake, and that data formats are secondary
to the behavior we expect from a protocol and to the data
needed to support that behavior.  Don't make that mistake
here.

And again, nobody has said that they intend to implement
the proposed mechanism - indeed, when asked, people have
said that they won't.  So I'm not really clear on the
benefit.

I'm compromising as a process matter (this needs to get
done) and because it's clear that nobody else will.

Melinda


-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Melinda Shore]

We really need to get this published, and in the interest of
making progress I will not block the addition of two bytes
to the extension.  I am highly reassured by Viktor's suggestion
that they will never be used, as unused fields with murky
semantics have never been shown to be a problem in IETF
protocols.  (<- I don't actually believe that, but hey).
I disagree with adding these bytes but I can learn to live
with it.

Something that actually is a concern is that we now have
a working demonstration that refusal to compromise is an
effective strategy and that DOSing a document is a good
option if you can't otherwise convince other working group
participants.  This, however, is a problem for the chairs
and the IESG.

So, onward.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Melinda Shore]

On 5/15/18 8:22 PM, Viktor Dukhovni wrote:
> It just leaves
> the door open going forward, at negligible cost (two bytes on the
> wire in bandwidth, and zero in implementation).

I would be grateful if you would have a consistent story on this.
Clearly, it's not just two bytes, or there wouldn't be a perceived
need for them.  It's two bytes plus the associated semantics and
processing algorithms.  In the event that anybody has an interest
in implementing something along these lines the offer to work on
an extension to support it still stands.

At any rate, this horse is long-since dead, and you're veering
into abuse-of-process territory.  Your proposal has been discussed
at length on the list, it's been discussed at length off the list,
and there is still no consensus to modify the extension to support
your use case.  And as a reminder, "Rough consensus is achieved
when all issues are addressed, but not necessarily accommodated."

Melinda

-- 
Software longa, hardware brevis

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

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Melinda Shore]

We've had this discussion already, at terrific length.

To my knowledge it's still the case that nobody intends
to implement the proposed changes, and it's still the
case that should there be interest in implementing the
new functionality there's the option of a new extension.

At any rate this is starting to feel like abuse of process.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] Proposed text for dnsssec chain extension draft

[Melinda Shore]

On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it
> clear that the requested 16-bits are a reasonable consensus outcome.

Hi, Viktor:

This doesn't actually reflect the consensus called by the
chairs, as I understand what was posted.  It may be useful
to start work on a new draft describing your proposal.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/18/18 10:22 AM, Joseph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning
> and I do not think we currently have consensus to add pinning.  While I
> think it may be possible to come to consensus on pinning I think it may
> take some time.  I believe we can quickly get consensus for the
> following approach:
> 
> 1. Scope the document to the assertive use cases
> 2. Explicitly allow (but do not require) DoE be included
> 3. Remove current text about pinning
> 4. Re-submit the document for publication and start work on a separate
> extension that supports pinning

This sounds reasonable.  I'll talk with co-editors about text
changes.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/12/18 6:55 PM, Viktor Dukhovni wrote:
> If you'd like me to craft revised option (A) text, that includes a suitable
> caveat, I can try.  

I'm okay with putting denial-of-existence in there as a should,
but I do feel strongly that pinning belongs in a separate document.
As I  said earlier, I have a problem with putting features in protocols
that  nobody intends to use.  It's bad enough when it happens by
circumstance but doing it deliberately strikes me as a bad idea.

And while this may not be your problem, it's very much mine: this
kind of thing is bad for the IETF.  It discourages participation
(and, ironically, implementation) and it slows the process down
further, with no clear benefit (getting back to the implementation
question).  I've gotten an earful from several implementers about
this, and it concerns me.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/12/18 1:47 PM, Martin Thomson wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?

Clearly nothing, and I think this would be a reasonable way forward.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
> I'm waiting to see if anything else comes out of this thread.
> In particular, I am hoping that some authors/proponents of leaving the
> document in the RFC Editor queue would speak to the question of the
> target scope, given the arguments that have been presented regarding
> the risk/reward tradeoff of the current narrow scope.

I'm also waiting to see if something new comes up in the
discussion, but it seems at this point we're just rehashing
previous discussion and nothing much is changing.  In
particular, no new information is being contributed.

The one thing that could change my mind about this would be
if there was an intent to actually attack the problem described
in the changed scope (well, also if the proposed change could -
in fact - lead to the deprecation of the web PKI, but the chance
of that seems vanishingly small).  Absent that I really don't
like adding goo to protocols on the off chance that at some
unforeseeable point in the future there's a possibility that
someone might actually want to use that feature.  I think we've
got other ways of handling that eventuality and very little
assurance that it will ever happen, anyway.

Melinda


-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/10/18 3:53 PM, Nico Williams wrote:
> The earlier consensus is not just applicable, as if it were, we would
> not be having this LC.

I have no idea what that even means, to be honest.  We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've raised new issues.  So let's be
clear about that.

I've been watching this discussion and trying to get a handle
on what's been going on (and how this fits into several other
IETF issues more generally), and I think this discussion would
be over if the people arguing in favor of changing the use
of the extension had plans to implement it.  But so far nobody
has said that they do.  It's been suggested that if we intend to
stick with the original, intended use we can just ignore the extra
bytes, which strikes me as an exceedingly odd argument for including
new protocol features.

It's unfortunate that over in DNS-land they're discussing how
to get rid of unused features that increase complexity, while over
here we're having a discussion of how to add unused features that
increase complexity.

I think those of us who care about the institutional effectiveness
of the IETF and the value of the standardization process care
quite a bit about the amount of time it takes to push a document
through to publication.  Aside from negatively affecting the chances
of the success of a given protocol, it's harmful to the standards
process more broadly and discourages participation from people who want
to get work done.  There's an unfortunate number of IETF protocols that
people worked on for years and that never saw implementation, and
it seems to me that we ought to be trying to minimize the chances
of that happening with the protocols we're working on.  I haven't seen
anything in this discussion that leads me to believe that the
extension as specified is fundamentally broken or insecure for its
intended use.  I'm good with adding clarifying text or scoping it
more clearly, but beating this thing to death for a use case that
nobody intends to implement seems a bit misguided to me.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/4/18 2:53 PM, Richard Barnes wrote:
> I support publication of the document as is.  I would also be
> comfortable with a minor modification to say that TLSA certificate
> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.

The addition of text that clarifies that seems absolutely reasonable
to me.

I do think there would be a problem with adding additional complexity
to the extension to support functionality that nobody has said that
they intend to use (including the proponents of the changes), given
that the changes would not be introduced to correct an error in
the existing spec.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

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

[Melinda Shore]

On 3/13/18 10:44 AM, Kathleen Moriarty wrote:
> And then there are other options too, like another WG.  Even from
> Stephen's list of who is in agreement with him, I've received a few
> messages saying their text wasn't what he thinks it was.  More
> discussion here would be good to figure out a way forward.  The chairs
> have not agreed to allow the work to go forward, but just the
> discussions to determine next steps.

Part of the problem here, I think, is that it's not clear
what's under discussion - the general problem or this
specific draft.  I tend to think that discussions of the
general problem will probably be unproductive and
polarizing, and that if there is a way forward on this
it's to have credible and specific technical proposals.
Remember that in terms of process we don't need to have
unanimity on a decision, but all serious technical
objections need to be addressed and resolved.  So,
if someone has a draft that can eventually clear that
bar, proponents of allowing third parties to decrypt
TLS sessions have a way forward.  (Unfortunately I
don't think this draft can make it through).  At any
rate I would regret (a lot) seeing discussion meander
on over to the broader should-we-or-shouldn't-we question.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] TLS@IETF101 Agenda Posted

[Melinda Shore]

On 3/13/18 8:09 AM, nalini elkins wrote:
> I agree that the room hummed to "continue the discussion".

This might be a good time to review RFC 7282 ("On Consensus
and Humming in the IETF") so that everybody is more-or-less
on the same page with respect to what a roughly 50/50 split
hum means.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



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

Re: [TLS] TLS@IETF100: Agenda Requests

[Melinda Shore]

On 11/5/17 7:14 AM, Ted Lemon wrote:
> My point here is that that's not the reason to reject the document.  
> The reason in this case is that there already exist better ways to solve
> the problem, and the proposal would clearly make TLS 1.3 worse, even
> though there is disagreement about how /much/ worse it would make it.

Right, the question is about the technical merits of the proposal.
If I'm recalling correctly the widespread view of STUN when it was
first brought in was that it was revolting.  That may continue to
be the most widely-held view, but unlike the rhrd draft there was no
other workable solution at the time to an extremely pressing problem.
Anyway there's precedent for something most people don't like moving
forward and eventually being published as a standard if the technical
arguments are sound.

At any rate, the discussion of the proposal, if there is to be one,
belongs on the mailing list.  Having the discussion and coming to
a conclusion 1) during a meeting 2) where none of the proponents
is present seems like an abuse of process to me (not to mention a
waste of meeting time).  Furthermore it seems like the technical
merits of the rhrd proposal are thin enough that it's unlikely to
progress, anyway.

Melinda


-- 
Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
 AB36 FE18 57E9 6B9D A293



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

Re: [TLS] TLS@IETF100: Agenda Requests

[Melinda Shore]

On 11/2/17 8:40 AM, Salz, Rich wrote:
>> Due to some unforeseen circumstances neither author of
>> draft-rhrd-tls-tls13-visibility is able to attend IETF 100.  As a
>> result, they’ve withdrawn their request for agenda time.

> I think it would still be worthwhile to have time for the WG to see
> if it can come to consensus on whether or not to do anything in this
> area at this time.

Well ...  Decisions are made on the mailing list, not at meetings.
Either way, I don't think that it makes sense to try to come to a
decision on this without its advocates present.  I don't like this
proposal, and few other people seem to, and it seems to me that a
bunch of us sitting around telling each other that we don't like it
is probably not a very good use of meeting time.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
 AB36 FE18 57E9 6B9D A293



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

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

[Melinda Shore]

On 7/17/17 1:23 AM, Daniel Kahn Gillmor wrote:
> Could you point me (and the list) to those requirements, please?  More
> specificity than "some countries" would be a useful contribution to this
> discussion.

At the time when I was working on VoIP there were a few countries,
such as South Africa, which required that any media streams collected
as a result of a wiretap order be handed over in the clear.  But this
was 20 years ago and things may or may not have changed.  That said,
I expect their requirements can be met by having operators in those
countries stick with TLS 1.2.

There are things that would surprise me more right now than having
proponents of weakening TLS 1.3 come back with a list of countries.
Such as, for example, having representatives from service providers
in those countries show up with requirements - that would surprise me,
given that they haven't yet and that getting TLS 1.3 done has been a
lengthy effort.

At this point the request to add the static D-H proposal to TLS 1.3
strikes me as unreasonable, even given what are frankly vague
references to countries requiring that data be decrypted before being
handed off to law enforcement or the government.

Melinda

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

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

[Melinda Shore]

On 7/16/17 7:55 AM, Salz, Rich wrote:
> I am not offended.  I am saying that if it terminates the connection it
> is an endpoint not a middlebox.

Well, maybe.  That's certainly the general understanding of middleboxes
(i.e that they they are not directly addressed [well, NATs, but] and
that they don't terminate traffic) but even way back when we did the
original midcom work and produced 3234 (hard to believe it's been 15
years) there was some mushiness around transparency being a requirement
for being considered a middlebox.  For example, from 3234:

   Note that HTTP proxies do in fact terminate an IP packet flow and
   recreate another one, but they fall under the definition of
   "middlebox" given in Section 1.1 because the actual applications
   sessions traverse them.

However, that's not really a description of the behavior of CDNs -
HTTP sessions really do terminate on cache nodes.

That said, I'm not sure how this helps sort out the question of what
(if anything) needs to be done to satisfy monitoring requirements in
some deployments.

Melinda




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

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

[Melinda Shore]

On 7/15/17 4:01 PM, Sean Turner wrote:
> draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday
> because that’s the only time Melinda can make.

No, I'm afraid that I *cannot* make it Monday, and need to have
our slot stay on Wednesday.

Melinda



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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Melinda Shore]

Thanks for the careful review, Ilari.  It's a long weekend in the US
but we'll get some proposed text out mid-to-late this week.

Melinda



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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Melinda Shore]

On 4/24/17 7:39 AM, Hannes Tschofenig wrote:
>> There is enormous amount of red tape obtaining intermediates, even
>> technically constrained ones. And as consequence, it is enormously
>> expensive (through not nearly as expensive as public CA).
> In essence you are doing this through the extension as well just using a
> different format.

In some sense the proposal is about having a trusted issuer who's not
included in public trust stores, which is a reasonable goal (there's
a fantastic amount of work, including external audits, in having
your intermediate included in browser trust stores, etc.).  We haven't
had a good delegation story since, like, ever, but now there's a
somewhat compelling use case (CDNs) that needs attention and will
benefit from a solution.

Melinda




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

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

[Melinda Shore]

On 4/12/17 11:31 AM, Sean Turner wrote:
> At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on
> the list so please let the list know whether you support adoption of
> the draft and are willing to review/comment on the draft before
> 20170429.  If you object to its adoption, please let us know why.

I support its adoption (for whatever it's worth I work for a
CDN) and would be happy to review the draft before the end of
the month.

Melinda



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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Melinda Shore]

Thanks for the thorough review, Viktor.  I'll get the straightforward
bits into the draft over the weekend and plan on discussing the ones
proposing changes to the extension or to chain construction and
processing in the working group session.

Melinda



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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Melinda Shore]

Thanks - I've updated those, as well.

Our sense right now is that the pieces that need completion
prior to going to working group last call are to add
some pseudocode to clarify construction of the chain, and
test vectors.  The draft could definitely benefit from
additional review.

Thanks,

Melinda



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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Melinda Shore]

On 3/21/17 4:20 PM, Eric Rescorla wrote:
> SUBSTANTIVE
> 
>Servers receiving a "dnssec_chain" extension in the client hello, and
>which are capable of being authenticated via DANE, SHOULD return a
>serialized authentication chain in the Certificate message, using the
>format described below.  The authentication chain will be an
>extension to the certificate_list to which the certificate being
>authenticated belongs.
> 
> In TLS 1.3, the extensions are attached to the certificates, so you
> need to say which one. I assume end entity. You could also shove
> this in EncryptedExtensions, one supposes.
> 
> 
> EDITORIAL
> You should replace "client hello" with ClientHello throughout.

Thanks, EKR.  I've updated the draft based on these comments and
will submit it once submissions reopen.

Melinda





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

Re: [TLS] Industry Concerns about TLS 1.3

[Melinda Shore]

On 9/28/16 4:36 PM, Tony Arcieri wrote:
> The IETF is doing great work. This entire thread is a distraction, and I
> hope it does not result in changes which weaken TLS 1.3's security.

I think it's quite clearly the case that that is not going to happen.
But, that doesn't mean that these guys don't have a problem worth
addressing, even if they're asking for a crap solution to it.  The
IETF is an insular organization and I tend to think that leads to
poorer outcomes in some cases than we might otherwise have produced.

I am not suggesting that his request for a protocol that he
can break needs serious consideration, but that the fact that he's
come up with an unacceptable solution to a problem that he's
identified doesn't mean that the problem either doesn't exist or
is completely outside the IETF's scope.

All that's going to come out of discussion here is unhelpful
and largely redundant finger-wagging.  I think these guys ought
to write up the problem they've got and post a draft.

Melinda




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

Re: [TLS] Industry Concerns about TLS 1.3

[Melinda Shore]

On 9/28/16 3:08 PM, Bill Frantz wrote:
> On 9/28/16 at 2:01 AM, m...@sap.com wrote:
>> I'm sorry, but I'm still violently opposed to the IETF endorsing
>> backdooring of security protocols.
> I find myself in violent agreement with Martin, and many others in the
> IETF.

This seems uncontroversial and frankly somewhat low-information.
Yay, crypto backdoors are bad.

That said, IETF participation is dominated by large equipment and
software vendors and the problem space, at least until recently
(there's been a crop of data center-related problems coming up in
OPS and routing), has tended to cover service provider-related
questions.  We have poor participation and representation from
enterprise networks.  So now we've got someone showing up from
the enterprise space and saying "I have this problem related to
protocol changes."  And yeah, he's very, very late in this
process, although it's worth pointing out that it's in the best
tradition of the IETF to deal with technical problems that crop
up with documents at any point in their development.

It seems to me that the discussions of alternatives to modifying
the protocol to meet his needs has been extremely helpful, and it
also seems to me that in some sense this ought to be an object
lesson to large enterprises dealing with fairly sophisticated
protocol problems that they really need to get involved and make
their requirements known.  If there's a need here for a new
monitoring framework that doesn't involve compromising the
security of IETF protocols, that strikes me as an interesting
question.  In the meantime I'd hate to see this level of hectoring
continue - we need more participation from other kinds of network
operators, not less.

Melinda




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

[TLS] draft-shore-tls-dnssec-chain-extension

[Melinda Shore]

Hi, all:

We haven't been pushing on this because we recognize that getting
TLS 1.3 published is top priority, but we've got a new version
posted 
(https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02)

that addresses many of the concerns raised both here and on the DANE
mailing list, including encoding the validation chain within the
extension in DNS wire format.  Once things quiet down a bit we plan
to ask the working group to adopt the draft for publication.

Thanks,

Melinda et al.

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

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Melinda Shore]

On 10/21/15 8:13 AM, Benjamin Kaduk wrote:
> I don't think that's quite the point I was trying to make.  HTTPS is
> HTTP layered on top of TLS, yes, but in order for there to be a
> separation of layers, TLS should not include any data structures that
> are only useful for the HTTPS case.  This document seems to add a field
> to TLS that is only used in the HTTPS use case, which seems like a
> layering violation to me.

In fairness you can express all sorts of endpoint addresses
as URLs, not just http.  That said I agree that this is not
an attractive proposal - the performance improvement over
existing redirect models is marginal, there may be some
unpleasant middlebox interactions, and it would require
API changes.  The cost/benefit tradeoff isn't favorable,
on balance.

Melinda

-- 
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net

"Software longa, hardware brevis."

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